From swarm to protocol: a year of vibing, from noob to pro

At the height of my AI delusion, I had sixteen coding agents running at once: four apiece across my laptop, an iPad I’d hauled from home, and a couple of monitors at the office. I was completely sure I’d cracked it. What I’d actually done was make myself the single slowest part of my own system. And this was real production code at a startup I’d recently joined, so the delusion wasn’t free: every confident wrong turn got paid for downstream, sometimes caught by someone else before I caught it.

This post is the story of my agentic workflow’s evolution through seven distinct stages, starting from the stereotypical vibecoder setup of VS Code with code on one half of the screen and Claude Code on the other half, to an organized and coordinated multi-agent system comprising models from multiple providers running completely from the terminal.

TL;DR — I once thought sixteen agents at once made me a genius. In fact, I was a fool. It made me the bottleneck and taught me that an agent saying “done” is a claim, not a fact. It only meant it stopped talking, not that anything worked. Thus, “done” doesn’t count until a merge, a reviewed diff, or a test suite that actually ran and meant something says so. The fix wasn’t more agents, but the boring engineering that grew out of agents blowing up prod: a spec, a reviewed plan, scoped writes, an independent panel, and a skeptical human who won’t wave anything through. To be completely honest, it trades quality for throughput: it won’t make the output excellent, just keep it from collapsing into vibecoded slop-spaghetti. Quality now at least has a floor that isn’t rock bottom. However, it can’t replace an engineer. It’s just a prosthesis. That is, it only extends your reach, never your judgment, so the human at the last gate matters more as the agents improve, not less. Strip the agents out and what’s left is just engineering.

TL;DR of the TL;DR — Vibecoding, and its (disastrous) results, made me rederive engineering from first principles. It was just engineering the whole time. Always has been.

Stage 1: The Vibes

My first foray into vibecoding agentically-assisted programming came at CalHacks 12.0 last year,¹ where I got ahold of $150 of Anthropic API credits.

Over the weekend, my friends and I attempted, well, initially attempted, to build something that let an AI chatbot interact with multiple people in a single environment all at once.

We initially started building a Discord-esque chatroom to situate our chatbot within to demonstrate its ability to chat with many people simultaneously in the same place. Then, while that was being built out, we decided that a social deduction game not too dissimilar to Among Us² would be a great way of demoing its multiplayer capabilities. The setup: A queue of 3 to 8 anonymized players would be dropped in a chatroom with a chatbot placed amongst them, and then multiple rounds of voting/deliberation would be given after some time, with the players winning if the chatbot gets voted out, and the chatbot winning if there is only one other player left.

“Wow! That sounds like a lot to build out, even with gen-AI helping,” some of you may be thinking (or the complete opposite for some of you), and indeed it was. Due to my gross dereliction of duty — choosing to play poker on the concrete floor with strangers the first night, and a victorious poker tournament the second night³ — we barely finished building out a semi-functional Discord clone with an LLM wrapper (that was undemoable due to, again, the internet being uncooperative) and a Figma mockup of the videogame.

Honestly, for being a bunch of non-CS sophomores, I’d say we did pretty well!

My “process” for vibecoding the demo at this point was that of the stereotypical vibecoder’s — VS Code split into two with one half displaying the code and the other half being Claude Sonnet 4.5 (wow how far we’ve come with flagship models). There was little to no prompt engineering being done here, just straight up one-shot prompts like “build me a fully functioning chatroom”.⁴ Needless to say, this was not at all an effective nor mature way of building with agents… which led to features not working as intended with extended debugging periods following the initial “completion” of each minor feature.

Process I

1. Open up VS Code
2. Open the Claude Code panel
3. One-shot prompt the entire way through
4. Review the output

Gates

1. Output review (manual)

Wiring

flowchart TD
    YOU(["You"])
    AGENT["Claude"]
    REVIEW{"Eyeball it"}
    SHIP(["Ship"])

    YOU -->|"one-shot prompt"| AGENT
    AGENT -->|"code"| REVIEW
    REVIEW -->|"bugs / mismatch"| YOU
    REVIEW -->|"looks done"| SHIP

The board

Problem	Status
“Done” isn’t done	🟥 open

Stage 2: The Plans

Fast-forward a couple months and… poof. All of a sudden, I’m a college dropout! A founder I knew was looking for engineers to help build his startup. Disillusioned with a future in academia, I applied to the job, took a short interview, attended a week-long work trial, got my offer, and then clicked that button that submitted my withdrawal request from my alma mater UC Berkeley. That’s roughly when the hackathon toy problem became a production problem.

Given the velocity at which one is required to build and ship features in order to grow the company at a startup, the CalHacks workflow was no longer sufficient — I had to ship real production systems with a tiny team and not drown. When you’re tasked with “build a planning engine in two weeks,” you either start effectively wielding agents or you become the bottleneck — dead weight in a team of less than 10 people is not something I am keen on being.

Having learned my lesson from my previous vibecoding experience, I evolved my process into something a bit more appropriate, or at least what I thought of as appropriate, for the workspace.

Using the stereotypical vibecoder’s setup as a jumping-off point, I realized that building stable production software is completely different from building a demo, and that requires more than a well engineered prompt, but rather a well written plan for agents to follow.

Initially I tried writing out plans by hand but realized that, without the experience of decades+ of senior engineers, it was exceedingly tedious and slow, kinda what you don’t want at a growth-minded startup. Luckily, however, after just a couple of hours going about this the wrong way, I found out that Claude Code actually had a native planning feature built in! Huzzah! Now it can draft me plans and output a full spec doc ready for my review — IMO it is certainly much easier, at least in the sense of documentation, to review rather than to write.

With the reckless one-shots removed, the number of holes the agent left in their implementation, and with it the length of the cycle of prompt-till-no-visible-bugs, decreased by a non-trivial amount; a simple addition of a small gate before sending off an agent to implement was an incredibly cheap win. However, the bugs never really stopped coming — they only got more subtle. Every half-fix still bred the next one that failed in quieter, harder-to-spot ways; fix begetting bug begetting fix, like an ouroboros that ate its own tail and called it progress. This will be a recurring issue throughout the journey, though it does get smaller and smaller as we go along.

Process II

1. Open up CLion (not VS Code anymore, working on C++)
2. Open the Claude Code panel
3. Prompt Claude to start plan mode
4. Review the finished plan and make/prompt edits
5. Send Claude off to implement
6. Review Claude’s final output

Gates

1. Plan review (manual)
2. Output review (manual)

Wiring

flowchart TD
    YOU(["You"])
    PLAN["Claude<br/>plan mode"]
    PLAN_REVIEW{"Plan review"}
    IMPLEMENT["Claude<br/>implement"]
    OUTPUT_REVIEW{"Output review"}
    SHIP(["Ship"])

    YOU -->|"prompt"| PLAN
    PLAN -->|"spec doc"| PLAN_REVIEW
    PLAN_REVIEW -->|"revise"| PLAN
    PLAN_REVIEW -->|"approved"| IMPLEMENT
    IMPLEMENT -->|"code"| OUTPUT_REVIEW
    OUTPUT_REVIEW -->|"bugs / mismatch"| YOU
    OUTPUT_REVIEW -->|"looks done"| SHIP

The board

Problem	Status
“Done” isn’t done — now called the vibecoding ouroboros	🟨 smaller — a plan gate helps, but the bugs just get subtler

Stage 3: The Swarms

Ok, so, quick preface, some may view this stage as a regression from the previous stage, but I think it’s more fair to see this as a separate path that developed near-concurrently rather than a sequential progression from Stage 2.

Anyways, I was quick to realize that one agent shipping everything simply wasn’t going to do — implementation often took far too long, sometimes over an hour or so! This is when I decided to copy the setups I’ve seen on twitter X and Reddit and other places online, where people often had many agents running at once. I then had the brilliant idea to get two more screens (on top of my MacBook and the monitor it was connected to); at work I was able to procure a leftover monitor as an additional screen after the other work trialists left and brought an iPad I had from home with me. I then decided to run not just one, nor two, nor four agents at once, but four on each of my four screens — a MacBook, an iPad, and the two monitors — for a total of 16 concurrent. I recall once where I managed to cram eight agents on one single screen operating all at once! (I have no clue how I did it back then)

I usually split the 16 agents up into two teams, with one planning agent and seven implementation agents. The protocol was kept mostly the same except while planning I directed each planning Claude to parallelize it up to seven lanes for the implementation agents by outputting prompts to give to each agent (note this was BEFORE Claude Code Agent Teams was a thing, and far before it got out of the experimental phase). And yes, I believe there was once where I had all 16 on a single team! Doing this I was able to cut down implementation time from around an hour to around half an hour or less for most tasks.

When I got to this point, I saw myself “handling” the 16 agents and thought to myself: “Wow, I am such a genius!” as one would typically say at the top of Mount Stupid on the Dunning-Kruger curve.⁵

For disjoint work, the throughput gain was significant. However this led to five compounding problems:

1. Coordination: I was the coordination layer and I don’t scale — textbook Mythical Man-Month, except that every message was routed through me rather than amongst the agents themselves.⁶ The “swarm’s” speed was capped not by the agents but by how fast I could read, summarize, and re-prompt. The entire time I felt like I was a 20th century switchboard operator.

2. Context fragmentation: Context was fragmented across independent agents. Each agent saw its slice and made locally reasonable decisions that were globally incompatible. The canonical disaster: two agents touching opposite sides of an internal API, each “fixing” the contract toward its own caller. Both diffs looked clean in isolation and they merged without issue. However, when it was deployed onto a dev mirror (yes I did NOT push to prod :D), it took a while to figure out why data didn’t make it through an internal service boundary. Yikes, a rather important bridge sabotaged by agents unaware of each other’s plans.⁷

3. Edit collisions: I did not have agents work in separate worktrees — they were all working on the same one and only local checkout I had on my machine, leading to an abundance of race conditions which slowed stuff down a lot when different agents tried to edit the same file.

4. Mid-flight visibility: I lost the ability to see what each individual agent was doing throughout implementation; it was hard to examine exactly what and how each line of code was being edited. Whether or not an agent was going sideways was now mostly based off of vibes while it was running and its final output.

5. Token burn: And the worst of all — it took up a helluva lot of tokens. Sixteen agents all at once on the top-tier Opus 4.5 model drained accounts relatively quickly.

my friends and me routing more than a dozen operators each, if I had any friends that is.

I want to especially flag the first two problems, because it took me embarrassingly long to see them as structural problems rather than vigilance problems. The clean tell: the obvious fix for the edit collisions — giving every agent its own worktree — would’ve done nothing for the first two. I would’ve still been the router, each agent still seeing only its own slice; the collisions were a config problem, but the first two were the topology:

The swarm wasn’t failing because I wasn’t paying enough attention — it was failing because I’d made myself the coordination layer.

This will come back later…

Process III

1. Open up CLion
2. Set up 4 displays and open up 4 tabs of Claude Code on each
3. Prompt Claude to start plan mode
4. Instruct Claude to plan for parallelization
5. Review the finished plan and make/prompt edits
6. Signal to planning agent for the first batch of prompts
7. Dispatch to each agent their prompt
8. Review each PR generated at each step of the stage and either merge or pass back issues
9. Signal to planning agent for next batch of prompts
10. Repeat 7 through 9 until done
11. Review their final output

Gates

1. Plan review (manual)
2. Output review (manual)

Wiring

flowchart TD
    YOU(["You, the switchboard"])
    PLANNER["Planning agent"]
    PLAN_REVIEW{"Plan review"}
    A1["Agent 1"]
    A2["Agent 2"]
    A7["Agents 3-7"]
    OUTPUT_REVIEW{"Output review"}
    SHIP(["Ship"])

    YOU -->|"prompt + parallelize"| PLANNER
    PLANNER -->|"plan doc"| PLAN_REVIEW
    PLAN_REVIEW -->|"revise"| PLANNER
    PLAN_REVIEW -->|"approved"| YOU
    YOU -->|"lane 1"| A1
    YOU -->|"lane 2"| A2
    YOU -->|"lanes 3-7"| A7
    A1 -->|"code"| OUTPUT_REVIEW
    A2 -->|"code"| OUTPUT_REVIEW
    A7 -->|"code"| OUTPUT_REVIEW
    OUTPUT_REVIEW -->|"bugs / next batch"| YOU
    OUTPUT_REVIEW -->|"looks done"| SHIP

The board

Problem	Status
The ouroboros	🟨 still there
Coordination — I’m the router	🟥 new
Context fragmentation	🟥 new
Edit collisions	🟥 new
Mid-flight visibility	🟥 new
Token burn	🟥 new

Stage 4: The Superpowers

After just a day or two of cosplaying a switchboard operator with the agent swarm, I realized that the plans Claude was writing were too high-level for any sort of reasonable execution/coordination outside of a one-shot attempt; these high level spec docs lacked a detailed implementation plan, which was a major contributor to the fragmentation and edit-collisions that plagued the swarm.

As luck would have it, as I googled “top 10 must have skills and mcps for vibecoding,” and browsed through several clearly AI-generated slop skills, I stumbled upon obra’s Superpowers. Let me tell you, it was like finding gold in a pile of gravel.

I then immediately went /plugin marketplace add obra/superpowers-marketplace, added the skill, and immediately went right into using it. It was a complete game changer — the brainstorming and writing-plans subskills provided crucial improvements to the workflow! Instead of having a single one-shotted high level spec doc, brainstorming actually ran me through most of the big architectural and design choices and recommendations with reasoning — I actually had a say in what the agent was going to output before it wrote a doc with no reasoning behind why it chose that specific design. Additionally, it produced a detailed implementation plan with specific lines of code and files to edit that stipulated test-driven development rather than requiring me to add it in myself or prompting the agent to add it. Though, I still had to instruct it to parallelize the plan afterwards.

Now, agents stopped sprinting headfirst into implementation with some high level plan and half-assed prompts with vague implementation directions and instead had a properly written and tailored spec doc along with a detailed implementation plan to work off of — “done” started meaning something in the rough neighborhood of done, and the gargantuan ouroboros of bug -> fix -> bug had significantly decreased to just a short period of post-implementation churn (calling it PIC, from now on) — the terrible plague that afflicted many vibecoders was slowly turning into a myth (or a fable, if you’d prefer), well for me at least.

Within a single Superpowers cycle from brainstorm -> PR, context fragmentation mostly stopped as every agent worked off the same detailed implementation plan and thus their local decisions stopped colliding. An additional win was that each agent’s file assignment was in the plan itself so they didn’t wander off onto another agent’s assigned file — though, nothing actually stopped them from colliding since they were still sharing the same worktree; there was only prose keeping them in line. Sure this probably was enough but it wasn’t exactly as persistent as an agent skill, so it was still very fragile — when a session autocompacted, it would often forget what file it was permitted to edit and veer off of its assignment. For the most part though, fragmentation and collisions mostly stopped, and now only really existed between separate Superpowers cycles and random freak edge cases.⁸

It still had problems, though. Most importantly, I’m still the bottleneck in terms of distribution and coordination between agents in large swarms — plans and spec docs still had to be manually reviewed, though, again, it was much easier to answer a couple of design questions and review a full doc rather than materialize it yourself; mid-flight visibility still hadn’t been solved — while Superpowers spec and planning docs did cut down on the chances of an agent going sideways, it could still happen; and tokens were still being burned at an incredible rate, requiring nearly two $200 Claude Max subscriptions’ worth of weekly usage.

However, the part that stuck with me wasn’t Superpowers itself, nor any of the subskills it provided. It was realizing one thing:

You can ship discipline as plain text.⁹

There was no bespoke harness and no deterministic push in general; just a couple of short, well-written directives dropped into the context of every agent were enough to make sure what was implemented was as intended and reduced the effects of each independent agent having independent contexts.

Process IV

1. Open up CLion
2. Set up 4 displays and open up 4 tabs of Claude Code on each
3. Prompt Claude with /superpowers:brainstorming
4. Answer all of its design questions
5. Review the finished spec doc and make/prompt edits
6. Prompt Claude with /superpowers:writing-plans, with specific instructions for parallel implementation
7. Review the finished plan doc and make/prompt edits
8. Signal to planning agent for the first batch of prompts
9. Dispatch to each agent their prompt with /superpowers:executing-plans
10. Review each PR generated at each step of the stage and either merge or pass back issues
11. Signal to planning agent for next batch of prompts
12. Repeat 9 through 11 until done
13. Review the end output

Gates

1. Design choices (manual + Claude)
2. Design review (manual)
3. Plan review (manual)
4. Output review (manual)

Wiring

flowchart TD
    YOU(["You, still the switchboard"])
    BRAINSTORM["Claude<br/>brainstorm"]
    DESIGN_CHOICES{"Design choices"}
    DESIGN_REVIEW{"Design review"}
    PLAN["Claude<br/>plan"]
    PLAN_REVIEW{"Plan review"}
    A1["Agent 1 (+TDD)"]
    A2["Agent 2 (+TDD)"]
    A7["Agents 3-7 (+TDD)"]
    OUTPUT_REVIEW{"Output review"}
    SHIP(["Ship"])

    YOU -->|"/brainstorming"| BRAINSTORM
    BRAINSTORM -->|"design Qs"| DESIGN_CHOICES
    DESIGN_CHOICES -->|"answers"| BRAINSTORM
    BRAINSTORM -->|"spec doc"| DESIGN_REVIEW
    DESIGN_REVIEW -->|"revise"| BRAINSTORM
    DESIGN_REVIEW -->|"/writing-plans"| PLAN
    PLAN -->|"plan doc"| PLAN_REVIEW
    PLAN_REVIEW -->|"revise"| PLAN
    PLAN_REVIEW -->|"approved + parallelized"| YOU
    YOU -->|"lane 1"| A1
    YOU -->|"lane 2"| A2
    YOU -->|"lanes 3-7"| A7
    A1 -->|"code"| OUTPUT_REVIEW
    A2 -->|"code"| OUTPUT_REVIEW
    A7 -->|"code"| OUTPUT_REVIEW
    OUTPUT_REVIEW -->|"bugs / next prompt"| YOU
    OUTPUT_REVIEW -->|"looks done"| SHIP

The board

Problem	Status
Post-impl churn (PIC)	🟨 smaller again — real plans + TDD
Coordination	🟥 still me
Context fragmentation	🟨 held by the plan, in-cycle (fragile)
Edit collisions	🟨 held by the plan, in-cycle (fragile)
Mid-flight visibility	🟥 still tricky at scale
Token burn	🟥 still brutal

Stage 5: The Pairs

After barely a week of commanding swarms of agents, it became rather clear that it was neither sustainable nor efficient; RPing as a switchboard operator was burning me out, QA was difficult, and I was burning through usage limits at a ridiculous rate.

So I did the unthinkable for someone who’d just set up parallel agent swarms — I killed it. All of it. Back down to just one or two agents at a time for a single task, with no more than two or three tasks at once.

It felt like a demotion, honestly. I’ll admit, at the time I felt like the God-Emperor of Agentkind commanding the swarm of 16 frontier models at once, only to fall to the level of some L3 engineer handling just a couple of bumbling idiot interns. However, I realized that me manually reviewing everything was too high a cap on throughput while also insufficient due to my lack of engineering experience, and, by extension, a lack of knowledge of specific/subtle techniques, architectural choices, and pitfalls (after all, it was my second or third week ever of building production software).

Traditionally, this is where you’d pull up Google and try to find analogues to your problem at hand, and, if it somehow didn’t exist, go on StackExchange, make a post about it, and get downvoted into oblivion with unhelpful snarky comments — or if you’re lucky, a comment that said “duplicate issue” with a link to a post from 15 years ago that was quite clearly outdated.

Anyways, I digress. But I thought of a solution to this: why not just get an agent to review it?! Well, two catches:

1. it can’t be the same agent that wrote the plan or did the implementation, for obvious reasons with bias,

2. and I’d have to review the plan anyways.

Well, I didn’t want to feel like I was slacking with just two or three tabs of Claude Code running, so I decided to get fancy and pair each instance up with a Codex agent. As for why I partnered it with Codex instead of another Claude instance? Well, you see I wanted an agent to adversarially review every single artifact outputted, whether that be a spec doc or a git diff — I had a gut feeling about how the models in the same family would tend to agree with each other more compared to using different models, mostly since models within the same family would have overlapping datasets and similar training methods, leading to minor shared biases, even if they were technically independent instances;¹⁰ I also did not want to use a lower-intelligence Claude model. Thus the natural choice was to just use the frontier model from Anthropic’s primary competitor, namely OpenAI’s flagship coding agent at the time — GPT-5.2-Codex.

Additionally, I moved the implementation to Codex. As for why? Well, I’ve encountered many anecdotes online that, in general, stated Codex was better at following instructions than Claude,¹¹ and instruction-following is quite important for an implementation agent. Also, I was trying to split usage roughly evenly across both my Claude Max and GPT Pro subscriptions to make them last longer, though I was no longer running 16 parallel agents so that was probably moot. Unfortunately, token usage remained roughly the same per cycle. Buuuuuut… (big but), tokens were being used more efficiently — rather than being spent on ad hoc in-cycle management of agent swarms, it was being allocated towards an upgraded planning cycle which would ultimately lead to fewer bugs and thus fewer tokens would be spent on remediating these bugs.

Eventually, after a couple hours of playing around with the, now named, agent-pair framework, I converged on the following structure:

• Claude, the planner, owns the framing, the audit, the design, the plan, the acceptance criteria. It does not write any code.
• Codex, the implementer, runs its own independent audit before it ever lays eyes on Claude’s artifacts, picks apart Claude’s audit, spec, and plan docs looking for holes and gaps, and after all is reconciled, gets dispatched to implement in accordance with the plan doc.

With just a single agent-pair, coordinating seemed almost trivial after going through an entire week or so managing a complicated web of agents in a swarm — I only had to relay information between two agents, two panels. Moving terminal text back and forth between Claude and Codex before they both converged sometimes felt almost too mechanical. However, it was necessary as I was unaware of any better method for having the two models communicate with each other while also maintaining interactivity.

Now that I only had one agent implementing per pair, I was able to also more closely monitor exactly what it was implementing and stop it the moment I felt or saw it going off track, and easily rectify any issues, basically resolving the mid-flight visibility problem from the days of the swarm.

Anyways, over the course of running this structure for just a few days, I learned three things that made the lost parallelism worth eating:

1. Two independent audits of the same problem may disagree. When neither agent has seen the other’s take yet, they can come back with different maps of the same territory. Sitting them down to reconcile — here’s what we agree on, here’s what we don’t, here’s where we just looked at different things — and forcing the two to correct each other allowed a more complete examination and, in many cases, caught completely incorrect architectures, prevented reimplementing something that already existed, and corrected data schemas, all before a single line of code was ever committed.

2. Confining implementation to a single separate model kept context intact the whole way through, which turned the Stage 4 fixes for fragmentation and collisions from a behavioral fix into a structural fix: one model holding the entire context, with the schema contracts already locked into the reviewed plan, meant collisions and API contract mismatches just stopped — within a single Superpowers cycle, at least. Across separate cycles, contract drift could still sneak back in. Also, it actually didn’t restrict throughput as much as I thought it would. Locally yes, implementing a single task took longer due to the lack of parallelism, but this allowed me to parallelize by being able to more efficiently manage one or two more other agent-pairs while not reaching the level of mayhem that was coordinating eight or even 16 agents all at once on one or two tasks.

3. With the consolidation of implementation back to a single agent on a separate model family, the PIC decreased further, but didn’t vanish completely — only now, instead of being several very obvious problems, it became just a couple of tiny, barely noticeable, yet critical, issues (more on that in a bit).

I was still a huge bottleneck in the entire system, having to step in at quite a few places, but the tedium of handing off several relays to a swarm of agents no longer existed. This really made coordination less of a hassle since I no longer had to frequently relay prompts to a swarm of agents during the implementation phase; I went from being actively involved in everything from planning through relaying multiple batches of prompts during implementation and review, to really only the planning and review phases, you know, the more important parts.

But — and you can probably already see the next pothole coming — this stage still had only me reviewing the finished work. The big new issue is something the swarm never had as the swarm was at least incoherent in obvious different directions. On the other hand, two agents, even if from two different model families, stewing in the same conversation reaching shared conclusions, will tend to be wrong together, often in very very subtle ways — resulting in correlated errors.¹² There was that one time where a single memory leak caused by both Claude AND Codex misinterpreting an aliased type led to my MacBook going OOM and crashing; it took several crashes and a couple of hours before it was finally diagnosed and fixed. Despite using two different model families, the decorrelation afforded by doing so only had the strongest protections for the initial independent audits, and the moment I set them both on a convergence course, that protection evaporated.

The agents no longer disagreed chaotically — they just agreed a tad too easily.

Also, worth a tangent, during this stage I moved off of CLion¹³ and onto just having only terminal windows open, with documents and code being opened up in nvim whenever needed.

I won’t be writing out the long step-by-step list of actions anymore. From here on it’d be too long to be readable and won’t be all that useful as the flow chart will be a superior visual tool. In lieu of the sequential steps, here’s a table of who owns what and (more importantly) what each one isn’t allowed to touch:

Roles

Role	Owns	Forbidden from
Claude — planner	framing, audit, design, plan, acceptance criteria	writing a single line of code
Codex — implementer	its own independent audit, picking apart Claude’s docs, the implementation	changing the agreed scope or design
Me	reconciling the two, the final review and merge call	letting vibes count as verification

Gates

1. Auditing the codebase (Codex + Claude)
2. Design choices (manual + Codex + Claude)
3. Design review (Codex)
4. Plan review (Codex)
5. Output review (manual)

Wiring

flowchart TD
    YOU(["You (juggling 2-3 pairs)"])
    PLANNER["Claude<br/>planner"]
    IMPLEMENTER["Codex<br/>implementer"]
    AUDIT_RECONCILE{"Audit reconcile"}
    BRAINSTORM["Claude<br/>brainstorm"]
    DESIGN_REVIEW{"Design review<br/>(Codex)"}
    PLAN["Claude<br/>plan"]
    PLAN_REVIEW{"Plan review<br/>(Codex)"}
    IMPLEMENT["Codex<br/>implement"]
    OUTPUT_REVIEW{"Output review<br/>(you)"}
    SHIP(["Ship"])

    YOU -->|"audit prompt"| PLANNER
    YOU -->|"audit prompt"| IMPLEMENTER
    PLANNER -->|"audit doc"| AUDIT_RECONCILE
    IMPLEMENTER -->|"audit doc"| AUDIT_RECONCILE
    AUDIT_RECONCILE -->|"/brainstorming"| BRAINSTORM
    BRAINSTORM -->|"spec doc"| DESIGN_REVIEW
    DESIGN_REVIEW -->|"revise"| BRAINSTORM
    DESIGN_REVIEW -->|"/writing-plans"| PLAN
    PLAN -->|"plan doc"| PLAN_REVIEW
    PLAN_REVIEW -->|"revise"| PLAN
    PLAN_REVIEW -->|"converged + dispatch"| IMPLEMENT
    IMPLEMENT -->|"code / PR"| OUTPUT_REVIEW
    OUTPUT_REVIEW -->|"bugs"| IMPLEMENT
    OUTPUT_REVIEW -->|"looks done"| SHIP

The board

Problem	Status
Post-impl churn (PIC)	🟨 down to a couple subtle-but-critical issues
Coordination	🟨 reduced — still me, just less of me
Context fragmentation	🟨 structural in-cycle, but still exists cross-cycle
Edit collisions	🟩 structural, in-cycle
Mid-flight visibility	🟩 closed — though only by dropping back to one or two agents I can reasonably watch
Token burn	🟨 same cost, better spent
Correlated errors	🟥 new — wrong together (→ Stage 6)

Stage 6: The Reviews

February 5th was quite the exciting day, as I remembered it. It was the day where both Claude Opus 4.6 AND GPT-5.3-Codex dropped within half an hour of each other’s release. The models were most definitely a welcome upgrade to 4.5 and 5.2, respectively, but Anthropic shipped another experimental feature right under the new frontier model releases — Agent Teams.

When Anthropic shipped Agent Teams, I initially tried it out by resurrecting the swarm from a couple of stages ago. It, uh, didn’t go very well. The issues mainly came from the overhead caused by running multiple Claude Code agents at the same time — it burned tokens inefficiently, which led to usage limits running out mid-run, and switching accounts was a bit annoying since I had to keep asking for a token each time I switched. It also wasn’t that much faster than just having Codex do all the implementation on its own for some reason.

Feeling like the feature was more of a novel experiment and less groundbreaking, I almost put it off. That is until I read the documentation a bit more thoroughly and I found the following example prompt:

Create an agent team to review PR \#142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

“Hmm, might as well try it and see, perhaps it can find both the subtle and the glaring flaws in the code implemented.” And thus, at the end of implementing this feature, I just copied and pasted that exact prompt into the planner, Claude, only replacing the PR number while also indicating which repo on which branch. Lo and behold, it outputted a list of issues to be fixed in the codebase, labeled by concern and marked with severity.

There was something lacking though as security, performance, and test coverage weren’t entirely everything that should be reviewed when shipping a feature — correctness against the specified design and implementation plan docs was pretty, nay, probably the most important thing that needs to be checked. Thus I changed it from three to four reviewers and added another line to the prompt:

- One validating correctness with respect to the design and impl docs above

This was possibly by far the best upgrade throughout this vibecoder -> agentic engineer arc, especially in terms of the effort-to-reward ratio. Now, with a team of dedicated adversarial reviewers with absolutely no involvement in the planning/implementation, I was able to gain another look from a different perspective that would ultimately reveal shortcomings caused by the two agents in the pair converging. That is, the correlated errors were now being discovered much more easily.

Anyways, while working on the core engine, I soon thought of another necessary addition to the standard team of four. From working with these coding agents, I found that, when writing C++, they typically defaulted to only using C++11 or older features and idioms, with some amount of C++14/17 stuff thrown in. This isn’t too much of a shocker as a vast majority of their C++ training data was made up of legacy codebases, with a majority of them even being older than me. Obviously, since we weren’t dealing with a legacy codebase but rather building from scratch, we opted to utilize more modern (and memory-safe) features of C++20/23. We had to include directions in the repo’s AGENTS.md and CLAUDE.md to conform to C++20/23 standards — something we wanted confirmed at the end of implementation. This led to the inclusion of a dedicated idiomaticity checker whenever we were touching C++ code with the following prompt:

- One checking conformance to modern C++20/23 coding standards

Here I realized that it was very easy to add reviewers and modify their scopes whenever dictated by what was being implemented. Touching React modules? How about a specific reviewer for React? Making UI changes? How about a dedicated reviewer with Playwright to poke through your frontend? And so on…

After the planning agent collects the results of the team, it was fairly simple just to verify the issues and nits found were real and then copy-paste the issues over to the implementation agent for them to fix. Codex’s fixes were applied and passed back and another round of review by fresh reviewers commenced. I initially started off passing fix -> review -> fix back and forth until complete convergence but then later dropped to just 2 or 3 rounds tops. ¹⁴

Eventually, though, as the models got better and more work came onto my plate, I dropped down to just one round and a quick verification of whether everything highlighted in the original review was fixed. This was mainly a judgment call on my end as a tradeoff with throughput, and I only really dispatched multiple rounds when stuff like security or data schemas were touched, or when multiple gross errors/new revelations were found that naturally may have needed multiple rounds to reconcile.

This was the first time deep review gates (albeit agentic) existed at the end of my pipeline, and the catch rate embarrassed everything that came before. For example, the formerly common API contract drift problems, even between independent cycles, that plagued past stages were now able to be nipped very early before going live since some of the independent reviewers would, often unprompted, check against the other side of the contract. Though, this again was mostly behavioral and not structural.

Now, don’t get me wrong, there’s still a bunch of issues that this agent-pair + reviewer framework (we’ll call this framework agent-pair+ from now on) has, some new and some old:

1. The observant amongst y’all may have noticed that the independent panel is comprised of agents from the same model family as the planner — every single reviewer was either Opus or Sonnet, depending on what the planning agent was feeling at the time (this nondeterminism was also an issue, albeit small). This reintroduced the same-model bias discussed previously, only now it affected the review layer rather than the entire setup. One could perhaps use an entirely separate near-frontier model for reviewing (say, Gemini or DeepSeek for example) but that would mean a third $200 subscription (or, in the case of DeepSeek, API tokens) on top of the two Anthropic and OpenAI subscriptions, and it was hard to justify another subscription for a model family whose flagship was inferior (in software development contexts) to even the second-class frontier models of Anthropic or OpenAI — I didn’t think that the cross-model bias reduction was significant enough to balance against the lowered intelligence.¹⁵ Eventually though, throwing a third model into the mix would be smart if I were forced to use tokens, as many of these near-frontier models were way cheaper than their frontier counterparts. Also, I think it’s worth mentioning why the panel would have been the right home for a third family of models, provided that there was another family of models that were just as capable. Recall that the benefits of decorrelation only lasted a half cycle since they degraded through continuous back and forth till convergence, after which it disappears. The independent panel exists for one round and then gets restaffed with new agents the next so this convergence problem is moot.¹⁶

2. Instead of having to meticulously review the entirety of the implementation myself, I had to now review the reviewers and then still run a quick pass over the implementation anyways! Sometimes the panel would not only emit real findings, but also unnecessary nits (which, to their credit, did usually flag) and false positives. These were most noticeable when the original planning agent that spawned them was able to flag these nits and false positives, while also occasionally downgrading overplayed issues. Fortunately though the review panel was a rather cheap addition that ran on its own and took usually around 10 or so minutes, and the benefits gained from having another 4 pairs of metaphorical eyes reviewing the code — like being able to cover more ground and also knowing more, and sometimes better, than me — made this issue feel more like a justifiable tradeoff rather than a strict downside.

3. The largest issue by far is the same issue that plagued, not only this stage, but also the entirety of Stages 1 through 5 — namely, the issue of breadth. Every stage so far, including this one, only focused on improving the output of a single unit of work with better specs, richer plans, tighter review, fewer correlated mistakes, but none of them made the unit any bigger. An agent-pair+ was pretty much able to ship out an isolated small to medium sized feature on its own. Any larger and you’ll risk the spec doc being too high level and the implementation plan being too big for a single agent to handle. A bandaid fix for this was to manually direct the planner to split the implementation plan into multiple plans such that the implementer can execute in sequence. This kinda worked but wasn’t very elegant and still suffered from the spec doc being too high level. In the case where I didn’t do this, I had to split the development of features over multiple cycles, either over the same pair with repeated compaction of context or multiple independent pairs that required me to both determine how to organize as well as manually relaying context between them. That is, context fragmentation was a systemic issue with no resolution (yet). This ultimately led to me getting sloppy and complacent over time, and occasionally caused me to forgo the manual review gates I had set up.

4. And finally, of course, we were still racing through usage limits at F1 rates.

Despite these failures, the main takeaway of the agent-pair+ framework:

Parallelize reads, not writes.¹⁷

Reviewers are allowed to be orthogonal to one another even when they land in the same space since they’re each looking for different things, and even when reading the same thing, they’re at least coming from different angles. Also read collisions simply aren’t a thing the way write collisions are (duh). So the context-fragmentation tax and the collision issues that killed my Stage 3 and 4 swarms simply didn’t apply to them.

Looking back, I have come a long way from last October where I just kept prompting a single agent to death until the task looked done, and now, through just a couple of weeks of being tossed through the rings of fire of startup engineering culture, I’ve created a workflow that mimics a real engineering process with gates and active reviews nearly everywhere — and I used this agent-pair+ workflow nearly every time I did any sort of agentic development throughout the next four or so months.

Roles

Role	Owns	Forbidden from
Claude — planner	everything from Stage 5, plus spawning the review panel and collecting its findings	writing a single line of code
Codex — implementer	the implementation, and applying the review’s fixes	changing scope; reviewing its own work
Review panel — independent Claude agents	adversarial review by concern (correctness vs docs, security, performance, tests, idioms)	any hand in planning or implementation — they only ever read
Me	verifying the findings are real, routing fixes, the final merge gate	merging on vibes; treating “done” as a fact

Gates

1. Auditing the codebase (Codex + Claude)
2. Design choices (manual + Codex + Claude)
3. Design review (Codex)
4. Plan review (Codex)
5. Output review (manual + independent review Claude agents)

Wiring

flowchart TD
    YOU(["You"])
    PAIR_CYCLE["agent-pair+<br/>(audit → design doc → plan doc → implementation)"]
    PANEL["Claude spawns review panel"]
    R1["correctness vs docs"]
    R2["security"]
    R3["performance"]
    R4["test coverage"]
    R5["optional domain reviewer(s)<br/>(C++ idioms, React, Playwright...)"]
    FINDINGS{"Collect + verify real"}
    MERGE_GATE{"Merge gate (you)"}
    SHIP(["Ship"])

    YOU -->|"task prompt"| PAIR_CYCLE
    PAIR_CYCLE -->|"PR"| PANEL
    PANEL --> R1
    PANEL --> R2
    PANEL --> R3
    PANEL --> R4
    PANEL -.->|"per domain, as needed"| R5
    R1 --> FINDINGS
    R2 --> FINDINGS
    R3 --> FINDINGS
    R4 --> FINDINGS
    R5 -.-> FINDINGS
    FINDINGS -->|"real issues"| PAIR_CYCLE
    FINDINGS -->|"converged (1-3 rounds)"| MERGE_GATE
    MERGE_GATE -->|"bugs"| PAIR_CYCLE
    MERGE_GATE -->|"clean"| SHIP

The board

Problem	Status
Post-impl churn (PIC)	🟨 deep review gates catch most, but still exists
Coordination	🟨 still me (→ cracks at scale, Stage 7)
Context fragmentation	🟨 structural in-cycle; cross-cycle drift now occasionally caught in review, behavioral only
Edit collisions	🟩 structural, in-cycle
Mid-flight visibility	🟩 closed
Token burn	🟨 review adds cost, but high payoff
Correlated errors	🟨 caught by the independent review panel, buuuuut…
Same-model review panel	🟨 new — the panel is one model family; cross-checking can’t reach a blind spot they all share (→ a third family, when tokens force it)

Stage 7: The Teams

Over the course of the four or so months building with the agent-pair+ framework, its shortcomings, over time, snowballed and resulted in the codebase, in some places, being more tangled than TF2’s legendary coconut.jpg.¹⁸

Just recently, while working on something new, I took a step back and asked for a general audit of this one data pipeline before starting work. Turns out independent sessions had each reimplemented the same component several times. Another example was an incomplete database migration that reached deployment and silently dropped data before it was caught… oops.

These failures were obviously due to independent sessions touching the same surface area at different times, i.e. fragmented context. The pair + reviewer excelled at depth in a single local track, but it alone was incapable of the vast breadth that was required to properly build out large multi-domain features or refactors.

The immediate naive solution was, of course, to just have one single agent manage everything. Buuuuuuuuut (big but, again) this is impossible due to context limitations.

Sure with the introduction of each successive frontier model comes more context, better context management, better one-shotting, and by extension, wider breadth that a single agent could take on in one go. However, as many people who have actually worked with the agents know, this is mostly just a marketing stunt and the “one-shots” typically don’t work very well when placed inside of an already existing codebase since making just one new feature would require knowledge of how exactly everything remotely related to it connects.

This, of course, would far exceed the average ~256k token context limit of a single agent from half a year ago, and even the 1M context window that most frontier models can capably support now was not enough to store all the detail. This is also assuming that agents had perfect recall near max context length, which isn’t the case. According to research done in mid-2025 by Chroma, then frontier agents like Claude Opus 4, GPT-4.1/o3, and Gemini 2.5 Pro had suffered from serious performance degradation as context grew.

Note that, while the study was done nearly a year ago (a long time in the world of AI development), context rot is still an issue to this day — even according to Anthropic’s own introduction of Opus 4.6 where, while admitting to context rot being a problem, one of their top headline figures on a needle-in-a-haystack retrieval benchmark with 1M context was only 76% — a one-in-four error rate!¹⁹ On top of that, real life is often far rougher than a clean haystack so the true de facto number is probably way below that; and that isn’t even factoring in the possibility of ‘benchmaxxing’.²⁰

Going back to the Chroma paper, its run of the LongMemEval benchmark showed that a focused input of ~300 tokens beat out an entire context of ~113k tokens when agents were asked to both retrieve an answer and reason on it. The key takeaway is that models, even when given the information, reason worse when it’s surrounded by a lot of other irrelevant stuff. In our development setup, that would be the main thing holding back our agents from just having super long spec docs and implementation plans to build the entirety of a large, cross-domain feature with lots of sub features and lots of outgoing connections.²¹

Anyways, to solve this issue, I took inspiration from how DeepSeek V4 tackled the long-context tractability problem. V4 had just dropped and my YouTube feed was littered with videos about the release — in particular, its “revolutionary” solution to context rot. Naturally I watched a few of them (here’s one I remember watching), and a couple described the following method V4 uses to manage long context. In their architecture, they use heavily compressed attention (HCA) and compressed sparse attention (CSA),²² along with the typical sliding window context, to build three layers of context to be traversed, all at different depths. To illustrate this, take a book as a metaphor for session context, and suppose you’re in the middle of reading a book. The context is organized (roughly) like this:

1. HCA compresses every chapter to a sentence, and you read all of them, producing a dense but coarse summary of the entire book.

2. CSA then compresses every paragraph into a phrase, but you actually only read the ones most relevant to whatever questions you may have.

3. The local window is essentially the most recently read page, word for word.

A grossly oversimplified execution trace of an already oversimplified version of the system when you ask a question would go like this:

1. the model goes through HCA to find the chapters your question most likely relates to,

2. then uses CSA within that to find the most relevant paragraphs to your question,

3. and then, depending on how far back it is, the compressed context and/or the local exact context is read to help answer your questions.²³

The third layer is rather irrelevant for our purposes here since we’re not developing inside of the context of some LLM; thus, we can keep an exact copy of the codebase — our “context” — on hand at all times, which we do; it’s just the local checkout you keep on your dev machine and/or origin/main. The main thing to lift from this context management architecture is the high level design behind using HCA and CSA. In short, to manage a large amount of context, you need to have one guy manage a high level overview of the entire thing, and then dispatch more detailed and specific overviews relating to what you’re trying to do.

Before the machinery, the principle it all reduces to: by the end, the team ran on three rules: split ownership before writing, make handoffs persistent, and require explicit permission before action. Everything below is just the apparatus that enforces those three.

To facilitate this, I elected to recurse the general agent-pair structure one level higher. The structure I eventually converged on was the following:

1. At the top was a top level orchestrator-pair consisting of a ‘planner’, and a ‘reviewer’. In day to day work, I assigned Claude Opus 4.8 as the planner, and GPT-5.5 as the adversarial reviewer.

2. Then, the layer under consisted of two to five of the worker-pairs on the agent-pair+ framework, again with Opus 4.8 as the planner and GPT-5.5 as the implementer.

When developing a new feature, I would feed the pair a spec doc that simply listed what the feature had to include. Sometimes, that would go through a separate step of being passed to a chat model, like ChatGPT-5.5 on Pro Extended thinking and/or deep research,²⁴ to suggest tried-and-true architectures and designs, as well as suggested sequencing and timelines before getting passed into the orchestrator-pair. The planner would then dispatch auditing relays for codebase exploration — reviewed by the reviewer and me — to the subservient worker-pairs, who would each separately produce a pre-planning audit of their part of the codebase. The audit would then get passed back to the orchestrator-pair, where the planner would reconcile and consolidate the audits before using this info to generate and persist a more complete spec + roadmap document from the initially inputted spec doc. This doc would be the key point of reference for the orchestrator-pair in what to dispatch.

On each new item in the roadmap, the orchestrator-pair ran the following loop (starting off from fresh context each time):

1. The planner cut the item into one or more work bundles, partitioned so that no two simultaneously-active pairs owned the same surface area.

2. For each bundle, the planner drafted a dispatch down to a subservient worker-pair to either start the Superpowers cycle (from Stage 6 above) from the auditing phase, the design phase, or the planning phase, reviewed and checked off by the reviewer and me before it went out.

3. Each receiving pair kicked off the Superpowers cycle from the designated starting point on its own independent bundle.

4. On the PR(s) being deemed merge ready by the worker-planner and the panel of reviewers, it gets passed up to the orchestrator-pair (and me) for a light final review.

5. The orchestrator planner or I would then give a merge signal to the agent team.

The loop repeated, item by item, until the roadmap was exhausted.

Note that the roadmap was also a live document, meaning that, as agents run into something while doing their more focused audits, implementing, or reviewing, it would get passed up to the orchestrator-pair to fold into the roadmap.

The particularly observant would notice that the orchestrator-pair was basically, in a sense, just a slimmed-down version of the agent-pair framework — it just had no implementation and no independent review panel of the artifacts it produced. My reasoning for not having a panel review the pair’s work was simple — they merely produced sequencing, short dispatch relays, and maintained an easily parsable high-level spec/roadmap doc.²⁵ These were all in prose too so they were really easy for me to personally read and review whenever needed.

Really, this was just a purified reincarnation of the old swarm from a few stages back. Now, instead of me attempting to micromanage a team of largely uncorrelated agents attempting to tackle the same task in parallel, a large part of management got offloaded onto an orchestrator-pair and the uncorrelated agents were reduced to just a handful of worker-pairs that were more or less capable of standing on their own, leading to them being able to be dispatched individually to larger, non-overlapping portions of the specs at the same time, while also being able to coordinate with each other (though through the orchestrator) if needed. This dramatically increased breadth — by extension, throughput — and also basically removed the context fragmentation issue at the global level that every stage before this had. Though, at this point, each subservient worker-pair was still somewhat locally confined (more on that in a bit).

On the other hand, this orchestrator-team framework also reintroduced an issue from the swarm era: I still had to manually copy + paste relay everything by hand, though the dispatches were now written with better context and were also adversarially reviewed. I couldn’t use Claude Code’s Agent Teams to spawn pairs with a non-Anthropic model and I didn’t trust the planners to use codex exec to launch their own adversarial reviewer, let alone the agents within the Agent Teams doing that themselves.

And, as always, tokens were now burning close to swarm-level rates, though mostly due to the increase in the number of distinct worker-pairs working simultaneously on non-overlapping work. This kept the token cost per task the same, and only looks to be more expensive in any given time period only because the number of tasks done grew.

However, over the course of running this for a week or so, several new delegation-specific failure points came up repeatedly:

1. Implementer agents were jumping the gun. Dispatches would typically be given to both the planner and implementer agents in the worker-pairs and, before the planner even started designing/planning, the implementer just read it as if it was directed to them. They sometimes started planning even AFTER I reminded them that their job was to review the planner’s work, or worse, they would sometimes treat it as a one-shot directive and go straight to implementing and opening PRs without any plans at all!

2. No direct way to facilitate cross domain context transfer. Each subservient worker-pair only had the context it gained on its own exploration and whatever the orchestrator passed down and had little to no idea of what its peer pairs were doing — they couldn’t communicate with one another without having to go through the orchestrator. Needless to say, this was also a huge burden on the orchestrator-planner agent.

3. The orchestrator-planner agent had inconsistent relays. Over different orchestrator instances and even within the same instance over time, the exact format of the relays varied wildly, and sometimes they would even leave out crucial information like the exact stage it was at or to whom it was addressed. It would also sometimes confuse itself over what pair was supposed to get what relay.

Overall, there is nothing new here, at least in terms of structure. A simple way to look at this orchestrator-team framework is just the pair but recursed: the same separation of authoring from reviewing, the same targeted distribution of context throughout specialized agents, applied to the act of handing work out rather than the act of doing it. Now, going back to Stage 6’s maxim of parallelizing reads and not writes, we have shown that we can also parallelize writes, though only partitioned writes as write collisions can’t really be fixed unless you wanted a copy of each file for each agent and then handle 5 different merge conflicts on each file — absolutely ludicrous.

The board

Problem	Status
Post-impl churn (PIC)	🟨 smallest it’s ever been — gates + scope shrink the ouroboros to a trickle, but stochastic agents mean it never fully closes
Coordination	🟨 no longer mine to hold — the orchestrator-pair owns routing, I’m on exceptions + merge — but I’m still the one hand-relaying between agents
Context fragmentation	🟩 ownership-partitioned bundles + reconciled status
Edit collisions	🟩 structural at team scale, via ownership decomposition
Mid-flight visibility	🟨 reopened — more agents in flight at once than I can watch
Token burn	🟨 orchestration adds overhead; by-exception engagement keeps it bounded
Correlated errors	🟨 review panels (Stage 6), yellow only due to below
Same-model review panel	🟨 still deferred — panels remain single-family; a third family still isn’t worth the tokens
Implementer jumping the gun	🟨 new — a dispatch is supposed to be context, not a start signal
Cross-pair context transfer	🟨 new — isolation’s flip side; pairs can’t share context with each other except by routing through the orchestrator, which overloads it
Inconsistent relays	🟨 new — the orchestrator-planner’s relays vary in format and sometimes drop crucial fields like the stage or who they’re addressed to
Orchestrator as single point of failure	🟨 new — everything gets routed through it and everything rides on this, mitigated somewhat by being paired with a reviewer but still a bit fragile

That board still had quite a few unresolved issues, and I wasn’t going to just end it here staring. The two that nagged at me most were coordination — I was still the one hand-relaying every dispatch between agents — and the freshly arrived delegation-specific failures the team’s structure had just introduced. Most of them, it turned out, were fixable. Here’s how the worst of them got closed.

Firstly, to address the issue of coordination, the handoffs/dispatches became files. Instead of having to /copy,²⁶ and paste entire prompts that could potentially get mangled by latent issues with the TUI render, the agents could just write relays in a file and all I’d have to do is copy + paste the relay over to the recipient. Some unanticipated, but welcome, benefits came in the form of persistence and editability. Now, relays were actually easy to access and stored permanently as a markdown file, and I could also easily read and edit them through nvim. Additionally, agents now had a stable reference instead of keeping it ephemeral in their memory, further mitigating the context rot disaster.

Secondly, the handoffs got email-style headers. In order to enforce this without having to police every handoff myself, I loaded each agent with a mini-skill to preface its relays with an email-style header like

FROM:
TO:
CC:

and this actually solved two problems at once. The first issue solved was that the orchestrator now had to include information about, not only which pair the relay was for, but also which one of the pair it was directly for. This led nicely into the second issue fixed — the one of implementers jumping the gun. I reasoned that, since LLMs are probably trained on a bunch of email data, it would be able to understand that, if they were CC’d, it meant that they were only being kept in the loop without needing to respond. This hunch was right as, all of a sudden, the implementer agent stopped treating planning/design relays as signals for them to start.

Finally, standardized templates for relays were made, each with examples of what a relay of a sort should do. Like how a relay to audit should tell the agent READ ONLY or how a relay to plan/design would always have the implementation agent be CC’d and never be put as a direct recipient. This was an easy upgrade as now implementation agents could also just fill out a template rather than having to come up with one each time I asked.

Let’s take a look at the board now.

The board, again

Problem	Status
Post-impl churn (PIC)	🟨 smallest it’s ever been — gates + evidence + scope shrink the ouroboros to a trickle, but stochastic agents mean it never fully closes
Coordination	🟨 better — file-first relays kill the mangling and leave a persistent trail; still my copy-paste, but no longer fragile
Context fragmentation	🟩 ownership-partitioned bundles + reconciled status
Edit collisions	🟩 structural at team scale, via ownership decomposition
Mid-flight visibility	🟨 file-first relays + status reconciliation, but still too many agents to manually oversee each
Token burn	🟨 orchestration adds overhead; by-exception engagement keeps it bounded
Correlated errors	🟨 review panels (Stage 6), now standing, yellow only due to below
Same-model review panel	🟨 still deferred — panels remain single-family; a third family still isn’t worth the tokens
Implementer jumping the gun	🟩 closed — a CC’d agent stays in its lane, and acting now takes an explicit go-signal, not just a dispatch landing in its lap — so a hand-off stopped doubling as a cue to one-shot a PR
Cross-pair context transfer	🟨 better — addressing lets the orchestrator route peer context where it’s needed, but pairs still can’t reach each other directly
Inconsistent relays	🟩 closed — standardized templates; the format stopped drifting
Orchestrator as single point of failure	🟨 everything still routes through it and rides on it, mitigated by the reviewer but not gone

None of those three fixes were some ingenious invention. They all followed the same pattern: take a discipline that kept failing, and turn it into structure that holds whether or not anyone’s paying attention. Here’s why that works.

The failures above sort into two piles, split by the solutions for each.

The first pile is substantive: a wrong architecture, mismatching schemas, deviations from documentation, etc. Issues like these can be caught by just having a second set of eyes hunting for what’s wrong, and that’s pretty much the whole premise of the review gates from the last two stages where we just stacked mandatory adversarial review over pretty much every gate.

The second pile, the issues Stage 7 kept surfacing, is mechanical. That is, a failure of decorum and not correctness: an implementer misinterprets a doc meant for the planner as a go-signal for itself, a gate gets skipped because the agent assumes permission to skip it, or relays drop crucial fields that can compound the previous two problems. These issues were caused by the structure just being too loose and lax in its enforcement of decorum, and the fix is simple — just tighten it up. You could add a third reviewer to each pair to check relays but that’s inefficient and quite frankly overkill when a couple of persistent one-line rules enforcing behaviors (cough cough skills) would suffice.

As an aside, the fact that nearly every Superpowers cycle I’ve run had no issue with agents jumping steps was enough proof for me that just having a couple lines of markdown persisting as skills was enough to induce strict discipline, so I took this idea for myself.

By tightening the structure, the team regained and retained full structure throughout working sessions and I slowly got to trust the team’s ability to self-manage. Over time, the following lessons became apparent from the now disciplined and structured approach these teams were forced to take:

1. Permission should never be implied. The email headers were an example of this — an implementer mistaking being handed context for being told to build, and a CC’d agent learning to stay in its lane. But the stubborn version was me. So the act of going — actually writing code, actually merging — became something that only counts when it arrives as an explicit, unmistakable signal, and never something an agent should have to infer from a tone, a mood, or just the fact that a document landed in your lap. Eventually, due to other instances of assuming permissions — like going directly from a design doc into immediately writing a plan, merging after taking in just a single review without passing it back for a re-review, or checking off the task on the orchestrator owned roadmap as “done” (more on this in a bit) before it gets passed up there — this idea of making permissions clear, explicit, and persistent was extended to every single gate we had, from documents to merge confirmations.

2. “Done” became a claim, not a fact. The issue that’s been bugging me since the very beginning, the issue that motivated everything all the way back in Stage 1, was literally “Done” isn’t done. Now, we have a formal definition. Agents will tell you, with total serenity, that they did things they did not do — not lying exactly, just narrating the plausible. I recall several instances of the words “shipped” and “done” being tossed around to just describe a task completed within a PR without having been merged. So naturally, I had to define the word “done” to mean “merged cleanly” after the entire post-implementation review and fold cycle, and I required the implementer to provide evidence they had merged and the planning agent to verify it, and then the final state, again with all the evidence, was passed up to the orchestrator to finally check it off on the roadmap, as well as folding in any new findings from the agents. This discipline of evidence gradually expanded to other signifiers of completed actions; words like “done,” “fixed,” and “shipped” stopped being allowed to travel as bare words as each one has to arrive carrying what kind of proof stands behind it. The proof for “I changed the code” is the real state of the repository, not the agent’s summary of it. Still, that “done” was only ever dev-loop done — a claim promoted to a stronger tier of evidence, not proven correct in production; the last mile, QA and watching the deployed thing, stayed its own separate gate completely manned by me before it ever gets to prod.

3. Finally, sometimes you didn’t need all that pomp and circumstance. Not every single task needed to get involved with the level of ceremony of the full loop. Almost all of the time, it would be utterly ridiculous to run through an entire Superpowers cycle with the complete audit + design + plan + the independent review panel on a single line diff, let alone having to wire the relays all back and forth between the worker-pair, the orchestrator-pair, and me. Sometimes, especially with the introduction of new next-gen frontier models like Fable 5 (R.I.P.) that were essentially optimized for one-shotting, it was sufficient for the orchestrator just to produce a handoff and direct the agent to go ahead and one-shot; though the review gates after the PR gets created were still absolutely mandatory, especially so for these one-shot runs. What I’m getting at here is that, with sufficient evidence, the level of ceremony required to run through an entire task can be downgraded.

Roles

Role	Owns	Forbidden from
Orchestrator-planner (Opus 4.8)	decomposing work into ownership-partitioned bundles, dispatch, reconciling audits + status into the live spec/roadmap, the merge signal	writing code; reaching into a bundle’s internals; acting on its own decomposition unreviewed
Orchestrator-reviewer (GPT-5.5)	adversarially reviewing the orchestration itself — bundle boundaries, routing, framing, the order work has to land in	planning, implementing, or reviewing the pairs’ code — it only ever checks the hand-out
Agent-pairs (x2-5) — each a full Stage 6 setup	running the full Stage 6 cycle on one bundle, in isolation from its peers	touching another pair’s files; talking to a peer except through the orchestrator; merging its own work
Me	the exceptions, the light final review, the merge gate	real-time routing (the orchestrator holds it now); merging on vibes; treating “done” as a fact

Gates

1. Audit reconcile (orchestrator-planner + reviewer + me)
2. Spec + roadmap sign-off (orchestrator-reviewer + me)
3. Dispatch review — bundle ownership, routing, sequencing (orchestrator-reviewer + me)
4. The full Stage 6 cycle, run per bundle (inherited)
5. Final review + merge gate (orchestrator-planner + me)

Wiring

flowchart TD
    SPEC["Feature spec doc"]
    RESEARCH["Optional research<br/>prompt / doc"]
    YOU(["You<br/>exceptions + merge gate"])

    subgraph ORCH["Orchestrator pair"]
        ORCH_PLAN["Planner<br/>(Opus 4.8)"]
        ORCH_REVIEW["Reviewer<br/>(GPT-5.5)"]
        ORCH_PLAN <-->|"review"| ORCH_REVIEW
    end

    AUDITS["Agent-pairs<br/>audit codebase slices"]
    AUDIT_RECONCILE{"Audit reconcile"}
    ROADMAP[("Live spec + roadmap doc")]
    DISPATCH_REVIEW{"Dispatch review<br/>(ownership-partitioned)"}

    subgraph TEAM["Agent-pairs -- one per non-overlapping bundle (2-5 typical, scales out)"]
        PAIR_A["Pair A: bundle A<br/>(Stage 6 cycle, isolated)"]
        PAIR_B["Pair B: bundle B<br/>(Stage 6 cycle, isolated)"]
        PAIR_N["Pair N: bundle N<br/>(...as many as the work partitions into)"]
    end

    FINAL_REVIEW{"Light final review"}
    SHIP(["Merge / ship"])

    SPEC --> ORCH_PLAN
    SPEC -.->|"optional"| RESEARCH
    RESEARCH -.-> ORCH_PLAN

    ORCH_PLAN -->|"audit prompts"| AUDITS
    AUDITS -->|"audit docs"| AUDIT_RECONCILE
    AUDITS -.->|"discoveries"| ROADMAP
    AUDIT_RECONCILE -->|"spec + roadmap"| ROADMAP

    ROADMAP -->|"next items"| ORCH_PLAN
    ORCH_PLAN -->|"work prompts / docs"| DISPATCH_REVIEW
    ORCH_REVIEW -.-> DISPATCH_REVIEW
    YOU -.-> DISPATCH_REVIEW

    DISPATCH_REVIEW -->|"bundle A"| PAIR_A
    DISPATCH_REVIEW -->|"bundle B"| PAIR_B
    DISPATCH_REVIEW -->|"bundle N"| PAIR_N

    PAIR_A -->|"merge-ready PR"| FINAL_REVIEW
    PAIR_B --> FINAL_REVIEW
    PAIR_N --> FINAL_REVIEW
    TEAM -.->|"discoveries"| ROADMAP

    ORCH_PLAN -.-> FINAL_REVIEW
    YOU -.-> FINAL_REVIEW
    FINAL_REVIEW -->|"rework"| ORCH_PLAN
    FINAL_REVIEW -->|"merge signal"| SHIP

Epilogue: The Prosthetics

None of this is free. It burns way more tokens and more patience than just opening up Claude Opus 4.8 on ultracode and letting it go ham with one shot prompts. Some people, particularly those with years and decades of engineering knowledge, would benefit the least from my setup as they already contain the necessary skills to write proper specifications, detailed implementation plans, and better intuition on what exactly needs to be done and how. The only thing my maybe framework beats out on is the shipping speed, and even then a single talented, proper engineer with a single model burning about a quarter of the tokens would probably ship something better in maybe at most double the time, and a team of maybe two or three competent engineers would be able to match the speed and even surpass the quality with roughly the same amount of tokens spent.

The caveat: this was never a clean experiment. The workflow got better, but, over the same handful of months, so did the models underneath it. As well as my familiarity with the codebase, and my own judgment.²⁷ I’ll be honest and say that I can’t completely separate workflow lift from model lift from “just-getting-less-bad-at-this”; they all moved together. I also wish I could have given numbers and metrics but I honestly didn’t measure any — making them up would’ve been antithetical to one of the core lessons of this story!

Thing is, with the current state of gen-AI models, it’s very easy to start building something you can’t understand and can’t verify by yourself very effectively. With my framework, it at least allows someone with very little technical know-how to barely, just barely stand a chance, giving them a floor, not a license. And even then, it’s just mostly agents checking the work of other agents, which is still rather risky. Really, what the whole thing does is trade quality for velocity: none of the gates exist to make the output as good as it could be. They’re there to keep your codebase from being a complete slop-fest while you move fast, allowing you to ship something that is past MVP and is usable by clients, but not something that’s quite enterprise-grade. In practice this meant that an incomplete migration can still occasionally slip through to deployment before it reaches you.²⁸ Which means the moment velocity stops being the priority, the trade goes minus EV, and you’re better off slowing down and building it properly from the get-go without this whole multi-agent setup.

It’s worth noting that keeping it out of slop-fest territory is only the floor, so it’s important to be precise about what failures the floor actually catches. The loud ones — like an agent reporting work it never did — die the moment you demand evidence, so it’s easy to check no matter how little you know. The quiet ones are the dangerous remainder: the stochastic, plausibly-correct-looking work two agents converge on, the ouroboros that never truly disappears, and the many other errors my board never gets to green. Those only get resolved for real when you read the diffs as carefully as you’d read your own. In short, someone working with little to no knowledge would get the floor and almost nothing past it.

Therefore, let me be clear about what this whole multi-agent orchestration framework actually is.

It is not an engineer. It’s a prosthesis.

Something that lets you reach past what you could do unaided, whether that’s running models too cheap to trust, working a domain you only half understand (or in my case, understood only <5%), or holding more parallel surface area than one head can keep straight. And like any prosthesis, it’s only there because something is missing, not because you’ve somehow transcended the need for it.

This is evident from just looking at what’s actually stopping London Bridge from falling down. That stack of agents checking agents checking each other — a planner watched by a reviewer, an implementer watched by a panel, a roadmap reconciled by an orchestrator that is itself just two more agents — is turtles most of the way down.²⁹

The only thing that makes it trustworthy instead of terrifying is that, at the very top, there’s a skeptical human bolted to the last gate, refusing to call anything done until something real — a merge, a repo state, a test that actually ran — says so; even then, that’s just a call to go dress up as a QA team, either with agents, by themselves, or both, at which point they’d bug hunt the deployed output (hopefully not on prod). Pull that human out and let the loop run itself, fully agentified, and you won’t have an engineer, much less the engineering team you replaced it with³⁰ — you have the Stage 3 swarm again, just with better manners and a much larger bill: confident, plausible, and agreeable output at scale, with nobody left who can tell whether any of it is true and leaving QA for someone else downstream.

That’s the part the AI hype train these last couple of years gets backwards. The instinct, once a framework like this starts working, is to automate the last human out of it too — close the loop, walk away. But the more of the checking you hand to agents, the more weight lands on the one check you didn’t automate, not less.

Note that this gate is only ever as good as the time and judgment you spend standing at it. The cheap, fast version is just refusing to let “done” travel without proof: it’s the only node not drawn from the same stochastic well, so it’s the one place a claim can be forced to show a merge, a repo state, a test that actually ran, instead of just sounding right. That alone kills the loud failures, like an agent narrating work it never did or an agent going off in an orthogonal direction to your plan, and it works regardless of how much (or little) you know. The quiet ones, real work that’s subtly wrong, are catchable too, but only by reading the diffs as carefully as you’d read your own… which is exactly the slow, expensive review the speed was bought by skipping. So a sharp engineer can absolutely close that gap; they just close it by spending the time they came here to save. The one who can’t close it at any price is someone working a domain they barely understand — because that gap takes knowledge and intuition, and that is the thing that more review hours don’t buy.

If someone can figure out how to take the human out of the loop entirely, we’d have something very close to AGI! Unfortunately, or fortunately, we’re a bit far from there. I tried this loop out with Fable 5 the short time it was available, and it still didn’t reach this level!

However, here’s the thing that snuck up on me. Take out all of the agents — the orchestrator, the pairs, the panels, the relays — and look at what’s left. A spec written before any code. A plan reviewed by someone who didn’t write it. A claim of “done” that has to carry proof. A second reader whose whole job is to disagree. A rule for every place something once broke.

That’s not a multi-agent methodology. That’s just engineering.

It’s the workflow people were already doing long before any of this, and the kind I, and basically every vibecoder out there, skips. The agents didn’t teach me that. They billed me for it, over and over, in production, in front of whoever was downstream, at every place I’d been sloppy enough to assume the worker on the other end was competent and honest. The whole framework is just what good practice looks like once you can no longer assume either, and every ceremony in it is a scar — nothing made it in because it sounded clever, and any rule that couldn’t point to a specific time something went wrong didn’t earn its place.

So no — I wouldn’t hand this to someone as a way to replace or become an engineer(s), any more than I’d hand someone a wheelchair as a way to learn to run. I’d be much more comfortable recommending this as a tool for someone looking to get something done at least somewhat properly when constrained by budget, time, or knowledge. But if you’ve already got the judgment and a decent model, spend it — the bureaucracy my workflow runs on is the thing you use when you can’t.

To recap, I went into all this a sophomore one-shotting “build me a chatroom” into a split-screen editor, and I came out the other side running a simple multi-model bureaucratic emulator of an engineering team — and writing better software because of it. Somewhere in there I stopped being a complete vibecoder and turned into something closer to an engineer — less trial and error than being Sisyphus, if the boulder stayed up a little longer each push.

Key word being closer. Not quite my tempo. By the one rule this whole thing taught me, “engineer,” like “done,” is a claim, not a fact — and I don’t have the evidence, nor the knowledge, to back it up quite just yet.

---

References

In-text sources are linked inline and in the footnotes; this section just collects the key ones in one place.

Articles, papers & technical reports

• Anthropic. (2026). Claude Opus 4.6.
• Anthropic. (2025). Equipping Agents for the Real World with Agent Skills.
• Anthropic. (2025). How We Built Our Multi-Agent Research System.
• Baker, B., et al. (OpenAI). (2025). Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation. arXiv:2503.11926.
• Chroma. (2025). Context Rot: How Increasing Input Tokens Impacts LLM Performance.
• Cognition (Yan, W.). (2025). Don’t Build Multi-Agents.
• Cognition. (2026). Multi-Agents: What’s Actually Working.
• DeepSeek. (2026). DeepSeek V4: Compressed Attention.
• DeepSeek-AI. (2025). Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention. arXiv:2502.11089.
• Denison, C., et al. (Anthropic). (2024). Sycophancy to Subterfuge: Investigating Reward-Tampering in Large Language Models. arXiv:2406.10162.
• Kruger, J., & Dunning, D. (1999). Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments. Journal of Personality and Social Psychology, 77(6), 1121-1134.
• Lackner, S., Francisco, F., Mendonça, C., et al. (2023). Intermediate Levels of Scientific Knowledge Are Associated with Overconfidence and Negative Attitudes Towards Science. Nature Human Behaviour.
• Meinke, A., et al. (Apollo Research). (2024). Frontier Models are Capable of In-context Scheming. arXiv:2412.04984.
• OpenRouter. (2026). Surpassing Frontier Performance with Fusion.
• Sanchez, C., & Dunning, D. (2018). Overconfidence Among Beginners: Is a Little Learning a Dangerous Thing? Journal of Personality and Social Psychology, 114(1), 10-28.
• Sanchez, C., & Dunning, D. (2020). Decision Fluency and Overconfidence Among Beginners. Decision, 7(3), 225-237.
• Tacheny, N. (2025). Geometric Dynamics of Agentic Loops in Large Language Models. arXiv:2512.10350.
• Vercel. (2026). Introducing Skills: the Open Agent Skills Ecosystem.
• Verga, P., et al. (Cohere). (2024). Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models. arXiv:2404.18796.
• Wu, D., et al. (2024). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. arXiv:2410.10813.

Tools, frameworks & documentation

• AGENTS.md. agents.md.
• Anthropic. Claude Code — Agent Teams.
• Anthropic. Claude Code — Memory (CLAUDE.md).
• Anthropic. Claude Code — Run Parallel Sessions with Worktrees.
• Microsoft. Playwright MCP.
• Model Context Protocol. modelcontextprotocol.io.
• obra. Superpowers: An Agentic Skills Framework.
• skills.sh. The skills CLI.

Image credits

• The “Dunning-Kruger Curve” (Stage 3) — figure generated by the author; free to reuse.
• Switchboard operators (Stage 3) — Fort Richardson telephone operators connecting calls, 1950; photographed and released by David Bedard, U.S. Army (Joint Base Elmendorf-Richardson, 2012), via Wikimedia Commons; public domain.
• Bridge that doesn’t meet (Stage 3) — widely circulated “bridge fail” meme; original source/author unknown. Used pending any rights claim and removed on request.
• coconut.jpg (Stage 7) — texture asset from Team Fortress 2 (Valve); cultural reference, removed on request.
• Turtles all the way down (Epilogue) — River terrapin by Pelf, via Wikimedia Commons; public domain.

Icon credits: the dangerous bend signpost is by MetaNest (CC BY-SA 3.0) and the lightbulb is by Subhashish Panigrahi, derived from “Light Bulb” by Ian Mawle (CC BY-SA 3.0); the info glyph is by User:Kontos (public domain) — all via Wikimedia Commons.

Footnotes

1. Yes, that one — the one where the internet was absolutely cooked for the entire duration. ↩

2. Well, a better description would be a multiplayer version of the online game Human or Not. ↩

3. Launched my SF tech-bros poker arc, but that’s a story for another time. ↩

4. In fact, my first commit on that project was indeed a real-time chat websocket module in Python. ↩

5. The cartoon “Mount Stupid” curve isn’t from the original Kruger & Dunning (1999) paper, which only showed low performers overestimating — not the full rise-then-fall arc. But it isn’t pure meme either: Dunning’s own later work with Sanchez (2018, 2020) found a “beginner’s bubble” where confidence outruns competence early in learning, and Lackner et al. (2023) found overconfidence peaking at intermediate knowledge. So confidently writing the curve off as fake would itself be a nice little Mount Stupid moment — as, quite possibly, is this footnote. ↩

6. Note Fred Brooks’s The Mythical Man-Month is widely considered to be the “Bible of Software Engineering” since “everyone quotes it, some people read it, and few go by it.” Oh the irony of being the guy lifting this part straight out of Wikipedia. Anyways, within the book, Brooks states that communication paths grow quadratically with respect to the number of participants, or, to be more exact, $n(n-1)$ (if only I could do a double footnote, but we’re using directed edges to count instead of undirected edges as in the source material). My agents never talked to each other, so all that quadratic coordination demand funneled through one human channel instead: sixteen agents, one serial me. Theoretically speaking, if one were to just treat me like a node surrounded on all sides by the $n$ agents represented as nodes, the number of (directed) edges would actually only be $2n$; looking closer with more critical thinking, it turns out this model abstracted too much and neglected the fact that relaying (going to the sender, copying, looking up where the recipient is, going there, and then pasting) takes a nonzero amount of time, and since each agent is in a different place, I still have $n(n-1)$ possible routes for me to traverse! Even if we managed to reduce the travel time to near zero, I am still limited by the fact that I can only relay messages to one recipient at a time, which makes it strictly worse than just having the agents talk to each other, in terms of communication efficiency that is. ↩

7. Note Conway’s Law: a system’s interfaces mirror the communication structure that built it. Two agents that never talked shipped two incompatible halves of one contract — an org-chart fracture rendered in code. ↩

8. Caution We’ve since moved away from a singular local checkout — Superpowers now gives each cycle its own implementation worktree. That’s per cycle, not per agent, though: the parallel agents inside a single cycle still shared that one worktree, so intra-cycle collisions were still only held off by prose. ↩

9. This is basically the idea behind what Anthropic formalized as Agent Skills back in late 2025, popularized by Vercel in late January 2026 by launching the skills CLI tool. For those who (somehow) don’t know what this is, a skill is just a directory of plain-text instructions and metadata (a SKILL.md file). ↩

10. Closest formal analogue I found is LLM-as-judge work: Cohere’s PoLL paper reports panels drawn from different model families reduce intra-model bias. That doesn’t prove Claude/Codex coding-agent decorrelation, but it matches the failure shape I was seeing. ↩

11. Caution This was forum lore plus my own experience at the time, not a benchmark — and it mostly held when instructions were persistent rather than ephemeral (c.f. Stage 7’s jumping-the-gun problem). Treat it as a workflow choice, not a model-leaderboard claim. ↩

12. A line in this video — about an agent left looping until it “got stuck [in] a local minimum and improvements plateaued” (~18m in) — is what sent me digging, and there’s an empirical observation that rhymes with it: feed a single model its own output in a loop and the trajectory tends to go contractive, collapsing toward a stable attractor with shrinking dispersion (Tacheny, 2025 — measured but not proven, and only on single-model self-loops). It’s a loose analogy for why two agents dialoguing in the same long conversation drift to a shared answer too: both look like a trajectory contracting into a basin. Perhaps the introduction of a fresh agent reintroduces enough velocity to climb out of the well? ↩

13. Due to it being bloated, typical for JetBrains’s products. ↩

14. Note This was mostly because of two things: a) I was lazy and it took too long for more than a couple of cycles, and b) most finding after the second or third rounds were just tiny nits and seldom any blocking issues. Eventually, I dropped down to just one round of review and fixes then a quick re-review by the planner agent to verify that the reviewer’s issues were fixed and folded in properly. ↩

15. Caution This squares with OpenRouter’s Fusion result that even a same-model panel — Opus 4.8 + Opus 4.8, synthesized by Opus 4.8 — jumped from 58.8% solo to 65.5%, which suggests a meaningful chunk of panel lift comes from the synthesis step itself, not just model-family diversity. Not proof a third family is useless; just enough to make the cost/benefit harder to justify here. ↩

16. Caution I didn’t engineer the fresh-each-round part: every time I invoked Agent Teams it spun up new teammates with fresh context windows, so the panel got restaffed whether I asked for it or not. Do note that this wasn’t actually guaranteed in the docs… though, the architecture (new session IDs, freshly loaded context per spawn) makes it the natural behavior, and it held every time for me — call it observed, not promised. Either way, the thing keeping decorrelation from degrading across rounds fell out of a framework default, not any cleverness of mine. A “happy little accident”, quoth Bob Ross. ↩

17. Tip I later found I’d half-reinvented a wheel: Cognition argued against tightly coupled multi-agent coding, while Anthropic showed multi-agent systems shine for breadth-first research. (Cognition’s own follow-up later landed on basically this split.) My rule of thumb became: parallelize reads freely; parallelize writes only when ownership is partitioned (c.f. Stage 7). ↩

18. The coconut file is real; the ‘deleting it crashes TF2’ story is the meme — the point here is tangled-code folklore, not the literal crash claim. ↩

19. Anthropic reported 76% on the 8-needle, 1M-token MRCR v2 benchmark for Opus 4.6 (vs 18.5% for Sonnet 4.5). Impressive, but still a one-in-four miss on a clean benchmark, before real-codebase messiness. ↩

20. Note Training a model — intentionally or not — to maximize a benchmark score rather than the underlying capability the benchmark is supposed to measure. ↩

21. Note The uncomfortable point isn’t that long-context models can’t retrieve anything; it’s that irrelevant surrounding context degrades retrieval AND reasoning. In codebases that maps painfully well to giant specs and whole-repo dumps. ↩

22. Caution HCA/CSA are real DeepSeek V4 compressed-attention mechanisms (building on the earlier NSA); I’m borrowing the shape, not claiming the architecture literally solves codebase context rot. In model terms they make very long context cheaper and more tractable; in my workflow analogy they become coarse global context plus selective mid-level detail plus exact local context. ↩

23. Yes, I know this doesn’t do the ingenious mechanism justice, and that it isn’t exactly sequential — HCA and CSA actually work together in tandem. But that’s a bit too complex for what this blog is going for; this isn’t a technical explanation of DeepSeek V4’s write-up, it’s how to vibecode properly!! ↩

24. Tip This was even more powerful when the chat model had access to the codebase itself via a GitHub integration. ↩

25. Though simple enough to skip a panel, a structural check turned out to be necessary — as it soon did. ↩

26. Or, even worse, manually selecting text when working through an ssh session — or just getting copy-to-clipboard to work in the first place. ↩

27. Mind you, I wasn’t just brainlessly vibing the whole time — I spent a nontrivial amount of my time researching and reading up on proper software development: security architecture and threat modeling, system design, how to actually structure a schema or a service contract before it solidifies into the wrong shape. Some of that operator lift was deliberate and not osmosis. ↩

28. Though in all fairness, this still happens even with a full engineering team and a dedicated QA team. ↩

29. Though I will say this tangled web of checks and balances still functions better than the analogous system in the US government. ↩

30. Looking at you, Corpo Tech — especially Microsoft and Meta. Among others. ↩