AI assistants have changed how we write code. The typing is nearly free. What has not changed is the need to understand the problem before solving it.
This is a renaissance for Test-Driven Development, TDD, and Behaviour-Driven Development, BDD. When generating code costs almost nothing, the specifications become the most valuable thing a developer produces. Concrete examples, failing tests, clear acceptance criteria — these are no longer just good practice. They are what separates working software from plausible-looking software.
The developers who write clear, testable specifications and let AI handle the implementation will build better software faster than those who prompt an assistant and hope for the best.
Day 1 — Specifying before generating
You start with BDD. Conversations, concrete examples, Example Mapping — the same discovery techniques that have always worked, now more valuable than ever. You write Gherkin scenarios that describe what the system should do. Then you hand them to an AI assistant and watch it generate the step definitions and production code.
The red-green-refactor cycle gets faster, not obsolete. You write or review a failing test. Red. You ask the assistant to make it pass. Green. You look at the result and refactor. The feedback loop tightens. You spend more time on the interesting parts — deciding what to test next and improving the design.
Day 2 — Responsibility, baby steps, and characterizing tests
AI assistants make mistakes. Elegant-looking mistakes that pass a manual review but fail on a boundary condition the assistant never considered. Day two is about staying in control.
You will practise baby steps — small enough that you can review every change. You will learn to use characterizing tests to fill coverage gaps in existing code before refactoring. You will build the discipline of seeing every test red before any production code changes.
You can never blame the assistant for mistakes. It is a tool. You are the professional. Your name is on the commit. When a user reports a bug and you trace it back to code an assistant generated, the conversation is not “the assistant got it wrong.” The conversation is “why did we ship this without proper tests?” Skipping tests because the code was generated rather than typed is not a shortcut. It is negligence.
What you bring home
The ability to think at a higher abstraction level — specifying what the system should do while your assistant handles the how. And the discipline to make sure that what ships to production actually works, no matter who or what wrote the code.