The direct links below always point to the latest local build:

Windows

macOS

Linux (Ubuntu/Debian)

Conclusion first: the value of multi-agent doesn’t come from more models; it comes from the right structure. Multi-agent without structure is just more expensive concurrency — burn 2 to 3 times the tokens to watch a group of models nod at each other. Multi-agent with structure is an execution system that can delegate, parallelize, and verify.

Why a Single Agent Fails at Long Tasks

Diagnosis first. A single agent executing complex tasks has five structural defects — blame the execution structure, not the model’s intelligence:

Let me start with something that actually happened.

In early 2025, I added a feature to an internal system: export to Excel. Small requirement — I didn’t even write it up, just typed “add an export button to the list page” into the chat box.

The AI delivered in ten minutes. Frontend changes, new endpoint, SQL — all in one pass. I was pleased when I opened the PR, right up until review revealed: the export columns didn’t match the list page, a hundred thousand rows would hang the service outright, there was no permission check, and the tests only covered the happy path.

The conclusion first, so you don’t waste your read

We used to split teams by craft: frontend, backend, product design. Now we split teams by stage: Prototyper — grabs the first idea and fails fast Builder — turns the prototype into a product you can take to market Maintainer — holds the fort once the software reaches scale Scaler — takes a proven product and scales it 10x, 100x Finisher — polishes the product and the code, sands off the burrs As for why we’re only splitting this way now — the answer involves AI. Read on.

Thoughts on Dynamic Intervention in AI Agent Runtimes

A few weeks ago, late at night, I stared at the agent logs scrolling through my terminal, frustrated enough to want to smash the keyboard. It was dutifully generating a requirements analysis report — it had been running for a dozen-plus minutes, pulling loads of data and drawing charts, clearly on the verge of wrapping up — when I suddenly realized the requirements were missing a key dimension: “Don’t split by region, split by user age group.” If I interrupted it now, all the context, intermediate results, and tool call state would be thrown away and it would start over. If I didn’t, it would soon produce a wrong report that would cost me just as long to fix by hand.

First, One All-Rounder Recommendation

If you want a single install that covers most scenarios, take a look at this one:

dev-skills, at: https://github.com/ByronFinn/dev-skills

Attachment download: Agent Interview Questions.pdf — handy for printing or offline reading

Why Would You Need Multiple Agents

An opening question to separate people who have “read the articles” from people who have “actually built one”.

The bad answer: “Multi-agent enables parallel processing, which improves system throughput and robustness.”

Every word of that is correct, but if you follow up with “so after splitting into two agents, did throughput actually double?”, they stall. The reality: inter-agent communication has overhead, coordination has complexity, and after the split total throughput may well drop. Adding agents is not like adding CPU cores.

Twelve articles, from the Think-Act-Observe loop all the way down into the 500,000-line engineering abyss. Now, standing at the end of the series and looking back over the whole evolutionary path, a bigger question surfaces:

What will AI coding tools ultimately evolve into?

A better Copilot? A more powerful IDE plugin? Or something new that we haven’t named yet?

Three Evolutionary Paths

Looking back at the development of AI coding tools, you can see three clear stages of evolution:

The claude-code-from-scratch project implements a “mini Claude Code” in roughly 3,000 lines of TypeScript. It has the Think-Act-Observe loop, a tool system, a system prompt, permission control, memory, Skills, multi-agent, MCP — every core concept we tore down over the previous ten posts.

And the official Claude Code source? Roughly 500K lines of TypeScript/TSX.

That’s a 100x+ gap between 3,000 lines and 500K. What’s in it?

The gap isn’t “number of features”. from-scratch already covers every core concept. The gap is the road each concept travels from “it runs” to “it’s usable” — that road is called productionization.

Hand an architect a plot of land and he won’t start laying bricks immediately. He draws first, calculates load, considers daylight, plans the plumbing. Only when the blueprints are confirmed does the construction crew move in.

Hand an AI coding assistant a requirement and by default it starts editing code immediately. Not because it doesn’t understand “design first”, but because its loop mechanism rewards action — in the Think-Act-Observe loop, “Act” is the core capability. The model is trained to be “helpful”, and “helpful” in a coding context usually means “start changing things”.