Lead Architect Reveals His Rules for Coding Agents

In plain English

The guest is an experienced software architect. He says AI coding agents (software that writes and changes code on its own) are very good at producing a whole piece of work in one go. They are poor at making many small changes over time, and they forget how new code fits with the old.

So he builds the skeleton himself first: the folders, the file names and a few notes on how parts should connect. Then he lets the agent fill it in. If the result looks wrong when he checks in, he throws it away and tries again rather than patching it.

Three ideas worth keeping

• Brute force by an agent leaves messes: in one project he found the same feature built five separate times.
• Throwing work away is cheap now, so redo it quickly instead of repairing something you do not understand.
• His main agent is not allowed to change files. It only talks with him until it is confident it understands the job, and only then does it send helpers off to do the work.

What it means for your business

Whoever is building for you should be able to show the plan before the build starts. If they cannot explain how the pieces fit, speed will not save you. Ask how work is checked while it is in progress, not just at the end.

Also watch for a quiet risk the guest raises: people are working alone with their AI and talking less with colleagues.

What it means for software teams

Spend the first hour setting structure and boundaries, then let the agent work inside them. Check early and often, and treat “I do not recognise this” as a reason to discard the work. Keep real conversations and reviews between people, because the guest worries that teams are losing that habit, and that juniors are not learning.

What we found, and what we did

Our closest rule is a simple bar: if a senior engineer wouldn’t merge a change as it stands, it doesn’t count, however many tests pass (Would a human merge this?).

We keep changes small enough for a person to read: above a set size a change can’t merge without a person, so our agents split work into small steps that build on each other.

We haven’t written “throw away code you don’t understand” down as a rule, but we do throw away whole approaches when the evidence says no. We trialled a shortcut that skipped some re-testing, found two thirds of the cases it could skip would have been unsafe, and didn’t switch it on.

Our guide on vibe engineering and Vibe engineering vs. vibe coding cover the wider stance of keeping judgement with the human.

Worth watching

• 01:01: He explains his worry that teamwork and pull request reviews are fading as people work only with their agents.
• 12:02: He describes scaffolding the code by hand before the agent starts, and why.
• 1:00:10: Why his main agent is never allowed to touch files, and the rule that it must be confident before starting work.
• 1:03:36: How he reviews: a quick check against his scaffold, and discarding anything he does not recognise.