Agents are great at writing code and pretty bad at software design. Almost everyone who works with them seems to agree, and so do I. They’re focused on making it work, not on the long term health of the codebase.
That’s why I do the design first. Before any implementation, I work out the few modules that matter, each hiding a lot of work behind a small, simple interface, and put them in a document that becomes the source of truth for the implementation. The agents stay on track, the codebase stays sane, and as long as I understand those modules and their interfaces, I don’t need to know every line inside them.
The catch is that I still work out that design with an agent. That can be frustrating. The first proposal is usually horrible.
The trick that helps me the most comes from John Ousterhout’s A Philosophy of Software Design. He calls it “design it twice”: before committing to a design, come up with a radically different alternative and compare the two.
When I’m unhappy with a proposal, I ask the agent to “take a step back, design it twice and weigh the tradeoffs”. The results are better by a surprising degree. And event the agent usually ends up preferring one of the new designs over its first one.
It doesn’t make the agent a good designer. It makes it a better sparring partner.