A Confession from an Engineer: AI Has Almost Made Me Forget How to Code, and Concerns About a Hollowing-Out of Industry Skills Are Emerging

Software engineer James Pain admitted on his personal blog that after one to two years of using AI-assisted programming, he has almost "forgotten how to code." This isn't just a personal crisis—when the entire engineering community depends on AI to generate code, who will still remember how to read it and fix it? (Background: UC research on the "AI brain fog" phenomenon: 14% of office workers driven crazy by Agents and automation, with intention to quit up by 40%) (Context: OpenAI reportedly to sue Apple for "breach of contract"! Furious that Siri's integration with ChatGPT fell short, costing billions in subscriptions) The blog reads: "I haven't personally written a single line of code in one to two years. I've almost forgotten how to code, and this makes me feel very sad." Software engineer James Pain isn't complaining that AI tools are hard to use—quite the opposite. He says AI is so good, so usable, that he has come to rely entirely on "issuing commands" to produce code, no longer writing a single line by hand. Now, he is teaching himself how to code from scratch all over again. Pain's description is precise and unsettling: every time he wants to write or code, his first thought is "let AI do it." When he reads what the AI has generated afterward, it feels "nothing like the way I speak"; when he tries to write code himself, he finds his touch has grown rusty. This phenomenon has a cognitive science foundation, known as "cognitive offloading"—after long-term reliance on external tools, the brain reduces the neural activation frequency of the corresponding functional regions. Translated: if you don't use it, it deteriorates. This has been documented in fields such as GPS navigation replacing spatial memory and computer-aided design replacing hand drawing; the impact of AI programming assistance tools may be an accelerated version of the same effect. The scale of the problem extends beyond the individual level. According to a 2024 GitHub survey, over 92% of American software developers have used AI programming assistance tools at work; a Stack Overflow survey the same year showed 76% of developers are using or planning to use AI tools. If "Pain's phenomenon" occurs in even just 10% of them, that means hundreds of thousands of engineers are losing their active coding abilities at varying speeds. Even more noteworthy: this isn't individual laziness, but rational short-term decision-making. Generating code with AI is faster and produces fewer errors (in the initial draft stage), and the output meets delivery requirements. Under commercial pressure, choosing AI is logical for engineers. But in the long run, who will review this AI-generated code? Who will be able to pinpoint the problem when AI makes mistakes (and it does make mistakes)? In his article, Pain cites a historical observation by Robert Martin, author of Clean Code, which provides a longer-term perspective on the current dilemma. Martin points out that before computer science became an independent discipline, those who wrote programs were physicists, mathematicians, and academic researchers—people who already possessed rigorous professional training. From the 1970s to the 1990s, with the proliferation of personal computers and an explosion in software demand, the industry expanded rapidly, recruiting large numbers of developers without traditional "computer science" backgrounds. The professionalism of programming began to be diluted: documentation became sparser, software architectures became harder to maintain, and technical debt piled higher. Today, the high degree to which AI tools substitute for application-layer code is creating a second wave of dilution. What's special about this wave is: it's not just an "averaging down of talent quality," but a "de-skilling of existing talent." Engineers already in the workforce are losing their foundational capabilities due to long-term AI use. The design logic of AI tools is also fueling this trend. The core value proposition of mainstream AI programming assistants (including GitHub Copilot, Claude, Cursor, etc.) is "to let you deliver faster," not "to let you understand more deeply." Pain also mentions a detail in his article that reveals an even deeper cognitive predicament: after finishing this article, he "almost reflexively wanted to paste it into Claude to see what the AI would say," because he wasn't sure if what he had written was good enough. This isn't just skill atrophy, but a "transfer of cognitive confidence": people start treating AI's judgment as the verification standard for truth, rather than their own judgment. When an engineer's first thought upon seeing AI-generated code is "this should be fine" instead of "let me read it through before deciding," that's the more structural crisis. Against this backdrop, voices advocating the opposite approach are emerging in the industry. Some senior engineering teams have begun promoting "AI fasting days," requiring members to reserve certain hours each week for pure hand-written code; some technical interviews have explicitly banned AI assistance—not to make things difficult, but to confirm that candidates still possess basic reading and debugging abilities. Pain himself doesn't believe programming as a profession will disappear. Citing Martin's view, he points out that there will always be people needed to truly read and modify code. It's just that there will be fewer of them, and the standards will be higher. The question is: if the entire industry is de-skilling, where will that batch of "fewer but stronger" people come from? Pain has chosen the former path: relearning how to write code by hand—not because AI is bad, but because he has realized that this ability cannot be outsourced.