Use Test-Driven Development and Feedback Loops as the Agent's Control System

A coding agent without fast, meaningful feedback is coding blind. Test-driven development, type checking, and other executable checks provide the signals that let the agent correct itself. The quality of those feedback loops sets the practical ceiling on the quality of the agent's implementation.

The preferred implementation pattern is red, green, refactor:

• Red: write one test that expresses the next behavior and confirm that it fails for the

expected reason.

• Green: make the implementation change required for the test to pass.
• Refactor: improve the code while preserving the passing behavior.

This ordering matters. Agents often produce weak tests when they implement an entire feature first and add tests afterward. They may test their own chosen structure rather than the required behavior, mirror the implementation too closely, or create tests that pass without proving much.

Writing the failing test first instruments the desired behavior before the implementation exists. The agent must then satisfy an external signal rather than retroactively justify code it already wrote. The test becomes part of the task definition.

After the focused test passes, the agent should run the broader feedback loops required by the repository. In the demonstrated workflow, these include the test suite and the type checker. A type error or failing test becomes a concrete next action. The agent fixes the error, reruns the checks, and commits only after the feedback is green.

Feedback loops are not limited to unit tests. The principle is that the repository must be able to tell the agent whether a change is acceptable. A deep service with a clear interface can be tested as a meaningful unit. A fragmented collection of tiny functions provides weaker signals because tests may cover isolated pieces while missing the behavior that emerges from their interaction.

The agent cannot reliably inspect the consequences of its own code through language reasoning alone. Executable feedback constrains the solution and catches errors during the same session in which they are introduced.

This explains why improving a codebase's tests often improves agent performance more than adding another instruction. The feedback loop tells the agent what reality is. Without it, the agent can produce a fluent but incorrect implementation and continue building on top of the mistake.

For each implementation issue:

1. Identify one concrete behavior from the issue.
2. Write a test that fails because that behavior is absent.
3. Run the test and confirm the failure is meaningful.
4. Implement only enough code to make the test pass.
5. Repeat for the next behavior.
6. Run the relevant service or module tests.
7. Run the full test suite and type checker required by the repository.
8. Fix every failure before committing.
9. Include the checks and their results in the completion summary.

Review the tests before reviewing the implementation. The tests reveal what the agent believed the task meant. If the tests assert the wrong behavior, green output does not establish correctness.

Use TDD most aggressively where the behavior can be expressed through stable module interfaces. Service logic and data transformations are well suited to this. Front-end appearance is harder to capture with the same confidence and requires additional human inspection.

TDD is strongest where executable behavior can be tested. Visual front-end quality remains difficult. Automated browser and image tools can inspect an interface, but they may not reliably create a polished result in a mature codebase.

A passing test suite can still miss integration setup. In one implementation, automated tests and types passed, but manual use exposed a missing database table or migration state. Feedback loops reduce blindness; they do not eliminate the need for QA.

Tests can also be badly designed. An agent may test trivial details, mock too much, or wrap every small function in an isolated boundary. Human review of test intent remains essential.

Treat tests and executable checks as the agent's sensory system. Write the failing behavior first, implement against it, run broad feedback loops, and inspect the tests themselves before trusting a green result.