AI is quietly eating my brain — cognitive atrophy, the new bottleneck, and the 5 rules I now live by

The uncomfortable pattern I noticed in myself after 18 months of heavy AI use — and the protocol I’m running to reverse it.

There is an uncomfortable pattern I have been noticing in myself over the last 12–18 months, and I suspect I am not the only one.

I ship code 2–3x faster than I did in 2023. I can stand up a new service in an afternoon. I can drop into a codebase I have never seen and have a rough mental model of it in ten minutes. By every surface metric, AI has made me more productive.

And yet, when I am honest with myself, I can feel something else happening underneath. I do not remember the code I wrote two days ago. My first reflex when I hit an error is to paste it into Claude instead of reading the stack trace. Concepts I used to know cold — isolation levels, consistency models, what a memory barrier actually does — have gone fuzzy, because “I will just ask when I need it.” When I sit down to write 500 words of technical prose without AI in the loop, the sentences come out stiffer and less finished than they did two years ago.

That is cognitive atrophy. Muscle atrophy, but for the brain. Almost nobody talks about it, which is precisely why it is dangerous.

1. The symptoms, plainly

Before you dismiss any of this as vibes, do the self-test first. Five questions, answered honestly:

When was the last time you wrote 500 words of continuous technical thinking without AI?
Can you explain, with nothing in front of you, Raft consensus, your database’s isolation level, and why TCP needs congestion control?
In the past week, how many times did you paste an error or a snippet into an AI before spending three minutes reading it by hand?
Can you still summarize the argument of a paper or book you read three months ago?
If your internet died for eight hours, would you keep working, or would you freeze?

Each “no” is one mark of atrophy. Three or more, and the situation is urgent. For a stretch of months I was at four.

These are the symptoms I keep seeing in myself and in the engineers around me:

Writing code 2–3x faster but not remembering what I wrote after two days.
Debugging slower than I did two years ago, because I no longer sit with the code; I paste.
Losing the ability to think from zero — put me on a plane with no network and I stall on problems I used to solve routinely.
Remembering less theory — consistency models, indexing strategies, allocator behavior — because “I will look it up.”
Writing prose more clumsily — the moment AI is out of the loop, my sentences become obviously under-cooked.
Reading fewer primary sources — papers, books — in favor of AI summaries, which feel like understanding but are not.

If you recognize yourself in two or three of these, welcome to the club. Atrophy does not hurt and it does not announce itself. It just quietly makes you a weaker version of yourself, twelve months at a time.

2. Why it happens

AI is good enough that it erases productive struggle — the effortful mess your brain has to sit in in order to learn. The struggle is the learning mechanism. When your brain organizes information itself, it builds connections. When AI organizes it for you, nothing rewires. You “know” the concept in the shallow sense of being able to retrieve it on demand. You do not know it in the deeper sense of having internalized it.

Worse, AI produces a false sense of mastery. Reading an AI summary of DDIA feels like reading DDIA. A PR whose tests are green feels like a PR you understand. Both are illusions, and the comfort of the illusion is what makes it dangerous — you feel no pressure to check.

The good news: atrophy reverses, exactly the way unused muscle does, provided the training is deliberate and structured. “Use AI less” is not the fix. A protocol is.

3. The bottleneck moved

Before 2023, the bottleneck for a senior engineer was execution — speed and quality. Write faster, ship cleaner, read codebases quicker, deploy with fewer incidents. That was the game, and the people who won the game were the people who won on execution.

After 2023, execution is close to free for anyone who knows how to drive AI. A motivated junior with Claude Code can approximate 80% of a senior’s execution output in three months. The 80% is no longer where the leverage lives.

The remaining 20% — the part AI has not commoditized — is:

Judgment. Knowing what is worth doing and what is not.
Taste. Recognizing what is good and what is ugly without a checklist.
Synthesis. Taking five contradictory sources and forming one coherent view.
Framing. Re-posing a question so a solution becomes visible that was not visible before.
Navigating uncertainty. Making good decisions with incomplete information.

These are the new scarcity. If you have them, AI makes you 10x. If you do not, AI makes you feel like you have them, while you quietly depreciate.

A concrete test. Give two engineers the same prompt: “build a rate limiter for a public API.”

Engineer A opens a chat and has 200 lines of token-bucket middleware in Redis before lunch. It runs.

Engineer B asks back: “who is this for? what does a rate-limit failure look like from the caller’s side? can we live with eventually consistent counts? what is our scale today, and what is the cost of a false positive vs a false negative?”

Two years ago both of them were valuable — A shipped fast, B shipped safe. Today B is worth five of A, because A has been commoditized and B has not. The move is not become B and drop AI. The move is be B and still have A’s speed, via AI.

4. The quiet advantage of backend work

Here is the part I think most backend developers miss: the job has already been training us in the new bottleneck skills, for free. We just have not been naming them.

The daily work of building backend systems forces you to think in:

Dependencies. What does this call trigger, and where?
Failure modes. What breaks if this timeout fires, this partition happens, this queue backs up?
Invariants. What state must never be violated, even mid-crash?
Time. Ordering, causality, concurrency, clock skew.
Tradeoffs. Consistency vs availability, latency vs throughput, reads vs writes.

This is systems thinking. It is, in my opinion, the single most transferable intellectual skill of the 21st century, and frontend developers, data scientists, and PMs do not get it automatically the way backend engineers do. I did not realize I had it until I started trying to write about it deliberately.

The gap is that most of us run this reflex unconsciously and only on code. The opportunity is to run it deliberately and on everything — product decisions, organizations, careers.

5. The five rules I have forced on myself

These are the habits I have been trying to install. None of them are clever. All of them are uncomfortable for the first two weeks. If you do them for 60 days they stop feeling like rules and start feeling like reflexes.

Rule 1 — Write first, prompt second

Before I ask an AI anything important, I write 200 words of my own thinking first. Problem, current approach, alternatives I have already rejected and why, and the open questions I am unsure about. Then I hand it to the AI.

Writing forces articulation. Wherever I hesitate is wherever my thinking is still mud. An AI summary of the problem hides this from me; writing my own draft makes the mud visible.

The bigger effect: once I have written my own version, AI becomes a sanity check and a critic instead of an oracle. That is the difference between studying and looking something up.

So instead of asking “how should I design a cache layer for X?”, I write:

Problem: cache for GET /users/:id, hot path, ~10k rps.
Current thinking: Redis LRU, TTL 5m, key "user:{id}", invalidate on a
  Kafka user-updated event.
Rejected: in-memory LRU (no cross-instance share); write-through (extra
  ~15ms on the register flow is not acceptable).
Open: cache stampede on mass expire? cold cache after deploy?
  region-split or not?

Then: “attack this design as a hostile staff engineer who has seen five production incidents.” The AI’s response is worth ten times more now, because it is hitting a target instead of staring at a blank page.

Rule 2 — Adversarial, not cooperative

By default I reframe my prompts from “help me do X” to “attack X” or “argue against X.”

Out of the box, Claude and ChatGPT are too nice. They are RLHF’d to collaborate, not to disagree. If I ask “is this design okay?”, 90% of the time the answer is “yes, with a few minor notes,” even when the design is trash. I think this is the most quietly destructive effect AI has on critical thinking, and almost nobody notices.

When I force the AI into an adversarial posture, I get genuinely useful feedback, and I train my own resilience to criticism. The real test of a senior engineer is not how fast they defend their design; it is how cleanly they can take a credible “this is wrong because of X, Y, Z” without flinching.

Prompts I use often:

“Here is my design. Act as a hostile staff engineer who has seen five prod incidents — find five ways this breaks in production."
"Argue against my approach. Give me the strongest counter-argument you can construct."
"If I shipped this, what would it look like 18 months from now? List three failure modes."
"Assume I am wrong. Where am I most likely wrong?”

Warning: asking for a hostile review and then ignoring it is worse than not asking. Read every argument and try to counter it in your head. If you cannot, there is a real hole.

Rule 3 — Delayed synthesis

For anything I actually need to understand, I read 3–5 primary sources before I touch an AI summary. I form my own view first, and then compare.

AI summaries are pre-digested thinking. Fine for deciding whether a topic is worth deeper attention; terrible for actually learning. If I start with the summary, my opinion anchors to it, and I lose the ability to disagree because I never developed a different view.

Do it the other way and something interesting happens: the delta between my summary and the AI’s is where the real learning lives. One of us is simplifying too hard or getting it subtly wrong. Figuring out which is the single most valuable exercise I know.

I do not try to do this on every topic — I would burn out. One topic per week is plenty.

Rule 4 — Feynman, with AI as the skeptical interviewer

Once a week I pick a concept I believe I understand, explain it in writing as if to a twelve-year-old, then ask the AI to play a skeptical staff engineer and interview me — five questions, escalating in difficulty, designed to expose someone who only memorized the definition.

I am going to explain [concept] to you. After I do, act as a skeptical
staff engineer and ask me 5 clarifying questions of increasing difficulty —
the kind of questions that trip up someone who only learned the definition.
Do not give me the answers. Only ask.

Concept: [name]
My explanation: [200–500 words]

Feynman’s point has been known since the 60s: you understand something only if you can teach it to someone who does not. The AI version has an advantage over the human version — the AI is never tired, never polite, never embarrassed when I stumble.

A 12-week reading list for a backend dev, one per week, 60 minutes, alone, no internet during the explanation:

CAP, and why the “C” does not mean what most people think.
Isolation levels in the DB you actually ship with — phantom read, non-repeatable read, write skew, when each actually happens.
TCP congestion control — why network stability comes from algorithms, not from a rigid protocol.
Raft/Paxos — quorum, log replication, split-brain conditions.
Garbage collection — generational, concurrent, stop-the-world tradeoffs.
B-tree vs LSM — why PostgreSQL picks one and RocksDB picks the other.
Event sourcing vs CRUD — not “which is better,” but “which is right for which domain.”
Eventual consistency in production — what it really means, and its failure modes.
Load balancing — L4 vs L7, sticky sessions, weighted round-robin, what each actually solves.
OAuth 2.0 — why there are so many flows, authorization code vs implicit vs PKCE.
TLS handshake — what actually happens in the first ten round-trips.
The memory model of the language you ship in — JMM for Java, Go’s model, C++ memory order.

Do these twelve and I promise you will know backend better than most people with “senior” in their title.

Rule 5 — One adjacent domain per quarter

Every quarter I pick one domain adjacent to backend and go deep, using AI as a tutor. Crucially, with exercises, not just reading.

Adjacent matters. Distributed systems, ML fundamentals (enough to make good product decisions, not enough to become an ML engineer), security, infra, database internals, a little compiler theory — all of these compound with the backend work I already do. A quarter on law or finance might be good for my life, but it would not compound.

The protocol is simple: one good primary source (book, course, paper series — not an AI summary); 30–60 minutes a day; one Feynman session per week on a concept from that domain; one small project every two weeks that actually uses what I just read; one 800-word blog post per month.

6. Five traps I keep catching myself in

These are failure modes I fall into repeatedly. Naming them helps me step out faster.

The autocomplete trap. Accepting Copilot/Cursor suggestions I have not read carefully. My codebase fills up with code I do not really understand. Fix: turn autocomplete off for critical paths (auth, payments, migrations). Everywhere else, read every suggestion as if I were reviewing a coworker’s PR. Hard rule: if I cannot explain a line I just committed in thirty seconds, I am in the trap.

The summarization trap. I “read” ten papers this month and cannot explain any of them. Summary is fine for screening — is this worth going deeper? — but anything my decisions depend on, I go to the source. No exceptions.

The authority trap. The AI is articulate and confident, so my brain hands it authority it has not earned. Fix: triangulate on important claims, and specifically ask “when is this claim wrong? what is a counter-example?”

The infinite-information trap. AI drops the cost of consuming content to nearly zero. The cost of my brain absorbing it stays the same. Result: overflow input, zero output. Fix: 80% produce, 20% consume, with a hard time-box on consumption.

The outsourced-thinking trap. I reach for AI before sitting with the problem for even a minute. Struggle is uncomfortable and AI erases the discomfort instantly. But the discomfort is the signal that learning is possible. Five minutes of thinking before any prompt on a new problem, non-negotiable.

7. A 90-day starting point

If 12 chapters of advice is too much, here is the smallest useful commitment:

Weeks 1–4. Install Rule 1 (write first, prompt second). Add adversarial prompting on every important design. Start a Sunday self-review — thirty minutes, append to a blind_spots.md file. Do your first Feynman session on one concept from the list above.
Weeks 5–8. Start one Tier-1 book — Designing Data-Intensive Applications is the correct answer if you cannot decide — thirty to sixty minutes a day, no AI summary first. Continue weekly Feynman. Publish one 800-word post on a concept you Feynman’d.
Weeks 9–12. Start juxtaposition practice: pick one topic per week and compare three serious approaches side by side. Teach one person one concept in forty-five minutes. Publish one more post. Write a 1000-word private retrospective and plan the next quarter.

After ninety days the habits run themselves. Before ninety days, you will feel dumb for two weeks, then a little faster than before, then noticeably sharper. That is the curve.

8. Three things I want to burn into my own head

Cognitive atrophy is real, it is happening right now, and it reverses — but only with a protocol, not with willpower. “Use AI responsibly” is not a protocol.
The bottleneck moved from execution to judgment, taste, and synthesis. Spend ~70% of learning energy on the new bottleneck, ~30% on execution. Most developers do the opposite, because execution is easier to measure.
Upgrading your thinking is a habit system, not a flash of insight. The five rules above are enough. Do not wait for the perfect framework. Start with Rule 1 this week.

I will know I have stayed honest with this post if, six months from now, I can read it again without an AI in the loop and actually recognize the person who wrote it.

AI is quietly eating my brain — cognitive atrophy, the new bottleneck, and the 5 rules I now live by