I Outsourced My Thinking to AI, and Three Months Later I Became Illiterate in My Own Project

AI turned me from an 'architect' into a 'messenger' — and my team was still praising my efficiency

---

01. I Became the Company's 'AI Expert'

Let me start with how I got here.

I was one of the first people in my company to use large models. Not to follow a trend, but because I genuinely believed in it. Back in 2024, when colleagues were still using AI to write weekly reports to fool their bosses, I was already using it to refactor a microservice module. The results were genuinely good: clean code, complete tests, PRs passed on the first try.

My boss saw this and, of course, labeled me the 'AI Expert'.

Later, the company gave me a new project. The system was quite complex, involving interactions between several microservices. I designed the initial architecture myself — drawing diagrams, selecting technologies, defining interfaces. I was crystal clear on every layer. Back then, I was truly 'making' this thing.

Then the models kept getting stronger.

At first, I outsourced the implementation to AI — writing code, AI is indeed fast. Later, I even outsourced the planning. 'Help me break down this requirement,' 'Help me design the call chain for this module,' 'Help me evaluate the pros and cons of these two solutions.' AI always answered eloquently, ten times faster than me agonizing in front of a whiteboard.

My team started delivering features at an astonishing speed. PRs rolled out like an assembly line, code reviews were mostly handed off to Agents. During the quarterly review, our delivery volume was three times that of the same period last year. My boss named me at the all-hands meeting, saying I had 'redefined engineering efficiency with AI.'

I sat in the audience, clapping, but breaking out in a cold sweat inside.

Because only I knew — I hadn't touched this project's code with my own hands for a long time.

---

02. The Day I Broke Out in a Cold Sweat

The turning point happened on a very ordinary afternoon.

Someone from the neighboring team came over to ask me a question: 'For your message queue consumer, are you using At-Least-Once or Exactly-Once semantics? If messages are duplicated during downstream retries, at which layer is your idempotency handled?'

A year ago, I could have answered this question with my eyes closed. Because I designed the architecture, I knew the responsibilities of every layer inside out.

But now?

I froze for two seconds. Not thinking about the answer, but thinking — which version of this question should I throw to AI?

I took out my phone, opened AI, pasted the question verbatim, and AI gave me a very polished answer. I glanced at it, it looked plausible, copied, pasted, and sent it back to that colleague.

He replied with a '👍'.

The matter just passed like that. But that night, lying in bed, my heart was pounding hard.

I suddenly realized something: I am no longer the architect of this project. I am a forwarder between AI and my colleagues.

You ask me any question about this project, my first reaction is not to think, but to ask AI. My brain no longer participates in this project. It is only responsible for 'forwarding'.

Before, I always felt I didn't deserve this position, at least I was secretly competing, trying to prove myself. Now I don't even have the qualification to compete — you can't compete with something you fundamentally don't understand.

Now I don't even have the qualification to think, because I don't know what to think about.

---

03. 'Cognitive Debt' — A Word You Haven't Heard Yet But Will Soon Be Anxious About

I later found a word to describe this feeling — 'Cognitive Debt'.

A good word.

You've heard of technical debt — writing bad code to meet a deadline, to be repaid later. Cognitive debt is its twin brother: outsourcing 'understanding' to AI to meet a deadline, the debt you owe is not in code, but in 'whether you still understand'.

Technical debt is at least in the code; you can scan it, schedule it, refactor it. What about cognitive debt? It's in your head. You can't see it, can't measure it, don't even know when it's due — until someone asks you a question and you find your mind is completely blank.

That moment is the day of reckoning for cognitive debt.

And it has a most insidious feature: the interest is compound.

You don't understand Module A, so you dare not modify Module A. You let AI modify it. After the modification, you understand it even less. Next time a requirement comes, you are even more afraid to do it yourself. Cycle repeats, your understanding of this system is like a photo being compressed layer by layer — losing a bit of detail each time, until only a blurry outline remains.

You think you are the architect. In reality, you only have a title left.

---

04. I Am Not Alone

I later started paying attention to my colleagues' replies.

If you use AI often, you will recognize some 'secret codes' — sentences are always neatly structured 'General-Specific-General', wording is always neutral, balanced, every point must add 'Of course, on the other hand'.

I saw these codes everywhere in my colleagues' messages.

Someone replied with an analysis of a caching strategy, beautifully worded, logically rigorous, but if you read carefully, you'd find the two 'key metrics' he used were actually contradictory — he hadn't thought about it himself, just copied AI's output.

Someone wrote a technical proposal document, three thousand words, every paragraph perfect. But during the meeting discussion, when you asked him 'Why choose B over A?', he froze. Because AI said 'B is better', he couldn't explain why it's better. He wasn't answering your question, he was recalling AI's answer — but that answer wasn't in his head, it was in the chat history.

The entire team is pretending to understand.

No one is doing it on purpose. Everyone is busy, delivery pressure is high, AI is indeed fast. But when everyone around you is 'forwarding' AI's answers, you get an illusion — everyone else understands, I'm the only one who doesn't, I must quickly use AI to keep up.

Little do you know, no one understands. It's just that AI's output looks too much like 'understanding', we've all been fooled — fooled by ourselves.

---

05. Five Whys — Where Does Cognitive Debt Come From?

I spent many sleepless nights thinking about this question. Why, knowing it's wrong, do we still keep going down this path?

I summarized five reasons.

Reason One: AI's Output Looks Too Much Like 'Understanding'

This is the most fundamental trap.

When a human says something, you default to assuming they have 'thought about it'. Because speaking has a cost for humans — organizing language, recalling, ensuring logical consistency. This process itself is evidence of 'understanding'.

AI breaks this default assumption. Every paragraph it outputs is perfectly organized, logically consistent, professionally worded — but it hasn't 'thought about it'. It calculated it.

The problem is, you cannot infer from the output whether it has 'thought about it'. So you instinctively think it understands, and you think you understand too — because you saw a piece of text that looks like 'understanding'.

By the time you realize you don't understand, three months have passed.

Reason Two: Verification is Ten Thousand Times More Expensive Than Generation

Generating code is almost free. Verifying code is painfully expensive.

You let AI generate 1000 lines of code, 30 seconds. You read these 1000 lines of code, confirm every line is correct, compatible with other parts of the system, no edge-case bugs — potentially two hours.

This asymmetry is the engine of cognitive debt.

Because verification is too expensive, you choose not to verify. You glance at it, 'looks fine', and LGTM. AI-generated code increases, truly reviewed code decreases. The proportion of code in the system that no one understands grows larger.

Someone once said something I still remember: 'AI hasn't raised the ceiling of code quality, it has only raised the camouflage level of bad code.'

Reason Three: The Reward Mechanism Encourages 'Pretending to Understand'

This is the most ironic part.

Do the math carefully. You spend two hours deeply reviewing a PR, what's the output? Nothing. Did the code get better? Maybe. But this won't be written into your performance review. Did you prevent a bug? No one knows what you prevented — because the bug didn't happen, no one saw the bug that didn't happen.

But you spend two hours using AI to generate three new features? The output is clear: three PRs, three features, the boss sees it, something to write in the quarterly review.

The return on deep understanding is invisible, the return on fast delivery is visible.

So everyone is generating, no one is reviewing. If you insist on reviewing, you become the 'person slowing down progress' — someone was even implicitly told by their boss 'your pace can't keep up with the team' because they insisted on deeply reviewing AI-generated PRs.

Eventually, they gave up too. Now they also glance, LGTM, next.

Reason Four: You Don't Know What You Don't Know

This shares the same root cause as AI hallucinations — lack of 'metacognition'.

When you write code yourself, during the writing process you know where you are uncertain, where you are guessing, where you need to check documentation. Writing code itself is a form of 'self-testing'.

AI skips this process. It directly gives you the final result — a seemingly certain answer. You didn't experience the 'uncertainty' phase, so you think there was nothing 'uncertain'.

Until production goes down.

During the incident post-mortem, you open that piece of code and find a logic branch you never noticed. You ask yourself 'What does this part mean?' — you can't answer. You never looked at it, didn't look when AI generated it, and AI itself... it never 'looked' at it either.

Reason Five: Management Cannot See Cognitive Debt

This is the fundamental reason the entire system loses its ability to self-correct.

What can management see? Delivery speed. Feature count. PR merge rate. These metrics are all rising — because AI indeed makes these things faster.

What can't management see? Code comprehension. The team's control over the system. If production goes down, how many people can locate and fix it within two hours?

One developer said something that sent chills down my spine: their company, with over a thousand developers, after a year of using AI, the code has become so messy that they can't read their own codebase without opening AI. Turn off AI, no one knows what that code is doing.

This is not a tool, this is dependency. Like a person whose muscles have atrophied to the point of needing a wheelchair — not that they 'choose' the wheelchair, but they can't not use it.

And what does management see? Annual feature delivery doubled. Year-end bonuses paid as usual. Everyone is happy.

---

06. Day of Reckoning — Stories of Debt Coming Due

Cognitive debt doesn't disappear, it just waits for a day of reckoning. Here are real cases I've collected.

Reckoning One: Customer Satisfaction Dropped from Near Perfect to Failing

A large tech company, after a year of using AI, doubled its feature delivery speed. Management reported 'record-high delivery efficiency' at the all-hands meeting.

But a developer checked the data on the feedback platform: before AI, feature ratings were near perfect. After AI, ratings were cut in half, several features couldn't even reach the passing line.

Customers were dissatisfied. But management only looked at delivery speed, not quality scores. The code had rotted to the point where no one could debug independently, they couldn't understand what those codes were doing without opening the AI assistant. The developer said: 'I thought AI could help us eliminate technical debt, but instead, technical debt exploded.'

The manager still got their year-end bonus.

Reckoning Two: Thousands of Lines of Code, Dozens of Files, Zero Tests

A developer confronted another developer in front of the team: you admitted to heavily using AI to refactor a core module, dozens of file changes, thousands of lines of new code, no tests, no explanation, just saying 'it was bad before, now it will be better'.

The confronter demonstrated all potential crashes and business impacts on the spot. The other party dismissed it, instead saying the confronter was 'creating obstacles'.

The manager, after hearing this, still gave that AI user complete freedom.

Then production incidents happened continuously. Customer complaints kept coming. The manager's response was — 'Next time we will listen to your opinions more.'

Empty words.

Reckoning Three: That Afternoon When Screen Sharing Was Requested

Someone had a good idea: make the person submitting a suspicious PR share their screen and explain the code logic on the spot.

'Can you open a screen share and walk me through this code? There are a few places I don't understand.'

The other person fell silent. Stammered.

If they don't understand the code they submitted — a 1000-line PR, they might not be able to explain even half of it. Then your reason for rejecting this PR is very solid: if the submitter themselves doesn't understand it, then this code is an uncontrollable risk for the team.

But the problem is — can you do this for every PR? You can't. Because so many PRs flood in every day, do you have time to make everyone screen share?

The reckoning of cognitive debt lacks sufficient 'reckoning capacity' to handle it.

---

07. AI-Assisted Learning? Or AI-Replaced Learning?

You might say: isn't AI just a more advanced calculator? When calculators came out, everyone also said 'oh no, no one will be able to do multiplication by hand anymore'. Isn't this the same thing?

No.

Calculators replace 'calculation' — a mechanical operation you don't need to do in your head anyway. Using a calculator to compute 347×892 doesn't mean you 'don't understand multiplication'. The concept of multiplication is still in your head; the calculator just helps you skip the tedious arithmetic.

AI replaces 'understanding' itself.

You let AI design a caching strategy for you, it gives you an LRU+TTL solution. You implement it. But do you understand why LRU is better than LFU in this scenario? Do you understand what the TTL should be set to and why that number? Do you understand the behavior of this solution during a cache breakdown?

If you designed it yourself, you would be forced to think about these questions. AI helps you skip this thinking — and it is precisely this thinking that constitutes your 'ability'.

One experiment illustrates this well. Someone conducted a controlled experiment: let two groups of junior engineers learn an unfamiliar library, one group using AI assistance, the other handwriting. Then test comprehension.

The AI-assisted group's comprehension was significantly lower than the handwriting group, with the gap concentrated in debugging ability.

What is debugging? Debugging is 'you can find the cause when something goes wrong'. If you've never written it yourself, never stepped into the pitfalls yourself, you fundamentally don't know where problems can occur. AI helped you avoid all the pitfalls — you also avoided all the learning.

Generation becomes cheap, understanding becomes scarce.

---

08. Can It Be Cured?

It can be mitigated, not cured. Here's what can be done currently.

Method One: Set an 'Understanding Threshold' for Yourself

The rule is simple: You must be able to explain every line of code you submit.

Not 'seen it', not 'AI said it's fine', but you can explain to another person why this line of code exists, what it does, and its relationship to the context.

If you can't explain it, you don't submit. Even if the AI-generated code is flawless, even if you're rushing a deadline, even if everyone else is delivering fast — you don't cross this threshold.

This is hard. It means you have to slow down. In an environment where everyone is running, you choose to walk. But this is the only way to prevent cognitive debt from exploding.

Method Two: Use AI as a Sparring Partner, Not a Ghostwriter

There are two ways to use AI.

The first: 'Do it for me'. You throw the task to AI, it finishes, you copy and paste. This is ghostwriting. Your brain does not participate.

The second: 'Help me think'. You write a version yourself first, then ask AI 'Where do you think there are problems?' AI gives you feedback, you modify, ask again. Repeat several rounds. This is sparring. Your brain participates throughout.

The second way is much slower. But you understand what you ultimately deliver.

Using the first, you accumulate cognitive debt. Using the second, you use AI to accelerate learning. The difference is not whether you used AI, but whether your brain was working.

Method Three: Keep an 'AI-Free Project'

Even a very small one is fine. A personal project, an open-source contribution, a side project — no AI throughout the entire process.

Not to prove you are 'handmade', but to maintain your feel. Just like professional runners also do jogging training — not every run needs to be at race speed. You need a place where your brain maintains the habit of 'thinking for itself, writing for itself, debugging for itself'.

Otherwise, your skills will atrophy. One developer described that feeling: 'After leaving AI and writing a few lines of code, I found I couldn't even remember basic APIs, as if a piece of my brain had been stolen.' — That is the feeling of cognitive atrophy.

Method Four: Establish an 'Explanation Culture' in the Team

If everyone in the team is LGTM-scanning PRs, it's useless for you alone to insist on deep review — you will be isolated, called 'slowing down progress'.

But if the team has one rule: Every PR author must be able to verbally explain their code during review, then cognitive debt will be limited to a controllable range.

This is not distrusting AI. This is distrusting the human part of the 'Human+AI' combination. AI doesn't owe you anything, the code it generates has no meaning to it. But you are responsible for what you submit — because your name is on it.

---

09. A Question That Gives Me Chills

One last small thing.

A few days ago, I was organizing project documents and came across an architecture design I wrote myself a year ago — hand-drawn flowcharts, hand-written interface definitions, every comment in my own words.

I read through it.

I understood every line. I remembered why I drew every arrow. I could state the reason for every trade-off.

Every line of that document was painfully slow. I stood in front of the whiteboard for two days before finalizing the plan. If I had today's AI back then, I probably would have had it produce a plan in ten minutes, then gone off to do something else.

But that 'slow' output, I still fully understand today. And a plan AI produces in ten minutes, three days later I've already forgotten why I chose it.

I suddenly understood something: The speed of understanding is directly proportional to the speed of forgetting.

Something you spend two hours figuring out will be etched into your mind. Something you spend two minutes 'reading through' will leave only a vague impression after two days.

AI always gives you the two-minute version. Looks like it has everything, actually leaves nothing behind.

---

10. Finally

I did one thing afterwards.

I went to my boss and said I wanted to reduce my AI usage and go back to handwriting on core modules. My boss looked at me like I was someone voluntarily asking for a pay cut.

'You know this will be slower, right?'

'I know.'

'Then why?'

I thought for a long time about how to answer. Finally said:

'Because I'm afraid that one day someone will ask me a question about this project, and I won't be able to answer. Not because the question is hard, but because this project is no longer mine. I just happen to be in its commit history.'

My boss didn't say anything.

I don't know if he understood. But I know, that was the first sentence I've said in three months that was completely my own.

Not written by AI for me.

Thought of by myself.

---

You use AI, don't let AI use you.