Hypothesis-driven development

In software architecture, we often face moments where the correct path isn't immediately obvious. Instead of debating these choices in lengthy meetings, we can use TDD as a laboratory for hypothesis-driven development. In this context, the test isn't just checking for a bug or testing a new feature; it’s an experiment designed to validate whether a specific structural approach is viable. We treat our architectural assumptions as hypotheses that must be proven through implementation.

For example, imagine the team is debating whether a complex calculation logic should be a shared internal library or a standalone microservice. Writing a test suite that mimics the service call and implementing the minimum code to pass these tests, you might discover that the data contract is so large and complex that the simple service becomes a maintenance nightmare. The test fails the viability experiment before spending weeks on infrastructure. The TDD process also allows deciding in the Last Responsible Moment.

Reducing accidental complexity

In his seminal essay No Silver Bullet, Fred Brooks makes a distinction between essential complexity — the inherent difficulty of the problem we are solving — and accidental complexity, which is the difficulty we create ourselves through poor design, bloat and mismatched tools. Brooks famously argued that no single technology or management technique could provide a tenfold improvement in productivity. Instead, he advocated for growing software organically through incremental development rather than building it all at once.

TDD is perhaps the most effective tool to cultivate organic growth. By forcing us to write only the code necessary to pass a specific test, TDD acts as a filter that strains out accidental complexity before it enters the codebase. It prevents us from building unnecessary abstractions that Brooks warned would lead to the tar pit of software engineering. When we focus on the smallest possible increment, we ensure that the software remains as simple as the problem allows it to be.

AI agents work better with TDD

As we enter the era of AI-assisted coding, the discipline of TDD has never been more relevant. Tools like Claude Code and advanced agentic frameworks work best when they have clear exit criteria. Without a test-first approach, AI agents often fall into the trap of AI Slop and AI Smells — generating massive blocks of code that look correct but suffer from hallucinations or hidden bloat.

By instructing an AI agent to write the test first, or by providing the test ourselves, we provide the guardrails necessary to keep the agent focused. This forces the AI to provide the minimal, functional implementation required, effectively preventing the accidental complexity that Brooks warned us about. TDD transforms the AI from an unpredictable tool into a disciplined engineering partner that iterates until it achieves a deterministic, verified result.

Conclusion: ATDD and the future of orchestration

Software emerged as a commercial product approximately 75 years ago evolving into an engineering discipline around 55 years ago, triggered by the software crisis and the 1968 NATO conference. Since that time, proven methods and methodologies have been developed to address the challenges found along the way. Extreme Programming (XP) encompasses many of these solutions, TDD standing out as a pillar. TDD lies in the balance between discipline and flexibility, control and clarity. Whether we are using tests as an experimental lab for architectural hypotheses or as a filter for accidental complexity, the goal is to grow software organically and intentionally. 

Looking ahead, in a world with AI more and more present, where code agents write thousands of lines of code in a non-deterministic way, we start to see the problems that could appear in this scenario. These are problems that we’ve actually lived through in the past, and for which we likely already know the solution. Acceptance test-driven development (ATDD) is the natural evolution for this mindset, especially as we begin to orchestrate multiple AI agents. While unit tests handle the how, ATDD focuses on the what and engineers in the why from a business perspective. By defining high-level acceptance criteria before any agent begins its work, we can orchestrate complex, multi-agent workflows with confidence. ATDD will likely become the primary interface for software engineers through acceptance tests, and our agentic teams work to make those tests green using TDD.