Six AI agents wrote a complete screen of my cockpit in two hours. That is not the interesting part.
TL;DR: code generation is no longer the bottleneck. Proof is. A multi-agent workflow is only worth its verification harness. Mine demands four proofs: visual parity with the design, flows clicked in a real browser, green tests, an empty punch-list. Give your agents proof obligations. Not longer instructions.
This article is for developers who use coding agents and want to ship with them, not just demo them.
My prospecting cockpit is a personal Go app. Server-side rendering with html/template
, htmx, PostgreSQL behind it.
I needed one more full screen: list, detail view, creation, status edition. The mockup existed. A neighboring screen served as the code model.
I orchestrated a multi-agent workflow: specialized AI agents chained together, each with one role. Backend, design, verification, tests. Six agents in total, about two hours.
At the end: the store, the migration, the handlers, the template, the navigation and the tests, merged. But the credit does not go where people usually put it.
"Build the screen" is an instruction. An agent always answers an instruction the same way: "done".
Sometimes it is true. Sometimes it is plausible. And plausible is the real danger, because plausible survives a quick review.
The fix is not writing longer prompts. It is changing the nature of the request: every agent gets a proof obligation, binary, checkable without asking the agent.
For this screen there were four. The screen matches the design, in light and in dark theme. The four flows pass in a real browser. The test suite is green. The punch-list is empty. A punch-list is the list of remaining gaps, a term borrowed from construction. As long as it is not empty, it is not delivered.
The classic trap: the agent states the UI matches. Nobody actually compares.
In my setup, a design inspector runs on a dedicated port. It shows the reference mockup next to the app's real rendering.
The verification agent compares both, screen by screen, in both themes. Every gap goes into the punch-list: a spacing, a color, a shadow, an empty state.
This run's verdict: approved, empty punch-list, light and dark. That verdict is a fact, not an agent's opinion.
Last week I wrote that a green E2E suite can lie when it asserts JSON instead of the DOM. The rule counts double for agent-written code.
So the four flows of this screen were played in a real browser, against the real app. Add a target. Add a person. Change a status. Promote a record.
No simulation, no direct API call. The form, the click, the render. What the user will see, checked the way the user sees it.
The classics keep their place, as an exit gate: go build
, go vet
, and the full suite. This run ended at 167 green tests.
One detail that matters: the PostgreSQL store tests are gated behind an environment variable. Without a test database, they skip cleanly. The suite stays runnable everywhere, by a human or by an agent.
The workflow's first run did whatever it wanted. Launched a local binary by hand, tried to pkill
running processes.
I corrected it mid-run, and the correction became a written rule of the harness. Never pkill
. Always rebuild and restart through docker compose. The demo dataset is idempotent, behind an environment variable.
That is the real learning loop: every agent mistake becomes a harness rule. Not a better prompt. A written rule the next run cannot bypass.
Human time does not disappear. It moves. I spend less time writing code, and more time defining proofs, arbitrating a punch-list, reviewing a diff.
That is the right trade. Generation is fast everywhere now. Trust only comes from the harness.
And the limits are real. This workflow worked because a reference mockup existed, and a neighboring screen provided the code model. Without an enforceable reference, the harness has nothing to compare, and the agent falls back to plausible.
Before handing a feature to agents, run this list. It is what separates a production tool from a demo generator.
build
, vet
and tests are gates, not suggestionsAgents do not need better instructions. They need proof obligations.
A screen shipped in two hours only has value if you can say why you trust it. In my case, the answer is four proofs, all checkable without asking the agent.
Build the harness once. It serves every next feature, and it ages better than any prompt.
Want to industrialize coding agents without shipping plausible? Let's talk.
Sources and related reading: Your test suite is green and your product is broken · My AI agent tried to delete my secrets · Hacker News, "Some uncomfortable truths about AI coding agents"