DEV Community: Miro Ma

Why the Same AI Model Can Feel Completely Different Across Coding Agents

Miro Ma — Tue, 08 Sep 2026 10:35:14 +0000

A while ago, I tried building my own coding agent.

My goal was not to compete with Claude Code or other mature coding agents. I simply wanted to reach what I personally considered a level where the agent was reliable enough to handle real development tasks.

After a lot of work, it eventually reached the point where it could complete many ordinary tasks.

Then I started running benchmarks.

That was when I realized that getting an agent to work and getting an agent to work reliably are two very different problems.

The deeper I went, the more convinced I became of one idea:

The model determines the capability ceiling of an agent, but the runtime determines how much of that capability is actually realized.

Eventually, I started thinking about agents in another way:

An agent is a bounded optimization process.

Here is how I arrived at that conclusion.

1. From a Phrase-Driven Loop to a Task-Driven Runtime

My first implementation was relatively simple.

Conceptually, the loop looked something like this:

Model says what it wants to do
        ↓
Runtime executes it
        ↓
Model sees the result
        ↓
Runtime follows the next instruction

I think of this as a phrase-driven agent.

The runtime is largely following what the model says from one turn to the next.

This can work surprisingly well for simple tasks.

But anyone who has used LLMs extensively has probably seen the failure modes:

the model drifts away from the original task,
repeats something it has already done,
forgets earlier state,
believes an operation succeeded when it did not,
or declares completion too early.

I later changed the architecture toward something more task-driven:

What is the current task state?
        ↓
What is still missing?
        ↓
Execute the next step
        ↓
Verify the result
        ↓
Update task state
        ↓
Continue

The important difference is that the runtime no longer advances purely because the model produced another instruction.

It advances according to the state of the task.

That change noticeably improved stability.

But it also made me realize how much engineering sits between an LLM and a reliable coding agent.

Eventually, I stopped trying to build the whole thing myself.

Not because the model was incapable of writing code, but because the runtime itself had become a serious systems-engineering problem.

2. What Building With AI Taught Me About Software Engineering

Modern coding models make it possible for an individual developer to build things that would previously have required far more time or a larger team.

If your objective is:

“Get something running first.”

AI is extremely effective.

A website, a prototype, a demo application, or an early version of a product can often be built much faster than before.

But the situation changes when the goal becomes:

Stable, production-ready, and maintainable for years.

The larger the codebase becomes, the more important architecture, constraints, review and verification become.

AI continues to help, but raw code generation stops being the main bottleneck.

I repeatedly ran into three problems.

2.1 AI Can Generate Technical Debt Extremely Quickly

AI is very good at solving the immediate problem in front of it.

A bug appears here:

Add another condition.

A state mismatch appears somewhere else:

Add a fallback.

Another integration breaks:

Add a compatibility path.

Each individual change can look reasonable.

But after dozens of iterations, the accumulated result can look very different:

duplicated logic,
temporary state that became permanent,
overlapping compatibility layers,
excessive fallbacks,
abstractions wrapping other abstractions,
and code whose original design intent is increasingly difficult to recover.

This happens partly because understanding a large repository is still a retrieval problem.

An agent normally sees only a subset of the codebase at any particular moment. It searches, reads files, follows symbols, retrieves additional context and progressively constructs a picture of the system.

That picture is necessarily incomplete.

Without deliberate refactoring and architectural control, local fixes accumulate.

One of the strongest lessons I took away from this was:

AI dramatically increases the speed of code generation, but if architecture, review and refactoring do not keep pace, it can generate technical debt at roughly the same speed.

2.2 Your Ability to Evaluate the Result Still Matters

This became increasingly obvious as my project became more complex.

Suppose the problem requires knowledge beyond your own current ability.

The AI produces a solution.

Now you still have to answer:

Is the architecture actually reasonable?
Did it really fix the bug?
Did it merely work around the bug?
Is the test meaningful?
Is the system now more fragile?
Is there a better abstraction?
What should be done next?

If you cannot evaluate those questions, development becomes increasingly difficult.

A common response is:

“Just use a stronger coding model.”

I spent thousands of RMB experimenting with different frontier models.

There were absolutely differences between them.

Some planned better. Some followed instructions more reliably. Some handled large refactors better. Some were more consistent with tools.

But none of them eliminated the fundamental problem:

The complexity of the project you can safely build is still influenced by your ability to understand and evaluate what is being built.

A stronger model expands that boundary.

It does not make evaluation unnecessary.

2.3 Complex Software Depends More on Constraints Than Cleverness

Large systems usually do not remain reliable because one function is exceptionally intelligent.

They remain reliable because they have structure:

clear module boundaries,
stable interfaces,
explicit state transitions,
controlled dependencies,
type constraints,
tests,
invariants,
and layers that compose in relatively predictable ways.

If the entire architecture is continuously delegated to AI without strong constraints, something interesting happens.

In one context, the model may conclude that architecture A is best.

Later, with a slightly different context, architecture B appears more attractive.

Several iterations later, architecture C gets introduced to solve problems created by the previous two.

Add incomplete context, model variation and occasional hallucination, and architectural drift becomes easy.

This is why I increasingly think the important question is not:

“How much code can the model generate?”

but:

“How tightly can we constrain the system so that generated changes remain coherent?”

3. Why the Same Model Behaves So Differently Across Agents

This was the question that became much more interesting to me after building an agent myself.

People often assume that if two products use the same underlying model, their coding ability should be roughly equivalent.

For example:

Same Claude model
or
Same GPT model
or
Same Gemini model

So perhaps the only meaningful differences are the UI and a few extra tools.

In practice, that is nowhere near the whole story.

While testing my own Rust-based agent runtime, I encountered problems in almost every part of the execution pipeline.

3.1 Tool Calling

Tool calling sounds straightforward until you build it.

You have to deal with things such as:

argument parsing failures,
schema differences,
provider-specific behavior,
inconsistent tool outputs,
malformed responses,
partial execution,
retries,
and determining whether a tool actually succeeded.

If the runtime records a failed operation as successful, the model starts reasoning from a false state.

Everything after that can be wrong.

3.2 Task State

A coding agent may contain conceptual stages such as:

Planning
    ↓
Execution
    ↓
Verification
    ↓
Completion

If one transition is incorrect, the agent can stop even though obvious work remains.

Or it can continue executing after the task is already complete.

The model itself may be perfectly capable of performing the next step.

The runtime simply never gives it the opportunity.

3.3 Repeated Execution and Infinite Loops

If previous actions are not represented correctly in state, an agent may:

read the same file repeatedly,
apply the same modification repeatedly,
rediscover the same plan,
retry an impossible action,
or cycle between two states.

Loop detection sounds like a small runtime detail.

During long tasks, it becomes essential.

3.4 Completion Detection

When exactly is an agent finished?

If the completion condition is too permissive:

Model: Looks good. Done.

the task may stop before the code is actually working.

If it is too strict, the opposite happens.

The build passes, tests pass and the requested change is complete, but the runtime continues looking for more work.

Reliable stopping conditions are surprisingly difficult.

3.5 Context Pollution

Long-running coding tasks generate enormous amounts of information:

terminal output,
compiler errors,
logs,
tool results,
plans,
failed attempts,
code,
diffs,
previous messages.

Keeping everything is not a solution.

Even very large context windows are finite, and more context does not automatically mean better context.

Eventually, irrelevant information starts competing with important information.

3.6 Error Recovery

Suppose:

the model stream disconnects,
a provider returns an error,
a tool fails,
a file write partially succeeds,
or the environment changes unexpectedly.

What should happen?

Should the agent:

retry?
continue from the existing task state?
roll back?
re-plan?
retrieve the environment again?
restart the entire task?

Each strategy has trade-offs.

And every recovery strategy changes the information available to the next model call.

3.7 Retrieval Changes Intelligence

Consider two coding agents using exactly the same model.

Agent A can:

read precise file ranges,
search symbols,
inspect references,
retrieve repository structure,
make targeted edits,
inspect diffs.

Agent B has only a few coarse tools and sometimes returns inconsistent results.

On paper, both agents have the same “brain.”

In practice, they are reasoning about different worlds.

The difference becomes even clearer with code retrieval.

One agent may effectively rely on:

grep -R "something" .

Another might combine:

repository maps,
symbol indexes,
reference graphs,
LSP information,
semantic retrieval,
dependency relationships.

The second agent can often place the same code inside a much more accurate structural context.

The underlying model has not changed.

The evidence provided to it has.

And that changes its reasoning.

3.8 Small Differences Compound Over Long Tasks

This is probably one of the most important observations I made.

Imagine two agents starting from the same model and the same task.

Agent A retrieves slightly better information during step one.

That means its decision during step two is slightly better.

That changes which file it reads during step three.

That changes what it edits during step four.

That produces a different compiler result during step five.

Now the two agents are operating from different states.

Run this loop for dozens of iterations and the trajectories can diverge dramatically.

So the phenomenon:

“This model feels amazing inside Agent A but strangely stupid inside Agent B.”

is not surprising at all.

The model may be identical.

The execution trajectory is not.

3.9 Context Engineering

After experimenting with this problem, context engineering became one of the areas I consider most important in agent design.

A long-running agent must simultaneously make the model remember important things and prevent the context from becoming polluted.

That requires constant decisions:

What should remain permanently?

Which history is no longer relevant?

What can be compressed into one sentence?

Should failed reasoning remain in context?

Should a tool result be stored verbatim or summarized?

Which pieces of code should stay available?

Which ones should be retrieved again when necessary?

Every decision changes future model behavior.

Again, small differences accumulate.

Over a task containing dozens or hundreds of interactions, context policy can significantly change the final result.

3.10 Verification Changes Everything

There is a huge difference between an agent that stops after:

“I believe the issue is fixed.”

and one whose loop looks more like:

Modify
   ↓
Inspect diff
   ↓
Build
   ↓
Run tests
   ↓
Inspect failures
   ↓
Fix again
   ↓
Verify

The second agent may appear significantly more intelligent.

But part of that apparent intelligence comes from the runtime forcing the model to collect evidence.

This applies to many other runtime components as well:

search budgets,
task-state management,
tool design,
loop detection,
permission systems,
recovery policies,
model-specific prompts,
verification requirements.

The visible “intelligence” of an agent is an emergent result of the whole system.

4. An Agent Is a Bounded Optimization Process

This eventually led me to a mental model that I now find useful.

At every step, an agent is effectively trying to choose a better next action based on the state it currently understands.

It might decide to:

search the repository
read another file
inspect a symbol
call a tool
modify some code
run the compiler
execute tests
collect more evidence
stop

But the agent never has perfect knowledge of the environment.

Its repository view is incomplete.

Tool results may contain noise.

Context is limited.

Search costs time and tokens.

Execution has side effects.

And the current state may itself contain incorrect assumptions.

So the agent is not solving a fully observable global optimization problem.

It is repeatedly making local decisions with incomplete information under constraints.

That is what I mean by:

Agent = bounded optimization.

Once you look at agents this way, many runtime features start to look different.

A search budget is not merely an implementation detail.

It defines how much evidence the optimizer is allowed to gather.

Loop detection prevents the optimization process from getting trapped in cycles.

Verification changes the effective objective from:

produce a plausible answer

to something closer to:

produce an answer that survives external evidence

Context management determines which approximation of the current state the optimizer gets to see.

And stopping conditions define when the optimization process is considered sufficiently converged.

Seen from this perspective, much of agent engineering is really about defining the boundaries of that optimization process.

5. Stronger Reasoning Does Not Automatically Mean Better Convergence

There is another interesting consequence.

A more capable reasoning model does not automatically produce a more reliable agent.

Without appropriate constraints, a stronger model may:

search more,
explore more branches,
call more tools,
generate more hypotheses,
and continue reasoning for longer.

That can be extremely useful.

But without search budgets, stage boundaries, loop detection and stopping conditions, it can also make convergence harder.

In other words:

Better exploration is useful only if the system can eventually turn exploration into convergence.

This is why agent engineering cannot be reduced to simply inserting a stronger model into an existing loop.

A stronger model gives the agent a larger and potentially better search space.

The runtime still has to guide that search toward a useful result.

6. The Agent Is the Whole System

After building one myself, I no longer think of a coding agent as simply:

“An LLM with tools.”

The actual product is closer to:

Model
+ Context Engineering
+ Retrieval
+ Tools
+ Task State
+ Execution Loop
+ Verification
+ Error Recovery
+ Permissions
+ Model Adaptation
+ Stopping Conditions

All of these components shape the model's future observations and actions.

Together, they determine whether the system eventually reaches a useful result.

So my current summary is:

The model determines the capability ceiling. The runtime determines how much of that capability can be realized reliably.

Or, from the optimization perspective:

The model provides the intelligence to search the solution space. Agent engineering defines the boundaries that make that search converge.

That is why the exact same model can feel dramatically different depending on the agent around it.

The brain matters.

But so does the rest of the system.

How to Use Android as a Remote IDE with Tailscale + NimoteCode: Free SSH Access to Mac & Linux Over the Public Internet

Miro Ma — Fri, 04 Sep 2026 08:39:35 +0000

This short guide shows how to connect NimoteCode on Android to a Mac or Linux machine through Tailscale and SSH. You do not need a public IP address or router port forwarding.

macOS: install Tailscale from the command line

First, check whether Homebrew is installed:

brew --version

If Homebrew is not installed, install it first:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Install Tailscale:

brew install --cask tailscale

Launch Tailscale:

open -a Tailscale

The first launch opens a sign-in page. Sign in with your Tailscale account, then find this Mac's Tailscale IPv4 address:

tailscale ip -4

You will usually see an address similar to:

100.80.12.34

Confirm the connection status:

tailscale status

macOS: enable SSH

Enable Remote Login:

sudo systemsetup -setremotelogin on

Confirm that it is enabled:

sudo systemsetup -getremotelogin

The output should be:

Remote Login: On

You can also test SSH locally. Replace your_username with your macOS username:

ssh your_username@localhost

Linux: command line only

Linux does not need a GUI. Install the Tailscale client and service once, then let it run in the background. For Ubuntu or Debian, run:

curl -fsSL https://tailscale.com/install.sh | sh

Start Tailscale and sign in:

sudo tailscale up

The command shows a sign-in URL; open it in a browser to authorize the device. Then check the Tailscale IP and status:

tailscale ip -4
tailscale status

Linux servers are a particularly good fit for this workflow: install once → run in the background → usually no further attention required. In NimoteCode, use that 100.x.x.x address, port 22, your Linux username, and your password or SSH key.

Android: install Tailscale and connect NimoteCode

Search Google Play for Tailscale, install it, and then:

Open Tailscale.
Sign in with the same account used on your Mac.
Turn on the connection.
Confirm that your Mac appears in the device list.

Next, open NimoteCode on Android and create a new SSH connection:

Host: 100.x.x.x
Port: 22
Username: your macOS username
Auth: Password or SSH Key

Replace 100.x.x.x with the address returned by tailscale ip -4 on the Mac.

Finally, turn off Wi-Fi on your phone and test once over 4G/5G. If NimoteCode can still connect to the Mac over SSH, you have successfully set up:

Android phone → Tailscale → home or office Mac → SSH

Use your Tailscale connection in NimoteCode

Tailscale gives your Android device and Mac or Linux machine a private network path. NimoteCode turns that private SSH connection into a complete mobile development workspace.

After creating the connection in NimoteCode, you can:

Open the remote project root and browse it with Explorer instead of memorising paths.
Edit source files directly on the Mac or Linux machine from your phone or tablet.
Run tests, builds, Git commands and diagnostics in the integrated SSH terminal.
Review Git diffs, branches and commits before you ship a change.
Use AI Chat and Agent alongside the remote project, terminal output and code context.

This is the difference between having remote access and being able to complete real development work away from your desk. Tailscale handles the secure private route; NimoteCode keeps the files, editor, terminal, Git review and AI assistance in one place.

What this setup gives you

With Tailscale and NimoteCode, you can securely work from Android even when your devices are on different networks—without exposing SSH directly to the public internet or configuring router port forwarding.

Can an AI Agent Really Code From a Phone?

Miro Ma — Sun, 30 Aug 2026 13:58:04 +0000

This is a real AI Agent demo inside NimoteCode.
Starting from an almost empty workspace, the AI Agent plans the task, creates and edits code, runs commands, verifies the result, and finally commits the changes.
Everything happens directly inside NimoteCode — a mobile SSH IDE built for developers.
✅ Long-running AI coding tasks
✅ SSH remote development
✅ Terminal + Git + Code Editor
✅ Automatic verification and code commits
NimoteCode is available now on Google Play, with the App Store version coming soon.
Search NimoteCode and start coding anywhere.

Agent Design is Bounded Optimization, Not Intelligence

Miro Ma — Sun, 05 Jul 2026 23:16:43 +0000

🧠 Introduction

AI agents are often described as intelligent systems.

However, after building and iterating multiple agent systems, a different pattern becomes clear:

An agent is not intelligence.
It is a bounded optimization process operating over partial information.

1. Formal View of an Agent

We can define an agent policy as:

π∗=argπmaxE[R(τ)]

Where:

( \pi ): policy (decision function)
( \tau ): trajectory (sequence of actions + observations)
( R ): reward function

At each step, the agent selects:

at=argamaxE[Q(st,a)]

2. The Real-World Constraint

In real systems, the assumptions above break:

State ( s_t ) is partially observable
Rewards are sparse and delayed
Tool outputs are stochastic and noisy
Environment is non-stationary

So the agent is not solving global optimization.

Instead, it performs:

local greedy optimization over incomplete state

3. Why Agents Fail: Looping Behavior

A key failure pattern emerges in practice:

repeated file reads
redundant tool calls
over-exploration of same context
non-terminating reasoning loops

Why does this happen?

Because locally:

every action still has positive expected utility

So from the agent’s perspective:

continuing to explore is always “reasonable”

This leads to optimization loops.

4. The Missing Dimension: Termination

Most agent designs focus on:

reasoning capability
tool usage
planning quality

But ignore a critical axis:

When should the agent stop?

Without termination control, the system degenerates into:

infinite exploration
tool loops
unstable execution trajectories

5. Agent Design Space

Agent behavior is fundamentally a trade-off between:

Exploration (gathering information)
Exploitation (executing actions)
Termination (converging output)

We can think of this as a constrained optimization system rather than pure reasoning.

6. Bounded Optimization Perspective

A more accurate formulation is:

Intelligence = optimization
Agent = bounded optimization
Engineering = defining the bounds of optimization

These bounds include:

exploration budgets per module
loop detection mechanisms
phase separation (analysis → planning → execution)
early stopping heuristics

7. Key Insight

An important observation from practice:

Improving reasoning alone often increases instability.

Because stronger reasoning tends to:

increase exploration depth
increase tool invocation frequency
delay convergence

Without proper constraints, this leads to worse system behavior.

🧩 Conclusion

An agent is not a system that “thinks better”.

It is a system that:

optimizes under constraints and knows when to stop optimizing

I built a mobile IDE with ~90% AI-generated code — but it still took me 6 months

Miro Ma — Sat, 20 Jun 2026 13:55:31 +0000

I recently shipped a mobile IDE on Google Play.

~90% of the code was generated with AI tools. I handled architecture, product decisions, testing, and iteration.

From the outside, this sounds like it should be fast.

But in reality, it still took around 6 months of continuous work.

What AI actually helped with

AI significantly accelerated:

boilerplate code
UI implementation
feature scaffolding
refactoring suggestions
debugging assistance

It reduced the time spent on writing code line by line.

But what still took time

Even with heavy AI usage, a large amount of time was still spent on:

system design and architecture decisions
ensuring correctness across features
testing UI behavior across edge cases
fixing inconsistent AI-generated logic
integrating complex workflows (SSH, Git, remote execution)

The key reality

For complex applications, AI doesn’t remove the hard parts of development.

It shifts the workload.

Instead of writing code, you spend more time:

validating outputs
correcting assumptions
defining constraints clearly
repeatedly testing real-world behavior

What I learned

AI today is extremely good at speeding up implementation.

But it is still far from replacing:

system-level thinking
product decisions
correctness guarantees
end-to-end testing

In practice, it feels less like “AI builds software for you”
and more like AI increases your throughput as a developer.

The app

The result of this process is a mobile IDE:

SSH remote development environments
Git workflow support
mobile code editing
AI-assisted coding features

It’s now live on Google Play:
https://play.google.com/store/apps/details?id=com.nimote.nimotecode&pcampaignid=web_share

Final thought

AI didn’t reduce the need for developers.

It changed what developers spend time on.

Is Local Heavy Compilation Dead? The Rise of 2026 AI-Agentic Mobile IDEs 🚀

Miro Ma — Fri, 12 Jun 2026 07:38:33 +0000

Let’s be honest: until recently, the phrase "Mobile IDE" felt like a bad joke.

Who in their right mind would want to squint at a tiny tablet screen, fighting with heavy Gradle or Xcode compilations that turn an iPad into a literal frying pan? We all agreed: Real developers need heavy local hardware.

But it’s 2026, and the paradigm has completely broken.

Mobile IDEs are no longer just "code editors on a tablet"—they have evolved into the ultimate "Thin-Client Windows" powered by autonomous AI Agents and Full-Stack Cloud Containers.

🛠️ The 2026 Shift: Three Core Pillars

1. From "Copilot Chat" to "Agentic Engineering"

In 2024, we had chat windows for code autocompletion. In 2026, we have Autonomous AI Agents.
Modern Mobile IDEs feature background agents that scan your entire repository, read error logs, write tests, and deploy fixes inside cloud sandboxes without constant developer typing.

2. Multi-Modal "Visual Edits" (Goodbye, heavy typing!)

Typing code on a touchscreen sucks. The solution? Direct UI Manipulation.
You can now directly tap or drag a UI component on your tablet preview. The AI Agent instantly maps that visual component to the underlying declarative code (SwiftUI, Jetpack Compose, or Flutter) and modifies it in real time.

3. 100% Cloud-Native + WASM Previews

Local hardware constraints are neutralized. Heavy compilation, bundling, and dependency matching are completely offloaded to ultra-fast, ephemeral cloud containers. Your mobile device is just a low-latency rendering engine running WebAssembly.

📊 Paradigm Shift: 2024 vs 2026 Mobile Development

To understand how drastically this changes our daily workflow, here is a quick breakdown:

Dimension	2024 (Traditional Dev)	2026 (Agentic & Cloud-Native)
AI's Primary Role	Simple autocomplete & chat	Autonomous engineering & self-healing bugs
Core Interaction	Heavy keyboard typing / Ext. Monitor	Natural language + Multimodal Visual Edits
Compilation	Battery-draining local hardware	100% offloaded to scalable Cloud Containers
Barrier to Entry	Pro-code mastery required	Hybrid (Low-Code/AI-Generated architecture)

🔥 Is Local Compilation Dead?

We are moving away from the "Bring Your Own Heavy Laptop" era. When the cloud handles 99% of the heavy lifting and AI handles the syntax, a high-bandwidth network and a portable screen are all you need.

What do you think? Are you still refusing to code without your multi-monitor desktop setup, or have you already used an iPad/folding screen to fix a critical production bug on the go?

Let's argue in the comments below! 👇

Maybe the real limitation isn’t AI coding… 🤖 but the fact that developers still expect 100% deterministic control over every line of code. That mindset might be the real bottleneck Or are we just not ready for non-deterministic workflows yet? 👀 Thoughts？

Miro Ma — Fri, 12 Jun 2026 03:44:18 +0000

SSH + mobile coding is still broken — so I built my own IDE

Miro Ma — Thu, 11 Jun 2026 15:17:34 +0000

I’ve tried a lot of mobile coding tools—SSH apps, code editors, cloud IDEs.

Most of them feel useful… but incomplete.

They either:

only edit code
or only provide a terminal
or feel like a desktop tool squeezed into a phone

But real dev work isn’t just “writing code”.

It’s:

SSH + files + terminal + git — all together.

So I started building a mobile-first IDE called NimoteCode.

The idea is simple:

A workspace should include everything — not separate apps.

Local & SSH workspaces
Integrated terminal
Code + project structure in one place
Mobile-first UX (not desktop copy)

Still early, but it’s currently in testing phase on Google Play.

If you want to try it or give feedback, you can join the testing program here:

🚀 Try NimoteCode (Closed Beta)

NimoteCode is currently in closed testing on Google Play.

If you’re interested in mobile development workflows (SSH, coding, terminal, and workspace-based development), you’re welcome to try it and share feedback.

Join the tester group

https://groups.google.com/g/nimotecode-testers

Wait for access to activate

It usually takes a few minutes after joining.

Install via Google Play

https://play.google.com/store/apps/details?id=com.nimote.nimotecode

⚠️ Notes
Please use the same Google account for both Google Groups and Google Play
If the app doesn’t show up immediately, wait a bit and refresh
This is still early — expect rough edges

Feedback from real usage (especially SSH + mobile workflows) would be very valuable.

👉 Do you think mobile development is actually usable today, or still fundamentally fragmented?

Why Existing Flutter Code Editors Broke Down When I Built a Mobile IDE

Miro Ma — Thu, 11 Jun 2026 07:41:13 +0000

When I started building NimoteCode, I didn’t plan to write a code editor.

My assumption was simple:

Flutter already has code editor packages. I would just pick one and move on.

There are several solid options:

code_text_field
flutter_code_editor
re_editor

They all solve a similar problem well:

How to display and edit code inside Flutter.

So I did what most people would do:

I tried to integrate one of them and focus on the “real product”:
SSH, terminal, Git, AI workflows.

That assumption broke quickly.

The problem wasn’t “editing code”

It was this:

I wasn’t building a code editor.

I was building a mobile IDE.

And those are fundamentally different systems.

Where existing editors start to break

On paper, existing Flutter editors look complete:

syntax highlighting
folding
autocomplete
basic selection handling

But once I connected real IDE features, cracks started to appear:

SSH remote files instead of local strings
LSP needing full document lifecycle sync
Git diff depending on editor state
multi-panel UI sharing the same document
large files streamed instead of loaded

At that point, the editor is no longer a component.

It becomes shared infrastructure.

The key architectural difference

The real shift is this:

Most editor packages are built around text rendering.

A mobile IDE needs an editor core.

That difference changes everything.

Instead of “a widget that edits text”, you need:

a document model
a layout system
a state engine
a sync layer for external systems

Once multiple systems depend on the editor state, it can’t be passive anymore.

It must become the source of truth.

Why I eventually had to build my own editor

The decision wasn’t about performance or missing features.

It was about control over the model.

Existing editors assume:

local text
single-file context
UI-driven updates

My requirements were different:

local + SSH remote files unified
LSP lifecycle tightly bound to editor state
Git diff tracking per tab lifecycle
large files streamed in chunks
mobile-first selection and interaction model

These constraints conflict with widget-level architecture.

So instead of extending an editor, I rebuilt the core abstraction.

What I built instead

The new editor architecture is built around a shared core:

EditorState as single source of truth
FileLoader abstraction (local + remote)
Streaming file ingestion for large files
Tree-sitter + LSP hybrid analysis pipeline
diff + CodeLens + symbols bound to document model
mobile-first selection and coordinate system

The key idea:

Everything depends on the same document model.

Not the UI.

The real advantage of self-building

Rewriting the editor wasn’t about “adding features”.

It unlocked structural advantages:

1. Remote-first is native, not patched

SSH files are not adapters — they are first-class documents.

2. LSP becomes part of lifecycle

Not a separate service, but synchronized with editor state.

3. Git diff becomes state-aware

Not snapshot-based, but tab-aware.

4. Mobile editing is designed, not adapted

Selection, handles, scrolling all operate on a custom coordinate system.

5. All IDE features share one model

No duplicated state between panels.

This is where complexity actually decreases long-term.

The conclusion I didn’t expect

I originally thought:

I will save time by using an existing editor.

But the real outcome was the opposite:

Using an existing editor would have shifted complexity elsewhere.

Because the real problem wasn’t syntax highlighting.

It was system design.

And once you treat the editor as infrastructure instead of a widget, rebuilding it becomes the simplest consistent choice.

Final thought

I didn’t replace a code editor.

I replaced the assumption that a code editor is enough for a mobile IDE.

Why I Decided to Build a Mobile IDE Instead of Another AI App

Miro Ma — Tue, 09 Jun 2026 10:38:17 +0000

I used to work at a company, focusing on low-level system development. The work was technically solid but often felt fragmented. Over time, I realized I was mostly working within narrow boundaries of large systems, which made it harder to stay connected to the bigger picture of what I was building.

When AI started to rapidly evolve, like many developers, I found myself both excited and uncertain. The capability of AI in coding tasks grew faster than expected, and it naturally raised questions about the future of software development roles.

But over time, my perspective shifted. Instead of thinking about AI as a replacement force, I began to see it as a shift in how software is created and interacted with.

That shift pulled me toward a different question:

What does a native AI application actually look like on a mobile device?

At first, the market seemed full of AI apps. New products appeared constantly—chatbots, writing tools, coding assistants, automation tools. But the more I explored, the more I noticed a pattern.

Most AI applications were still built around a very narrow interaction model:

A prompt box
A response output
Some form of lightweight workflow wrapping

Even when the underlying models were powerful, the product surface remained relatively simple and repetitive.

This led me to a realization:

The AI application layer on mobile is still in its early form—mostly conversational, not system-driven.

That distinction became important.

Because AI is not just about generating responses. It is increasingly about orchestrating actions, systems, and workflows.

And that is where I started to rethink the role of a “mobile IDE”.

Rethinking What an AI Application Can Be

Most AI apps today focus on interaction—asking questions and receiving answers.

But software development, even at a simplified level, is not just conversation. It is a structured process involving:

Understanding context
Generating or modifying logic
Executing actions
Observing results
Iterating continuously

In most AI tools, these steps are disconnected. The user is still responsible for bridging the gap between intention and execution.

This creates a subtle limitation:

AI can generate output, but it does not own the workflow.

So I started to ask a different question:

What if an AI application on mobile could own the entire loop, not just the response?

Not just answering prompts, but managing a continuous system of:

intent → generation → execution → feedback → iteration

This is where the idea of a mobile IDE began to form, but not as a traditional “development tool”.

Instead, as something closer to a workflow-native AI application.

From Tools to AI-Native Workflows

The more I explored AI systems, the clearer it became that the real shift is not about individual features like code generation or chat interfaces.

The real shift is structural:

AI is turning software from static tools into dynamic workflows.

In this context, the concept of an IDE changes meaning.

It is no longer just an environment for editing code.

It becomes a system that can:

understand user intent
generate structured outputs
execute actions in real environments
observe results
and continue iterating

In other words:

The IDE becomes a workflow engine powered by AI.

This is especially relevant in a mobile context, where interaction is naturally intent-driven rather than process-heavy.

Users don’t want to manage systems manually on a small screen. They want to express intent and see results.

So the question is no longer:

How do we shrink a development environment into mobile?

But instead:

What does an AI-native workflow application look like on mobile?

The Shift in Interaction Model

Traditional software interactions are based on explicit control:

open tools
configure environments
execute steps manually

But AI changes the interaction model fundamentally.

It introduces a new pattern:

intent-driven execution

Where the user provides:

goals
constraints
context

And the system handles:

decomposition
execution
orchestration
iteration

This shift makes mobile devices particularly interesting—not because they are “limited versions of desktops”, but because they naturally align with intent-driven interaction.

Mobile is not a constraint here.

It is actually a natural interface for AI-native workflows:

short inputs
fast iterations
contextual usage
continuous interaction loops

What a Mobile IDE Actually Becomes

In this framing, a mobile IDE is not a tool for writing code.

It becomes a system that connects three layers:

1. Intent Layer
Users express what they want to achieve in natural language.

2. AI Orchestration Layer
The system interprets intent, generates solutions, and plans execution steps.

3. Execution Layer
Remote environments, APIs, services, and workflows are triggered and managed.

So the product is no longer defined by “editing capability”.

It is defined by:

the ability to turn intent into executed systems.

This is the key difference.

A mobile IDE in this sense is not a scaled-down development environment.

It is an AI-native workflow application that happens to include development as one of its capabilities.

Why This Matters Now

The reason this direction feels important is because AI is collapsing the gap between:

thinking
describing
and executing

As that gap shrinks, the value of software shifts upward:

from tools that require manual operation
to systems that respond directly to intent

In that world, the most important product question becomes:

How quickly can a user turn an idea into a working system?

Not how many features a tool has.

Not how complete an environment is.

But how directly intent can become execution.

Conclusion

Looking back, the decision to build a mobile IDE was not really about development tools.

It was about recognizing a shift in what AI applications are becoming.

From my perspective, the next generation of AI applications will not be chat interfaces or standalone tools.

They will be:

workflow-driven systems that translate intent into action.

A mobile IDE, in this sense, is just one early form of that direction:

an AI-native application where interaction, generation, and execution are part of a single continuous loop.