About this post. I am having an ongoing argument with parts of my development team about whether AI-written code is a liability. Rather than keep arguing from vibes, I put the same question, verbatim, to three models and read the answers side by side. This post is the summary of those three transcripts, drafted with Claude Code and edited by me. The opinion section at the end is mine.

The argument, roughly, is this: using AI to write code introduces AI slop — plausible-looking output that carries a high risk of bugs and technical debt, enough to eventually bring a project to a halt.

It is not a stupid position. It is also not a position anyone on either side has brought evidence to. So I typed the same paragraph into three places:

Same prompt, no follow-up steering, no telling them which side I was on. Here is what they had in common.

1. All three conceded the concern before answering it

Not one of them opened with a defence. All three led with the failure modes, and the lists overlap almost item for item: code that compiles and passes the happy path but misses edge cases; duplicated logic instead of refactoring, because the model lacks whole-codebase context; confident use of deprecated or invented APIs; and tests that validate the implementation's own assumptions rather than the requirement.

ChatGPT added the one I find most uncomfortable — code that "technically works while making the architecture worse." That is the failure that survives review, because there is nothing wrong with any individual line.

2. AI is an amplifier, not a cause

This is the strongest agreement in the three transcripts, and the phrasing is nearly identical across all of them.

• Copilot: "AI doesn't cause slop and tech debt — it amplifies whatever process you already have."
• ChatGPT: "AI increases the throughput of both good engineering and bad engineering."
• Fable: the AI "isn't the root cause, but it's an accelerant."

The practical consequence they all draw is the same one: if your review culture is already thin and you are already under pressure to ship, the team's fear is correct — not because AI writes worse code than your engineers, but because it lets a weak process produce debt faster than it used to. Fable was blunt about it: teams that get burned are "almost always" teams where output goes in with weak review, no tests, and no clear ownership.

3. The quality boundary was never AI versus human

All three refused the framing of the argument itself. ChatGPT put it most directly — the meaningful boundary is "reviewed, tested, understood and architecturally coherent code vs. code that isn't." Copilot: the determining variable "isn't 'AI vs no AI.' It's whether the human stays the author and the reviewer." Fable: "'AI introduces slop' is a statement about process, not about the tool."

The pointed version of this, which two of them made explicitly: the anti-AI argument quietly assumes hand-written code carries some inherent quality guarantee. It does not. Copy-paste from Stack Overflow, rushed deadlines and unreviewed PRs produced slop for twenty years before any of this. Quality has always come from review, tests, architecture and ownership — never from the fact that a human typed every character.

4. The author rule, stated three times in three ways

Every one of them landed on the same single rule, and it is the one I would actually take to the team:

Whoever raises the PR must be able to explain and defend every material change as if they wrote it. "The AI wrote it" is not an answer.

Fable framed it as a postmortem test — "the AI wrote it" is never an acceptable answer in one. Copilot named it the author rule outright. ChatGPT turned it into a checklist: you should be able to say why the implementation is structured that way, what alternatives were considered, what its failure modes are, what tests demonstrate correctness, and how it fits the existing architecture. If you cannot, it does not merge.

Three models, two vendors, one rule. That convergence is worth something on its own.

5. Loss of understanding is the one genuinely new risk

Everything else on the list — bugs, duplication, bad abstractions — is an old problem arriving faster. This one is new, and all three flagged it independently.

ChatGPT called it out as the AI-specific problem it would "take very seriously": if developers start merging code they cannot explain, you end up with a codebase nobody really owns. Copilot framed it as skill erosion in juniors. Fable came at it from a different angle and, for my money, the sharpest one:

Reviewing code is harder than writing it, and when AI writes the code, your whole team shifts into review mode, which humans are demonstrably worse at sustaining.

Copilot made the structural half of the same point — the bottleneck moves from writing to reviewing, and teams that do not scale review capacity to match the new output volume get buried. That is a capacity problem with a real ceiling, and it is the argument my sceptical colleagues are closest to being right about.

6. Use it on a gradient, by blast radius

All three drew the same map, in the same direction.

Aggressively: tests, documentation, boilerplate, mechanical refactors, adapters, repetitive API migrations, well-specified bug fixes, codebase exploration, prototypes.

Cautiously: core business logic, security-sensitive paths, domain models, database schemas, new frameworks and dependencies, sweeping cross-service refactors, and architectural decisions generally.

ChatGPT drew the sharpest line here: there is a large difference between using AI for bounded engineering work and letting it autonomously redesign systems. The second one is where the compounding debt the team fears actually comes from.

7. AI is unusually good at the debt humans avoid

The inversion two of them made, which I had not expected: AI is best at exactly the work that generates technical debt through neglect. Adding the missing tests. Documenting the legacy module. Improving typing. Standardising two hundred near-identical components. Migrating the repetitive API.

Humans skip that work because it is tedious, and the skipping is itself a source of debt. A model does not get bored. Used on those jobs, with someone controlling the scope, AI is a debt reducer — which makes an outright ban a decision with a cost, not a safe default.

8. Stop arguing, start measuring

Two of the three ended in the same place: this is an empirical question, and the debate is unwinnable as a debate.

Fable's version was compact — pick a bounded area, agree the quality metrics up front, run it for a quarter, let the data decide. ChatGPT went considerably further and produced a full pilot proposal unprompted: two to three sprints, a defined scope, guardrails, and a metrics table comparing AI-assisted work against a historical baseline — cycle time, PR review comments, rework within 30 days, defects found in QA, escaped production defects, code churn, incidents, coverage, complexity warnings.

Its framing of the outcome is the part I keep coming back to:

If AI gives you 30–50% faster delivery but creates three times the defects, your colleagues have a strong argument. If delivery gets substantially faster and defect rates remain unchanged, the "AI slop" claim becomes much harder to defend.

That is a proposal both sides of my argument can sign, because it can lose.

Where they actually differed

Three things only one model said, each worth keeping.

Only ChatGPT defined failure. Alongside the success criteria it wrote an explicit list of what would prove the sceptics right — significantly higher production defect rates, repeated architectural inconsistencies, rework shortly after merge, ballooning reviewer effort, more security findings, and developers unable to explain the code they shipped. If those show up consistently, restrict AI usage or strengthen the controls. A pilot that cannot fail is marketing, so this is the most intellectually honest move in all three transcripts.

Only Copilot named the mechanism for conventions. The others said "AI should follow your existing architecture" and left it there. Copilot pointed at the actual artefacts — instruction files (copilot-instructions.md, AGENTS.md) and a durable, checked-in knowledge base of house patterns — as the specific thing that keeps output on-pattern instead of divergent. It had context on a real workspace, which is presumably why it was the only one to get concrete. Context blindness is not a fixed property of the model; it is a thing you are or are not feeding it.

Only Fable named the failure mode of banning it. Its worry was symmetrical: the teams vibing whole features into production, and the teams banning it outright, who "will lose real productivity on boilerplate, tests, and migrations, and their engineers will use it secretly anyway, which is worse." Unsanctioned use is unreviewed use. A ban does not remove AI from the codebase — it removes it from the conversation.

Also worth noting as an absence: Copilot never proposed measuring anything. Its answer is six guardrails and a bottom line, and it is the most immediately actionable of the three — but it asks you to believe the guardrails work rather than to check.

The obvious problem with all of this

I asked three AI models whether AI is dangerous. They said it is fine if you are careful.

That is a conflict of interest, and the convergence is weaker evidence than it looks in three ways. Two of the three models are from the same vendor, so I have two vendors here, not three independent opinions. Where the wording matches almost verbatim — the "fast junior developer" analogy, which all three reached for unprompted — that may be agreement on the merits, or it may be that they were trained on the same body of blog posts making the same argument. And Fable claimed "studies and plenty of postmortems" back up the point about defect rates in lightly-reviewed AI code, without naming one. I have not chased that down, and until I do it is an assertion, not a citation.

None of which makes them wrong. It does mean the honest summary is: three models trained on overlapping data agreed on a position that the internet broadly holds. The pilot is what would turn that into evidence about our codebase, which is the only evidence that settles our argument.

My take

AI code assistants make my professional life easier. They increase my productivity, help me deliver faster, and clear up my schedule, allowing me to focus on the bigger picture.

Instead of investing my time in writing the same things over and over again, I can guide my AI coding assistant to create the artifacts I need to get the job done. I'm still solely responsible for the output it produces, and I'm the one deliberately putting my name on it.

Choosing the right tool for the task at hand and automating repetitive work are both part of what I try to do every day. For me, an AI coding assistant has become one of the best tools for this kind of work — not because it replaces my role, but because it helps me spend more of my time on the work that actually requires my attention.

Where this leaves the argument

The three transcripts do not settle anything, and I do not think they were ever going to. What they did do is move the disagreement to somewhere it can actually be resolved.

Nobody in my team is arguing for merging code nobody understands, and nobody is arguing that review and tests should be optional. Once you strip out the framing, both sides already agree on the author rule, on the quality gates, and on the gradient. What is genuinely in dispute is a number — whether AI-assisted work on our codebase raises the defect rate — and a number is not something you win by arguing louder.

So the next step is the boring one. Pick a bounded scope, agree the metrics before starting, let the sceptics write the failure criteria, and run it for two sprints.

If they are right, the data will say so.