I had an interesting conversation with a colleague a few weeks ago. He was looking at his team's metrics - sprint velocity up 40%, PRs merging faster than ever, test coverage sitting pretty at 94%. Everything green. Everything humming.
And then he said something that stuck with me: "Why does it feel like everything takes longer to fix?"
That question was the spark for this post.
The Saturday Night Scenario
Does the following sound familiar to you?
It's a Saturday night. You're finally watching that show everyone's been telling you about. Your phone buzzes. Production is down. The payment service is throwing 500 errors.
You open the code. You stare at it. You wrote this... didn't you? Actually, no. You merged this. Three months ago. Your AI assistant generated it, the tests passed, the PR got approved, and you shipped it.
And now you're sitting there, on your couch, trying to reverse-engineer the thought process of a model that doesn't have thoughts.
Your partner looks over and asks, "Everything okay?"
And you say, "Yeah, I just need to debug code that nobody wrote."
That sentence should terrify you. And it's happening in code bases everywhere, right now.
Let Me Be Clear
This is not an anti-AI post. I love AI coding tools. They've made me faster, they've made my team faster, and honestly, they've made me look a hell of a lot smarter than I actually am.
But over the past year, I've started noticing something. The code we're shipping faster... we're understanding less. The bugs we're creating faster... we're fixing slower. And the teams that are most productive on paper... are accumulating a kind of debt that doesn't show up in any dashboard.
I call it invisible technical debt. And I think it's time we make it visible.
The Productivity Illusion
So let's start with something we can all agree on. AI coding tools are genuinely incredible. Really!!
You type a comment describing what you want, and working code appears. You paste an error message, and you get a fix. You describe an API, and you get the boilerplate, the error handling, the tests, the whole nine yards. A few years ago, this was science fiction. Now it's taken for granted.
And the numbers back it up. Studies show developers using AI assistants report 30 to 55 percent productivity gains. PRs are merging faster. Features are shipping sooner. Sprints are completing ahead of schedule.
If you're a team lead looking at those metrics, you're thrilled. If you're a CTO looking at those metrics, you're buying everyone licenses for whatever tool they want.
So what's the problem?
Here's the thing about productivity metrics, they measure output. Lines of code. Features shipped. PRs merged. Time to deploy. And all of those are going up. Dashboards are green. Everyone's happy.
But let me ask you something. Does your dashboard track how well your team understands the code they shipped? Does it track how long it takes to debug a feature when it breaks six months later? Does it track whether a developer can confidently modify a function they merged last quarter?
No. Nobody tracks that. Because those things are hard to measure. And because right now, everything feels fine.
This is the productivity illusion. You're measuring the speedometer. But nobody's checking the engine.
The Compound Interest You Don't Want
Traditional technical debt accumulates slowly. A shortcut here, a hack there, a "we'll refactor this later" that never gets refactored. We all know this. We've all lived this. It's manageable because it grows at roughly the pace of human coding.
AI changes the math.
When a human writes a shortcut, they usually know it's a shortcut. They remember where it is. They can explain why they did it. The debt is visible, at least to the person who created it. When an AI generates code, the shortcuts are invisible. The developer who merged it may not even recognize them as shortcuts. They look like clean, well-structured code. They pass every check. And they accumulate at the speed of AI generation, which is 10 to 50 times faster than human coding.
Picture a graph with two lines. The blue line is traditional debt accumulation - gradual, linear-ish. The red line is AI-accelerated debt. It starts similar, then curves sharply upward. At some point, the lines cross. That's the moment where the time you spend debugging, maintaining, and trying to understand AI-generated code exceeds the time the AI saved you in the first place.
And the worst part? Most teams don't notice the crossover when it happens. Because the dashboard is still green. Velocity is still up. PRs are still merging.
The symptoms show up later, as longer incident response times, as features that take mysteriously longer to modify, as senior developers who say "I don't know, let me look at this" more and more often.
The Three Invisible Debts
So where exactly is this debt hiding? I've identified three specific types, and I've given them names, because naming things is the first step to seeing them.
Invisible Debt #1: Comprehension Debt
Code that works. Code that nobody understands.
Here's the definition: code that runs correctly, passes every test, ships to production without a single issue... and that nobody on your team can actually explain.
This isn't buggy code. This isn't spaghetti code. This is clean-looking code that happens to be a black box to every human who touches it.
And here it comes, the uncomfortable part.
You know how it happens. I know how it happens. Because I've done it. You've done it. We've all done it. The AI generates something. It looks reasonable. The variable names make sense. The structure looks clean. You run the tests, and they pass. You think, "Yeah, that's probably right."
Probably right.
That word "probably" is doing a lot of heavy lifting in your code base right now.
Here's what changed. When you used to write code yourself, you made decisions. "I'll use a map here because lookup speed matters. I'll handle this edge case because I saw it in production last month." Every line had a reason, even if you didn't write it down.
When AI generates code, the decisions are made for you. And they might be good decisions! But you didn't make them. You don't know why they were made. And six months from now, when something breaks, you can't retrace the reasoning. Because there was no reasoning. There was pattern matching on training data.
You went from being the author of your code to being the audience for it.
Let me put a price tag on this:
- Debugging code you didn't write takes 3-5x longer than debugging code you authored yourself. That's not an AI-specific stat, this has been true forever. But AI has dramatically increased the percentage of your code base that falls into the "didn't write it" category.
- The knowledge about why your code works the way it does? It lives in the model's training data. Not in your team's heads. Not in your documentation. Not in your commit messages.
- When a senior developer leaves and takes institutional knowledge with them? With AI-generated code, the institutional knowledge was never there in the first place. The developer who leaves can't do a knowledge transfer because they never had the knowledge to transfer.
Invisible Debt #2: Homogeneity Debt
When every solution looks the same.
This one is subtle. It's not about individual functions being wrong. It's about your entire code base starting to look like it was written by one person.
Because it was. It was written by a model.
Take two teams. Different companies. Different products. Different requirements. Give them the same problem - say, "build a rate limiter for an API." If both teams use AI to generate the solution, they'll get... basically the same code. Same pattern. Same structure. Same libraries. Maybe some variable names are different. But architecturally? It's a copy.
Now, is that code bad? No. It's probably the most popular pattern on GitHub for that problem. The model learned it from thousands of repositories. It's battle-tested. It's fine.
So what's the problem? The problem is what you didn't get.
A senior developer who understands your specific traffic patterns, your specific infrastructure, your specific failure modes, they might have written something completely different. Simpler. More tailored. Better for your system. But the AI doesn't know your system. It knows the internet's system. It gives you the average of every solution it's ever seen.
And the average is... just that, average.
When you ask five developers to solve a problem, you get five different approaches. You debate them. You learn from the differences. Someone says, "Actually, we don't need the full pattern here because of X." That debate is where engineering judgment lives.
When you ask an AI to solve a problem, you get one approach. The popular one. And the debate never happens.
The Monoculture Risk
There's a concept in agriculture called monoculture. You plant the same crop across an entire field. It's incredibly efficient. Yields are high. Everything is optimized. And then one disease shows up that targets that specific crop, and you lose everything. Because there's no diversity. No resilience. No plan B.
This is what's happening to code bases.
When every team uses the same AI tool, trained on the same data, generating the same patterns, you get a monoculture. Imagine a vulnerability is discovered in a common pattern that AI tools love to generate. How many code bases are affected? Not one. Not ten. Thousands. Tens of thousands. Because they all got the same code from the same model.
With human-written code, vulnerabilities are scattered. Different teams make different mistakes in different places. It's messy, but it's resilient. With AI-generated code, vulnerabilities are correlated. Same tool, same training data, same output, same bug, same place, at scale.
Security people reading this, I see you nodding.
And there's one more cost that bothers me the most. When AI consistently gives you the popular solution, your team stops exploring alternatives. The muscle that says "wait, what if we approached this differently?", that muscle weakens. And you end up with a team of developers who are incredibly fast at implementing the AI's ideas... and increasingly unable to have their own.
Invisible Debt #3: Ownership Debt
It's in my repo. But it's not my code.
This is the human one. The first two debts are about code. This one is about people. Ownership debt is what happens when your team stops feeling responsible for the code in their own repository.
Think about the shift:
In 2022, when something broke, the developer said, "I'll fix it - I wrote it, I know where to look." In 2026, when something breaks, the developer says, "Let me try regenerating it with a different prompt."
That's not debugging. That's gambling. You're rolling the dice and hoping the AI gives you a better answer this time.
And here's the psychological piece that nobody talks about. When you write code, you feel ownership. It's yours. You're proud of it, it's your baby, or at least you're responsible for it. When it breaks, it's personal, and that's actually a good thing, because it means you care enough to fix it properly.
When AI writes code and you merge it, there's a psychological distance. It's not yours. You're a curator, not a creator. And when it breaks, the instinct isn't "let me understand what went wrong", it's "let me get the AI to try again."
Let me walk you through a scenario that's happening right now on teams everywhere.
Month one. A developer needs to build a data pipeline. They describe it to their AI assistant. The AI generates it - ingestion, transformation, validation, output. Beautiful. Tests pass. Ships to production. Everyone's happy.
Month three. An upstream data format changes. The pipeline breaks. The developer who merged it opens the code.
And here's the moment of truth. Do they read the code, understand the transformation logic, and make a targeted fix? Or do they open their AI assistant, paste in the error message, and say "fix this"?
If your honest answer is "they'd probably ask the AI".
Bam!! That's ownership debt.
Because what happens when the AI's fix introduces a new bug? They ask the AI again. And again. And now you're three layers deep in AI-generated patches on top of AI-generated code, and nobody, nobody, has a mental model of how this pipeline actually works.
You don't own code you can't change confidently.
And this has a human cost. Developers who spend their days reviewing and merging AI output start to feel like operators, not engineers. They're not solving problems, they're supervising a machine that solves problems. That's not why most of us got into this field.
Your best developers, the ones with options, they notice this first. And they leave. Not because the AI is bad, but because the work stopped being interesting.
And when they leave? The institutional knowledge was never formed. There's nothing to transfer. The new developer inherits a code base that the previous developer also didn't fully understand.
It's turtles all the way down.
Why Your Safety Nets Have Holes
Three invisible debts. Some of you are thinking, "Okay, but we have processes for this. We have tests. We have code reviews. We have CI/CD pipelines. Surely those catch this stuff."
Let me show you why every single one of these is blind to the debts we just talked about.
The Test Coverage Illusion
AI tools are phenomenal at generating tests. You point them at a function, and they'll produce unit tests, edge case tests, integration tests, the works. Your coverage number goes up. Your dashboard goes green. Everyone celebrates.
But here's what's actually happening. The AI wrote the code. Then the AI wrote the tests for its own code. The tests validate the AI's logic. Not your requirements. Not your business rules. Not the things your users actually care about. It's like writing an exam and then grading your own paper. Of course you're going to pass.
Here's a concrete example. Imagine a pricing function. The AI generated it. The AI also generated tests for it. Coverage: 100%. All passing. But there's a business rule: discounts over 30% require manager approval. It's in a Confluence doc somewhere. It's in the heads of the sales team. It's in the contract with your biggest client.
It's nowhere in this code. And it's nowhere in these tests. Because the AI didn't know about it. And the developer who accepted the code didn't think to add it, because the tests were already green. Why would you add more tests when you're at 100%?
100% coverage. Zero percent of the business rule covered. And the dashboard says everything is fine.
The Code Review Problem
When you review code a human wrote, you're not just reading code. You're reading intent. The commit message tells you what problem they were solving. The PR description explains their approach. You know the developer, you know their patterns, their strengths, their blind spots. You can ask, "Why did you do it this way?"
When you review AI-generated code, all of that context is gone. The commit message is vague. The PR description is "generated with AI" or, let's be honest, empty. And if you ask the developer why the code works this way, they say...
"I don't know, the AI suggested it."
And here's what the research shows, reviewers spend less time on AI-generated PRs, not more. Because the code looks clean. It's well-formatted. The variable names are good. It looks like it was written by someone who knows what they're doing.
So we review it faster, with less scrutiny, and with less context than we'd give to human-written code. That's not a safety net.
That's a trap door with a nice rug over it.
The Documentation Gap
AI is actually pretty good at generating documentation. It'll add comments, docstrings, README sections. But look at what it generates.
It generates what documentation: "This function calculates the retry delay using exponential backoff."
What it can't generate is why documentation: "We use exponential backoff here because our upstream API rate-limits aggressively after 3 rapid retries. Linear backoff caused cascading failures in the Nov 2024 incident (see post-mortem #47)."
The why is what saves you at 2 AM. The what is just a slightly more readable version of the code itself.
When humans write code, the why lives in their heads even if they don't write it down. You can walk over and ask them. With AI-generated code, the why doesn't exist. Not in the code. Not in the docs. Not in anyone's head. It's just... gone.
Three safety nets. Three holes.
Now you might say, dude, you are all doom and gloom, and don't give me problems, give me solutions! Ok, here you go.
The Playbook: Four Things You Can Do on Monday
I'm going to give you four plays. They're not theoretical. They're not "hire a team of consultants that will charge you half of your IT budget and come back with a 400 page document in 8 months." They're things you can bring to your team on Monday morning and start doing that week.
Play 1: Make the Invisible Visible
You can't fix what you can't see. So start measuring.
Metric one: AI Ratio. What percentage of your merged code was AI-generated versus human-authored? Most teams have no idea. They'd guess 20%. The real number is often 60, 70, sometimes 80 percent. How do you track it? Simple. Add a tag to your PR template. A checkbox. "This PR contains AI-generated code: yes/no." It's not perfect, but it's a start. You'll have a baseline within two weeks.
Metric two: Comprehension Checks. This one's my favorite because it's so low-tech it's almost embarrassing. Two weeks after a PR merges, randomly pick a developer and ask them to explain a function from that PR. No looking at the code. Just explain it. What does it do? Why does it do it that way? What are the edge cases? If they can, great! If they can't, you've found comprehension debt. Mark it. Track it. Watch the trend.
Metric three: Debug Delta. Start tracking how long it takes to resolve incidents in AI-generated code versus human-written code. You probably already have incident response times. Now slice them by whether the affected code was AI-generated. I'll tell you what you'll find, the delta is real. And once your team sees the numbers, the conversation about AI coding practices changes from philosophical to practical.
Play 2: Review Like It's AI Code
Change how you review AI-generated code. Using three simple rules.
The Explain Rule. Before merging any PR that contains AI-generated code, the developer writes, in the PR description, in their own words, what the code does and why it does it that way. Not "AI generated retry logic." I want: "This implements exponential backoff starting at 200ms, doubling up to 5 retries, because our upstream API returns 429s under load and we need to stay under their rate limit. And this bit us in the ass during the downtime in November 2025." If the developer can't write that explanation, they don't understand the code well enough to ship it.
Full stop.
The Touch Rule. Every AI-generated block must have at least one meaningful human modification before it merges. Not a renamed variable. A real change, an added edge case, a refactored condition, a different approach to error handling. Because the act of modifying code forces you to understand it. You can't change something you don't comprehend. It's a forcing function for engagement.
The Buddy Rule. AI-heavy PRs get two reviewers, not one. The second reviewer has one specific job: "Could I debug this at 2 AM without the original author?" If the answer is no, it's not ready to merge.
Three rules. You can implement all three by Friday.
Play 3: Build Ownership Rituals
Walkthrough Wednesday. Once a week, one team member picks a section of AI-generated code and explains it to the team. Not a formal presentation, just 15 minutes. "Here's what this does, here's why, here's what I'd watch out for." Two things happen. The person presenting has to actually understand the code, so they learn it. And the rest of the team gains shared context.
Rotate the hot spots. Don't let one person be the permanent owner of AI-generated modules. Rotate. If Sarah generated the payment pipeline, have David do the next modification. Now two people understand it. This feels slower. It is slower, in the short term. But it eliminates the single point of failure where one person leaves and nobody understands a critical system.
Rewrite the critical path. Identify the most important code paths in your system, the ones that handle money, user data, authentication, core business logic. If those were AI-generated, schedule time to rewrite them by hand. Not all of them. Not everything. Just the code where a failure at 2 AM means you're waking up the CEO. That code needs to be yours.
Play 4: Set Boundaries, Not Bans
Don't ban AI tools. That's a losing battle and it's the wrong answer anyway. Instead, create zones.
🟢 Green zone - AI encouraged. Boilerplate code. Scaffolding. Utility functions. Test generation for code your team already understands. This is where AI shines and the debt is cheap. Let it rip.
🟡 Yellow zone - AI with extra scrutiny. Business logic. API integrations. Data transformations. This is where the Explain Rule and the Buddy Rule kick in. Use AI here, but make sure a human deeply understands every line before it merges.
🔴 Red zone - Humans only. Security. Authentication. Financial calculations. Core algorithms that define your product. This is the code where a bug doesn't just cause an incident, it causes a headline on the daily news.
The goal isn't to stop using AI. It's to use it where the debt is cheap and avoid it where the debt is expensive. Your team can define these zones in a single meeting. Put it in your contributing guide. Make it explicit. Because right now, the boundary is implicit, which means it doesn't exist.
One Question to Take Home
Four plays.
Measure it. Review it differently. Build ownership. Set boundaries.
None of these require new tools. None of these require budget approval. None of these require your CTO to sign off on a six-month initiative. They require a conversation with your team and the willingness to slow down just enough to stay in control of what you're building.
But if all of that feels like too much to start with, let me leave you with just one thing.
Go back to work tomorrow. Pick a function, any function, one that shipped in the last month. Ask the developer who merged it to explain it from memory. No looking at the code.
If they can, great. You're in good shape.
If they can't, you've just found your invisible debt. And now you can see it. Now you can do something about it.
That's all it takes to start. One question. One conversation.
AI coding tools are the most powerful productivity tools our industry has ever seen. That's not changing. And it shouldn't change. But productivity without understanding, is just speeding towards a wall.
Build fast. Ship fast. But build things you understand. Ship things you own. And make sure that when the phone buzzes at 2 AM, someone on your team can say, "I got this."
I would be very interested to hear your thoughts or comments, so please feel free to ping me on Twitter.
Top comments (0)