Test-driven development

He and his team had essentially spent 18 months trying to force clumsy object oriented constructs to behave like a functional pipeline.

But wait, I mean, if we're taught that TDD and interfaces and dependency injection are the gold standards of software engineering, why would he feel like they were clumsy? I mean, aren't those patterns the exact mechanisms that guarantee our code is robust?

Well, yeah, but only if you assume that complex state mutation is unavoidable.

Oh, interesting.

Right.

Because in OPIDO, you are constantly managing objects that hold both data and behavior, and that data can change.

So all those patterns you mentioned, like dependency injection and massive mock libraries for TDD, they're largely just defense mechanisms.

Defense mechanisms against the changing state.

What

you're describing is basically TDD applied to AI prompting.

In traditional TDD, you write a failing test before you write any application code, so you know exactly what success looks like.

With this, you write the failing test in your head or in that one sentence before you let the AI spin up its context window.

If you don't define what done looks like, the AI will just wander around your code base, hallucinating edge cases and burning tokens on features you didn't even ask for.

The thing that Anthropic at least points out in a lot of the things and the stuff that I've seen with them is you want your skills to be more incremental, like small, that you can plug and play.

So you could have, say... a code review skill that does like one part of the code review, or you could have a TDD skill maybe that is broken down into multiple skills.

So more modular, basically.

I haven't quite gotten there myself, but I like the concept because, you know, their argument is partially just if you write one skill that's like basically like a huge script, right? And it goes through and it does stuff and then you want to modify it or you want to take like part of that and use it for something else.

So again, the code itself isn't really that important, but there's-- the process of getting them down and organizing our thoughts was what mattered, and we've lost something in taking that away.

Now, you know, I'm sure you've seen there's lots of debates of whether or not test-driven development works, whether or not it's a good idea, uh, and so on.

I think a lot of those miss the point, because you can write really good software with TDD.

You can write really good software without TDD.

If you're, I don't know, Stephen King, you can probably write really good stories with a pen and paper or with a typewriter or with a word processor.

And you, and you find the right process that works for you.

And I don't know what his process is.

He's probably documented it in his own writing book.

This is typically how I write.

I'm not a TDD person.

I don't write a failing test and then write my code to the failing test and then go from there for a couple of reasons.

Number one, I think it encourages you to be a tactical tornado, to get back to Osterhout's ideas, where...

And if you're not doing test-driven development as you get there, you're going to be in a lot of trouble because it's the same exact problem That we saw when you didn't do test-driven development on personal projects or anything or at a company, right? You would build something, something would break somewhere else and people would go, well, why did that break? And it's like, well, you didn't have a testing practice in place.

So now one of the best things about...

My flow now is very strict adherence to TDD.

I'm very, you know, and especially with agents, you know, whereas when it was me writing the code, I might kind of know inherently, like I'm not touching this part of the app.

So I'm not now I'm like, no, you need to make sure that you got every single thing.

I feel as if maybe this is somewhat weird to say, but like my first introduction to just iterative and agile and everything was like through XP, like extreme programming.

And over the years, it's like, oh, here's how you do TDD.

And then here's how you do BDD.

And of course, most people did not do these things.

Yeah.

And I feel like, are we in a place where AI is going to actually bring TDD and BDD back? Because what you're explaining is almost like, what's the acceptance criteria for this thing? And if you don't give it acceptance criteria, you are not going to get the quality you want.

I mean, in a weird way, are we sort of going to see AI help us be more disciplined in that? I think

we already are.