The software industry is rapidly evolving right before our eyes. It’s both exciting and somewhat terrifying to witness. Paradigm shifts are often uncomfortable, but we know that AI tooling is here to stay, so we need to make the most of it — in a responsible manner.
It’s very easy to tell a coding agent to go wild on a problem, and oftentimes it will produce workable output. Workable output, however, is only one aspect of software development. Granted, it’s a big one, but many others exist: maintainability, security, compatibility, user experience, and resilience, just to name a few. How do we make sure that the software we write, with more and more reliance on AI tooling, continues to be of high quality?
The answer is simple, though seldom easy: verification.
What is verification?
Verification refers to everything that we do to make sure our software is built correctly. It encompasses tools and processes such as linting, static analysis, unit testing, integration testing, system testing, code reviews, and manual test procedures. All these aspects of verification were important before AI tooling as well, but they are crucial now. Without proper verification, AI tooling may produce usable code, but it will accumulate technical debt at alarming rates, and eventually, the code will become a jumbled mess with lots of bugs that cannot be easily fixed either with or without AI.
So we just tack it on at the end, right?
No! Somewhat counterintuitively, most verification work done by us humans should happen before the first line of production code is even written. We need to make informed decisions on what tech stack we want to use, how the codebase should be structured, what the user experience should be. We need to determine what linting and testing tools we have available, what processes we want our AI (and everyone, really) to follow. Naturally, AI can help with all of this, but the final decisions must be made by us because, ultimately, we are responsible for the codebase, the development processes, and of course, the end product.
How do we know it’s working?
Setting up verification is one thing. Knowing whether it’s doing its job is another. This is where it becomes very easy to drop the ball. We can have all the linting rules and test suites in the world, but we need to measure their effectiveness in order for all this verification to provide real value in the long run.
Metrics matter. Start with the basics: code coverage trends, defect escape rates (how many bugs make it past our verification steps and into production), and review turnaround times. These numbers do not represent an absolute truth about the quality of our code, but tracked over time, they tell a story. If our code coverage is climbing, but the defect escape rate isn’t budging, then our tests might be targeting the wrong things. If review turnaround times are ballooning, then our process might not scale with the volume of code now being produced.
The key is to build feedback loops. When bugs escape into production, and they will, we need to do more than just fix them. We must ask why they escaped. Was there a missing test category? A linting rule that should exist but doesn’t? A review checklist item that was overlooked? Then we can feed that insight back into the verification process. We tighten the loop. This is not a new idea by any means, but the speed at which AI generates code means these loops need to be tighter and faster than ever before. Our rigor must keep up with the increasing volume of changes.
Can’t we speed things up with AI verifying itself?
The idea that AI can effectively verify itself might be the most tempting and dangerous misconception floating around today. The reasoning goes something like this: “If AI is smart enough to write the code, then surely it’s smart enough to check its own work.” And to be fair, AI can catch many of its own mistakes. But relying on it to do so consistently is like asking a student to grade their own exam. Sometimes they’ll catch errors, but they have the same blind spots that produced those errors in the first place. And besides, today’s AI tools are all based on highly advanced pattern matching, so if an erroneous pattern is repeated enough times, it may not be called out by these tools.
There’s a related objection worth addressing: “All this verification slows us down.” It does, in the short term. But technical debt has interest rates that would make a credit card company blush. The time you “save” by skipping verification today, you will pay back tenfold in debugging sessions, regressions, and rewrites six months from now. And that’s true whether a human or an AI wrote the original code!
Finally, some will argue that AI output is “good enough.” And for a quick prototype or a throwaway script, it very well might be. But production software is not a prototype. It has users who depend on it, security requirements that must be met, and a lifespan that extends far beyond the initial commit. “Good enough” has a way of becoming “not nearly good enough” the moment real-world complexity is introduced. Verification is not the enemy of speed — it’s what makes speed sustainable.
Is it really worth the effort?
With today’s AI tooling, verification is more critical than ever before. When anyone can generate code with a sentence or two of plain English, the mere act of writing the code stops being quite so meaningful. The ability to verify the code becomes paramount. It’s not a nice-to-have. It’s a baseline.
P.S. Yes, AI helped me with some parts of this post. No, it didn’t add all of the em-dashes — I happen to be a fan of them.
