Test-Driven Development is not a way to test—it's a way to code. A way that helps you write clear code that stays clear. And clearer code is cheaper to change.

But TDD doesn't come naturally. It's almost impossible to adopt before the right architectural boundaries are in place. Boundaries that your code probably doesn't have yet.

In this session, I'll show you how to draw the hard lines in your code that keep your software soft. I'll test-drive changes in a real app—no boring toy examples here. I'll be coding live (mistakes and all), so you can see what it’s really like to work this way. And we'll cover important concepts like:

+ TDD in the age of AI-assisted programming
+ Why TDD adoption is not what it should be
+ The real relationship between TDD and good design

Boundaries, people! Let's make TDD make sense, and make our changes cheaper.