Staying Human as AI Accelerates
The most expensive mistake you can make this year isn't ignoring AI. It's letting AI do the work that was making you a senior engineer.
Ruben Hassid recently shook hands with Demis Hassabis and came away with a quote: AGI by 2030. Four years, maximum. Hassabis added a softer line — maybe we weren't supposed to be watching a screen so much. The internet has been chewing on that for a fortnight.
I have a different question. If your job in 2030 is going to look more like a 1984 marketing job than a 2026 engineering one — more conversation, more taste, more judgement — what are you doing between now and then to make sure you still have those skills?
Because most engineers I talk to are quietly letting them atrophy.
The homogenisation is real
Open a PR queue at a team that has been heavy on Claude Code or Cursor for six months. Pull up five reviews from five different engineers. Read them.
They sound the same. The same hedging tone, the same bullet-pointed concerns, the same suggestion templates. Same with commit messages, ADRs, RFC documents, even Slack threads explaining design choices. The voices have collapsed into one voice, and it isn't anyone's.
Ethan Mollick calls this choosing to stay human — the deliberate act of keeping your own shape when the easy path is to let the model do the shaping. AI-generated text has a particular weight: meaning-shaped sentences that take effort to decode and pay back very little understanding. The skim-and-skip reflex kicks in. You start scrolling past PR descriptions you'd have read three years ago.
That's the cheap part of the problem. The expensive part is what's happening inside the engineer's head while the AI is writing.
Cognitive surrender at the keyboard
Mollick's piece points at a phrase his colleagues at Wharton have been using: cognitive surrender. People stop thinking about problems and just let the AI take a swing — even when the AI is wrong. The papers he cites are about students, but you've seen it in your own team. You may have seen it in yourself.
One study compared two groups of high-schoolers learning maths. One had ChatGPT, one didn't. The ChatGPT group produced better homework, felt smarter, and underperformed at exam time. The AI was solving their problems instead of forcing them to solve their own.
For engineers, the equivalent is the moment you skim the AI's suggested fix, run the tests, see green, and merge. You didn't form an opinion about the fix. You verified it didn't break anything. Those are different operations, and one of them is how you became a competent engineer in the first place.
Five years of that and you're not a senior engineer with AI superpowers. You're a junior with confidence.
The skills that don't survive frictionless tools
The AGI-by-2030 framing gets the question wrong for working engineers. The question isn't "will my job exist in four years." Your current job won't, and neither will most jobs as currently defined. The question is "what skills will compound over the next four years, and which ones will rot?"
The skills that compound live in your head, where the model cannot help you:
- Taste. Knowing a particular abstraction will age badly even though it tests fine today.
- Judgement under ambiguity. Picking which of three plausible designs your specific team can actually maintain.
- Specification. Translating a fuzzy customer complaint into a problem statement that doesn't quietly assume the wrong solution.
- Review. Catching the bug the AI confidently introduced, especially when the diff is large and the suite passes.
These are the things experienced engineers used to charge a premium for. They are also exactly the things that get duller when you outsource the warm-up exercises — the small design choices, the first-draft architecture, the boring code reviews where nothing was wrong but you read it anyway and built a quiet model of the system.
When was the last time you held a strong opinion about a design before reading what Claude thought?
The trade-off most engineers are getting wrong
I am not arguing against AI tools. I use them every day and I'd be slower without them. But there's a trade-off I see engineers getting wrong, consistently, and it goes like this.
The right way. Use AI to remove friction from things you already know how to do — boilerplate, search, generating mock data, one-shot scripts, drafting commit messages from your diff. Keep doing the work yourself on the things where you're still building skill: design decisions, review of unfamiliar code, debugging novel problems, writing the actual specification.
The wrong way, which is more common. Use AI for everything. Especially the hard parts, because the hard parts are the parts you don't want to do. Get faster. Ship more. Stop noticing that you no longer remember how to think through a domain model on your own.
The wrong way feels like leverage. It is leverage, for about eighteen months. Then you stall, because the leverage was sitting on top of skills you stopped maintaining.
Three things to refuse to outsource
A practical workflow change, the kind we run inside CompoundCoders training.
- Pick three skills you refuse to outsource. Mine are: writing the initial problem statement before any prompt, doing the first pass of code review with the AI turned off, and sketching the design on paper before the AI sees anything.
- Use AI as a critic, not a generator, on those three. After I write the problem statement, I ask Claude to find holes in it. After my code review, I ask what I missed. The work stays mine; the AI sharpens it.
- Track the friction. When something feels uncomfortable, that's usually the muscle that needs the exercise.
This is unglamorous. It's slower in the short run. It does not produce a viral X thread.
The prediction worth disagreeing with
Here's my bet. Feel free to disagree.
By 2030, "uses AI for everything" will be a red flag on a CV, not a feature. The engineers commanding the highest rates will be the ones who can demonstrate that they still have taste, judgement, and the ability to specify a problem without an LLM in the loop. Not because AI is bad — but because by then everyone has access to the same AI, and the only differentiator left is what's actually in your head.
Hassabis is probably right that the work returns to being more human. But "more human" doesn't happen automatically when AGI arrives. It happens because you defended the human parts of your work the whole way through.
What to do this week
Pick the three skills. Write them down. Then run the next ticket end-to-end with the AI as a critic only — problem statement first, design sketch second, code review with the model closed. See what you'd forgotten you knew how to do. The compound interest on that one experiment is bigger than anything in your tool stack.
Sources I drew from: