Your feedback loop is your bottleneck, not your build speed

This article was originally written in Dutch.

‍

The answer is unromantic: an exhaustive test suite was already in place, checking query by query whether the new version does what the original did. No magic, just craftsmanship. Craftsmanship that existed before a single line of Rust was generated.

And that’s what I want to talk about today. Since agents took over the typing, building costs almost nothing anymore, and the old brake, typing speed, falls away. A new brake takes its place, and to me that means this: the speed of your feedback is your speed limit. Without a feedback loop, an agent builds at breakneck speed, and completely blind.

Give the agent a chance to fail

I saw this up close at a hackathon where every team worked with the same agents and models, for half a day. Same tools, different outcomes: one team delivered something workable, another’s demo fell over the moment you started it. The difference wasn’t in the models used, but in the approach.

Working with agents means it helps to have something the agent can test against, something it can use to decide for itself whether it has failed or not. A test suite, a build that fails or passes, a screenshot next to the design. With that, the agent can work on independently: build, check, read the result, correct. The teams without such a check had only one touchstone: the developer. That developer became the bottleneck, and what rolled out was fast, plentiful, and not to be trusted.

pgrust from the opening is proof of that: a complete database system, rebuilt by a machine, and yet trustworthy, not despite but thanks to that test suite. Not that you’d switch to it blindly, and a test suite certainly doesn’t guarantee quality on its own. But without that suite the rebuild simply wouldn’t have been trustworthy. On a small scale exactly the same mechanism is at work: a check the agent can run itself decides whether it keeps building or gets stuck.

Another insight: large language models are stronger in widely used languages like Python than in Rust, simply because there’s more of it in the training data. You could imagine it’s useful to let the model build where it’s strong and translate afterwards, with your test suite as the safety net. Whoever has a covering set of tests turns the programming language into an implementation detail rather than a gamble. That, at least, is what happened at pgrust: the translation to Rust leaned entirely on that regression suite.

Draw the boundaries yourself

The second fault line between working and worthless is architecture. And here lies a trap: the agent doesn’t pick the right solution, it picks the most common one. My colleague Michiel Kooiman aptly calls this automating your assumptions: every time a model fills something in, it chooses for you, and it chooses by probability, not by quality. Ask for a web app and you get React. Ask for a system and you get the architecture that appeared most often in the data.

And that’s exactly the work you shouldn’t gamble on. Martin Fowler wrote it years ago: the hardest thing about a system is getting the boundaries right, and splitting too early smears a layer of treacle over the wrong boundaries. Start small, start simple, split only when the boundaries are stable. That wisdom only becomes more urgent with agents. On projects where the interface was agreed up front, I saw noticeably less noise between the parts. Agents build multiple parts at once, at high speed, so you get into trouble faster than ever if the boundaries are wrong.

So here’s what to watch for concretely: you draw the boundary, the agent fills it in. Constrain the space so little can go wrong, as my colleague Nahuel Manterola shows with making illegal states unrepresentable. The tighter you bound the space, the less the agent can wander.

Contain the damage, and learn faster

Speed without guardrails isn’t speed, it’s risk. The practice that presents itself here comes from the world of agentic engineering: let agents work in an isolated environment and deliver their result as a proposal, not as a direct change to the main line. Everything passes through a gate, and that gate is human judgment.

Only: that gate costs time you don’t have on a day like this. A logical step would then be to let an agent do the first review, checked against the shared quality bar I called quality.md in the previous post. That same agreement about what “good” means, you now use twice: once to build, once to assess. Human and machine both test against the same document.

And then remembering. A team that makes a mistake and doesn’t learn from it makes it again; that’s what the retrospective is for. But what if we extend that line? If the retro exists to prevent repeated mistakes, why isn’t the agent part of it? The agents didn’t take part in our “inspection” at the hackathon, even though they made the most mistakes. So record every fix a human contributes in a place where the agent reads it back next time itself. In practice that can be as simple as a single markdown file or skill per topic where you collect the findings, which you pull in only when it’s relevant. The retrospective then becomes not a ritual but a loop, and loops turn faster than meetings.

The bottom line

Same tools, different outcome. That means it’s not the models, it’s the practices. And the uncomfortable part: those practices aren’t new. Tests, small steps, clear boundaries, review, learning from your mistakes: it’s been in every good engineering handbook for decades. What AI changes is the stakes. It removes the typing brake and lays bare, mercilessly, who had the discipline underneath in order and who leaned on building being slow enough to catch mistakes on its own.

And are you thinking now: pgrust had its test suite ready, my code doesn’t? Then that’s precisely the argument for working on your software craftsmanship. Building a test suite, knowing what “good” means, being able to draw the boundaries: that’s craftsmanship, and it was always the real work. AI hasn’t made it obsolete, it has made it much harder to hide. As my colleague Jorrit Everts argues, software development in the age of AI demands more craftsmanship than ever.

Want to put this in front of your own team on Monday? This is the core:

1. Give every agent a check it can run itself: a test, a build, a screenshot. No check means you are the check.
2. Keep the steps small and ship a thin, working whole before you build out.
3. Draw the boundaries before the agent does: architecture is your decision, not its default.
4. Let an agent do the first review against a written quality bar, and keep the human gate behind it.
5. Record every fix where the agent finds it back, so the same mistake isn’t made twice.

Building is no longer your bottleneck. The question is whether your feedback is fast enough to earn that speed.