Shift note: Put a failing test ahead of the AI patch

Start the shift with an example, not an implementation

An AI coding assistant can produce a plausible patch before you have finished deciding what the feature should do. Writing tests first slows down that first decision on purpose. You describe the behavior you need, turn it into a check the computer can run, and only then ask the assistant to implement it.

This approach is usually called test-driven development, or TDD. Its basic loop is simple: write a test that fails, make it pass, then tidy the code without changing its behavior. An AI assistant can help at each stage, but you remain responsible for deciding whether the tests describe the right thing.

Give the assistant one small behavior to pin down

Suppose your application needs a delivery-fee function. Orders worth at least $50 receive free delivery; smaller orders pay $5. Before asking for code, settle the details. Does an order worth exactly $50 qualify? What happens if the amount is negative? Is the amount represented in dollars or integer cents?

For this example, choose integer cents, make 5,000 cents the free-delivery threshold, and reject negative amounts. These decisions become the starting contract. They come from your requirements, not from whatever implementation the assistant happens to suggest.

A useful first prompt is: “Inspect the existing test setup. Add tests for a delivery-fee function using integer cents. An order of 4,999 cents costs 500 cents to deliver, an order of 5,000 cents ships free, and negative amounts raise the project’s usual validation error. Do not implement the function yet. Explain any assumptions before editing.”

Check that the first failure means something useful

Review the proposed tests before running them. A test is a small executable example: it supplies an input and checks the result. For a beginner, the most important question is whether you can explain each expected result without reading the future implementation.

• Check that the examples cover the threshold, not just a comfortable value far above it.
• Check that the assertions verify actual results or errors rather than merely confirming that some code ran.
• Check that the assistant used the project’s existing testing tools instead of introducing an unnecessary framework.

Run the relevant tests yourself, or have the assistant run them and inspect the output. A broken dependency or incorrect import does not demonstrate that the intended behavior is missing. If necessary, add only the minimal function declaration needed to reach a meaningful failure. Confirm that the new test fails because the required behavior is not implemented.

Authorize the patch only after reviewing the tests

Now ask: “Implement the smallest change that satisfies these tests. Do not weaken or remove assertions. If a test seems inconsistent with the requirement, stop and explain the conflict.”

This instruction helps keep the task focused, but it is not a guarantee. Review the diff. An assistant might make a test pass by hard-coding the examples, bypassing validation, or changing unrelated behavior. Look for an implementation that follows the rule, rather than memorizing the tested inputs.

Run the focused tests again, then the relevant broader suite. Once everything passes, simplify confusing names or duplicated logic and rerun the tests. That cleanup step is the final part of the TDD loop.

Keep passing tests separate from proof of correctness

Tests only check the cases and properties they express. When the same assistant writes both tests and implementation, one mistaken assumption can appear in both. Compare the result with the original requirement, add overlooked cases, and use human review where consequences matter. Passing unit tests do not establish security, performance, or production readiness.

Choose assistant access without changing the review loop

If your team wants pay-as-you-go access across model families, Relay365 is worth considering. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients, so it can fit an existing assistant workflow. Create a Relay365 account if that access model suits your setup, and check current pricing and compatibility before adopting it.

Whichever assistant you use, keep the same handoff rule: agree on behavior, inspect a meaningful failing test, review the implementation, and rerun the checks. The useful shift is not asking AI to write more code. It is giving both you and the assistant a clearer definition of done.