In my last post, I wrote about how AI killed my passion for programming. Many people asked me the obvious question: OK, so what should we do about it? Fair. Complaining is easy. So here is part two: how to deal with skill atrophy, where AI is strong, where it is weak, and the rules I use to stay a real engineer and not just a prompt operator.
One thing first. I am not going to tell you to use AI less. That advice is useless. AI is here, your company uses it, your competition uses it, and honestly, it is a great tool. The question is not if you use it. The question is how.
A lot of this post is built on two sessions from DDD Europe 2026: Michael Feathers’ lecture on skill atrophy, and the anniversary panel with Eric Evans and Martin Fowler. I will give them credit where the ideas are theirs. The rants are mine.
First, check yourself: the four warning signs
Feathers gave four signs that you are deskilling while using AI. Read them slowly and be honest:
- You can’t explain it. You cannot walk through and explain the AI-generated code you just shipped.
- You keep asking for the same thing. You ask the AI for the same task again and again instead of ever learning it.
- Your systems are brittle. The AI-generated system is too complex to change step by step. Every small change needs a complete rewrite.
- You feel anxious without AI. You face a task, the AI is down or not allowed, and you feel real anxiety.
That fourth one is the scary one. If losing your tool feels like losing your hands, the tool already replaced your hands.
Know where AI is strong
Let’s be honest about what AI does really well. If you deny this, you are lying to yourself:
Boilerplate and scaffolding. New service, new module, CI pipeline, Dockerfile, config files. AI writes this faster than you ever will, and this code was never interesting anyway. Nobody ever grew as an engineer by writing another Kubernetes manifest by hand.
Familiar, well-known patterns. CRUD endpoints, standard integrations, mappers, DTOs, test setup. The internet is full of this code, so the model has seen it a million times. It will do a solid job.
Tests. AI is great at generating test cases, especially the boring edge cases you would skip because it is Friday afternoon. It finds the empty string, the negative number, the null you forgot.
A tireless rubber duck. Explaining your problem to AI often solves it before the AI even answers. And unlike your colleague, it is never in a meeting.
Exploring unfamiliar territory. New library, new API, new language ecosystem. AI gives you a working starting point in minutes instead of hours of reading documentation. This is a real speed-up.
A team archivist. One idea from Feathers that I really like: use AI to document team decisions and the reasons behind them. Institutional knowledge usually dies when people leave. AI is actually good at keeping it alive and explaining the “why” to new team members.
Know where AI is weak
And now the part that companies do not want to hear:
Architecture decisions. AI will happily give you an architecture. It will even sound confident. But it does not know your team size, your budget, your traffic patterns, your history. It optimizes for “sounds like a good answer”, not for “works in your company for the next five years.”
Domain modeling. This is the heart of DDD, and AI is bad at it, because the knowledge is not in the training data. It is in the head of your domain expert, in half-finished sentences during meetings, in that one Excel file from 2019. Fowler said it clearly at the panel: the bottleneck in software was never typing code. It is communication between developers and domain experts, and AI only speeds up the technical parts, which puts more pressure on that bottleneck, not less.
Novel problems. When you hit a problem that nobody has written a blog post about, AI starts to hallucinate with full confidence. Distributed systems are full of these problems. Race conditions, split-brain scenarios, that one strange timeout that only appears under production load. Been there.
Sycophancy. This one is dangerous and most people underestimate it. LLMs are designed to be agreeable and to make you feel smart. You show it your design, it says “Great approach!” and you walk away more confident and not one bit more correct. Feathers called this a trap, and he is right. A senior engineer tells you your design is wrong. An LLM tells you that you are brilliant. Guess which feedback makes you grow.
Nondeterminism. Evans was very direct about this: LLM outputs are nondeterministic, so every LLM output in a real system must pass through strict validation. Deterministic guards around nondeterministic components. If you connect an LLM directly to something important without a validation pipeline, you are not doing engineering. You are gambling.
So the pattern is simple: AI is strong where the thinking is already done. It is weak where the thinking still has to happen. And thinking is exactly the muscle that atrophies.
Why “muscle” is the right word
Feathers made a point that changed how I think about this. Learning is a physical, biological process. Effort literally strengthens neural pathways, the same way stress makes muscles grow. And the growth happens in a cycle: effort, then rest, then effort again. The struggle is not a bug in the learning process. The struggle is the learning process.
Now look at what AI removes from your day: exactly the struggle. Every time you skip the effort, you skip the growth. Not sometimes. Every time. There is no shortcut, the same way there is no pill that replaces the gym.
And there is a second trap on top of it: availability bias. The AI gives you a “good enough” answer instantly, so you take it, because it is right there. You stop exploring better options. Slowly, the AI starts dictating your system design by default, not because it is right, but because it is fast. Convenience is how skill atrophy gets in.
My rules against skill atrophy
Here is what I actually do, mixed with what Feathers recommends. No theory, just practice.
1. Attempt before you ask. Before you send the problem to AI, spend at least ten minutes solving it yourself. Then compare your solution with the AI’s. The gap between them is where the learning lives. Feathers put it well: prediction failure is a powerful teacher. When your guess is wrong, your brain remembers why.
2. The explain test, every time. If you cannot walk through the code and explain it, you cannot merge it. I apply this brutally to myself. If AI generated something and I do not fully understand it, I stop and read until I do. Yes, it is slower. That is the point.
3. Let the AI quiz you. A simple trick from Feathers that I started using: after AI generates code or explains something, ask it to generate questions about the material and test yourself. It turns passive reading into active learning. Thirty seconds of effort, and you find out immediately if you understood anything.
4. Fight sycophancy with hostile prompts. Never ask “is this good?” The answer is always yes. Ask instead: “Argue against this design. Find the weak points. What breaks at scale?” Make the AI your opponent, not your fan club. An engineering mindset prefers hard truths over flattery.
5. Write the spec yourself, then compare. Feathers calls it intentional specification, and it matches exactly how I work: write a clear specification with your own head before generating anything. Then compare the AI output against your spec and judge it. Never the other way around. If AI writes the spec and you just click approve, you have outsourced the only part of your job that matters. And as Fowler says, clear prose is the new code, and writing is thinking. Give away your writing and you give away your thinking.
6. Explain things to humans. Explain your design to a colleague. Teach a junior. Give a talk. Nothing exposes the holes in your knowledge faster than another person asking “wait, why?” This is also why I still speak at conferences: preparing a talk teaches me more than attending ten.
7. Go one level down. Both Feathers and Evans said a version of this. Feathers: build T-shaped skills, be a generalist with at least one deep specialty, because people without a solid mental model get stuck when AI leads them into the woods. Evans: study one or two levels deeper than the API you use, because the theory underneath survives every technology shift. I studied group theory to understand functional programming. Nothing about AI made that knowledge less useful. When everyone can generate code, the engineers who understand systems are the ones who survive.
8. Learn adjacent and distant things. Another Feathers strategy I like. Learn an adjacent skill, like a language close to yours, to sharpen your eye for fine differences. And learn a distant skill, a foreign language, a hobby far from software, to keep your mind flexible. For me the distant skill is cooking. It sounds unrelated, but variation is what builds antifragility: you get stronger from stress instead of breaking.
9. Keep a no-AI zone. I have personal projects where AI is not allowed to write code. Not because it could not, but because I need a gym for my brain. And sometimes, when a bug appears, I do not paste it into AI. I open the debugger, read the library source, dig through logs. Once you lose this skill, no prompt brings it back, and one day there will be a production incident where the AI has no idea and you are the only one left.
10. Protect the juniors. This one is about the team. Juniors who never struggle never build judgment. If your junior ships a big feature with one prompt and cannot explain a line of it, you did not save time. You created a future incident. Give juniors problems they must solve with their own head, and review their thinking, not only their output.
Verify and validate, because nobody else will
One more thing from Feathers that deserves its own section, because it is where AI-driven teams fail silently.
Verification asks: is this built right? With AI this gets hard, because AI generates more code than any human can review. The only way to verify AI output, including AI-generated tests, is deep domain knowledge. There is no tooling shortcut here. You either understand the domain or you are approving blind.
Validation asks: is this the right thing at all? AI will happily build the wrong product very efficiently. Fast generation of the wrong feature is not productivity. It is expensive waste with good syntax.
Both jobs land on humans. AI made them harder, not easier.
The amplifier goes both ways
Fowler’s magnifying lens metaphor is the best summary I know. AI amplifies whatever you already are. If you are an engineer with strong fundamentals, clear thinking, and good practices, AI makes you dramatically better. If you are a prompt operator with shallow knowledge, AI amplifies that too, and produces confident garbage at a speed nobody can review.
So this is my answer to skill atrophy: make sure there is something worth amplifying.
Use AI for the boring 70 percent. Guard the interesting 30 percent with your life, because that 30 percent is where the engineering lives, where the learning lives, and where the passion lives.
The forklift can lift more than you. Go to the gym anyway.
And, as Eric Evans joked at the end of the panel, be kind to your AI agent. Just in case.
← Back to writing