This is the third note on how coding agents change the work. The first, The Inversion of Software Engineering, covered cheap production and subtraction. The second, The Work Is the Same. The Working Style Is Not., examined how humans and agents move through a feature differently. This note focuses on how the agent's work gets checked.
As production got cheaper and deletion became routine, testing changed too. I used to run the code and look at the result, or write tests around the lines I had just added and watch them pass. That gave me confidence and a clear sense that the work was finished.
Manual testing gives way to verification loops
My first instinct with coding agents was to fight the pace manually: read the diff, run the app, click through the behavior, inspect the output, repeat. That worked for small changes. It did not scale to a collaborator that can rewrite a module while I am still parsing the first diff. I cannot hand-check the output of a system that produces faster than I can read. The check has to become mechanical, fast, and standing: a loop the agent runs before the work reaches me.
My engineering time now goes into the harness that checks the work. I need tests that exercise behavior instead of implementation trivia, types and assertions that rule out whole classes of mistakes, and linters, property checks, and review gates that return a fast, unambiguous signal. Finishing the harness well matters more than watching my own lines pass a test.
The loop is only as good as the judgment in it
The agent runs the loop on its own: generate, check, signal, correct. I do not sit inside every pass. I set the standard: what the checks test for, what counts as drift, and where the bar sits. The checks apply decisions I made earlier. Weak checks approve weak work repeatedly; specific checks give the agent something useful to fix.
What the engineer still owns
Engineers still decide what should exist, what should be cut, and what "correct" means in this system. The difference is that those decisions must be stated precisely enough for a literal collaborator to follow and for a test to enforce.
This is the work I think about at Duaility. An agent can produce many credible options, but it does not retain the team's preferences on its own. Constraints, checks, review gates, and standards have to carry those preferences from one run to the next. Our first open-source implementation of that idea is Governance Kit.