Your architecture debate belongs in an agent, not a meeting

Remember how a project used to start?

A design lands. You open it with the team and start pulling it apart: what can we build easily, what is going to fight us, what quietly doubles the estimate. Then come the discussions. Tens of hours, sometimes more, spent deciding the approach. Someone argues for one state management library, someone else for another. Half the room is searching the internet mid-meeting for whatever the current best practice is supposed to be.

Then the real list starts. Identify the components in the design. Plan the architecture. Pin the React Native version. Pin the React version. Choose the UI library. Assign someone to build the reusable components. Follow the latest patterns, whatever those are this quarter. Raise the PRs, wait on review, go again.

An MVP took five to six months. Not because the work was hard, but because the deciding was slow, and we did it from scratch every time.

Where that time actually went

Almost none of it went into typing code.

It went into rediscovering decisions we had already made. My team had opinions, good ones, earned on real projects. But they lived in people's heads and in old Slack threads. Every new project, we paid for them again in meeting hours.

That is the part worth fixing. Not the typing.

What I ask my team to do now

Build a plan agent.

One agent that holds the team's accumulated wisdom, written down with everyone's consensus. When a new project or a new feature comes in, that agent produces the plan.

Not a vague prompt. A real document that encodes what your organisation already knows:

That last item is the one people leave out, and it is the one that makes the difference. An agent that knows what it must ask you is far more useful than one that confidently fills every gap on its own.

Here is roughly what a section of ours looks like:

## Non-negotiables: never skip, never ask permission to include
 
- TypeScript strict mode. No `any` without a comment explaining why.
- Every screen reachable by keyboard and screen reader. WCAG 2.2 AA floor.
- Secure storage for anything user-identifying. No AsyncStorage for tokens.
- Error and empty states designed before the happy path is called done.
- Analytics events named to the existing convention, not invented per screen.
 
## Must ask before deciding
 
- Client compliance constraints (banking, health, government)
- Anything that changes the release timeline
- Third-party SDKs that add a native dependency

Nothing exotic. It is just our standards, finally written somewhere an agent can read them.

The step everyone skips

Once the plan exists, read it.

This is where I see the split. A good engineer reviews the plan before a single file is generated. Everyone else accepts it and starts building.

Someone who went through the process, studied, shipped, broke things in production, fixed them at 2am, has critical thinking the agent does not. You know what the model cannot know: the client who always changes scope in week three, the deadline that is real versus the one that is padded, the junior on your team who will need the architecture to be obvious rather than clever.

I have eight years behind me and I still read every plan. Even knowing the agent was written with my own team's wisdom, I give it a proper read. The plan is cheap to change. The implementation is not.

Implement in modules, never all at once

Write this into the plan agent explicitly: do not implement the whole project or the whole module in one pass.

Break it down. One increment at a time, each small enough to review in a single sitting. When something goes wrong, and it will, you lose an hour instead of a week.

The plan stays the contract. The implementation is measured against it.

Two reviews, not one

Manual review of everything an agent produces does not scale. So we added a review agent first.

You write your rules once, the same standards from the plan agent, aimed at reading code instead of producing it. That agent reviews what the coding agent wrote. Context gaps, misread requirements, quietly dropped edge cases: most of it surfaces there, before a human has spent any attention on it.

Then the PR goes up, and a human reviews it. Usually me. Then it ships.

Four stages. Two of them are review. That ratio is not an accident.

What it actually bought us

Same team. Same standards, arguably higher, since the standards are now written down instead of remembered. The difference is where the thinking lives.

The mistake I see most

People build the agents, feel the speed, and then leave them alone for six months.

Agents are not set-and-forget. Ours change every week. When the review agent misses something, that miss goes into its rules. When a plan turns out optimistic in a specific way, that goes in too. When we find a workflow worth repeating, it becomes a skill the agent can call.

Put it on the calendar. One slot a week to update the agents with what the last week taught you. That is the compounding part. The agents you use in month six should be visibly better than the ones you wrote in month one, because your team got better and you actually wrote it down.

Skip that, and you have automated last quarter's opinions forever.

Where to start

If you are setting this up for a team, Anthropic's Claude Academy covers the pieces directly:

• Introduction to Subagents is the foundation for both the plan agent and the review agent. Start here.
• Introduction to Agent Skills covers how to give agents repeatable capabilities instead of longer and longer prompts.
• Claude Code in Action is the implementation half, module by module.
• AI Capabilities and Limitations is worth the time specifically because it sharpens what you should be looking for when you review a plan.

Start with one plan agent for one project. Write down the five decisions your team argues about most. Review what it produces, then fix the agent rather than fixing the output.

Do that for a month and you will not want to go back to the meeting.

I lead a team of five engineers at VentureDive, shipping mobile and web products for banking, government and enterprise clients. If you are working through the same shift, I am happy to compare notes.