how we stop ai from shipping bad code

Then when building the build and quality pipeline and adding all those quality guard rails to make sure that code actually does what is supposed to do that there's no dead code, you need to be a lot more aggressive than back in the day, just because not only AI makes mistakes, but also you are shipping a lot more volume, a lot more code. And so the main idea here is you want deterministic measures on your code.

Because AI already introduces a lot of probabilistics, and that's too much risk. We cannot just let it hallucinate. So we need to go back to traditional software engineering knowledge. And when we talk about deterministic measures, is the first thing we use is basically having a code linter with your own set defined where, you know, you just use as linter defaults are pretty good. And then we have TypeScript.

That's used to be enough in back in the days. But now we also have better tools like fellow for static analysis. And if you don't know what it is, check out the project, 100% recommended. But fellow is a tool where I can run it and it can tell me if there's any code duplication, trying to statistically identify duplicated functionality in the code. And I know there's a lot of people out there saying, okay, so if code is duplicated, but it turns out that if you have duplicated code, you're going to spend a lot more tokens, because you need to write unit tests on that duplicated code, you're going to have to ingest it next time you extend your codebase.

So regardless of AI, duplicated code and duplicated features are not a good thing. Then it will also check out the cyclomatic complexity. I mean, that's a way to measure functions and how complex they are, so we don't have this monolithic components that are 1,000 lines long. And the cool thing is that you can run those static measures and then feed their input back into the agent, and you have the agent correcting its own code using those static measures.