CODING AGENT HARNESSES

CONSTRAINTS THAT MAKE GENERATED CODE RELIABLE Code written by a model can look convincing and still be wrong. So the harness adds constraints, which are rules that narrow what the agent may do and how it must work. Here are the most useful ones. Narrow scope: give each task a small, clear boundary, such as fix this one function, instead of improve the project. Read before writing: require the agent to read the relevant existing code and conventions before changing anything, so its changes match the project. Small steps: have the agent make a change, check it, and only then make the next one, instead of rewriting dozens of files at once. Protected areas: block edits to files the agent should never touch, such as automatically generated folders, configuration with secrets, or the tests that define correct behavior. Review of the difference: show the diff, which is the list of exact lines added and removed, to a human or a second checking agent before the change is accepted. Test first: require the agent to write a failing test before writing the fix. A test is a small program that checks whether another piece of code behaves correctly, and a failing test proves that the bug exists. When the fix is written and the test now passes, there is objective evidence that the problem was solved. This practice, known as test-driven development, turns a vague claim of done into something that can be confirmed by machine. Beware a subtle trap here. An agent told to make the tests pass may cheat, for example by deleting a failing test, weakening its checks, or writing code that special-cases the test. Guard against this by protecting the test files from edits during a fix, and by reviewing any change to tests with extra care.