A Failing Test Gives Coding Agents Direction

A coding agent can produce a working-looking change in seconds, but speed does not tell you whether the change solves the right problem. Asking the agent to write tests before implementation gives both of you a chance to make the expected behavior visible before the code takes shape.

This approach borrows from test-driven development, a practice built around a short cycle: write a test, see it fail for the expected reason, make it pass, and improve the code while keeping the test passing. You do not need to master the practice to benefit from its central idea. A test is an executable example of what the software should do.

A Useful Test Describes Behavior Before Implementation

Suppose a small application calculates a delivery fee. You want orders above a certain amount to qualify for free delivery. Before asking the agent to change the calculation, describe a few concrete cases: an order below the threshold, one exactly at it, and one above it. State whether the threshold is inclusive, because that detail determines the expected result.

Ask the agent to turn those examples into tests using the project's existing test framework. A good test checks an observable result, not an internal detail such as the name of a temporary variable. This leaves the agent free to implement the behavior in a way that fits the project.

Tests also expose gaps in a request. If the agent asks about discounts, taxes, or invalid amounts, decide which rules belong in this change. You can record the rest as follow-up work instead of letting the agent invent business rules.

The First Failure Needs a Careful Look

Run the new tests before implementation, or ask the agent to run them and report the results. A failure can confirm that a test reaches behavior the existing code does not yet provide. It does not automatically prove the test is correct.

Read the failure message. A test that fails because the delivery fee is wrong is useful evidence; a test that cannot start because a dependency is missing tells you something else. Setup errors, incorrect imports, and broken test data should be fixed before treating the failure as a meaningful signal. Some edge-case tests may already pass, and that is fine: they can still protect existing behavior.

Review The Tests Before The Agent Implements

Pause between test writing and code writing. Check that each test matches an agreed example and that its expected result follows the stated rules. Watch for tests that merely repeat the current implementation or assert that a function ran without checking its result.

Then authorize the agent to implement the smallest change that satisfies the tests. Ask it to run the relevant tests again and to report any broader checks it ran. A passing result is encouraging, but it is not proof that every possible situation is covered. Review the implementation for clarity, unintended side effects, and consistency with the surrounding code.

For risky changes, add cases for invalid input, permissions, or interactions with other parts of the system. Tests can be wrong or incomplete, and an agent can misunderstand a requirement. Human review still matters, especially when failures could affect money, privacy, or safety.

Short Feedback Cycles Work Across Agent Tools

The same workflow works with tools such as Claude Code, Codex, and Gemini CLI. Give the agent one bounded behavior, request tests first, inspect the results, and then move to implementation. Smaller cycles make failures easier to interpret and reviews easier to complete.

BestRelay, the publisher of this article, provides a quality-first API relay for these tools and any OpenAI SDK. It forwards each request to the official model named in that request without substituting another model. Its pay-as-you-go billing uses provider-reported token counts, with cache reads and writes priced separately; members can also earn a referral commission when invited users top up. Create a BestRelay account to try the workflow.