- \n
- Intent<\/strong>: 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 to generate code, regardless of the Test-first or Test-after approach.
<\/li>\n\n\n\n- Simple design & reusable code<\/strong>:\n
- \n
- AI generates tests in batches, eliminating the Test-first traditional Red-Green-Refactor micro-cycles that ensure simple implementation code and protect against false positives.
<\/li>\n\n\n\n - Frequent AI-generated code reviews encompass both code and design refactoring.
<\/li>\n<\/ul>\n<\/li>\n\n\n\n - Behaviour documentation<\/strong>: no major differences here.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
My own conclusions<\/h2>\n\n\n\n
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 don’t see a clear winner between AI-Test-first<\/strong> and AI-Test-after<\/strong>. Both seem valid options, each with its pros and cons. Further evolution of LLMs’ capabilities is likely to change this.
A Sr software engineer experienced in TDD and A-TDD<\/strong>, 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<\/strong> 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,<\/strong> may benefit from the guidance along the TDD and A-TDD way of thinking coming from following the AI-Test-first<\/strong> and its pros in code design quality (resulting from code generation after generating the tests) and test reliability.
Keep reading my list of pros and cons; you can use it as inspiration to reflect on the pros and cons that apply to you and your context, compare and contrast.<\/p>\n\n\n\nTest-first and Test-after: the Pros and Cons I experienced<\/h2>\n\n\n\n
- \n
- About Testable code (modular design, dependency inversion, etc.):<\/strong>
\n- \n
- AI-Test-first<\/strong> 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.
<\/li>\n\n\n\n- With AI-Test-after,<\/strong> 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.
<\/li>\n<\/ul>\n<\/li>\n\n\n\n- The Asymmetric AI Efficiency (Rapid tests-after generation):<\/strong>
\n- \n
- With AI-Test-after, <\/strong>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.
<\/li>\n<\/ul>\n<\/li>\n\n\n\n- AI micro-management Trap (for unit tests):<\/strong>
\n- \n
- In AI-Test-first,<\/strong> 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.
<\/li>\n\n\n\n- With AI-Test-after<\/strong>, it is enough to reference the class or module and ask in the prompt to generate the unit tests. Voil\u00e0.
<\/li>\n<\/ul>\n<\/li>\n\n\n\n- High Friction:<\/strong>
\n- \n
- With AI-Test-first, <\/strong>the generated tests are more prone to small, time-consuming, hard-to-detect issues, such as using deprecated test framework functions, subtle mocking errors, wrong interface or implementation assumptions.
<\/li>\n<\/ul>\n<\/li>\n\n\n\n- Increased Cognitive Overhead<\/strong>:
\n- \n
- With AI-Test-first<\/strong>, 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.
<\/li>\n<\/ul>\n<\/li>\n\n\n\n- The \u201cDouble Hallucination\u201d Trap<\/strong>:
\n- \n
- With AI-Test-after, <\/strong>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.
<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\nWhich Pros and Cons have you experienced in your own context?<\/strong><\/p>\n\n\n\n
<\/div>\n\n\n\n
\n\n\n\n\n\n![\"\"](\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/develop.png\")
<\/figure><\/div>\n<\/div>\n\n\n\n\n\n\tDevelop Technical Excellence that delivers.<\/h3>\n\t
\n\t
\n\tSee how we can help.\n\t
\n\tYou, your team, your Tech.\n\t
\n\t
\n\t<\/p>\n\n\t\n\t\t\n\t\tVirtual Tech Mentoring\n\t\t<\/a> \n\t\t\n\t\tVirtual Tech Assessments\n\t\t<\/a>\n\t<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"Test-First is a clear winner in manual coding. But how does AI-assisted development shift the pros and cons and change the balance between Test-First and Test-After?<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-3606","post","type-post","status-publish","format-standard","hentry","category-ai-assisted-coding"],"_links":{"self":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts\/3606","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/comments?post=3606"}],"version-history":[{"count":14,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts\/3606\/revisions"}],"predecessor-version":[{"id":3622,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts\/3606\/revisions\/3622"}],"wp:attachment":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/media?parent=3606"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/categories?post=3606"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/tags?post=3606"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- The \u201cDouble Hallucination\u201d Trap<\/strong>:
- Increased Cognitive Overhead<\/strong>:
- With AI-Test-after<\/strong>, it is enough to reference the class or module and ask in the prompt to generate the unit tests. Voil\u00e0.
- AI micro-management Trap (for unit tests):<\/strong>
- With AI-Test-after,<\/strong> 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.
- AI-Test-first<\/strong> 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.
- About Testable code (modular design, dependency inversion, etc.):<\/strong>
- Simple design & reusable code<\/strong>:\n