Jeroen Cottaar: evaluation

Transcript context

…We don't have a discrete answer yet, but I think what we've found is like you need deep understanding of some important parts. Some other parts like let's say a web viewer, you can vibe code more easily because that's not really if it breaks, it's fine. But like the core logic for like they say the implementation and also evaluation is especially important. Like we have to make sure it's working, but it is a case that we're gradually we are understanding less and less of our own code base. And we're struggling even with reviewing some of the changes is you might use a codex to help review some of it because it's such a broad change or we need to split it up. But things are moving so fast that you can't just manually yeah, if you just manually write everything, you can't keep up with the rest of the team. So yeah, I guess this is an active discussion, it's difficult. As for me, my career has been going on a bit longer, and let's say most of it, for most of my career, there were no coding agents, which means I also have a bit of an opportunity to still make use of patterns that have been useful in the past. And I think 1 important 1 that, as a team, we are more and more learning to use properly is requirements based engineering. So we will formally write requirements, let's say, really following the detailed prescripts like number requirements and to specify how they are tested. I mean, we might still have the coding agents helping there, but mostly handwritten. We will review that as a team, and from there, the coding agents do we can much more confidently hand it to a coding agent to implement than if it's just a Viper single prompt. Yeah. I love all of that, but I suppose that there's always been this thing, right, that in software engineering, we have specifications, we have documentation, we have user stories, we have requirements and all these things. And there was waterfall versus agile. For me, the difference between waterfall and agile is this admission that there is epistemic uncertainty. So we need, you know, like reality pushes back, we discover contours in reality that we didn't see before and we need to adapt the requirements over time. And my worry is that when when you kind of crystallize the process, I guess what I'm saying is there's more to tacit knowledge in developer teams than the requirements. There's there's there's the generative process that created the requirements in the 1st place. And when you kind of only write software for the purpose of satisfying the requirements, then the ability to evolve the requirements gets kind of deteriorated?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.