“I'm okay with not looking at the code as long as you're doing other things to make sure the system is operating correctly, and that you're thinking critically about how the system needs to change and evolve. If you're just not looking at the code and you're not caring about those other things, well, then you deserve everything that's going to happen to you.”

See, I feel like I've got to channel my friend Charity at this point and say the truth is production. Everything else is the lies we tell ourselves. Production is truth. But I think in terms of like a definition of what the system should be doing, there is this ongoing debate about where is that definition? Is it the code or is it the spec? Brigitte Broccoli did a nice article on Martin Fader's website recently about spectrum development. And she talks about the idea of some companies using being spec first or spec anchored. And a lot of it comes down to where they see the source of truth being. So a lot of companies are using things like Kiro or SpecKit to define a feature and then the LLM executes that spec and you can iterate on that process, right? And so a lot of people, they start off, they use the spec to write the code and then they throw the spec away. And then you get other companies that keep the spec and then when the feature changes, they just update the spec. And so they're sort of seeing a bit, the code and a bit, the spec as a source of truth in terms of what the system should do. And then you're now starting to get companies where they don't even ever look at the code and they just look at the spec. And so we're kind of going on this spectrum. She had some great terms for these. And I think for me, it's like, is that the right path? I don't know. I think there's a lot of questions about what we would need to do to get that. We have a degree of confidence about what happens when I execute a line of Java code beyond the safety of the compiler and the runtime and all that stuff. There's a lot more questions to answer, I think, before the whole world is ready to say the spec is the source of truth of what our system is supposed to do. Production is always going to be the real truth, though, just to be clear. But

I think it's a good question to just ask yourself, however you're building and however you're using agents, of where is the truth of your system right now? Is it more in the code? Do you have a spec? Is it scattered between the minds of people? Which goes back to the collaboration. Because again, a lot of the reality of a lot of startups are is a few people hold these things in their head, right? Which is okay in the beginning. But of course, as you scale, one of the reasons we used to love code review, which is now going out of fashion, but we used to share information. And when someone left the company or got ill or the famous bus factor, it was okay because other people understood because they reviewed they were taking part in that part of it. But now we're, you know, with AI code review is some companies are like, well, we're not going to do it because of it's with too much code. That

Which also goes back a little bit to what Charity was talking about on how you want to have systems that value that works about having empathy, for example,

for the work that QAs and SRE folks have had to own code in production that they did not write. They don't necessarily read or even understand, but they know how to operate. They know what good looks like in production. They know what it looks like when it goes poorly.

I mean, that's also a bigger thing that now more developers are having to struggle with, because if you want to do spec-driven development, you have to know what good looks like. I run these sort of half-day conferences for O'Reilly online. We did one recently on software delivery. A load of speakers and about six speakers, and four of them were talking specifically around different varieties of spec-driven development effectively. And all of them came back and says, you can't do this unless you can define what good looks like. And if you can't, don't bother. And, you know, some of those people were much more bullish, like Addy Osama is very bullish on all of this stuff. But one of the presenters who was doing, they've got like a small software fraction, only team or three people, but like they're actively pulling in their observability data, their OTEL stuff, right, into their agent to understand how it's changing. And I think that's exposing, I think, more developers into understanding. I mean, this comes back to the acceptance criteria, stuff people do in stories. They were always very narrow around functional requirement stuff. So now it's like, I think we'd have to be more grown up about those things. The discipline is absolutely important and the expertise is still needed. It's just needed at a different place.