How AI Changes What Good Code Looks Like

AI did not change what good code is. It changed what good code proves. Clean, working, idiomatic code is now the cheapest artifact in software: any engineer with a frontier model can produce it in minutes. So the definition of quality has moved up a level, from the file to the system and the process around it. Good code in 2026 is code that is woven into the codebase instead of duplicated beside it, that surfaces errors instead of hiding them, that someone actually verified, and that survives the next change in requirements. This article walks through the data behind that shift and what it means for how you review code and evaluate engineers.

Good code used to mean a good engineer

For most of my career as a CTO and VP R&D, reading a candidate's code was a reliable shortcut. Writing clean, well-structured code required understanding. You could not fake naming things well. You could not fake a sensible decomposition. The artifact was proof of the thinking, so we built entire hiring processes on inspecting artifacts: take-home projects, portfolio reviews, algorithm puzzles.

AI severed the link between the two. A model trained on decades of well-reviewed open source produces idiomatic, commented, plausible code by default. Style, the thing reviewers spent the most time on, is now table stakes. The artifact stopped being evidence of the engineer.

That would be fine if AI code were reliably good all the way down. The data says it is not.

What AI-era codebases actually look like

GitClear's 2026 maintainability research analyzed 623 million code changes from 2023 to 2026, the window in which AI authorship scaled to a substantial share of all commits. Every reuse signal fell and every risk signal rose:

1. Block duplication is up 81%. Duplicated code blocks climbed from 40.3 per million changed lines in 2023 to 73.0 in 2026, the highest level on record. Every duplicate imposes a propagation tax on whoever changes one copy later.
2. Refactoring collapsed. Moved (refactored) code fell from 21% of changed lines in 2022 to 3.8% in 2026, while copy/paste climbed from 9.4% to 15.7%. Developers are now roughly 5x more likely to duplicate than to refactor. In 2022 the preference ran 2x the other way.
3. New code stands alone. Function connectivity, how often new code calls into existing methods, fell 35%. New features arrive as self-contained islands instead of extensions of the system.
4. Legacy maintenance is disappearing. The share of changes touching code older than twelve months fell 74%, from 1.7% to 0.46%. Old code is not being consolidated or retired. It is calcifying.
5. Error masking is up 47%. Catch blocks and safe-navigation operators that swallow unexpected input are spreading, which means failures surface later and further from their cause.
6. Churn is rising. Code rewritten within two weeks of landing is up 15%, a sign that what shipped did not actually hold.

GitClear's framing is precise: the problem is not that AI writes bad code. It is that the default AI workflow is optimized to deliver atomic code, a happy path, a passing test, a closed ticket, while quietly taxing the invisible work of reuse, consolidation, and error surfacing that determines what a codebase costs to own in year three.

Review-level analyses point the same direction. CodeRabbit's study of open source pull requests found AI-coauthored changes carried roughly 1.7x more issues than human-written ones, with logic and correctness problems up about 75%. The code looks better than ever and fails more often. That combination is exactly what makes evaluation hard.

The new definition: from the artifact to the system

Put those findings together and the markers of quality shift like this:

Old signal of good code	What it proves in 2026	What to look at instead
Clean, idiomatic style	Nothing. It is the model's default output	Whether the structure survives a changed requirement
Compiles and passes tests	The happy path works	Which tests the engineer added for the paths the model skipped
Feature complete, ticket closed	Atomic output was produced	Whether the change reused existing code or duplicated beside it
Well-commented	The model comments by default	Whether the engineer can explain the tradeoffs without the comments
Defensive error handling everywhere	Possible error masking	Whether failures surface early with signal or get swallowed
High volume of output	Throughput, which AI made cheap	The delta between what the model proposed and what the engineer shipped

The left column is what most code reviews and most technical interviews still grade. The right column is where strong and weak engineers actually diverge now.

Reading became the senior skill

There is a second-order effect that matters more than any single metric: the volume of code is rising while the human attention available to read it is not. When most code is generated, the engineer's contribution concentrates in three acts.

Verification. Deciding whether to trust what the model produced, which means reading it adversarially: tracing the edge cases, questioning the error paths, testing what the model did not.

Integration. Forcing new code to connect to the system: reusing the existing module instead of accepting a fresh copy, refactoring when the third duplicate appears, updating the old code the model does not know about.

Pruning. Rejecting output. The strongest engineers I have watched work with AI delete a large fraction of what the model offers. The weakest accept nearly all of it. That acceptance rate is one of the most revealing numbers in modern engineering, and almost no evaluation process measures it.

This is the line we drew in AI cheating vs AI collaboration: the question is never whether the candidate used AI, it is whether they drove it or were driven by it. Code that was verified, integrated, and pruned is good code. Code that was merely accepted is a liability wearing good code's clothes.

What this means for hiring

If your technical assessment grades the artifact, everyone now passes. The take-home comes back clean because the model wrote it clean. The detection arms race does not fix this, because the problem is not cheating. The problem is that the thing you are grading stopped carrying signal.

Eval-X is an AI-native technical interview platform that evaluates how engineers work with AI rather than the code artifact alone. Candidates work in a browser-based IDE with real AI assistance, and the platform records the full session: every prompt, every accepted and rejected suggestion, every edit, every test run. Scoring runs across six dimensions of engineering judgment, and the Code Quality dimension asks one question: does the code survive change? Style is worth little. Structure, integration, and error behavior are worth a lot, because those are the qualities the data shows AI-era codebases losing.

How to evaluate code quality in the AI era

Whether you use a platform or run interviews yourself, five moves translate the new definition into practice:

1. Grade the delta, not the snapshot. Change a requirement mid-task and watch what happens. Code that was understood adapts cleanly. Code that was accepted wholesale gets regenerated from scratch, and the candidate cannot tell you what broke.
2. Ask where the code connects. Have the candidate walk through what existing code their change touches, reuses, or should have reused. Isolated, self-contained solutions in a task that provides an existing codebase are the signature of duplicative reinvention.
3. Review the unhappy path first. Ask what happens on bad input, on timeout, on a partial failure. Engineers who verified their code answer immediately. Engineers who accepted it start reading it in front of you, which is itself the answer.
4. Watch the verification, not the generation. The generation step tells you about the model. The candidate's next five minutes, what they test, question, and correct, tell you about the engineer. This is the core of assessing AI collaboration skill.
5. Score the pruning. Track what the candidate rejected, simplified, or deleted. Zero rejections across a full session is not a sign the model was perfect. It is a sign nobody was driving.

What has not changed

The fundamentals did not move. Naming, boundaries, data modeling, knowing when a dependency is worth its cost: taste still separates engineers, and AI amplifies it in both directions. An engineer with judgment uses the model to produce more good code than was previously possible. An engineer without it produces more liability per hour than any human could type. The ceiling went up and the floor went down, which is precisely why the artifact in the middle tells you so little.

Good code still exists. It just stopped being self-evident. You now have to look at the system around the code and the process behind it to know whether it is there.

If your hiring process still grades code the way it did in 2022, that is the gap Eval-X was built to close. See how session-level evaluation works at eval-x.com, or start with our guide to assessing AI collaboration skills.