Paul Dix

Yeah, yeah.

Yeah, it's like if there's a failure and the AIs can't actually solve the problem, then an engineer has to dig in and get deep with it and whatever.

And it's like, how do you determine what things you want to support at that level?

Because we only have so many engineering support tokens that we have to hand out.

Right.

And the thing is like, as will help scale that.

But if you get to the point where the AI can't help and you actually need to do it yourself, then there's that limitation.

So, but like, how do we, I guess it, you know, the question for me then became like, how do we avoid this kind of thing?

So one, like, as I'm,

an absolute believer in a solid verification suite.

And I think a verification suite is much, much bigger than unit tests or even integration tests.

It has to be more comprehensive.

It's basically what I would have a QA engineer do back in the day.

I got my start as a contract tester on Windows 2000 back in like 98, 99.

And I was a QA engineer.

And essentially, I spent my time writing code to create QA environments to test out new builds and test out these different scenarios and stuff like that.

I think that's going to become a lot more relevant for engineers

this year right they're going to spend a lot more time if they actually want to get the benefits of you know agentic coding velocity they have to spend more time building qa tooling to make sure that what they're cranking out is actually good and robust and all this other stuff so i basically like we have a bunch of testing internally obviously and we have multiple teams doing it but we need more and then the other piece is

kind of just like a matter of like functional code organization.

So the problem I was working on spanned across, you know, probably like 10 different files in the code base or more.