AI Coding Test-first Vs Test-after: pros & cons

I am a long-time enthusiast and expert in test-first TDD and A-TDD. And I have spent 2+ decades leading organisations and teams through major tech shifts and pioneering new ways of working.

As part of the task of reimagining how we code with AI, I am reflecting with openness and curiosity on my experience with AI-assisted coding (human-driven, agentic, frequently reviewed AI-generated code). This experience comes from creating production-grade software.

Specifically, in this post, I document the pros and cons I have observed in the test-first and test-after approaches when used with AI-assisted coding.

Structural changes AI coding brings to testing

Here, I revisit the traditional benefits of Test-First development and compare them directly with Test-After in AI-Augmented Development.

• Expressing Intent: The Test-first approach drives developers to clarify code intent and make design decisions, one test at a time. When pairing with an AI, the developer already does that every time they write a good prompt or specification for the AI, regardless of the Test-first or Test-after approach.
  
• Achieving simple design & reusable code:
  • AI generates tests in batches, eliminating Test-first traditional Red-Green-Refactor micro-cycles and ensuring simple implementation code while protecting against false positives.
    
  • Human reviews of AI-generated code focusing on code and design refactoring have the potential to lead to simple design and reusable code, even with a Test-after approach.
    
  • After implementing a few classes with a simple design and reusable code, they can be referenced in subsequent prompts as examples to follow, achieving the same simple design and code reusability as with Test-first.
    
• Documenting the code behaviour: no major differences here.
  
• Testing the tests: Test-first ensures the tests are not giving false positives, and all the execution paths are covered (think about the cyclomatic complexity), unlike Test-After. This is a difference, unless something else is done.

My own conclusions

Let’s start from the end. So far, these are my conclusions following from the Pros and Cons I have experienced in my own context.

Unlike before in manual coding, where test-first is a clear winner, now in mid-2026, I see AI-Test-first and AI-Test-after both working well, with the latter (Test-After) being faster and consuming fewer tokens while achieving the same benefits of Test=First. Each has its pros and cons. Further evolution of LLMs’ capabilities may change this; meanwhile, this is where things stand.

A Sr software engineer experienced in TDD and A-TDD, who naturally adopts the A-TDD and TDD way of thinking about behaviour and code design already when writing each prompt, may benefit from the pros of AI-Test-after while countering the cons with an additional step in which they direct the AI to perform mutation testing, fault injection, or adversarial verification.

A Jr software engineer, and everyone without ingrained TDD and A-TDD habits, may benefit from adopting the AI-Test-first approach. This guides the development along the lines of TDD and A-TDD ways of thinking, improving code design quality (resulting from code generation after tests are generated) and test reliability.

Below is the complete list of pros and cons underpinning these conclusions.

Test-first and Test-after: the Pros and Cons I experienced

• About Testable code (modular design, dependency inversion, etc.):
  
  • AI-Test-first generates testable code and architecture and helps less experienced developers to methodically adopt the A-TDD and TDD way of thinking about behaviour and code design, maintaining sight of the important design decisions.
    
  • With AI-Test-after, I direct the code behaviour and design with specific instructions in the prompt (instead of the tests); I further refine the design as necessary, with quick manual or AI-generated small refactorings during the code review step. I find this approach faster and more effective for me, as I gain speed without losing quality.
    
• The Asymmetric AI Efficiency (Rapid tests-after generation):
  
  • With AI-Test-after, I have found LLMs extremely efficient at generating good-enough tests against existing code, with little instruction, giving me a huge productivity advantage compared to AI-Test-first.
    
• AI micro-management Trap (for unit tests):
  
  • In AI-Test-first, the prompt for generating granular unit tests (before the implementation code) requires a lot of detail; writing such a prompt is very time-consuming, and not too far from manually writing the unit tests.
    
  • With AI-Test-after, it is enough to reference the class or module and ask in the prompt to generate the unit tests. Voilà.
    
• High Friction:
  
  • With AI-Test-first, the generated tests are more prone to small, time-consuming, hard-to-detect issues, such as using deprecated test framework functions, subtle mocking errors, and wrong interface or implementation assumptions.
    
• Increased Cognitive Overhead:
  
  • With AI-Test-first, spotting a problem in the generated tests, identifying the root cause, and fixing it often involves a triple conceptual indirection: Prompt => Test => Implementation code (yet to be generated). In general, it tends to require more time, attention and a higher cognitive effort.
    
• The “Double Hallucination” Trap:
  
  • With AI-Test-after, a hallucination can introduce a bug in the implementation code; later, the generated test may mirror the bug as intended behaviour. The generated test code may not cover all possible execution paths or return false positives. Furthermore, LLMs may not spot complex domain properties, existing semantic gaps, non-explicit invariants, and non-obvious failure modes; as a result, they may not generate tests for these.
    
    To counter these weaknesses, it is useful to take an additional step by directing the AI to perform mutation testing, fault injection, or adversarial verification
    
• Examples better than tests:
  
  • Where the LLM struggled to generate the right code, both with AI-Test-first and AI-Test-after, what worked for me has been providing examples (of the data or of input and output).
    
    

What others are reporting on this

See similar conclusions reported by other practitioners: compared to testing afterwards, a test-first approach increases costs and extends timelines without improving outcome quality.

See, for example, Birgitta Böckeler’s findings, here: https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html

Stefan Smith, Head of Technical Excellence at Gousto, who experimented with having the agents follow TDD, found that it doubled costs and increased latency by 2 to 3 times. A positive side effect he noted was the reduced cognitive costs of reviewing and thinking about the decisions and code changes made by agents:

Uberto Barbini, Author of “Process over Magic: Beyond Vibe Coding, on the other hand, is experimenting with making the agent write all the Acceptance tests first, so a big batch ATDD, to verify the model understood the specification, before jumping into the implementation. This is halfway between Test first (for the acceptance tests, all in one block) and Test after (for the unit and integration tests).

What is your experience so far?

Which Pros and Cons have you experienced in your own context?

_______________________________________________________________________________

Appendix 1: Useful lens: Feedforward and Feedback

Here are two concepts that can be used as lenses when analysing the pros and cons of AI Test-first and Test-after:

• Feedforward: like the prompt and what comes with it to anticipate the agent’s behaviour and aim to steer it before it acts. The guides provided in the prompt increase the likelihood that the agent creates good results in the first attempt.
• Feedback: like the output produced following the agent code generation, by a linter, a compiler, automated tests and so on, helping the agent to self-correct.

With AI test-after, during the 1st step of code generation

• Feedforward: it is easier to prompt and make LLMs generate good implementation code than good test code
• Feedback: the implementation code generated must also pass the pre-existing test suite (regression) or, in case of failures, generate feedback that triggers self-correction

With AI test-first, during the 2nd step of code generation, which follows the tests’ generation

• Feedforward: the tests generated can be easily referenced in the prompt as spec/guides, to quickly and effectively direct the code generation
• Feedback: the executable tests create, in case of failures, feedback that triggers self-correction
  

Appendix 2: Mutation testing in the local workflow Vs in the CI/CD pipeline

Running mutation testing tools like Stryker or PITest across a full codebase and test suite in CI/CD can take up to 30 minutes.
Here, the goal and granularity are different.

In manual TDD, short Red-Green-Refactor cycles, writing a failing test first, then writing only the minimal code needed to make it pass, prevent false positives and guarantee the coverage of every execution path. That’s the safety net I want to preserve.

Because the AI generates code and tests simultaneously, having the AI follow up with mutation testing on that specific changeset is fast and restores that exact safety net.

The AI spins up isolated worktrees and injects bugs across different execution paths. If a test fails to turn red, the AI immediately uses that feedback to fix the test on the spot.
The AI spins up isolated worktrees and injects bugs into different execution paths. If a test fails to turn red, the AI immediately uses that feedback to self-correct and fix the test on the spot.

It’s also possible to instruct the AI to run mutation testing tools like Stryker or PITest directly within the local workflow before CI/CD. By scoping execution to only the newly modified code and test files, runs complete in seconds. If a mutant survives, the AI captures the log and feeds it into its fast agentic self-correcting loop to fix the weak test automatically (as it does for failing builds, lint, or test failures).

This localised mutation testing and the CI/CD codebase mutation testing steps can coexist and support each other. Like running tests locally before a commit and running them as part of the CI/CD pipeline.

Ship Production-grade Software Faster with AI. No AI slop.

Drive Value Faster with AI. No AI bloat.

See how we can help across the full AI adoption lifecycle.

AI Services