The One Thing Every AI Coding Tool Gets Wrong

It's 2pm on a Tuesday. You've got an AI agent refactoring your authentication module -- ripping out the old session-based system, replacing it with JWTs, updating middleware, fixing tests. The agent is three files deep and making real progress. Meanwhile, you've just gotten the go-ahead to start building the payment API. You know exactly what you want: a clean Stripe integration, a new set of endpoints, maybe a webhook handler. You could start right now.

But you can't.

The auth refactor is touching middleware.ts. The payment API will need to register routes in the same file. The agent is modifying your user model. The payment flow will need to reference it. If you open a second Cursor tab or fire up another Claude Code session in the same directory, you're asking for conflicts, half-written files, and a mess that will take longer to untangle than it would have taken to just write the code yourself.

So you wait. You check Slack. You review a PR from yesterday. You wait some more. The agent finishes. You start the next task. Sequential. Always sequential.

This is the daily reality for every engineer using AI coding assistants in 2026. And it's the thing nobody seems to be fixing.

The bottleneck isn't intelligence

Let's be honest about where AI coding tools are right now. They're impressive. Claude can hold enormous context windows, reason through complex refactors, and produce code that actually works on the first try more often than not. Copilot's inline completions have become second nature. Cursor's agent mode can tackle multi-file changes that would have seemed like science fiction two years ago.

The models are good. They're getting better every quarter. The ai coding assistant limitations that engineers hit day after day aren't about model intelligence, context length, or even hallucination rates. Those problems are real, but they're being solved by very smart people at very well-funded companies.

The problem that nobody is solving is much more mundane.

It's the filesystem.

Two agents, one directory

Every AI coding tool you use today -- Cursor, Copilot Workspace, Claude Code, Aider, Continue, all of them -- operates inside a single working directory. Your project. One checkout. One set of files on disk.

When an AI agent modifies a file, it's modifying the actual file. The bytes on your SSD. The same bytes that every other tool, every other agent, every other terminal session in that project is looking at. There's no isolation. There's no transactional boundary. There's just one directory, and whatever happens to be written to it at this particular moment.

This means that running two AI agents simultaneously on the same codebase is, at best, a recipe for merge conflicts you didn't ask for. At worst, it's a recipe for silent data corruption -- one agent overwrites another agent's changes mid-operation, and neither of them knows it happened.

The standard workflow, even for engineers who are deeply invested in AI-assisted development, looks like this:

1. Give the agent a task
2. Wait for it to finish
3. Review the changes
4. Commit or discard
5. Give the agent the next task
6. Go to step 2

It's a sequential pipeline. One task at a time. One agent at a time. The throughput ceiling isn't the model's tokens-per-second -- it's the fact that you can only run one workstream.

Think about what that means for a typical day. You might have a backlog of eight tasks. Each one takes the agent ten to twenty minutes. Even if the AI does perfect work every time, you're looking at two to three hours of wall-clock time, most of which is spent waiting. You're the bottleneck, but not because you're slow -- because the tool forces you to be sequential.

AI Coding Tools: Parallel Development Support

Every tool on this list does good work within a single session. The difference is what happens when you need more than one workstream running at the same time.

What developers actually want

Talk to any senior engineer who's been using AI tools seriously for six months and they'll describe the same fantasy. It goes something like this:

You open your project. You see your task list -- maybe from Linear, maybe from GitHub issues, whatever. You assign three or four tasks to AI agents. Each one starts working immediately, in parallel. You can see what they're doing in real time -- which files they're modifying, what their approach looks like. If one of them is going down the wrong path, you intervene early. When they finish, you review clean diffs, just like reviewing a colleague's PR. You approve, merge, move on. The agents start on the next batch.

That's parallel ai development. Multiple workstreams, running simultaneously, each isolated from the others, each producing a clean, reviewable unit of work. You're not waiting. You're orchestrating.

This isn't a wild fantasy. This is how teams of human engineers already work. Developer A works on auth. Developer B works on payments. They work on separate branches, in separate checkouts, and they merge when they're done. We've had the tools for this since the invention of version control.

The only reason AI agents can't do this today is that nobody has built the infrastructure for it.

The answer has been in git since 2015

Here's the thing that changed our entire approach: git worktree.

Git worktrees were added in Git 2.5, released in July 2015. They let you check out multiple branches of the same repository simultaneously, each in its own directory on disk. Every worktree shares the same .git directory -- the same object store, the same refs, the same history. But each one has its own working tree, its own index, its own HEAD.

# Create a worktree for a new feature branch
git worktree add ../my-repo-payment-api -b feature/payment-api
 
# Now you have two directories:
# ./my-repo              (main branch)
# ./my-repo-payment-api  (feature/payment-api branch)

The overhead is near zero. You're not cloning the repo. You're not copying files. Git just creates a new working directory and checks out the branch into it. The .git directory is shared via a small pointer file. Creating a worktree takes milliseconds, even for large repositories.

This is perfect isolation. An agent working in one worktree cannot affect files in another worktree. They share the same repository, the same history, the same remote -- but their working files are completely independent. One agent can rewrite your entire auth module while another builds the payment API from scratch, and they will never step on each other's changes.

When both are done, you merge. Just like you'd merge any two branches. Git handles the rest.

If you want the deep dive on worktrees -- how they work internally, the commands you need, the edge cases to watch for -- we wrote a full technical breakdown. The short version is: this is the most underused feature in git, and it's exactly what git worktree development for parallel AI sessions needs.

What we're building

We're building ChatML: a native macOS application that orchestrates parallel AI development sessions using isolated git worktrees.

Here's how it works.

You open ChatML and point it at your project. You create a new session -- let's call it "refactor auth." ChatML creates a git worktree, checks out a new branch, and spins up a Claude agent inside that worktree. The agent has its own isolated copy of your codebase. It starts working.

While that's running, you create another session: "build payment API." Another worktree, another branch, another agent. It starts working too. In parallel. No conflicts. No coordination needed.

From the ChatML interface, you can see both sessions side by side. You see the files each agent is modifying, the diffs in real time, the conversation history with each agent. If the auth agent is doing something you don't like, you jump in and redirect it. If the payment agent finishes early, you review the diff, approve it, and create a PR -- all from the same window.

Each session is fully isolated. Each session produces a clean branch with a clean commit history. Each session can be merged independently. You're not managing worktrees by hand, not running git worktree add in the terminal, not keeping track of which directory is which. ChatML handles all of it.

The stack is deliberately multi-language, and we wrote about why:

• Go for the backend service -- session orchestration, worktree lifecycle management, git operations. Go's concurrency model is a natural fit for managing multiple parallel agent sessions.
• React for the UI -- the session interface, diff viewer, conversation panels. We need a rich, interactive frontend, and React in a webview gives us that.
• Rust via Tauri for the native macOS shell -- system integration, file watching, process management, menu bar presence. Tauri gives us a native app with a tiny footprint.
• Claude Agent SDK for the AI layer -- each session runs its own Claude agent with access to tools, file operations, and terminal commands, all scoped to its worktree.

This isn't a wrapper around an API. It's a development environment built from the ground up around the idea that AI-assisted coding should be parallel, isolated, and reviewable.

The workflow we're targeting

Let's make this concrete. Here's a Monday morning with ChatML:

9:00am -- You open ChatML. Your repo is loaded. You pull up your Linear board and see four tasks ready to go.

9:02am -- You create four sessions. "Migrate user model to new schema." "Add rate limiting to API endpoints." "Write integration tests for search." "Update onboarding flow copy." Four worktrees. Four branches. Four agents. All running.

9:15am -- The onboarding copy agent finishes. It was a small change. You review the diff -- looks good. You approve and create a PR. Three agents still running.

9:25am -- You check in on the rate limiting session. The agent is adding middleware, but it's using an in-memory store instead of Redis. You type a message: "Use the existing Redis client in lib/redis.ts instead of an in-memory map." The agent adjusts and keeps going.

9:40am -- The rate limiting and integration test sessions finish around the same time. You review both. The tests look solid. The rate limiting implementation now correctly uses Redis. Two more PRs created.

9:55am -- The migration agent finishes. This one is more complex -- you spend ten minutes reviewing the diff carefully, checking the migration script, verifying the rollback. It looks right. PR created.

10:00am -- Four tasks done. Four clean PRs ready for review. One hour. No waiting. No context switching between tasks. You orchestrated; the agents executed.

That's the workflow. That's what parallel ai development looks like when the filesystem constraint is removed.

What this isn't

Let's be clear about what ChatML is not.

It's not an AI model. We're not training anything. We're using Claude via the Agent SDK, and we'll support other models as they become capable enough for agentic coding.

It's not a replacement for your editor. You'll still write code in VS Code or Neovim or whatever you use. ChatML is where you go when you want to delegate tasks to AI agents and manage multiple workstreams.

It's not magic. The agents will still make mistakes. They'll still need guidance. The difference is that you can guide three agents in the time it currently takes to babysit one, because you're not blocked waiting for each one to finish before starting the next.

Building in public

This is day one. The app is GPL-3.0 licensed and fully open source. We're building in public because we think the best developer tools get built that way -- with real feedback from real engineers solving real problems.

The core worktree orchestration is working. The session management is working. The Claude integration is working. There's a lot left to build: better diff review, smarter conflict detection, tighter git integration, support for team workflows, and a hundred other things we haven't thought of yet.

We're going to ship fast, write about what we learn, and be honest about what works and what doesn't. Since writing this post, we've shipped ChatML v0.1.0 and built the entire product using its own parallel workflows -- 750+ pull requests, zero human-written code. If you've felt the pain of sequential AI development -- if you've ever sat waiting for an agent to finish so you could start the next task -- we're building this for you.

Download ChatML and try it. Break it. Tell us what's missing. Open issues. Submit PRs. This is an open source project, and it's going to get built by the community that uses it.

The AI models will keep getting smarter. The context windows will keep getting bigger. But until someone fixes the filesystem problem, all that intelligence is stuck in a sequential pipeline. That's the one thing every AI coding tool gets wrong.

We're going to fix it.