An AI rewrote a million lines of code in 11 days.
This was a real production runtime. Bun, the JavaScript engine that millions of apps quietly run on, went from 535,000 lines of code in one language to more than a million lines in another, all of it inside two weeks. Close to a year of work for a team, by hand.
And the thing that rewrite produced is already on your PC. Not in a repo you would have to go dig up, not behind a signup. Ten seconds to prove it:

strings ~/.local/bin/claude | grep -m1 'Bun v1'
# → Bun v1.4.0

The runtime that million-line rewrite produced is already inside the tool you code with.
What pulled it off was the shape of the work itself. The models were ordinary, the ones you already run. Wire them as a graph instead of a line, and one job at a time becomes a fleet running at once.
That is the layer almost nobody is taught to see.
Most people still line their agents up and wait. You type a request, wait for it, fix what came back, then ask the next thing. The context fills up, the agent forgets what it did three steps ago, and you end the day with twenty open chats and no single answer.

You draw a line where the work is a graph.
By the end of this you'll have drawn your own graph, built one in any agent you already have, made it hard to break, learned to call your speedup before you ever deploy a single agent, and walked away with six recipes ready to run this week

Before we get into it: the builds, the fails, and the alpha from these experiments go out on X and in the Telegram channel, every day. Both are free.
X - https://x.com/Argona0x
Telegram - https://t.me/+r0clI4-MMC03ZjAy

What graph engineering is

A linear agent looks like the natural way to work. It's the shape of typing itself: one line, one thing at a time.
Three words carry the whole discipline. Learn them once.
A node is one unit of work: one agent, one input, one output. Picture a single worker at one station, one thing in, one thing out.
An edge is a dependency: the output of one node is the input of the next. Picture a rope handing a bucket down the line. If the next worker never reads the bucket, the rope is painted on.
A graph is the network where independent work runs at once. A wiring board with current in every trace at the same time.

Your "do A, then B, then C" is already a graph. Just the saddest one there is, one edge wide. B hangs, and C never happens.
https://pbs.twimg.com/media/HN_XnpqW4AAJeHK.jpg
None of this is new. The US Navy laid out the same critical-path chart to schedule the Polaris missile in 1957, make -j built code in parallel by 1976, MapReduce carried it into the data center in 2004, and Airflow wired it into daily pipelines by 2014. The same directed graph of dependencies every single time, arrows that only ever flow forward. This is fifty-year-old machinery, and it has only just reached the agents.
So which of your "and thens" are real edges, and which are just the word?

Step 1 · See the edges that aren't there

The mistake almost everyone makes: reading "and then" as a wire.
Half of them aren't wires at all. They're two jobs that have nothing to do with each other, chained into a line for no reason, each one made to wait on a result the next step never even opens.
The test is one question, and it's the whole skill. On every "and then," ask whether the next step actually reads the previous step's output. Yes means it's a real edge, so keep the order; no means it was never an edge, so run them at the same time.
Take a real one:

summarize this file, and then tell me the weather."
Two boxes, no arrow between them, because the weather never reads the summary. A linear script chained them anyway, purely because the words "and then" looked like a wire.
https://pbs.twimg.com/media/HN_YMtOX0AALWO7.jpg
Look closely at your own "and then." Go down your real task list and put each seam to the one question. The arrows that survive are your real edges. The rest were only ever standing in line for nothing.

Step 2 · Draw your graph

You've got your steps in a row. Stop reading them as a list. Start seeing them as a graph.
Go down the list and tag each seam: real edge, or not. The real edges keep their order. Everything else gets stacked side by side to run together. What's left on the page is your graph.
Now find the longest chain of real edges still standing. That's your critical path, and it's the one airport queue you have to stand in. Sixteen agents don't shorten it, and sixty-four don't either.
The longest chain of real edges is the fastest this work can ever finish.
https://pbs.twimg.com/media/HN_YtdNXYAA9EBF.jpg
Want it faster? Then cut a false edge instead of adding an agent. A→B→C never beats its own sum, no matter how many workers you throw at it.
Draw it wide enough and you hit a new problem: parallel agents in one folder start overwriting each other's work.

Step 3 · Build and run your first one

Build one and watch it run.
You don't need a paid feature underneath it. Any capable agent runs a graph if you hand it the structure in plain words. Paste this into the agent you already run:

You are an orchestrator. Build a graph, not a chain.

TASK: <describe the work> across <N> independent items (e.g. every file in src/routes/).

RUN AS A GRAPH:
1. FAN OUT — one worker per item, in parallel. Each worker: one input, one output. Workers share NO state.
2. VERIFY — for each worker's finding, spawn a SEPARATE verifier with FRESH context.
   The verifier checks a REAL signal (does the test pass / does the claim hold), not "did the worker say done".
3. MERGE — collect all verified findings into ONE report. Intermediate results stay in your notes, not re-fed as chat.

RULES: workers never review their own work; the verifier never implements; start with max <20> items to stay cheap.
Begin.

One paragraph that turns any capable agent into a graph runner.
Inside Claude Code you don't even write the orchestrator. You describe the graph in one line and it writes the script for you:

ultracode: audit every route handler under src/routes/ for missing
authentication checks, then adversarially verify each finding before
reporting. Analyze at most 20 files to start.

Claude drafts a JavaScript orchestrator, prints the four phases (scope, fan-out, verify, synthesize), and waits for you to say "yes, run it."
One line in. Claude writes the orchestrator, runs it in the background without tying up your session, and hands back a single report that folds every worker's finding into one place instead of the twenty scattered chats you would have opened by hand.
Open /workflows and watch it happen: sixteen workers spin up at once, each on its own file, each reporting a finding, while a separate verifier picks up every hit on fresh context and the results collect into one report, all of it running while your session stays free the whole time.
https://pbs.twimg.com/media/HN_ZVq8XUAAWXbX.jpg
Like the run? Press s and it saves to the project's .claude/workflows/, versioned and shared with your team and winning on a name clash, or to your personal ~/.claude/workflows/. Saved, it becomes a /name command you rerun forever. Trigger it in any session with ultracode; turn it on for a whole session with /effort ultracode.
The caps are sixteen agents at once, a thousand per run: a hard brake on a runaway.
The "zero tokens" line you'll hear is half true. The coordination is free: it's plain code, and the in-between results live in script variables, never piling into your context. But every agent underneath is billed. A workflow burns more than a normal session. Start at twenty files. Widen once it works.

Step 4 · Make the graph powerful

You built the graph. Two moves turn it from fragile into iron.
The first is a fresh verifier. An agent that checks its own work rubber-stamps it, and that is measured. GPT-4 recognizes its own writing 73.5% of the time, and that self-recognition causally drives it to prefer the very text it wrote (Panickssery, NeurIPS 2024). Grade a lineup of answers and a model scores its own higher: GPT-4 by 10%, Claude by 25% (Zheng, NeurIPS 2023).
The model knows its own writing most of the time, and once it knows, it grades it kinder. Which is why the maker never grades its own exam.
The fix: the verifier is a separate node with fresh context, an outsider who never touched the work, and it checks a real signal like a test that passed. For subjective calls, run a jury of three models from different families.

A graph of agents on one shared context is just one loop with extra steps, agreeing with itself.
Fresh context is what turns a check into an actual check.
The second move is isolation. Parallel agents in one git checkout clobber each other's work, the problem Step 2 left open. The fix is real, straight off the Bun port: freeze one rule into every worker.

Never git stash. Never git reset.
No git command except committing a specific file.
No slow commands before the test phase.

The rule that let sixty-four agents share four checkouts without overwriting each other, frozen into one sentence.
Then shard the fleet across worktrees, separate working copies of the repo, and each crew works only on its own copy while the others stay untouched. Isolate by the group: four worktrees of sixteen, so you never pay for sixty-four separate checkouts. Set worktree.baseRef: "head" and each one starts from your current branch. Now they run wide, and nobody overwrites anybody.
https://pbs.twimg.com/media/HN_ajanW8AAMKlz.jpg

Step 5 · Aim the fleet and count the win

One run unfolds to a thousand agents.
Sixteen at once, a thousand per run, deployed in waves from a single window.
But sixteen agents rarely buys sixteen times the speed, and you can know the real number before you deploy a single one. That is what the calculator is for. Amdahl's law is a formula you check before scrambling the fleet:

S = 1 / ((1 − p) + p/N)
  p = share of the work that's independent (parallel)
  N = number of agents

p = 0.95, N = 16  →  ×9.14   (not ×16)
p = 0.70, N = 16  →  ×2.91
ceiling (N = ∞)   =  1 / (1 − p)

Sixteen agents buy you nine times over. The naive guess says sixteen; the merge-and-verify tail eats the difference.
https://pbs.twimg.com/media/HN_a2QmXIAAdq0l.jpg
Push it and the ceiling holds: even 256 agents at 95% only reach ×18.6. The serial tail is the anchor: the final merge, the verify, every real edge.

The critical path was the floor. The serial fraction is the cap.
And the "and then" test from Step 1 is exactly how you estimate p: count the independent node, and you've got your number before a single agent runs.
That ceiling is a real, documented brake: a thousand agents unfolding from one window, the same fifty-year lineage we started with, now aimed at your agents.
https://pbs.twimg.com/media/HN_bGtwXIAArGDU.jpg
Now point that same method at six different jobs.

Step 6 · Six graphs you'll build this week

The method is one: find the real edges, fan out, verify on fresh context, and isolate the workers. Now aim it at new work.
Every one of these is the same skeleton with a different task line:

1. Security-sweep: one agent per file hunts a missing auth check, and an independent verifier confirms every hit before it reaches the report.
2. Cited research: the question splits into angles, the search runs in parallel, and the agents refute each other before a word gets written. Claude Code ships this one as /deep-research already.
3. Module port: file by file, the test suite is the gate, and every failure loops back into the queue.
4. Adversarial diff-review: route by size. A small diff gets one pass. A large diff gets the full parallel audit.
5. Scheduled ecosystem scan: save it once, run it by name on a timer.
6. Unknown-size discovery: finders run in parallel, each result is checked against everything already seen, and the loop runs until two rounds come back empty.
   Six jobs, one method. You change the task line, the graph is already built, so save this card.
   https://pbs.twimg.com/media/HN_b8iiXQAEvGi6.jpg
   This method has a ceiling, and it is the rewrite from the top of this article: around fifty workflows, sixty-four agents at peak, four worktrees of sixteen. 535,496 lines of Zig turned into more than a million lines of Rust, across 6,502 commits, in eleven days. The merge gate was the whole Bun test suite: 1.38 million assertions across six platforms. Out the other end came Bun v1.4.0.
   Eleven days for what would be close to a year of a team by hand. The ceiling of the exact graph you just learned to draw.

The shift

The linear agent is just the first shape you reach for, the one that feels natural because it's how you type. It was never the ceiling.
Once you can see nodes and edges, you start reading every task as a graph: you walk the seams, cut the arrows that were never really there, fan the independent work out wide, and gate the few edges that actually carry a result. The question changes. You stop asking an agent to do more in a line. You start drawing a graph that runs the work wide.
Three lines hold the whole discipline:

1. Fan out where the work is independent.
2. Gate the edges where confidence matters.
3. Freeze the nodes that hold the truth.
4. A prompter asks a question. An architect draws a graph.
   The layer nobody teaches is yours now.

If you want to catch the next build while it's still quiet, it's all here:
X - https://x.com/Argona0x
Telegram - https://t.me/+r0clI4-MMC03ZjAy