有个场景正在一些研发团队里真实发生：下班前给编程 Agent 丢一句"把登录模块的报错修了，跑通测试再提交"，第二天早上回来，分支上多了一个跑通的代码。我的判断是，自主编程 Agent 把"写代码"往前推到了"领任务"，程序员该担心的不是被替代，而是还没学会怎么管它。
事实不神秘。Claude Code、Cursor 这类工具，今年把"后台自主运行"做成了现实：它能读你的代码库、定位问题、改文件、跑测试、甚至开 PR，全程不用你盯着。对"修一串零散 bug""补一批测试"这种机械又耗神的任务，它确实比人能熬。
为什么争议这么大？因为"它能自己改代码"戳中的是两件事：一是信任——它改错了怎么办，半夜跑飞了谁兜底；二是角色——当写代码这层被自动化，程序员的价值往哪移。我的看法很明确：这类 Agent 是放大器，不是替代。它放大的是"你会不会把任务说清、会不会审它的产出"，而不是消灭你的判断力。
对几类人的影响很具体。初级开发者：别慌，但它会逼你把"基础编码"练得更扎实——因为你得能看懂它改得对不对；资深工程师：你的活从"自己写"变成"派活+验收"，评审能力反而更值钱；技术管理者：得定规矩——哪些任务能放手给 Agent 跑通宵，哪些必须人在回路里签字。
带五人后端组的强哥跟我聊过他的边界设定：他把"修已知报错""补单测"这类封闭任务交给 Agent 夜里跑，早上自己花半小时审 diff；但涉及架构改动、对外接口，一律不许它擅自提交。"有次它把一个边界判断改错了，测试过了但逻辑偏了，幸好我晨会前扫了一眼。"他的体会很准——Agent 最危险的地方不是不会做，是"做完了看起来都对"，所以人必须留在验收那一环。
想试的：本站收录的 Claude Code、Cursor、v0 都能做"描述到代码"，从修一个小 bug 起步最划算。判断标准就一句——它交回来的活，你改得动、改得对，才是真用了它。
自动化会越来越大度地接管"怎么写"，但"写什么、为什么这么写、谁来兜底"，依旧是人说了算。