Nobody Codes This Way Anymore — But Maybe They Should
In this article
**Marcus Webb** — Infrastructure engineer turned tech writer. Writes about AI, DevOps, and security.
> **Bottom line:** After six months of accepting nearly every Cursor and Claude 4.5 suggestion verbatim, I couldn't explain my own authentication middleware to a junior engineer without re-reading it first.
A 2025 MIT Media Lab study using EEG found that writers who leaned on ChatGPT showed measurably weaker neural connectivity than those who wrote unassisted — the brain equivalent of muscle atrophy.
My fix, which sounds insane until you try it: I started manually retyping AI-generated code before merging it, character by character, no copy-paste allowed.
Comprehension and retention went up. Velocity dropped by maybe 15%. For anything I'd have to debug at 2 a.m. six months later, that trade was worth it every time.
Stop copy-pasting your AI-generated code. I'm serious.
After watching my own recall of a codebase I "wrote" collapse to almost nothing in under a year, I started physically retyping every function an LLM handed me — and it's the only thing that's actually fixed the amnesia.
The Setup: A Codebase I Couldn't Explain
Back in February, I was six months into a project built almost entirely with Cursor and Claude 4.5 doing the heavy lifting.
Authentication, rate limiting, a queuing layer for webhook retries — I'd prompted it all into existence, reviewed the diffs, and shipped.
Then a teammate asked me why we were using exponential backoff with jitter instead of a fixed retry interval. I stared at the screen. I knew the code worked.
I had reviewed it, tested it, approved the PR myself. I could not, from memory, explain the reasoning behind a decision that was sitting in a file I'd technically authored.
That's when I went looking for the MIT Media Lab paper everyone on Hacker News had been arguing about — the one where researchers hooked writers up to EEG while they used ChatGPT versus writing solo, and found the AI-assisted group showed weaker brain connectivity and worse recall of their own work, even minutes after finishing it.
The paper was about essays, not code. But sitting there unable to explain my own middleware, the parallel felt uncomfortably exact.
Copy-Paste Is a Skip Button, Not a Shortcut
Here's the thing nobody wants to say out loud: **when you copy-paste code, your brain treats it like information you've already processed**, because visually, you did just "read" it.
But reading a diff and encoding it into long-term memory are different cognitive tasks, and the second one requires friction. Copy-paste removes the friction entirely.
I'd been calling this "cognitive debt" in my own notes for months before I found a name for the pattern I was seeing.
**You're not building understanding, you're building a proxy for understanding** — a feeling of having reviewed something that isn't backed by the recall you'd need if that code broke in production without an LLM nearby to explain it back to you.
Andrej Karpathy's "vibe coding" post from early last year captured something real about how fast you can move when you stop fighting the model and just accept what feels right.
What it didn't warn people about is what happens eighteen months into vibe coding a system you now have to maintain solo.
Velocity up front, comprehension debt compounding in the background — and debt always comes due.
The Retyping Experiment
So I ran an experiment on myself for a sprint, then extended it because it worked.
The rule was simple: **any code Claude or Cursor generated that was going into a file I owned, I retyped by hand from the suggestion panel** instead of hitting accept.
Not transcribing blindly — reading each line, deciding if I agreed with it, and only then typing it out myself.
Three things happened I didn't expect.
First, I started catching bugs during the retype that I'd have accepted on autopilot — an off-by-one in a pagination cursor, a missing `await` in a Promise chain that would've caused a silent race condition.
Second, my retype speed on logic I actually understood was fast; on logic I was rubber-stamping without real comprehension, my hands would hesitate, which turned out to be an incredibly good bug-smell detector.
Third — and this is the one that surprised me most — two weeks later I could explain that code from memory, the same way I can explain code I wrote in 2019 without an autocomplete in sight.
**The retyping wasn't the point. The forced comprehension check the retyping created was the point.**
Where This Falls Apart
I want to be straight with you about where this breaks down, because I've seen people take "retype your AI code" and turn it into a purity ritual that wastes everyone's time.
For boilerplate — a standard REST controller, a Dockerfile, a config schema you've written a hundred times — retyping adds friction with zero comprehension benefit, because there's nothing new to encode.
You already know it cold.
The technique only pays off on code you'll actually need to reason about later: business logic, anything touching security or money, algorithms with real trade-offs baked in, code you'll be debugging alone at odd hours.
Applying it to everything is how you turn a useful discipline into busywork that makes people quietly resent you and quit doing it within a week.
There's also a scale problem nobody in the "just retype everything" camp wants to address.
If you're shipping fifteen PRs a day at a startup burning runway, a 15% velocity hit isn't a rounding error — it's a resourcing conversation with your manager.
This is a tool for code with a long half-life, not a universal law of software engineering.
And retyping doesn't replace testing, code review, or actually understanding your architecture at the system level.
It's a comprehension forcing-function for the *line level* — it will not save you from approving a design that's wrong at the design level, because typing something out slowly doesn't make a bad decision good.
What to Actually Do About It
I'm not telling you to abandon Cursor, Claude, or Copilot — that ship has sailed and honestly, it should have.
What I do now is a three-tier rule I've started calling **Copy, Read, Own**, and it's the framework I wish someone had handed me a year ago:
- **Copy** anything disposable — scripts you'll run once, prototypes you're throwing away, boilerplate you've written a hundred times before. Accept the suggestion, move on, don't overthink it.
- **Read** carefully anything mid-stakes — a new API integration, a utility function other code will depend on.
You can still paste it, but read every line like you're going to be quizzed on it, because eventually you will be, usually by production.
- **Own** — retype by hand — anything that touches auth, payments, data integrity, or any logic you'll be the only person on your team who understands.
If you can't explain why a piece of code exists, you don't own it yet, no matter whose name is on the commit.
The other habit worth stealing: once a week, pick one file an LLM helped you write and try to explain it out loud to nobody, like a rubber duck that already knows the answer.
If you get stuck, that's not an ego problem — that's your comprehension debt showing you exactly where the collateral is missing.
AI-assisted coding isn't going anywhere, and it shouldn't. It's just that "the AI wrote it and it works" was never actually the finish line — it just felt like one because shipping got so much faster.
The finish line is still the same as it's always been: you understand the system well enough to fix it when it breaks and nobody's around to ask.
Have you noticed gaps in your own recall on code you "wrote" with an AI's help, or is it just me and my one weird February afternoon?
I'd genuinely like to know if this is universal or if I just got unlucky with one bad sprint — tell me in the comments.
---
