Ultracode: When AI Can Lead a Coding Team, What's Left for Humans?

TL;DR Ultracode binds deep reasoning and automatic team orchestration into a single switch. It lets AI assess a task on its own, decompose it into steps, and even replicate itself into dozens or hundreds of parallel agents working simultaneously. When machines have learned even how to divide labor, human value gets pushed toward something more fundamental: Is this worth spending the compute on? And once it’s done, what makes the result actually count?

Not long ago, I opened Claude Code and noticed a new option at the bottom of the menu: Ultracode. I switched it on, handed it a tedious code-cleanup task, and then did nothing — just sat there watching how it worked.

It didn’t behave like a typical AI that charges ahead the moment it receives an instruction. It first took time to compare several diverging version histories, confirmed there were no file conflicts, and only then selected the safest merge path with quiet deliberation. It synced the mirror, wrote the history, and added that day’s work log as a matter of course. The words “almost done thinking” kept appearing on screen. By the time it finished, what struck me wasn’t how cleanly it had executed — it was that the shape of how it worked had changed. It operated with more caution than most engineers would.

Caption: I handed a complex version-cleanup task to Ultracode without intervening at any point. It compared versions on its own, chose the merge logic, updated the mirror, and completed the work log.

Beneath the Surface: Deep Reasoning and Dynamic Division of Labor

One thing worth clarifying upfront: Ultracode is not a new model, nor is it simply letting AI “think longer.” It is an operational mode within Claude Code, released alongside Opus 4.8 in late May 2026 (official documentation here). Enabling the toggle sets two mechanisms in motion simultaneously:

1. Maximum reasoning intensity (xhigh): Forces the model to mentally simulate all potential risks and architectural boundaries before touching a single line of code.
2. Automatic dynamic orchestration (dynamic workflow): The AI independently evaluates the scale of a task, decides whether it warrants decomposition, and distributes the work accordingly.

The key is that the second mechanism is conditional. Only when a task is large enough — and genuinely divisible — does it spin up sub-agents. If the task is inherently linear (like the version cleanup I handed it, where a single rebase cannot be split across ten agents working in parallel), it simply proceeds step by step. The same switch, applied to different problems, grows a different strategy on its own. That was the first signal I read while watching the screen: Ultracode was active, but it wasn’t using its capabilities for the sake of using them.

When the Task Is Large Enough, AI Assembles Its Own Team

When the scale of a task genuinely warrants it, Ultracode reveals its real force. It generates a script on the fly, spawning dozens to hundreds of sub-agents within a single session, each working through its own slice of the codebase.

What makes the validation approach particularly interesting is its adversarial structure. One set of agents attacks the problem from different angles; another set is dedicated to challenging the conclusions the first group reached. The two sides contend internally until an answer converges and no further vulnerabilities can be found.

This is not laboratory theory. It has already happened.

📊 Field Data: Porting a Programming Language in Bun

Bun, the well-known JavaScript runtime, had its author Jarred Sumner share an extreme case: using this mechanism, he ported nearly one million lines of Bun’s core codebase from Zig to Rust.

In the past, this would have been the kind of engineering effort that a full team of senior engineers might spend several quarters on — without any guarantee of finishing. With this approach, a mergeable result was produced in ten days. (Sumner also noted that this was more of an experiment and may not replace the existing Zig implementation.)

What I Thought Was My Core Competitive Advantage Has Become a Built-In Feature

Seeing this capability, I had a complicated reaction — because I had only just finished painstakingly building my own version of this multi-agent collaboration system by hand.

Not long ago, barely two months back, I wanted different AI windows to work together in something approaching genuine team collaboration. So I broke the process into clearly differentiated roles: Chat handled research and strategic judgment; Cowork handled synthesis and execution; Code handled programming and technical review. Between each stage, I used document and memory systems to synchronize state, preventing information from fragmenting, duplicating, or conflicting.

That kind of division of labor is a form of harness engineering: not merely throwing problems at AI, but designing a working system that constrains, guides, assigns, hands off, and validates AI across the entire process.

I had thought of this as my moat as an independent worker.

Ultracode filled it in completely. The sophisticated collaboration techniques that once required careful human planning, manual isolation, and deliberate window-switching — those are now an ordinary button embedded in the software’s foundation. What this signals is clear: the technical edge that came from manually orchestrating AI has been reduced to zero.

When Execution Becomes Free, What Remains Scarce?

When the tool takes over the most cognitively demanding work — dividing labor and orchestrating agents — at an open-ended cost (no ceiling; it runs until the answer stabilizes), the human role gets pushed back one notch.

You no longer need to think about how to decompose a task or how to assign it, because the machine does that faster and better. What this leaves as a genuine test of the person are two things that cannot be automated:

• Judgment about compute: Is this problem worth pressing the switch — worth letting a fleet of agents consume an unpredictable amount of compute until convergence?
• Taste in evaluating results: When hundreds of agents deliver a logically rigorous, architecturally complex output, on what basis do you trust it? How do you define its scope and set the acceptance criteria?

Evaluation is, at its core, a matter of taste. You have to know deeply what “good” means before you can look at thousands of machine-generated lines of code and immediately sense where something is off, what should stay, and what should go.

In my essay Beyond Man-Days, I argued that once AI lowers the barrier to execution, output shifts away from “how much time you invested” and toward “how you define the problem, allocate the work, and maintain quality” — moving the person from operator to project manager. Ultracode is one step further along that same line: even the act of allocating work is now something the tool begins to do on its own. What remains in your hands becomes more purely judgment. It hasn’t reduced the amount of judgment required — it has relocated where judgment sits. From the details of execution, to whether to engage at all, and whether to trust what comes back. Neither of those questions yields to automation, because they are fundamentally questions of value — not computation.

Conclusion: The Moat That Can’t Be Filled

Watching Ultracode run through that cleanup task on screen, the question that surfaced in my mind was more concrete than abstract: when machines begin taking over orchestration, execution, debugging, and even large-scale code migration — what capabilities should a person keep hold of?

The answer is probably not faster operation, or more practiced execution, because those capacities are being absorbed into automation at speed. Today it can handle close to a million lines of code. Tomorrow, the scope it can take on will only be larger. Individuals and teams who once took pride in their execution advantage need to reckon with a new reality: the importance of pure execution will be compressed further and further.

But this may not be a bad thing. It forces us to draw a distinction we often avoid: what is merely busyness, and what is actually valuable capability.

What remains in the end is judgment and taste. Judgment is knowing what is worth doing and what is not. Taste is knowing at what point something has been done well enough to truly count as done. Neither of these grows automatically from an upgraded tool, and neither can be acquired by pressing a switch. They come from real experience — from mistakes made, from bad design witnessed, from difficult trade-offs navigated, from a capacity for discernment built up slowly over time.

Machines will run faster, and they will keep doing more. But whether to run at all, and whether what they produce is right — someone still has to answer for that. That is the moat that cannot be filled.