The Slop Protection Team

AI is accelerating development. But it’s also accelerating the mess. The question is no longer how fast you can ship. It’s who is protecting what you ship.

In my first post in this series I talked about how the world has changed, how AI agents have fundamentally redefined what it means to be an engineer, and how the cost of writing code has collapsed while the cost of getting it wrong has not. In my second, I talked about a generation that was accidentally built for this moment, people who learned to think before the tools existed and who have been adapting to new paradigms every few years for their entire careers.

This third post is about the thing I keep coming back to. The thing that sits underneath both of those arguments and that nobody seems to want to talk about honestly. Technical debt.

Not the kind we have been managing for decades. A new kind. One that is accumulating faster than any team can pay it down, and one that most organisations have not even started measuring properly.

The old deal

Before AI-assisted development became the norm, a typical project would go live carrying somewhere around 10% technical debt. Maybe 15% if things got difficult towards the end of the timeline. You knew where it was. The tech lead could point to the module that needed refactoring. The architect could tell you which service was going to cause problems at scale. It was a known quantity. You shipped the thing, you drew up the roadmap to address it, and you moved on. That was the deal.

The deal was never perfect, but it worked because the debt was conscious. Someone made a decision to cut a corner, and someone else knew it had been cut. The knowledge existed in the team. The plan to fix it existed in the backlog, even if it kept getting bumped to next quarter. The important thing was that the debt was visible, understood, and bounded.

That is no longer the case.

The numbers

I want to lay out some of what the research is telling us, because the scale of the shift deserves to be stated plainly.

A 2026 study analysing over 8 million pull requests from nearly 5,000 engineering teams found that technical debt increases between 30 and 41% after adopting AI coding tools. A separate empirical study tracking 304,000 AI-authored commits across more than 6,000 GitHub repositories found that unresolved technical debt from AI contributions climbed from a few hundred issues in early 2025 to over 110,000 surviving issues by February 2026. That is not a gentle upward trend. That is a curve going vertical.

Ox Security’s analysis of more than 300 repositories identified ten recurring anti-patterns present in 80 to 100% of AI-generated code. Incomplete error handling. Weak concurrency management. Inconsistent architecture. These are not edge cases. They are systemic patterns appearing in the overwhelming majority of AI output. The report described AI-generated code as “highly functional but systematically lacking in architectural judgement.” That phrase should make every engineering leader sit up, because it captures precisely what is going wrong.

AI-generated code produces 1.7 times more issues per pull request than human-written code. Pull requests per developer went up 20% with AI assistance, but incidents per pull request jumped 23.5%. The code is being written faster. It is also breaking faster. And the gap between what is being generated and what is being properly reviewed is widening every quarter. One estimate puts the quality deficit for 2026 at 40%. That is 40% of code entering the pipeline that has not been reviewed to any meaningful standard.

Addy Osmani from Google coined a term earlier this year that I think captures something important about where this leads. He calls it comprehension debt: the growing gap between how much code exists in your system and how much of it any human being genuinely understands. Unlike traditional technical debt, which announces itself through friction and slow builds and that module everyone is afraid to touch, comprehension debt breeds false confidence. The tests pass. The syntax is clean. The dashboards are green. And nobody on the team can actually explain what the system is doing or why it was built that way.

An Anthropic study ran a controlled trial with 52 software engineers learning a new library. The group using AI assistance completed the task in roughly the same time as the control group, but scored 17% lower on a follow-up comprehension assessment. The biggest drops were in debugging. That is the exact skill you need most when AI-generated code goes wrong at 2am. So we are shipping more code, understanding less of it, and the code itself carries nearly twice as many issues. You do not need a crystal ball to see where this leads.

The velocity trap

None of this is necessarily because AI writes bad code. That is the lazy interpretation and it misses the point entirely. The real problem is cultural. It is the pressure to ship faster that AI has enabled, and it is what happens when the entire incentive structure of an organisation tilts towards speed.

Every product manager, every CEO, every board member has now seen the demos. They have watched someone build an application in twenty minutes that would have taken a team two weeks. And their immediate response is not “how do we maintain quality at this speed?” It is “why are we not already doing this?”

Development cycles that used to run in months now run in weeks. Features that used to take sprints now take days. The expectation has shifted from “build it well” to “build it now.” When the whole system around you is incentivising velocity, guess what happens to everything that slows you down. Architecture reviews get skipped. Security patterns get ignored. Standards documentation gathers dust. The whole concept of doing things properly becomes an obstacle to doing things quickly.

I have watched this happen. Teams that were already stretched now have AI generating code at a rate that would have seemed absurd two years ago. Developers who used to write maybe 200 lines of thoughtful, reviewed code per day are now shipping thousands. A METR study found a perception gap of 39 to 44% where developers felt 20% faster but actually measured 19% slower when you account for the full delivery lifecycle. The speed is real in isolation. But when you zoom out and include the debugging, the rework, the incidents, and the review overhead, the picture changes significantly.

This is the velocity trap. You feel faster. Your metrics say you are faster. But your codebase is degrading underneath you, and by the time anyone notices, you are six months into a system that nobody fully understands and nobody can safely change.

The code review illusion

The standard response is always the same. Code reviews will catch it. Quality gates will stop the bad code. Senior engineers will flag the issues before they hit production.

Let me ask you something. Do you know any engineers who genuinely enjoy doing code reviews? I mean actually enjoy sitting down with someone else’s pull request, reading through it line by line, checking for architectural consistency, verifying that the error handling is complete, making sure the security patterns are followed. I have worked with a lot of engineers over 25 years and I can count the ones who love code reviews on one hand. It is thankless work. It breaks your flow. And most of the time you are reviewing code that is perfectly fine, which makes it feel like a waste of time right up until the one time it is not fine and you miss it because you were reviewing your fourteenth PR that morning.

Now multiply that volume by ten. Because that is what AI has done to the review pipeline. Pull requests are 154% larger and there are 98% more of them than a year ago. Review times have increased by 91%. AI-generated pull requests wait 4.6 times longer in the queue than human-authored ones. Developers are citing review fatigue as a top contributor to burnout, and each context switch from your own work to someone else’s code costs 20 to 30% of your focus. A Harness study of 700 engineers found that 92% said AI tools are increasing the blast radius of bad code entering production. Two thirds said they spend more time debugging AI-generated code than they used to spend writing code from scratch.

So what is the natural response when you have too much code to review and not enough humans to review it? Use AI to review the code. AI reviewing AI-generated code. Let that sit for a moment. We are proposing to use the same class of technology that created the problem to validate its own output. That is not a quality gate. That is a feedback loop with no external reference point. It is the software engineering equivalent of marking your own homework.

In my first post I talked about using multiple models, playing them off each other, using one to review what another generates. That approach has real value when there is a skilled engineer orchestrating it, someone who knows what to look for and can judge between the outputs. But when the engineer is removed from the loop entirely and it becomes AI reviewing AI as an automated pipeline, you lose the thing that made the multi-model approach work in the first place: human judgement. The code review process was never designed for this volume, and automating it without that judgement does not solve the structural problem. It just adds another layer of false confidence on top of the one we already have.

The IKEA factory floor

One developer captured the feeling in a way that stuck with me. They said they used to be a craftsman and now they feel like a factory manager at IKEA. That resonated because it describes precisely what has happened to many teams. The craft of software engineering is being industrialised. And industrialisation without quality control is just a factory producing defective goods at scale.

Here is what I see happening in most engineering teams right now. Developers are generating code with AI tools as fast as they can. They throw an image across to the ops team to deploy and make it work. Most of the time they are not thinking about the architecture, the security policies, or the patterns they should be following. Not because they are bad engineers. Because the entire system around them is incentivising speed over quality. Ship it today. Launch it now. We will fix it later. Except later never comes because there is always another feature to ship, another demo to give, another sprint to start.

This model was always a bit broken. AI has turned a manageable dysfunction into an approaching disaster. Forrester predicts 75% of technology leaders will face moderate to severe technical debt problems by 2026. Gartner goes further and projects that prompt-to-app approaches will increase software defects by 2,500% by 2028. That is not a typo. Two thousand five hundred percent.

A different kind of team

So here is what I think we need to do about it. And I know this will be controversial because it requires admitting something that a lot of people in our industry do not want to admit: the current team structure does not work for AI-assisted development.

We need to reorganise.

Keep your development teams. Let them use AI. Let them move fast. Let them be the slop generators, and I use that term with no malice, because that is genuinely what the market is asking them to be right now. They are the factory floor. They are producing output at a rate we have never seen before. That is not going to change and I do not think it should change. The speed is valuable. The throughput matters. Businesses need to move quickly and AI gives them the ability to do that.

But you need another team. A team that does not exist in most organisations today. I am calling them the Slop Protection Team.

These are your senior engineers. The ones with the architectural instincts. The ones who have been through enough production incidents to smell a problem before it happens. The ones who understand not just how code works but why systems are built the way they are. In my last post I described the generation born between 1973 and 1984 who spent twenty-plus years acquiring exactly these skills the hard way, before any of it could be automated. This is where those people belong.

Their job is not to write features. Their job is to protect the company from the inevitable consequences of AI-accelerated development.

They refactor. They rearchitect. They take the output from the development teams and turn it into something that would pass muster as a quality solution. Something that is not going to be deemed 100% technical debt in a month’s time. They enforce the security patterns. They maintain the architectural standards. They are the quality gate that actually has teeth, because unlike an AI reviewer, they understand the system context, the business domain, and the reasons behind the decisions that were made six months ago.

This is not a new concept in other industries. Construction has building inspectors. Aviation has safety engineers who exist separately from the people who design and build the aircraft. Medicine has quality assurance processes that review clinical decisions. Finance has compliance teams that check the work before it goes out the door. Software engineering is one of the few disciplines where we expect the people building the thing to also be the ones ensuring it is built correctly, and then we act surprised when quality suffers under pressure. The pressure just increased by an order of magnitude. The inspection function needs to be formalised.

The learning loop

Here is the part that gets me genuinely excited about this model. It is not just about preventing disaster. It is about building a feedback loop that actually works.

Right now, the way most engineers learn is through code reviews. But as we have established, code reviews are collapsing under the weight of AI-generated volume. The educational value of the review process, which was always one of its most important functions, is being destroyed by the sheer throughput. Nobody is learning anything from rubber-stamping pull requests at 9am because they have twelve more to get through before lunch.

The slop protection model creates something different. When the protection team refactors and rearchitects the output from the development teams, those changes are visible. They are documented. They become a living record of what good looks like in your specific codebase, with your specific patterns, for your specific domain. The development teams can see exactly what was changed and why. They can see the difference between what they shipped and what eventually went to production.

That is a learning mechanism that scales. It does not require a senior engineer to sit with every junior developer and walk them through every review comment. It does not require endless pairing sessions that nobody has time for. It produces artefacts that anyone on the team can study. Over time, the gap between what the development teams generate and what the protection team has to fix should narrow. The slop generators learn from the slop protectors. The patterns improve. The refactoring burden decreases. The system gets better.

Critically, it also gives your senior engineers a role that actually matches the reality of AI-assisted development. Instead of spending their days drowning in review queues and burning out, they are doing the work they are actually good at: architecture, design, systems thinking, security. The work that AI cannot do and that creates the most value for the organisation. You keep them engaged. You keep them challenged. You keep them around. Because right now, the industry is losing people it cannot afford to lose. A Stanford study found that employment among software developers aged 22 to 25 fell nearly 20% between 2022 and 2025. The junior pipeline is already shrinking. If you also lose your seniors because they are buried under an avalanche of AI-generated pull requests with no time to do the work that matters, you end up with no pipeline at all.

This is not optional

I can hear the counterargument already. Another team? More headcount? In this economy?

Let me reframe that.

Unmanaged AI-generated code drives maintenance costs to four times traditional levels by year two. The first year already runs 12% higher when you factor in code review overhead, the expanded testing burden, and the code churn requiring rewrites. And that is before you account for the production incident at 3am because nobody understood the code that was deployed three months ago, or the security vulnerability that sat in an AI-generated configuration for six months because no one with the right experience ever looked at it.

The slop protection team is not a cost centre. It is insurance. It is the difference between moving fast and breaking things, and moving fast with someone there to catch the things before they break. The companies that work this out will ship just as quickly as the ones that do not, but they will still have a functioning codebase in eighteen months. That is the competitive advantage that does not show up in a sprint velocity chart.

The world has changed. The generation that was accidentally built for this moment has the skills the industry needs. And the organisations that survive the next five years will be the ones that figured out you cannot just generate faster. You have to protect what you generate.

Build the team. Protect the code. Or learn the hard way why you should have.