Shift Note: Tests Before the AI Writes the Function

Start the shift with an example, not an implementation

An AI coding assistant can produce a function before you have finished explaining the problem. That speed is useful, but it can also hide a misunderstanding. Writing tests first gives you a way to describe the expected behavior before the assistant chooses how to build it.

A test is a small, repeatable check. It supplies an input, runs some code, and compares the actual result with the result you expected. In a test-first workflow, you write that check before writing the feature. The test becomes a concrete instruction that both you and the assistant can inspect.

Turn one shipping rule into three checks

Suppose you need a function that calculates a shipping charge. Standard shipping costs five dollars, but orders of fifty dollars or more ship free. Rather than asking the assistant to build an entire checkout system, start with that single rule.

Ask: “Using the test framework already installed in this project, write tests for a shipping-charge function. An order subtotal of 49 dollars should return 5 dollars. Subtotals of 50 and 51 dollars should return zero. Do not implement the function yet, and do not add dependencies.”

Those examples cover the boundary where the behavior changes. They also expose questions worth answering before coding. Does the subtotal include tax? How should money be represented? What happens with a negative amount? Decide which questions belong in this task rather than letting the assistant quietly invent business rules.

Check that the first failure means something

Run the tests yourself, or let the assistant run them if your environment permits it. Read the output. A failing test is useful only when you understand why it failed.

• A missing function may be an expected first failure, but you may need a minimal function stub before testing behavior.
• A broken import or missing test runner is a setup problem, not evidence that the shipping rule has been checked.
• A test that already passes deserves inspection because existing code may satisfy it, or the assertion may not actually check the result.

Once the test reaches the intended code and fails for the expected reason, ask the assistant to write the smallest implementation that makes it pass. Explicitly tell it to leave the agreed tests unchanged.

Keep the red, green, refactor loop small

This cycle is often called test-driven development, or TDD. Red means a test fails because the required behavior is missing. Green means the implementation passes the tests. Refactor means improving the code’s structure without changing its behavior.

With an AI assistant, keep each cycle narrow. Add one behavior, inspect the test, run it, request the implementation, and review the changes. Then run the relevant existing tests as well. A new function can pass its own checks while breaking something elsewhere.

A useful follow-up prompt is: “Implement only the behavior covered by these tests. Explain any assumptions, avoid unrelated changes, and report which test commands you actually ran.” If the assistant cannot execute commands, treat its suggested commands as instructions for you, not as proof of a passing run.

Review the tests as carefully as the code

AI-written tests can be wrong too. Check that expected results come from your requirements, not from whatever the implementation happens to return. Avoid tests that merely repeat the same calculation as the function; both can share the same mistake.

Prefer checks of observable behavior over unnecessary checks of internal structure. Your shipping test should usually care about the returned charge, not the names of temporary variables. Tests make change safer, but they do not prove that every requirement or edge case has been covered.

Keep model access separate from acceptance decisions

If you use different assistants across projects, Relay365 can fit as a pay-as-you-go relay desk for multiple model families. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. That can be useful when accessing models through your preferred coding tools, but it does not replace running tests or reviewing changes.

If that access arrangement suits your workflow, create a Relay365 account. Keep the engineering routine unchanged: agree on the behavior, inspect the failing test, make the smallest change, and verify the result before accepting the work.