Built Correctly, Built Wrong

How trio programming turned my Control Room into an out-of-control room

I recently started using coding agents seriously.

At first, I did not understand them, and I definitely did not trust them. To be clear, I still do not really understand them, at least not internally. I do not know what is happening inside the model in any satisfying mechanical sense. But I do trust them a lot more now.

My first assignments were tiny. Search and replace this value. Format this file. Help me find the part of the codebase that does this thing. Make this small, low-risk change.

Then the tasks got more varied. Review the Docker Compose files I use for apps on my NAS and suggest security improvements. Create tmux scripts so I do not have to rebuild my terminal setup every time I restart my computer. Convert a cooking recipe into an Instant Pot version. Make local app logs available through Grafana.

Eventually I started using agents for work that actually mattered: help me investigate why an incident happened, propose fixes, implement one of them, analyze a repo for production-support events, create CloudWatch queries, help me interpret a dashboard screenshot.

Slowly, the agents moved from "useful autocomplete with extra steps" to something closer to a working partner.

My workflow settled around two tools: Codex and Claude. Not because I had some grand theory. I tried Cursor, Copilot, Antigravity, Claude, Codex, and a few others. Codex and Claude were the two I kept reaching for.

At first I thought I would use both until I picked one. Instead, I found that using both could be useful. One model would produce a plan or implementation, and the other would challenge it. The review quality felt richer when the feedback came from a different system, with different defaults and different failure modes.

So, in practice, I drifted into something like trio programming.

I brought the product intent. Codex was usually the driver for refinement and planning. Claude was often the executor or adversarial reviewer. Sometimes those roles swapped, but that was the basic shape.

This can work well. If the target is known, if correctness matters, if the job is "make this implementation robust," a second agent can catch things the first one missed.

But I learned the hard way that this is a terrible default for early product discovery.

The failed project was supposed to help manage the exact workflow I was using: agent handoffs, task state, prompts, reviews, next actions, artifacts, and the back-and-forth between "agent did work," "agent got feedback," "agent addressed feedback," and so on.

The irony is not subtle.

I was trying to build a control room for agentic work, and the process turned into an out-of-control room.

The failure did not happen because the agents could not code. The UI probably allowed me to do what I needed. The functionality mostly worked. I was not looking at obvious bugs or broken flows.

That was part of the trap.

The thing was mechanically correct. It made sense. It had reasons behind it. It had been refined, reviewed, planned, re-reviewed, implemented, reviewed again, and patched.

And yet when I looked at it, I did not want to use it.

It felt overengineered, non-intuitive, and even intimidating. It asked me to understand too much before I could do anything. It had too much meaning packed into the first interaction. It looked like the product had already decided what kind of user I was supposed to be, and I was not that user.

If this had been someone else's app, I would have dismissed it quickly.

That is the uncomfortable part: the agents did not build the thing wrong. They built the wrong thing.

The workflow looked responsible. It went something like this:

1. Discuss an idea with an agent.
2. Once it seemed aligned, ask for refinement.
3. Ask the second agent to challenge the refinement.
4. Ask the first agent to address the feedback.
5. Repeat as needed.
6. Ask for a high-level plan.
7. Ask the second agent to review the plan.
8. Address feedback.
9. Repeat.
10. Ask for an execution-ready plan.
11. Review that plan.
12. Address feedback.
13. Repeat.
14. Execute the plan.
15. Review the execution.
16. Address feedback.
17. Repeat.

There are probably situations where this makes sense.

This was not one of them.

The problem was not that the agents were throwing random opinions at each other. The feedback was valid in most cases. The agents were not blindly accepting every suggestion either; they pushed back when they disagreed.

In other words, the process was not obviously broken.

That made it worse.

Valid findings accumulated into the wrong product. Sensible requirements hardened around an unvalidated shape. The workflow produced confidence, but not enough contact with the actual experience.

I was using a high-assurance workflow for a low-certainty idea.

That is the core mistake.

When you are fixing a production bug, reviewing infrastructure, tightening a security posture, or implementing an agreed design, ceremony can help. You want adversarial review. You want completeness. You want someone to ask, "What did we miss?"

But when you are still figuring out what the thing should be, too much ceremony becomes a liability. The important question is not "is this defensible?" It is "do I want this?"

I should have been pair programming, not trio programming. Maybe even looser than that. One agent, one tiny artifact, immediate feedback. No elaborate planning. No review loop. No execution-ready plan. Just: make the smallest visible thing, look at it, react honestly, adjust.

Instead, I let the process get ahead of the product.

Before abandoning the repo and starting over, I asked Codex and Claude to estimate how much effort had gone into it.

Codex found about 11.8 million local tokens and roughly 5.5 active hours.

Claude found about 894.8 million effective tokens, around 55 active hours, across 5,291 assistant messages in 105 sessions.¹

The exact numbers matter less than the shape of the evidence.

This was not a failure of insufficient effort. It was not a failure of not prompting hard enough. It was not a failure of skipping review.

It was a failure of using the wrong collaboration model at the wrong stage.

One part did work surprisingly well: using Codex to generate UI and UX design prompts, feeding those into Stitch, exporting to Figma, and then having Codex implement the Figma design. That flow created visible artifacts quickly. It forced the conversation back to the screen.

That is the lesson I am taking forward.

For early product work, I do not need more agents in the room. I need faster contact with the thing itself.

Prototype first. Taste-check early. Keep the loop informal until there is something worth preserving. Bring in adversarial review only after the shape is directionally right.

The next version of this project will start smaller. Not with a comprehensive control room. Not with a workflow engine. Not with a carefully reviewed taxonomy of states and actions.

It will start with one screen that makes me want to keep going.

Then we can argue about the details.