This isn’t “AI is making us dumber.” That take is lazy and mostly wrong. Here’s the straight version nobody writes: AI raised the floor of output — anyone can ship plausible-looking work now — and quietly lowered the floor of understanding — fewer people on the team can tell whether that work is actually right. The skill that used to come free, because you couldn’t produce the artifact without understanding it, is now the scarce, appreciating one. And most teams are celebrating the wrong number.
Is AI actually lowering skill, or is that just people complaining?
The craft data already turned. This isn’t a vibe.
GitClear’s AI Code Quality Maintainability Gap report, published in 2026, tracked how code itself changed as AI assistants took over. Refactoring — reworking existing code instead of piling on more — collapsed from 21% of changed code in 2022 to 3.8% in 2026. Over the same window, copy/pasted code climbed from 9.4% to 15.7%, and block-level duplication hit an all-time high: 73 duplicated lines per million, up 81% versus 2023. Developers are now roughly five times more likely to duplicate a block of code than to fold it back into what already exists.
That’s the material fingerprint of a lowered floor of understanding. Refactoring requires you to hold the existing system in your head — to know what’s already there and improve it. Duplicating doesn’t. When the machine hands you a working block, the path of least resistance is to paste it and move on. The code runs. The system quietly rots. Cross-file reuse fell 35%; work on legacy code dropped 74%. Nobody’s maintaining the thing, because maintaining it requires understanding it, and understanding it is now the expensive part.
Why don’t people notice they’ve gotten worse?
Because it feels faster, and feeling faster is what we trust.
METR ran a proper randomized trial in July 2025: experienced open-source developers, working in their own mature repositories, with and without AI. Before the study, they predicted AI would make them 24% faster. Afterward, they believed it had made them about 20% faster. It actually made them 19% slower. The felt-floor and the real-floor moved in opposite directions, and the developers — expert, motivated, working in code they knew cold — couldn’t feel the gap.
Now pair that with the mechanism. Microsoft Research and Carnegie Mellon surveyed 319 knowledge workers about 936 real uses of generative AI at work (CHI 2025). The finding that matters: the more people trusted the AI, the less critical thinking they applied — and the more they trusted their own expertise, the more they applied. Confidence in the tool and confidence in yourself pull in opposite directions. Workers reported reduced cognitive effort in 72% of knowledge tasks; the job shifted from doing the work to verifying the output, and verifying is exactly the step most people skip.
So the people who trust the AI most do the least checking — precisely when checking matters most. That’s the confidence inversion. It’s not a character flaw. It’s the default the tools are tuned to produce: fluent, confident, plausible output that invites you to stop reading closely.
So what’s the skill that actually matters now?
Judgment. Taste. The ability to evaluate rather than generate — to look at what the machine handed you and know, fast, whether it’s right, safe, and worth keeping.
Generating used to be the proof of understanding. If you could write the function, you understood the function. That link is broken. The machine generates; understanding is now a separate, optional step you have to choose to do. Which means the valuable person on an AI-heavy team isn’t the fastest generator. It’s the one with a high, well-calibrated reject rate — who throws out 80% of what the model produces because they can see what’s wrong with it.
In adoption-maturity terms, this is the jump from early stages to late ones. Generating with AI is Stage 1 — everyone’s there now, it’s table stakes. Rejecting well is Stage 4. The teams pulling ahead aren’t the ones producing the most AI output. They’re the ones who kept, or rebuilt, the judgment to say no to most of it.
How do you protect judgment on a team?
You can’t feel skill atrophy happening, and you can’t manage what you don’t measure. So measure understanding, not output. A few concrete moves:
- Review for “can you explain it,” not “does it run.” In your next code or work review, ask the person to walk you through why it’s right — not what it does, why it’s correct. A good answer names the tradeoff and the failure mode. A bad answer is a paraphrase of the code, or a shrug. That single question surfaces borrowed-confidence fast.
- Track a reject rate, out loud. Make throwing out AI output a visible, respected act, not a confession. A team that never rejects anything the model produces isn’t efficient — it’s not checking.
- Keep some no-AI reps. Judgment is maintained by exercising it. Rotate people through problems they have to reason through unaided, the way pilots still fly manually so the skill doesn’t rust.
- Measure maintainability, not just throughput. Duplication, reuse, how much of last quarter’s code anyone dares to touch. If those are sliding, the floor of understanding is sinking under you — GitClear’s numbers are what that looks like at scale.
None of this is anti-AI. Use the machine for everything it’s good at. Just stop measuring the floor that went up and ignoring the one that went down.
The one thing to try this week
In your next review, ask one question and listen hard: “Walk me through why this is right.” Not what it does — why it’s correct, and where it would break. The answer tells you whether you’re looking at understanding or at confidence borrowed from a machine. Output is cheap now. That answer is the thing that got expensive.