SoftwareEngineering

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. ...

A colleague said something to me recently that I keep coming back to: “Often, by the time you’ve finished articulating a complex problem for the AI, you’ve already solved it yourself.” It sounds almost like a joke. You open a chat window, start typing out your problem in careful detail — and somewhere in the middle of the second paragraph, the answer appears. Not from the AI. From you. If you’ve worked with LLMs seriously, you’ve probably experienced this. And I think it points to something important about what is actually changing in our craft — something that goes beyond the usual conversation about automation and job displacement. ...

A question recently surfaced in my LinkedIn feed that I haven’t been able to shake: How will the next generation of software developers gain experience when AI takes over the writing? The analogy offered was that of a conductor — someone who doesn’t need to play the violin to judge whether the orchestra is in harmony. It’s a compelling metaphor. But I think it lets us off the hook too easily. ...