Ever since I wrote I stopped reviewing my own code, I keep getting the same question.
I ended up with a huge pile of code and I can't review it. What should I do?
The comments say the same thing in different words. The volume the AI writes went up. The reading side did not keep up. So what now?
Here is the blunt answer first.
Don't get into that state.
Taking something that already exists and rescuing it with review alone is, I think, very hard. You can split it, scope it down, throw parts away — but none of those is a substitute for actually reading it. And "just have the AI review it" probably isn't the answer either.
And this is not only a team problem. It happens exactly the same way when you work alone. The cause isn't headcount. It's writing a big spec up front and having the whole thing built in one go.
That is like buying a single lottery ticket where you don't find out whether you won until the very end. This post is about why, with arithmetic and with measurements.
The second half spills over into a related question: how many people should be on a product.
Note: the numbers here are measured from my own repository. But treat commit and PR counts as observational data about how I work, not as evidence of productivity.
Why you end up with "too big to review"
Most of the time, I think it's because the whole spec was decided first and built in one shot.
You write the spec. You hand it to the AI. A large amount of code comes out. And now, to judge whether any of it is right, you have to read all of it.
But there's a prior question.
You can't write a spec for something when you don't know if it's possible or if you even want it
The starting point for MulmoTerminal, which I build, was an experiment: can a terminal run inside a browser? It worked, so I widened it into a grid. After that I just used it and added what I wanted. That's all.
There was no room for a spec at that moment.
- I didn't know if it was possible — nine real terminals side by side in a browser tab, usable in practice?
- I didn't know if I wanted it — would putting them side by side actually be nice? I couldn't tell.
With those two unknown, what exactly is there to write? Anything you write is a wish, not a spec.
There are, clearly, cases where a spec works well. Building an Amazon clone. Building an internal system where the UI doesn't matter much. The reason a spec is writable there is that the thing already exists in the world.
A spec is a compression of knowledge that already exists. It is not a way to discover what doesn't exist yet.
You cannot compress something that isn't there to compress.
It's like buying a single lottery ticket
Deciding everything before you know anything is, to me, betting the outcome on one ticket.
And it's worse than a lottery in one specific way.
A lottery tells you whether you won on the spot.
A big spec doesn't tell you until you've finished building and started using it.
Let's compute the odds that "all of it works"
Hand over a big spec and let it build. Some of it comes out good, some of it doesn't. You can specify the UI in detail and sometimes get exactly that, sometimes not.
So what are the odds that all of it comes out the way you wanted?
Say each individual decision has a 90% chance of landing the way you intended. That's a generous assumption.
(This is a simple calculation that assumes the items don't affect each other. In reality they interact, so don't take it literally — it's for the order of magnitude.)
| Number of decisions | Chance all of them land |
|---|---|
| 3 | 73% |
| 5 | 59% |
| 10 | 35% |
| 20 | 12% |
| 50 | 0.5% |
It's a product, so it falls much faster than people expect. Even at a near-ideal 95% per item, twenty items gives you 36%.
And a big spec holds twenty or fifty decisions without trying.
Here's the part that matters. At twenty items, the chance that at least one of them does not land is about 88%. So what happened to that "at least one"?
Usually it gets accepted with "well, it runs, good enough." Because nobody checked which parts didn't land. Checking would mean reading all of it, and the amount that came out is exactly the amount you can't read.
Are you actually satisfied with that?
"Just write a more detailed spec" ends at implementation
Some of you are thinking:
Then write the spec in enough detail that it can't miss?
Correct. The only way to raise the per-item odds is to remove ambiguity.
But writing it out in full means enumerating, in advance, every decision you would otherwise make while implementing.
Where the button goes, what happens when you press it, what shows up when it fails, what to do when the value is empty. Write all of that and yes, you get closer to what you wanted — but the volume you write, and the volume you think, moves toward implementation.
And there is one decisive difference.
A spec doesn't run.
No matter how detailed it is, it will not tell you whether it's right.
Detailing a spec looks like raising your odds. In practice it tends to be "postponing the answer while increasing the bet."
And AI flipped this trade-off
"Settle it on paper first" used to be the correct call.
Before rewriting is expensive → building big and then fixing costs a lot
→ cheaper to be wrong on paper
Now rewriting is cheap → rebuilding doesn't cost much
→ cheaper to be wrong in working code
Being wrong on paper was rational because rewriting was expensive. That premise moved.
That said, not everything got cheap. What got cheap is transcribing something whose shape you can already see. Migrations, public APIs, anything wired to another company — rewriting those is still expensive. Settle those up front.
So: once you've reached the point of "let me spec this out in detail," you may as well build it there.
Give the AI instructions in small increments and you get something running in about the time it takes to write the detailed spec. And the running version has a decisive advantage.
A spec stays silent when it's wrong.
Something that runs tells you immediately.
If you're spending the time either way, spend it on the one that tells you. That's the whole argument.
So how do you build? Tighten the implementation, not the spec
First, look at what happens when you build big in one go and it turns out to be wrong.
Everything produced up to that point sits on top of that spec. You aren't fixing a part; you're restacking. And you usually notice "restacking would have been faster" only after you've finished stacking.
So keep it small enough to throw away. There's one thing to do.
Cut down to the smallest unit that needs a judgement, implement them one at a time, and judge each time.
What you tighten is the implementation, not the spec.
On odds, it's just the table read backwards: decide five at a time and you're at 59%; three and you're at 73%.
But odds aren't the only thing that improves. Cutting small changes three other things.
1. The judgement itself gets more accurate
Looking at twenty things at once and asking "is this fine?" versus looking at them one at a time — the second is more accurate. Detail drops out when you look at everything together. And as above, you end up waving it through with "well, it runs."
2. You can change direction partway
If you realise at the third one that the whole direction is wrong, you can turn there. Realise it after finishing all twenty and the cost of turning is everything you already stacked.
3. You can put it in front of people early
This might be the biggest one. Getting something running early also means getting it used early.
Later in this post I describe how the purpose I built the thing for turned out to be wrong. The only reason I found that out is that people could actually touch something running. Had I shown nobody until it was all finished, it would have been completed against the wrong purpose.
"Isn't one at a time slow?"
Yes. Done serially, of course it is.
So do it in parallel.
Run about ten independent things at the same time. Then evaluate them as they land and feed corrections back.
cut small, serially → slow. which makes you want to batch it up
cut small, in parallel → not slow. it can stay small
Cutting small only becomes practical once you can run things in parallel. Conversely, in an environment where you can't run in parallel, betting big is all that's left. That, I suspect, is why "write the whole spec first" still looks rational.
And what happens when you do run in parallel? You end up evaluating finished work, one after another. When that clogs, everything stops. If there's one person evaluating, their spare attention is the ceiling.
That's why the second half of this post ends up being about headcount and parallelism.
That said, cutting small isn't automatically safe
It isn't as simple as "cut it smaller and per-item accuracy is preserved." Cut in the wrong place and new mistakes appear at the seams.
What is decisively different is this: you find out you were wrong sooner, and you can throw away only what you built so far.
Every number in the second half of this post exists to serve that.
This isn't AI's fault. It was always like this
Something worth remembering.
Back when only humans wrote code, specs were wrong too.
You write the spec, hand it to engineering, and it comes back: "this doesn't work as written." You touch something running and only then realize "no, not this." Those round trips did not happen because implementation was slow.
They happened because the spec was wrong and nobody could tell until they touched it.
What AI made fast is mostly implementation, and the planning around it.
what was slow implementation → got fast
what was wrong the spec → barely changed
The cause of failure is largely unaddressed. If anything, wrong specs now become real faster and in larger volume.
The same thing happens under Agile
"That's why we do Agile" is a fair objection. Short cycles, build, check, correct. The distance really does shrink.
But it stops when the product owner and the team are separated. The person deciding is in a meeting, not at a keyboard. Decisions lag, and in the worst case the kind of judgement you only discover while writing code never reaches anyone.
I don't think the real variable is waterfall vs. Agile.
The distance between the person deciding and the code.
spec everything first the decider is farthest from the code, and decides once, from there
Agile (separated) the decider is in a meeting; decisions come at sprint granularity
working alongside the decider is at the keyboard
Agile shortened the distance. It didn't take it to zero. And there are decisions that only reach you at zero. The examples below are what I mean.
The tool got smarter. You didn't
Some of you are thinking:
But AI helps write the spec now. Isn't that different from before?
I think this is the biggest misunderstanding around.
AI did get smarter. Throw it requirements and a plausible-looking spec comes back. And that makes it feel like your own ability went up.
It didn't. The tool got smarter. You are still the bottleneck.
Leverage is a multiplier, not the number being multiplied
AI is powerful leverage. People with a clear vision of what they want to build use it astonishingly well. That part is real.
But leverage is multiplication, and the thing being multiplied hasn't changed.
A plausible spec appears instantly. But reading it and deciding "this is sound" or "this is wrong" is still you. And the ability to produce a good spec is still yours to have or not have.
Writing makes this easy to see.
Plausible prose is easy to get out of an AI.
Getting genuinely excellent prose out of one is still extremely hard.
Anyone who writes knows this in their gut. Specs and design are exactly the same.
Former CTOs joining AI labs as individual contributors is probably the same story
This is actually happening.
- Peter Bailis — CTO of Workday (from May 2025). Left in March 2026 and joined Anthropic as a Member of Technical Staff, working on reinforcement learning engineering (The Next Web, 2026-04-09)
- Bryan McCann — co-founder and CTO of You.com. Also moved to Anthropic as a Member of Technical Staff (The Information)
CTOs of public companies and fast-growing startups, dropping the title for an IC seat. At minimum, several moves in the same direction have been reported recently.
The Next Web characterises it this way:
executives at the top of established technology companies choosing proximity to cutting-edge research over the authority that comes with managing large organisations
That is where the reporting ends. Both moves are documented. Why they did it is not in those articles.
From here on, this is my speculation.
If the goal were a bigger title or better terms, being CTO somewhere else was available. Not taking that reads, to me, like a statement about priorities.
Until now, building something large required a large team. For a CTO-level person to realise an idea, they needed capable people and an organisation. AI is filling that part.
If so, taking an IC seat where the smartest model and unlimited access to it live, instead of leading an organisation, is an entirely reasonable choice.
This is also a story about people with a clear vision being able to move with fewer people — the same direction as this post's conclusion.
But again. What changed is leverage.
AI increases the material for a decision. It lists options, it catches omissions. But the criteria for picking among those options exist only inside you. More material without criteria means you feel like you can choose, and you can't.
Without something to multiply, a multiplier means nothing.
Some decisions don't exist until you build
Abstractions don't land, so here are two real ones.
Example 1: the purpose I built it for was wrong
MulmoTerminal, which I build, is a tool for running many AI agents side by side. The screen is a grid of cells, each running its own work.
My assumption while building was clear.
This raises the ceiling on how many you can run in parallel.
If I were writing a spec, I would have written exactly that. It's why I built it.
Once people were actually using it, I asked four of them. How many do you actually run? What's good about it?
Here's what came back.
agents actually run in parallel 1 to 6
people who said "I can run more now" 0
Not one. What all of them said was something else entirely.
I can handle the same number more easily.
One person runs one to three and dropped VS Code entirely. The count didn't go up. They switched anyway.
So the value of this tool was not "raising the ceiling." It was "not losing track." The person who built it had it wrong.
And then it got worse
From the same conversations:
I got up to eight, but the notifications became a storm and I got tired and stopped
Notifications exist to let you run more. So you can walk away and still be called back.
Those notifications were creating a new ceiling. One part of the tool was lowering the ceiling another part had raised.
The cause was concrete: "finished" and "waiting on you" played the same sound. Indistinguishable, so you end up caring about all of them.
There is no way to know this before building. At the moment you add notifications, you assume they only push in one direction. Nobody finds out until someone actually runs eight and gets tired.
Example 2: the AI said "don't do it" — and it was wrong
There are tools that find duplicated code automatically. At one point ours reported a lot of "the same shape appears in many places."
The shape was something like this:
read A → error if missing → catch the failure and log it
read B → error if missing → catch the failure and log it
read C → error if missing → catch the failure and log it
When I went to consolidate it, the AI told me not to. From the dev log:
The checker reports many duplicates, but this is a structural repetition — read, error if not found, catch the exception — and each site is readable precisely because it is self-contained. Consolidating would mean rewriting large parts of a 2,700-line file, and readability would get worse, not better.
The reasoning holds together. "A wrong abstraction is worse than duplication" is in fact a principle we've written down. I read it and thought, fair enough.
But when I opened the code myself later, it was wrong.
What had been flagged was not a coincidental resemblance. It was genuinely the same thing written over and over. Consolidating it made things noticeably cleaner. We ended up doing it as a separate task.
Laid out, what happened was:
the tool said "duplicate" → correct
the AI said "don't consolidate" → plausible, and wrong
I opened the file and checked → consolidating read better
AI can justify not doing something with a plausible reason. And the principle it cites is generally correct, which is why you nod along.
Whether an argument is convincing and whether it's right for this code are different questions. And the second one can't be settled until you open the file.
Which brings us back to distance.
If I had turned this into a ticket that said "reduce duplication" and handed it to someone, the AI's explanation would probably have won. It's well written; there's nothing to argue against. Only the person who opened the file can overturn it.
What these two share is that the right answer wasn't knowable until something actually ran.
- Example 1 — the purpose it was built for turned out to be wrong, and only usage revealed it
- Example 2 — a plausible explanation from an AI was, in fact, wrong
Neither fits in a spec or a ticket. By the time it fits, you've already checked.
What you can decide before building is only what you already know.
AI doesn't shorten the distance
This is where the original question comes back.
What AI made fast is mostly implementation and planning — and the benefit lands on whoever is at the keyboard. If the authority to decide sits far from the keyboard, that speedup doesn't reach it as-is.
authority at the keyboard → fast, and corrected as you go
authority still far away → fast, and still far away
"Fast while still far away" is the worst state. When the person judging stays distant, the speed at which mistakes are noticed barely changes, while the speed at which they accumulate goes up.
The result of that is "too big to review."
Why "just have the AI review it" doesn't fix it
AI reads far more text far faster than a human. That's true. So I won't claim "the AI can't read it."
Two things matter, though.
First, there's a ceiling on how much it can hold at once (the context — how much text the model can look at simultaneously). Depending on the model and your tooling, a large diff may not fit in one pass. Split it up and it fits, but splitting makes it much harder to surface "A and B don't line up." It only ever sees one side. And bugs usually live at exactly that seam.
Second, passing review doesn't mean the design is good. I have a concrete example of what survives after every machine check is green.
At one point I eliminated every "function that is too long" in my repo. Machines had nothing to complain about. Three months later:
CollectionView.vue 2,945 lines 187 functions longest 61 lines
server/index.ts 3,020 lines 212 functions longest 82 (most under 10)
There are no long functions. Nobody is being warned. And the files are 3,000 lines.
Because the machine only looks at "how long is this one function," never "how many different jobs live in this one file." CollectionView.vue had eleven separate jobs in it — list rendering, filtering, editing, chat, and more.
187 small functions added up to 3,000 lines, and the machine never once complained.
"The machine passed it, so it's fine" doesn't hold for review or for design. And a setup that puts AI review as the last line of defence collapses right here.
So what do I actually do
Numbers from my own way of working. Again: this is not proof of correctness, it's observational data about how I work.
MulmoTerminal (2026-06-14 → 2026-08-06, 53 days)
commits 3,235
merged PRs 1,170
releases 64 about 1.2 per day
written by effectively 2 people (2,990 / 221, plus one at 24)
Time from opening to closing, last 400 closed issues
median 1.6 hours
within 6h 77%
within 24h 92%
over a week 2%
Diff size, last 400 merged PRs
median 286 lines
under 300 51%
files changed median 7
How I measured
Closed issues: gh issue list --state closed --limit 400, taking the difference between created and closed timestamps. PRs: the last 400, additions plus deletions. Both are cut as "the most recent 400," so if the way I work changed partway through, that shows up in the number. Commits and releases are git rev-list --count and git tag.
Issues shaped like this are not specs written before building. They're notes of something I noticed while using the thing, fixed the same day. That's why they're short-lived. If everything had been decided up front, the distribution wouldn't look like this.
Also: all these numbers can show is that things were built fast. Whether what got built is good is a separate question. Please read them separately.
On that basis, I keep the state from ever producing a giant diff. Not "what do I do with unreviewable code" — don't get there.
I do write plans. 351 of them. But the AI writes them.
To be clear, I'm not building with nothing written down.
351 files in plans/
features 166 / fixes 132 / cleanups 37 / other 16
278 of them (79%) carry an issue number
But these are not specs. They're the steps for clearing one issue. And the AI writes them — I read and judge.
The order looks like this:
1 I notice "this is wrong" while using it
2 I open an issue ← me. deciding what to do
3 the AI writes the steps ← automatic
4 I read it, correct it ← me again
5 it gets implemented ← automatic
The AI can only write step 3 after step 2 is settled. For something where what-to-do isn't decided, having it write is pointless. As above: plausible output appears, and whether to take it is still my call.
Which is to say —
You can only write it once the shape is already known.
Our own process turned out to be the inverse statement of the argument. I'm not rejecting writing things down. I'm keeping to the conditions under which it can be written.
Adding one person doesn't add just one channel
From here on, this is about having more than one person. If you work alone, feel free to skip.
Judgement and alignment grow with the number of channels, not the number of people. It's pairs, so for n people it's n(n-1)/2.
| People | Channels | vs. 2 people |
|---|---|---|
| 2 | 1 | — |
| 3 | 3 | 3× |
| 4 | 6 | 6× |
| 5 | 10 | 10× |
| 8 | 28 | 28× |
| 10 | 45 | 45× |
Go from two to four and you double the hands — and multiply channels by six. At eight, four times the hands and twenty-eight times the channels.
This is a simplified model; not everyone talks to everyone. But it does show that what grows when you add someone isn't only hands. Brooks' The Mythical Man-Month — "adding people to a late project makes it later" — is rooted in the same place.
The question is what AI changed and what it didn't.
Before
what you gain implementation grows with headcount (n×)
what you pay channels grows as n(n-1)/2
→ there's a point where it stops paying, but below it the gain won
Now
what you gain implementation the AI produces it; barely tied to headcount
what you pay channels still n(n-1)/2. unchanged
→ the gain side shrank; the cost side stayed
At least the reason "we need more hands to write it" got weaker, while the price of adding people stayed put.
This connects back to the former CTOs
Earlier I mentioned CTOs from Workday and You.com joining Anthropic as individual contributors. I think that's this formula too.
Lead a large organisation and you get implementation capacity proportional to headcount. At the same time, you carry n(n-1)/2 channels. A decision only becomes real after it has been through all of them.
What happens if you step off that?
take it from an organisation capacity × headcount + carry n(n-1)/2 channels
take it from AI capacity + one person's worth of channels
Sit somewhere you can focus purely on judgement and use AI without limits. Get the implementation capacity from the AI rather than from an organisation.
None of them said this, of course, so this is my reading. But looking at what the people closest to the frontier just gave up and what they went to get, it points this way.
What they gave up was the organisation. What they went for was distance — between judgement and the AI.
That said, the formula doesn't give you a number
This formula does not produce "so the optimal number is N." Channel count is neither productivity nor decision speed. All the formula says is that one side of the scale got lighter; the specific number comes from my own experience below.
There's a ceiling on how much you can run in parallel
The same thing happens inside one person. Honestly, here's mine:
Within one project
just skimming and judging about 10 is reachable
thinking about design 5 is the limit
Across projects
work that takes no thought 3 to 4 projects
dependencies / design work /
chasing a repro can't parallelise (1)
The tool can show nine. The one that can't is me.
And adding "one more, I can probably take it" slows everything down. The closer your own utilisation gets to 100%, the more sharply the agents' waiting time grows (picture a convenience store with one register and a clerk who is essentially never idle — a small bump and the queue stretches).
So the way to raise parallelism isn't "add agents," it's reduce the part that can't move without you. Decide design up front, write the repro steps first, cut dependencies early. Though that carving-out is also your work, so it never reaches zero.
Which leads to: teams should be small too
Everything up to here holds for one person. What follows is the multi-person case.
The variable that should set headcount is not implementation volume. It's the amount of judgement. By judgement I mean setting priorities, settling design, deciding how exceptions are handled — the kind of decision that loses accuracy when handed to someone else.
The premise of sizing by implementation volume has broken down, at least around me, because implementation volume no longer tracks headcount. What's left is judgement, and splitting judgement is where the formula above bites.
So here's where I land.
If you're building something whose shape isn't settled yet, and the owner can touch the code:
one to three people per product.
The owner, or someone who can back them, does the implementing.
This is not a universal optimum. It's a conditional rule of thumb. It roughly holds when these are true:
- What to build isn't fully decided — you're still exploring the shape
- The product's owner can touch the code — the decider is at the keyboard
- One person can hold the whole thing in their head — when they can't, that's your split line
- You can ship on your own judgement — no approval queue
If any of those is missing, you can't cut headcount. Work that needs deep specialist knowledge, anything running 24/7, industries where the author legally can't review their own work. Those aren't headcount problems.
The two-pizza rule isn't about meetings any more
Amazon's two-pizza team idea was, originally, a design principle for small autonomous teams — meetings being part of it. When implementation needed people, capping communication on top of that was the rational move.
Implementation no longer scales with headcount. What's left is judgement, and judgement is what eats alignment cost.
then "we need the people. at least keep meetings and teams small."
now "we don't need the people. the unit of building can be small."
There are things you genuinely want more people for
Read this far and it may sound like "cut headcount, always." It isn't.
The only thing that should be small is the unit of building.
- The number of ideas — more is better
- The number of people giving you feedback — more is better
- The number of people using it — more is better
As in Example 1, I did not find out that the purpose was wrong until I asked four people. That doesn't happen without people around you.
So it splits like this:
the unit of building smaller is better because judgement can't be divided
the people around it more is better because it grows the material for judgement
That "around" is your community, and your company.
Separate the place you build from the place opinions gather. Two people inside is fine; outside, more is better. If anything, the smaller you make the unit of building, the more you need material from outside — with fewer people inside, your perspective narrows.
Cut people per product, not people
Easy to misread, so: this is not "turn eight people into two."
✗ make eight people into two
✓ stop putting eight people on one product
→ 2 people × 4 products
Reduce the headcount per product, not the headcount.
Though, as above, three or four projects at once only works for the low-thought work. If all of them are in design mode, one is the limit — so "two people, therefore six to eight products" doesn't follow. In practice it's one you're thinking hard about, plus a few you're coasting.
In the end, this is what I think it comes down to
I've written a lot above, but the essence is one line.
The product's owner, in a small group, building it while using it themselves in detail.
That's the shape I think fits building products in the AI era.
If you aren't the heaviest user, it won't get good
In Example 1, the purpose I built it for turned out to be wrong. The only reason I caught that is that I use it every day too.
If I didn't, someone saying "I can handle the same number more easily" would mean nothing to me. I wouldn't know the weight of the answer.
The material for judgement only accumulates through use. A tool its owner doesn't use can't be fixed by anyone's judgement.
You probably don't need to be a strong programmer
This is the hopeful part, I think.
What's required is being clear about what you want to build, and being able to look at the output and say "no, not this." Not writing code quickly.
If you have those two, an era where non-engineers build good products is coming into view. If anything, the clearer you are about what you want, the more the leverage pays.
But you can't just hand it off
You give the AI the spec and the implementation, and what comes out is "somehow not right."
Of course it is.
Without settling the details yourself, you don't get a product with substance. Micromanagement is not usually a compliment when the subject is a person. With an AI, though, I think it's simply the correct approach.
It doesn't complain. It'll redo it as many times as you like. So you may as well push until you're satisfied.
What this post said
- Rescuing "too big to review" with review alone is very hard. The answer is to not get there
- The cause is writing a big spec up front. This happens when you work alone too
- You can't write a spec for something when you don't know if it's possible or whether you want it
- This isn't AI's fault. Specs were wrong in the human-only era too, and nobody could tell until they touched it
- Even when AI helps write the spec, deciding whether to take it is still you. The tool got smarter, not you
- Leverage is a multiplier, not the number being multiplied. Without something to multiply, it means nothing
- Adding people grows channels as
n(n-1)/2. Hence one to three per product (a conditional rule of thumb)
Handing over a big spec and letting it build in one go is buying a single lottery ticket where you don't learn the result until the end. And if you try to fix that by writing the spec in more detail, where you arrive is implementation. Same effort — write the one that runs.
Rough out the base, then work alongside it, using it yourself in detail. That isn't "being sloppy." It means increasing the number of judgements.
And the only person who can increase that number is the one sitting at the keyboard, using the thing themselves.
One small plug at the end
Every number above came out of building MulmoTerminal. And I'll admit it: it's also the tool for working the way this post describes.
Cut small and draw often, and this always happens:
Wait — which one is waiting on me right now?
Run three or four agents and you'll leave one waiting for tens of minutes without noticing. Since your own attention is what caps parallelism, everything stalls when that clogs.
I built it to solve that with cell colour, sound, and a push to your phone.
This tool is specialised for how far one person can run in parallel. There is nothing in it for splitting work across a team. If you're comfortable in a terminal and don't mind working in parallel, it probably suits you best.
In practice, ten is reachable
Earlier I wrote "measured, it's one to six." That was the result of asking four people.
I myself run about ten when I'm purely skimming and judging. Someone at a US startup I spoke to said twelve.
That may look like a contradiction. It isn't.
thinking about design 5 is the limit
just skimming and judging about 10 is reachable
Mix them and you get dragged down to the lower number. Which also means: reduce the things that can't move without you, and the number goes up.
Ten to twenty for one person. If you're comfortable in a terminal and don't mind parallelism, I think that's reachable.
Getting there doesn't take more agents. It takes exactly what this post has been about: cut to the smallest unit that needs a judgement, cut dependencies early, write the repro steps first. Shave down the part that can't move without you, as far as it will go.
What raises the ceiling isn't the tool. It's how tightly you work. Give it a go.
But the tool alone won't get you to ten
If you go and read every one of them thinking "is this okay?", you'll cap out at five. To grow the number you have to reduce the attention each one costs.
What I do for that is written up in the other posts in this series (Japanese):
- I stopped reviewing my own code — the whole picture of not breaking without reading
- Green is not evidence — whether the checks you have are actually checking anything
Without that machinery in place, ten in parallel doesn't hold. With it, your attention goes to judgement only.
It's all connected. "Cut small and run in parallel" here, and "don't break without reading" over there, are the same one thing written from two sides.
It runs on your own machine and you look at it in a browser. It starts with npx, so there's nothing to install first.
npx mulmoterminal@latest
# → http://localhost:34567
→ receptron/mulmoterminal (MIT)
If you're running things in parallel on your own, or with a small group, it may well help.
Top comments (0)