The Slow and Quiet Cognitive Atrophy of a Modern Software Engineer

Over recent months, articles have been published discussing the effects of AI dependency on cognitive decline. In essence, this refers to the gradual loss of skills resulting from excessive reliance on AI. Frequently, these issues revolve around not resolving problems independently. Software developers frequently consult AI for the initial steps of problem-solving rather than formulating their solutions.

This overlooks the essential thinking process. This is the primary reason why I selected the image above: The Blind Leading the Blind (1568) by Pieter Bruegel the Elder. The scene portrays a line of blind individuals being guided by another blind person, eventually resulting in a fall. This artwork, painted centuries ago, continues to reflect current events, albeit with a modern twist. The key difference is that we are actively making ourselves oblivious to the process.

The AI-driven workflow lacks a review step, which proves problematic. While one might consider this acceptable, the repeated occurrence of small changes can lead to significant accumulation. Over time, you might discover that you cannot code without AI assistance. We are consciously distancing ourselves from the generated code. AI-generated code appears clean and deceptive.

The user interface appears polished, and tests, which the AI also created, pass successfully. The codebase seems to be composed of rainbows and sunshine. Consequently, engineers are accepting changes and moving forward. However, we are more than mere code contributors. Skill decay is not exclusive to this industry. Any skill that is not consistently applied will eventually deteriorate.

It is easier to dictate actions until you execute the task yourself. Often, instructing someone is not equivalent to performing the task yourself. Executing the task personally enables your brain to think critically. You will identify the right edge cases. You will consider the user experience. You will contemplate which tests are appropriate.

You will determine which code is most critical. That is the advantage of undertaking the task independently and utilizing AI as a complement for repetitive tasks. Delegating all thinking to AI, on the other hand, is a different story. While it is true that human-written code is not flawless, the majority of us are not exceptional programmers.

Our code often contains human errors. Nonetheless, this is the primary reason why it remains valuable. There is a human behind the code. Someone owns the decision. Someone is accountable. Someone possesses the necessary context. When errors occur, that individual already has a foundation and does not start from scratch. They originally developed the code and can rectify it as well.

Struggling, making incorrect assumptions, and ultimately discovering the right solution are essential steps for achieving genuine comprehension. In the future, when confronted with the same problem, they are more likely to solve it independently, leading to improved efficiency. Employ AI to learn and intentionally expose your knowledge gaps.

Question and scrutinize it. Challenge and verify it simultaneously. This approach to AI usage is far healthier than surrendering the thinking process. However, if you intend to delegate all tasks to AI, you might as well proclaim yourself as a tab-pressing robot for AI. Blind trust leads to a domino effect. When unreviewed AI-generated code is submitted for a pull request (PR) review, the chain reaction begins.

The junior relies on AI, the senior trusts the junior, and eventually, the code reaches production. This situation not only results in cognitive atrophy but also fosters a false sense of trust. How did we arrive at this point? Speed was never the primary indicator of high-quality code. A codebase is inherently fragile. It has always been so.

A single incorrect implementation can result in numerous errors. AI presents flawless, convincing code. The author becomes entangled in the illusion that everything functions correctly without truly comprehending it. Context is already lost the moment this new code is pushed into the system. You are betting on it to work from the outset instead of proactively enhancing the likelihood of success by thoroughly examining it.

Instead of questioning whether this change is beneficial, the senior may first wonder if the junior truly comprehends what they submitted (or if they even read the code). Who enjoys reading 1000+ lines of disorganized code? Reviewing AI-generated code is contagious, leading reviewers to become increasingly lazy and accept changes without proper review.

This adds even more uncertainty to the process. Although AI is beneficial when utilized as a complement, it should not replace human effort. It is a tool to be employed correctly and responsibly. You cannot compel everyone to adopt this workflow, but you can begin with yourself. Read before sending, understand the PR, and push with intention.

The objective is to make your PR ready for review. It does not need to be perfect. The most crucial aspect is that it is your work, and you can defend it confidently when the reviewer inquires. You can elucidate the intricacies of your code and ultimately respond to the question "Why?" The subsequent step involves bringing in additional eyes to review your code, incorporating minor or significant modifications, or requesting further refactoring.

Engaging in discussions about the changes facilitates the natural transfer of context to team members. If executed correctly, people will eventually adhere to the established norms. If not, at least you have avoided cognitive atrophy. To combat cognitive atrophy, we must discover ways to challenge our minds. The evidence suggests that the current approach is insufficient.

We need to exercise our brains. Personally, I consistently tackle at least one coding challenge daily and record my reflections.