Tests Don't Care Who Typed the Code

Tests Don't Care Who Typed the Code

A pattern keeps showing up in teams that have adopted AI-assisted development. The reasoning sounds compelling at first: “The AI writes the code. Why do I still need to spend time on tests? Surely the AI can handle that too.” This is a misunderstanding of what tests are for. Software failure modes are properties of the system — not of the author. Whether a function was written by a junior developer, a principal engineer, or a language model, the same class of bugs is possible: boundary conditions missed, edge cases unhandled, implicit assumptions unexamined. The mechanism of authorship is irrelevant. The failure modes are not. ...

July 1, 2026 · 7 min · Karl-Heinz Reichel
Nobody Chose BSUF. You Just Followed the Path of Least Resistance.

Nobody Chose BSUF. You Just Followed the Path of Least Resistance.

Big Spec Up Front failed. Not because the people who practiced it were careless — many of them were meticulous. It failed because of something structural: the act of implementation always reveals things that specification missed. Users cannot fully articulate what they want before they see it. Complexity defeats even complete knowledge. External requirements shift before the system ships. Agile was the response. Short loops. Working software over comprehensive documentation. Iterate toward understanding instead of specifying toward it. ...

June 30, 2026 · 7 min · Karl-Heinz Reichel
parallelization_paradox_header

AI + TDD: A Shortcut to the Goal or a Loss of Insight?

Test-Driven Development has always been slightly misunderstood — even by people who practice it. The name doesn’t help. “Test-Driven” sounds like it’s primarily about tests. Coverage metrics. Regression safety. The QA team’s peace of mind. But anyone who has worked seriously with TDD, or spent time with practitioners like Emily Bache, knows that tests are almost a side effect. The real output is understanding. TDD, done well, is a method for thinking your way through a problem one small step at a time. You don’t start with a complete picture of the solution. You start with the smallest possible question: what is the simplest behavior this code should exhibit? You write a test for that. You make it pass. And in the process of making it pass, you learn something — about the problem, about your assumptions, about the design that is quietly trying to emerge. ...

April 21, 2025 · 6 min · Karl-Heinz Reichel