当程序员退化成代码审查员，我们是否正在失去编程的快感？
我一直在反思，如果程序员的角色最终变成了单纯的“代码审查员”，每天的工作就是盯着 AI 生成的、语法正确但毫无灵魂的代码，那么我们最初热爱编程的那个驱动力还在吗？
回想刚入门的时候，编程最让人上瘾的时刻，其实是那种通过“克服困难”后获得的多巴胺分泌。那种快感来自于与机器的死磕，来自于在无数次报错后终于跑通的那一瞬间。
记得当年死磕汇编语言时，为了在屏幕上打印一行 Hello, World!，根本没有现在的 print() 那么简单。你得手动管理寄存器，处理内存对齐，面对各种莫名其妙的链接错误。那时候写一段代码，需要极其谨慎地操作：
section .data
msg db 'Hello, World!', 0xA
len equ $ - msg
section .text
global _start
_start:
mov eax, 4 ; sys_write
mov ebx, 1 ; stdout
mov ecx, msg ; bytes to write
mov edx, len ; message length
int 0x80 ; call kernel
mov eax, 1 ; sys_exit
xor ebx, ebx ; exit code 0
int 0x80这段代码在现在的工程实践看来极其低效，甚至显得笨拙。但当时的成就感恰恰来自于这种“摩擦力”。你必须理解 CPU 是如何工作的，必须知道 int 0x80 是如何触发内核调用，这种从底层向上构建的认知链路，构成了程序员最深层的自信。
而现在的 AI Agent 把这种摩擦力全部抹平了。你只要输入一个简单的 Prompt，它就能帮你实现功能。速度确实提升了，但那种深度思考带来的满足感却在迅速消失。当一个问题不需要经过思考、推演、失败、再尝试就直接被解决时，这个过程在认知层面上其实是“空洞”的。
如果所有的认知挑战都被 AI 替代，我们很容易从“解决问题的人”退化成“检查答案的人”。检查答案是一项极其被动的工作，它不需要创造力，只需要经验。但问题在于，如果年轻一代的开发者失去了在“摩擦力”中成长的机会，他们将失去判断答案是否正确的能力。
为了对抗这种退化，我最近给自己定了一套原则：将工作分为“体力活”和“认知活”。
对于重复性的体力活，比如编写冗长的样板代码（Boilerplate）、配置繁琐的 Schema 迁移、或者写简单的单元测试，我直接交给 AI Agent 处理，没必要在这些地方浪费生命。但如果涉及到核心架构设计、复杂业务逻辑的实现，我会强迫自己先手动实现一遍，而不是直接输入 Prompt 索要答案。
我希望在 AI 时代，我们依然能保留那种“死磕”的精神。因为编程的魅力从来不在于最终生成的那个 .py 或 .java 文件，而在于你在解决问题过程中，大脑中建立起的那个逻辑模型。如果失去了这个过程，我们可能在效率的巅峰，却在能力的低谷。
