A codebase contains between 15 and 50 defects for every 1,000 lines of code. That statistic comes from Code Complete by Steve McConnell, and it has stuck with me ever since I heard it.
With all the focus on AI-centric workflows, this post might be a little contrarian. For me, it’s a necessary reflection on the current state of the software industry.
My own experience
There’s no doubt that AI has allowed me to move faster. Late last year, I joined a new project as a back-end engineer. The project’s back-end was written in Go, which was a language that was completely new to me. With the aid of AI, I was productive almost immediately and started fielding tickets in my first week on the project. If I wasn’t able to use AI, it would have taken me much longer to orient to the codebase, learn the ins-and-outs of Go, and assimilate it to other languages that I was familiar with.
I’m not averse to using AI tools; I use them all the time and have written some of my own as well. In the last year, I’ve trained an ML model to predict real user experience, done analysis with K-Means clustering, built my own RAG, and built an MCP Server.
However, in the back of my mind, I have concerns about these new ways of working. If these tools allow developers to build more features faster, a corollary to that is they allow us to create defects faster as well.
Model availability and cost
We’re in the early days of market disruption, and providers are currently subsidizing the cost to access these models while they try to become essential infrastructure for businesses. Eventually, they will move to more sustainable pricing models. There are murmurings of companies in the industry expressing concern about token cost, but cost won’t truly be a limiting factor until the subsidies go away. Until then, it’s easy to let a platform sprawl with feature after feature because it’s relatively inexpensive to do so.
With agentic workflows, there is a danger that a team might offload its understanding of a system to the model that wrote it. This danger was not present “the old way,” and losing access to the model that wrote the system due to cost or emerging regulations means losing the one thing that could explain why the code works the way it does. If that happens, the team is left holding a system it never fully understood, at exactly the moment it needs to understand it.
The importance of mental models
I’m currently taking the Advanced Go course from Bill Kennedy, and it emphasizes building a mental model of a codebase, reducing cognitive load, and focusing on semantics.
The course was created before the AI era, but I agree with the overall philosophy and think these points are even more important for developers who are using AI tools. When development is delegated to an agent, it becomes more challenging to form a proper mental model of the codebase. For example, the agent might not consider how data moves around an application or how state is managed in a UI. LLMs do things like drift from a design system, miss existing conventions, and treat things like accessibility as a trade-off. Over time, an engineer might start to lose track of why some decisions were made, what patterns exist in an application, and how things work in general if they rely on AI too heavily.
It’s already difficult to create a spec or plan that captures all of this, even with all the skills, context, MCPs, and documentation you can provide up front when the information is fresh in your mind. When your platform spawls and the engineers don’t have a mental model of a system, it’s even harder as time goes by.
The current industry narrative
People are adopting ways of working that involve using AI more and more. “Nobody writes code anymore,” “we write specs and not code,” “build the software factory,” “you should be designing loops that prompt your agents” are all statements about AI that I’ve heard in the last month.
These days, my LinkedIn feed is filled with posts in two categories:
- Someone talking about AI or agentic development, what they do, and what we should be doing
- Someone who has been out of work for an extended period of time and is looking for new opportunities
When seeing those two things together in the same feed, it’s not a hard stretch for people to feel like they should be pushing toward using AI as much as possible out of fear of being left behind. I’ve even seen “AI levels” like it’s supposed to be an aspirational goal to reach the highest level of sophistication.
My opinion is that these new ways of working are exciting, but they are not one-size-fits-all. There are many different ways to use AI in development, and it’s important to consider the specific needs and goals of each project when deciding how to use AI. Instead of defaulting into as much AI as possible, I think the trade-offs should be carefully measured between velocity, cost, and quality.
For example, if you’re a startup and time to market is a critical factor, maybe you let it rip and factor the cost of token usage into your burn rate. However, if you’re a large enterprise with a complex codebase in a heavily regulated industry, you might want to be more cautious about the oversight you delegate to an agent.
Judicious application of AI
Over my career, one of my favorite sources of engineering wisdom has been the Software Engineering Body of Knowledge (SWEBOK), and I think it offers some gems to help navigate the risks of AI-native development workflows.
Before continuing, let’s provide some definitions from the SWEBOK Software Quality Knowledge Area (KA):
- Error
- A human action that results in a defect. We’re the ones designing and planning software, so we’re the ones accountable for the mistakes.
- Defect
- A flaw in a work product such as code, design, or a requirement. It is latent; it exists whether it has been discovered or not.
- Failure
- Observable incorrect behavior that occurs when a defect is activated.
Since I began this article with framing around defects, this quote from the SWEBOK Software Quality KA hit home.
A healthy software engineering culture includes many characteristics, such as the understanding that trade-offs among cost, schedule, and quality are a basic tenet of any product’s engineering.
Every project is already making this trade-off. The only real choice is whether the trade-off is made consciously by someone accountable for the decision, or whether it’s made by default and distributed across many small choices that nobody tracked.
The pitch is that AI collapses the triangle: ship faster, spend less, and quality holds because the model doesn’t get tired, cut corners under deadline pressure, or forget to write the test. To me, that seems like a claim that the trade-off has been engineered away, and we can now achieve the coveted trifecta.
However, my position is that the trade-off still exists, but it’s less visible as more tasks get delegated to agents. Consistency is different from correctness. An agent can apply the same judgment uniformly across a codebase, but if that judgment doesn’t fit the codebase’s specific constraints, it now produces the same wrong pattern everywhere instead of a few isolated mistakes.
The trade-off didn’t disappear. It just moved from “does this developer cut corners under pressure” to “does this model’s judgment match what this codebase actually needs,” which is a harder question to audit because it doesn’t show up as a missed deadline or a skipped step. It will, however, show up as a defect nonetheless.
What we can learn about quality from SWEBOK
Detection activities like tests, reviews, and audits find defects after they are created. Prevention activities like standards, training, process discipline, and quality culture reduce the rate at which defects are created in the first place. All of these come at a cost, and it’s a matter of when the cost gets paid.
The SWEBOK Software Quality KA states that we should have a classification system in place to label and quantify errors, defects, and failures of a system. Unfortunately, without a proper mental model, it becomes harder to classify and identify where failures are occurring and where they are likely to occur. This is especially true for AI-generated code, where the agent might make an implicit trade-off, make a decision, or write something more verbose or complicated than what’s needed to meet the requirements.
AI-generated code can change where defects enter the system and how densely they are distributed, and I still believe it’s important to have a human review things at every step. Everything moves so quickly now that the software development lifecycle is getting condensed and more work is in progress at any given time. This makes it harder to nail down where in the process the defect originates in the spirit of continual improvement.
Example scenario
Let’s look at this hypothetical but realistic example. Pretend an agent is prompted to add a caching layer. It decides, unprompted, to skip invalidating the cache on one update path because the happy-path tests it wrote for itself never exercised that path. That decision is the error.
The missing invalidation logic sitting undetected in the codebase is the defect. Weeks later, a user sees stale data right after making a change. That’s the failure.
Nothing in that chain requires the agent to be malicious or even wrong about the code it was asked to write. The LLM made a scoping decision that nobody was positioned to catch because no human held enough of a mental model of the caching layer to ask “what about this update path?”
Coming back to Go
I keep coming back to the Advanced Go course and how it has encouraged me to think about the choices I make during design. The presenter of the course isn’t interested in whether the code compiles. He’s interested in whether I can explain what a value is doing on the stack versus the heap, why something should be a pointer instead of a value, or what happens to a slice’s backing array when it’s passed across a boundary. This is a proper mental model, and none of that shows up in “it works.” Deviations from the conventions or constraints can and will show up in the form of a failure in a codebase I’m supposed to be able to reason about.
In practice, that means I want to take a few actions:
- Scoping what an agent is allowed to touch instead of defaulting to a hands-off approach
- Requiring it to explain the trade-offs behind a change rather than just producing the diff
- Treating the tests an agent writes as a starting point to extend rather than finished work
None of that is exotic. This is an expansion of decisions that many of us have had to make our entire careers but with new tools in the mix.
I don’t think the answer is to stop using agents or AI. I think it’s to be intentional about how I write software and to realize that not all situations and products are identical. I think it’s to notice, project-by-project, how much of that model-building I’m willing to delegate and to recognize that I’m still the one accountable when a defect I never saw coming finally fails in front of a user.