Five years ago these habits made you fast. They turned a tired engineer into a reliable one. They were the muscle memory that let you ship on a Friday afternoon without breaking the build. Now, paired with a model that writes plausible code at five times your typing speed, the same habits are the reason your regression rate is up. The fix is not heroic. It is to name each habit, notice it, and replace it with the senior version.
Why this matters
Habits are not personality. They are scripts the brain runs when attention is elsewhere. The trouble with AI pair programming is that attention is now somewhere new — on the suggestion stream — and the old scripts run unchanged in the background. The result is a quiet competence drop the engineer cannot see in their own work. Naming the scripts gives you something to interrupt. The rest of this post names five, shows what each costs by skill band, and walks the escape pattern that breaks them.
Why do these habits fail specifically with AI?
Each of the five was once a way to manage a scarce resource — your attention, your hands, your review time. The model breaks the scarcity. Suggestions arrive faster than you can fully read them. The diff lands cleaner than the one you would have typed. The boundary between "you wrote this" and "you approved this" gets blurry. The habits that used to economise on attention now economise on the wrong thing: on reading the suggestion, on questioning it, on noticing where the model assumed something you did not.
The first habit is typing-first reviewing — reading code by retyping it in your head. It used to be fine because the only code in front of you was code you or a teammate had just written. Now the input channel is flooded. Re-typing in your head while the model emits a hundred lines of context-light code is how you end up nodding along to a function whose middle three lines are wrong.
The second is trusting plausible diffs. You scan the surface, the variable names look reasonable, the control flow reads sensibly, and you click accept. The model has gotten very good at producing diffs that pass a surface read. Most regression-rate growth in median engineers traces to this one habit.
The third is linear debugging — reading a stack trace top-down. It was the right move when you wrote the code and your mental model matched it. Now half the frames are from a path the model wrote and you never internalised. Linear reading is slow; the senior move is to jump to the suspect frame and unwind from there.
The fourth is optimize-first iteration. You see code that does not feel right, and you tidy it. You rename. You collapse a loop. Then you check the output and discover the data shape was wrong all along. The model has raised the floor on how clean a wrong answer looks; tidiness used to be a proxy for correctness, and it no longer is.
The fifth is single-pass review — finishing a review in one read. It used to be a sign of seniority. Now it is a sign of someone trusting the surface of a model's output. The second pass is where boundary-drift and stale-context bugs get caught.
| Habit | What it used to do | What it now costs | What to do instead | Weeks to break |
|---|---|---|---|---|
| Typing-first reviewing | Built fluency in unfamiliar code by re-typing as you read. | Mentally narrates plausible AI output without catching the wrong middle. | Read by skeptical question — what would have to be true for this to be wrong? | 6 |
| Trusting plausible diffs | Cleared low-risk PRs fast when humans wrote them. | Lets stale-context and boundary-drift bugs through review. | Re-read the three lines surrounding every accepted change. | 4 |
| Linear debugging | Worked when your mental model matched the stack you wrote. | Wastes the first 10 minutes when the bug is in AI-written code you did not internalise. | Jump to suspect frames first. Use bisect on the diff, not the stack. | 8 |
| Optimize-first iteration | Kept code legible during long sessions when you wrote slowly. | Polishes the wrong answer because the surface already looks right. | Verify the data shape and edge cases before any cleanup pass. | 10 |
| Single-pass review | Signalled confidence and saved time on PRs you mostly trusted. | Skips the second pass where boundary and invariant bugs live. | Two passes always on AI-touched diffs: one for intent, one for boundaries. | 2 |
Which habit costs you the most regressions?
The cost is not uniform across engineers. The chart below shows the median regression rate attributable to each habit by skill band. Top-decile engineers pay almost nothing per habit because they tend not to carry any. Median engineers pay the most on trusting plausible diffs. Bottom-tercile engineers pay more across the board, with the largest single-habit cost on optimize-first iteration — they polish before they verify, and the polish hides the bug.
Two of the five — trusting plausible diffs and optimize-first iteration — account for most of the cost. They are both habits that mistake surface cleanliness for correctness. The fix for both is the same: verify the data and the boundary before you trust the read. That is the move top-decile engineers make without naming it. The senior version of "this looks fine" is "this looks fine and I checked the boundary."
The other three habits matter most when they compound. An engineer who reads linearly, accepts on plausibility, and reviews in a single pass is not paying three separate costs. They are paying one large cost because the same bug has three chances to escape and gets caught at none of them.
How do you actually break a habit you didn't know you had?
You cannot break a habit you cannot see. The escape pattern below is the one we teach in the Hard-tier replay program. Five stages, each with a measured retention — the share of engineers who reach the stage when they noticed the habit at the previous one. The funnel narrows because habit work is not a single-shot intervention; most people drop out before tracking, which is where the change becomes permanent.
Notice is the bottleneck most people focus on, but the steeper drop is between Replace and Track. Engineers who skip the tracking step regress within two months. Engineers who log every instance — a line in a markdown file, nothing fancy — keep the change. The tracking is not for management; it is for your future self, who would otherwise forget that you decided to read AI diffs twice.
The pause stage matters more than it looks. A habit interrupted without a pause gets replaced by another habit, often a worse one — typing-first reviewing replaced by skim-then-accept, for instance. The pause is the moment where you decide what to do next instead of letting the old script choose for you. Two or three seconds is enough.
How long does it take to replace these?
The time-to-break column in the table above is the median weeks for an engineer in our cohort to drop the habit below the once-per-week regression threshold. The numbers cluster around an unsurprising rule: habits with a clear, single-step replacement break fastest, and habits that require a new habit on top of the old one break slowest. Single-pass review breaks in two weeks because the replacement is "read it again." Optimize-first iteration takes ten weeks because the replacement requires you to verify the data shape first — a step most engineers never had, not just a step they were doing in the wrong order.
Two patterns matter for the engineer trying to break more than one habit at a time. The first is that the habits compound, but the breaks do not. Dropping single-pass review does not help you drop trusting plausible diffs; they are independent interventions with independent timers. Engineers who try to tackle all five at once tend to give up by week three. The reliable pattern is to pick one, break it cleanly, log the tracking for two weeks, and then start on the next. Total elapsed time to drop all five is around six months. That sounds slow until you compare it to the cost of carrying the habits indefinitely.
The second pattern is that the easiest habit to break first is usually single-pass review. The replacement is the lowest-friction. The win is visible in the next PR you review. Engineers who start there report higher confidence going into harder habits — they have already proved to themselves that the escape pattern works. The hardest habit to start with is optimize-first iteration; engineers who pick it first often abandon the program because the win is invisible for weeks.
The data on how much each habit costs by skill band — and how fast the gap closes in coaching.
From Codritium Research
Regression Rate by Skill Band
How often a 'fix' introduces a new bug, segmented across Easy / Medium / Hard sessions and twelve task categories. The fix-then-regress feedback loop, charted.
Common questions
Is this habit-list universal or AI-tool-specific?
Mostly universal. We tested across the three mainstream coding pairs and the share of regressions attributable to each habit varied by less than two percentage points between tools. The habits are about how the engineer reads and reviews, not about which model emits the text.
Can a habit be a good idea in some contexts and bad in others?
Yes. Linear debugging is still the right move when you wrote the code yourself and the stack matches your mental model. The trouble is that the heuristic for when to use it has shifted, and most engineers have not updated it. The rule of thumb: jump to suspect frames when the code is AI-written, read linearly when it is yours.
How do you spot these habits in yourself?
Record one half-hour pair session per week. Watch it back at 1.5x. The habits show up as the moments where you accept, scan, or move on without articulating a reason. The first time you watch yourself doing it is uncomfortable; the second time you catch it live.
Should code reviewers call these out?
Carefully. Reviewers calling out 'you accepted this too fast' tends to land badly. What works better is asking a specific question about the boundary or the invariant the habit usually misses. The engineer learns from the question without being told they had a bad habit.
Do junior engineers need to drop these too?
Two of the five — trusting plausible diffs and single-pass review — apply across all levels. The other three are habits engineers build during their first two or three years of writing code. Juniors who learn the senior alternatives first never form the bad versions; that is the cheapest path.
Where to go next
- The regression-rate study: Regression rate by skill band
- The taxonomy these habits leak: The 12 most common bugs AI pair programmers introduce
- The skill these habits erode: Defensibility, the engineering skill AI can't replace