Over the past couple of months, I've read a lot of articles about the consequences of AI dependency and one prominent finding is cognitive atrophy. In other words, it's about suffering from gradual skill decay because of over-reliance on AI.
Most of the realizations involve not solving the problem directly. Software engineers instinctively ask AI what to do first instead of thinking of a solution themselves. This means skipping the crucial process of thinking. This is primarily why I chose the banner above: The Blind Leading the Blind (1568) by Pieter Bruegel the Elder.
It depicts a row of blind men being led by also a blind man until they eventually stumble and fall. The artwork painted centuries ago still mirrors what's happening in today's world. The only difference is, we are deliberately making ourselves blind
Notice there's no review step. That's the problem. You may think this workflow is fine. You may say "It's just a small change, nothing to be worried about really", until you repeat the process over and over again and these "small changes" eventually accumulate. Stretch it out over the long term and you'll slowly realize you can't "code" anymore without AI.
AI-generated code is clean and deceiving at the same time. The UI looks good and the test (which it also generated) passes. It's like everything in the codebase is made out of rainbows and sunshine. No wonder engineers are just accepting changes and then moving on. But we are more than that.
Skill decay isn't unique to this industry. Any skill not used regularly will eventually deteriorate. It's always easier to dictate what to do until you do the task yourself. Oftentimes, dictating something isn't the same as actually implementing the task.
Executing the task yourself forces your brain to think. You'll find the right edge cases. You'll think more about the UX. You'll think about which tests make sense. You'll find which code matters more. That's the beauty of doing it yourself and using AI as a complement for repetitive tasks. It's a completely different story when we outsource all of the thinking to AI.
Sure you could argue that human-written code isn't perfect. The majority of us are not gifted programmers. Our code often has human errors. But that's the main reason why it's already valuable.
Someone already owns the decision. Someone is already accountable. Someone already has the context. When there's a mistake, that someone already has the foundation and they are not starting from zero. They built the code in the first place, they could fix it too. Struggling, making wrong assumptions, and eventually finding the right solution are the crucial steps for making genuine understanding. The next time they'll encounter the same problem, they have a pretty good chance of solving it alone this time resulting in better efficiency.
Use AI to learn and let it intentionally expose your gaps. Question and scrutinize it. Challenge and verify it at the same time. That's a much healthier way of using AI without surrendering the thinking process itself. But if you are going to delegate all the work to it, you might as well declare yourself as a tab-pressing robot for AI.
When unreviewed AI generated code is pushed for a PR review, the domino starts to fall. The junior trusts the AI, the senior trusts the junior, and eventually the code reaches production. This doesn't only cause cognitive atrophy, it also creates a false sense of trust.
Speed was never the best measure of quality code. A codebase is fragile. It always was. One wrong implementation can cause a multitude of errors.
AI lays down perfectly convincing code. The author sees it and gets trapped in the illusion that it works without actually understanding it. Context is already lost the moment this new code is pushed. You are betting on it to work from the start instead of deliberately increasing the chances for success by actually looking at it.
Instead of the senior asking whether this is a good change, they might first wonder whether the junior actually understands what they sent (or if they even read the code at all).
Reading AI-generated code is contagious to the point that the reviewer might as well be lazy too and accept the changes without reviewing them.
It is human nature after all. If too much change is introduced at once, quality checking isn't uniformly implemented. It tempts the reviewer to skip through the entire change, skim the important parts, or worse, rely on AI review agents on top of it. This adds even more uncertainty.
AI is good but only when used as a complement, not as a substitute. It is a tool to be used correctly and responsibly. You can't force everyone to use this workflow, but you can always start with yourself. Read before sending, understand the PR, push with intention.
The point is to make your PR "ready for review". It doesn't have to be perfect. The most important thing is that it is yours, and you can defend it in a snap when the reviewer asks about it. You can explain the ins and outs of your code and ultimately answer the question "Why?".
