“写代码从来都不是难点”，这是对全世界所有程序员的严重侮辱

作者 | Tina

有人讲, “大语言模型说不定颇为擅长编写代码, 然而软件开发的难点向来都不在此。”另外有人称, “编写代码挺简单的, 真正棘手的是搞明白该编写什么。”。

如果你靠代码吃饭，听到这句话什么感受？

在2026年的时候, 持有这种观点的人变得越来越多了。最近有一篇篇幅较长的文章, 在开发者社区引发了激烈的争论, 文章的作者一条一条地进行反驳, 直接抨击其是“对全世界程序员的严重侮辱”。评论区划分成了两派, 双方争吵得不可开交。

就在这个时候, 另外一件事情正在进行着, 将准备使得Code默认开启Auto Mode, 也就是让AI自己去判断操作所存在的风险, 而不是每一件事情都向人类去请示, 原因在于他们觉得数据已经显现出“人类靠不住”这样的情况了。

一边存在着程序员的尊严方面的争论, 使得那篇篇幅较长的文章引发了大家内心的共鸣。这是缘于它刚好精确地击中了相当多人为之憋屈不已却又难以言明状况, 即编写十年代码之后, 突然就被他人告知“你所从事的工作价值不高”。另一边则是人工智能处于正在着手接管人类决策这样的现实情形, 并且这种发展趋向好像是无法被阻挡住的。这两件事情同时发生, 真是恰巧成为当下程序员所处状况最为真实的一种呈现。下面所展示的就是那篇在社区产生巨大影响的长文, 它是值得每一个依靠编写代码来获取收入的人去阅读一次的。

引爆争议的原文：

计算机编程语言运用领域正在历经一场极为激烈的变动, 没有人清楚这场人工智能引领的革新最终会迈向何处, 然而能够明确的是, 它会对工作以及生存的诸多层面产生改变, 程序编写同样不能除外。

近期, 我时常听闻这般的表述: “大语言模型说不定极为擅长编写代码, 然而软件开发的难点向来都并非在于编写代码。”另外还有人讲: “编写代码是比较容易的, 真正艰难的在于搞清楚应当编写什么。”。

在我看来，这种说法是对全世界程序员的严重侮辱。

写代码真的很容易？

倘若编写代码轻而易举, 缘何程序员长久以来处于供不应求状态, 多年持续获取高薪? 为何在人工智能轻易生成数千行代码之前, 程序员便已然承受着极为巨大的工作压力, 长期进行加班工作, 甚至陷入职业倦怠状况? 为何公司还要四处寻觅所谓的“10倍程序员”“编程狂人”以及“明星工程师”, 再通过层层筛选的面试方式? 既然写代码这般容易, 找个刚毕业的大学生去编写岂不就可以了吗?

假若是编写代码轻而易举之事, 那为何会存在像《代码整洁之道》以及《程序员修炼之道》这类厚得能借助来挡门的书籍, 《计算机程序设计艺术》莫非会是适宜于暑假消遣的轻松类型的读物吗 , SICP难道会是一本放置在茶几上用于装饰门面的画册吗 , 为啥还会有专门教授编程的训练营呢 , 甚至还会有整套的大学学位课程?

要是写代码简直轻而易举了, 那传奇程序员卡马克（John）所取得的成就还仅仅是由于恰巧赶上有利时机、处于恰当位置所致吗? 我们缘何会将那个因 、QEMU 等项目在业界相当闻名的他看作是天才呢?

要是编代码轻而易举, 那为啥大伙会因人工智能或者旁人拷贝自身代码而恼火? 既然这事这般不值一提, 那他们何故表现得仿佛为这些代码倾注了汗水、灵魂以及大量时间?

倘若编写代码轻而易举, 为何当下会有众多人感觉, 属于自身的身份认同以及职业意义正遭受剥夺呢?

如果写代码很容易，为什么软件里还有这么多该死的 Bug？

如果弄清楚该做什么才是难点……

若判定去做何事才是最为困难的环节, 为何众多产品经理看上去依旧一脸茫然? 为何公司未曾为他们安排严苛的十轮面试? 为何他们的薪资并未超出开发者?

要是确定去做啥才是最为困难的环节, 为何市场研究工作者、可用性方面的专家, 甚至于客户成功领域人员, 没被软件公司当作明星型人才? 要是“领会客户”还要更难些, 为何业务分析师老是被看轻成只会撰写文档、制作表格的人?

要是实现功能轻而易举, 而寻觅真实需求反倒更具难度, 那么当销售人员为了搞定订单, 私自向客户应允一项新功能之际, 程序员缘何还会动怒, 他们分明已然寻得了一个真实存在且有人乐意付费的需求！

莫非编程特别简单, 那为何所有人不都去搞十个不一样版本的程序出来, 瞧瞧究竟哪个呈现出的效果最为出色呢?

根本不存在所谓的“典型程序员”

再来一句被反复提及的话语: “软件开发之中大量的活儿, 皆是跟利益相关的各方去交流、弄明白客户的需求, 并且清晰地确定工作的优先级。”。

对于我经历的职业生涯范畴, 其间我碰到过好多程序员, 这里呈现出的状况是, 极少有人乐意跟利益沾边的那些方面去交流, 更不要再考虑向着直面接触用户这一方向说了, 那些单独工作以及开创事务的人员属特殊情况, 特别是软件开发公司的开创者, 说到“清晰工作重要程度排序”, 一般能够转译成为这样一句话, “径直告知我要做啥, 之后别每间隔两天就出现变化”。

有些从事软件开发者的确会讲: “我并非编写代码, 我是去处理客户所面临的问题。”然而刚转过身, 他们便又开始滔滔不绝地谈论单据、内存安全性以及 DRY 原则。他们对于客户的认知源自一个完全凭想象虚构出来的“用户画像”, 甚至连可供性与零花钱都无法区分清楚, 还误以为前者是父母在周末给予自己用于外出游玩的零用钱。

另外有一些人声明称: “软件开发即为构建理论。”在他们的思维认知里, 程序事实上是一种证明, 此所说的便是数学证明范畴；每次提交代码之时均应当讲述一席完整的事情经过；要是有人仅仅借助 FTP上传这般一个 PHP 文件, 便把客户的疑难给化解了, 那绝对是严重违背正道的行为。

并不能说, 不存在开发者, 既能用心钻研软件开发这项技艺, 又能切实理解以及共情客户。然而, 这类人可能需要找专业人员瞧瞧, 自身是否存在些许人格分裂。

究竟什么才重要？

我的确深信着, 跟用户展开交谈, 去领会他们真切的体验, 对他们怀有同理心, 处理客户的问题, 并使得所有利益相关方达成一致看法, 针对于软件项目能不能成功这事极其关键。

我同样坚信, 编出出色的代码属于一门技艺, 它所需的有技巧, 还有耐心, 以及对细节的那种关注，再者是经验跟智慧。哪怕是到将来, 这些能力依旧有着重要性。

为什么不能两者兼得？

如果条件许可, 我们应当同时去追求这两者, 一方面要深入地领会自己正在搭建的系统, 另一方面要切实地明白我们搭建它的缘由。

大声宣告着；“写代码是十分容易的”, 又或者是迈向另外一个异常的方向；笃定宣告；“代码归属一类艺术范畴, 可以达成自动化并有着源自人类极特殊的创造性表达形式体现而不能被自动化”, 这些情况全部都是处于逃离真实实际情况那样类别的状况。

这仅仅是一种自我慰藉之举, 凭借自我慰藉并不能办妥问题, 我们所切实需求的乃是于这场变动当中寻觅到自身的方位, 且持续前行。

并非意味着所有人都得马上追赶大语言模型的热潮, 也并非意味着每个程序员都要是一支AI Agent大军的管理者。同样, 我们也没必要认定“AI生成的代码全是偷来的低质垃圾, 得拼命抵制, 反正泡沫早晚得破灭”。

但, 我们得承认, 整个从事的行当正在经历一场如同地壳运动那般的巨大变化。我们要寻找到适应这种境况的方式, 还得弄明白哪些事物有可能会产生改变, 哪些事物自始至终一定不会发生改变。

什么不会改变？

将变得越发错综复杂的软件, 永远都得进行维护，软件腐化是生活里无法避开的事实, 熵增同样是这样, 不管结果是好是歹, 技术, 囊括硬件与软件, 都会持续向前迈进, 由抽象层堆砌而成的高塔, 也就是摩天大楼, 只会越筑越高。

有着永远想要更多, 且只愿花更少钱这种情况的用户, 他们仍不晓得该怎么去表达自身的需求以及愿望, 更糟的是, 连他们自己常常都不清楚到底想要啥, 身为会交钱给软件的真正意义上的客户, 和实际使用软件的用户向来会有脱节, 企业具备的需求与客户需求之间也始终会有张力。

此外, 售卖“蛇油”的行骗者始终不会消失不见。时尚的技术不断更替——我依旧在等待着新一轮的VR再度兴盛起来呢！

什么会改变？

那曾是起始之时, 程序员持续对自身所处行业予以颠覆。当下已然无人再运用穿孔卡片, 而需要借助汇编语言或者 COBOL 编程之人数目已是极少。于 Rust、Go 盛行之际, 那些倾数十年时光同 C 或 C++ 内存错误展开搏斗, 致使自身满是伤痕的过往经历, 已然变得毫无价值可言。

随着年华流逝渐长, 也因岁月添痕变老, 我已然达到这年纪, 于其间得以体会某些事物实珍贵, 且仍记住 PHP 4 那个时期出现的 ring()。如此这般事物, 在余生里大概不会再被我所用。然而那一段历史, 实际上距离现世并没有过去较长时间！

当时我入行的时间相比于其他人稍微晚了那么一些时候, 恰好就这么不巧地错过了dBase极为流行、大行其道的那个满是朝气与活力的年代。然而即便是到了现在这个时候, 偶尔间还是能够在商店或者是咖啡馆里面惊奇地看到过去的这些老技术在运转且持续运行着: 有那么一台落有好多灰尘的中塔式电脑机箱了, 它原本的颜色是那种米白色的, 可是现如今已经慢慢地泛成了黄褐色的样子, 但是它此时此刻居然却还在这里相当欢快地运行着使用了某套定制的商业系统。

我们怎样才能过得更好？

必然会发生接受变化, 面对新事物, 要保持好奇, 还要保持批判性。

清楚知晓, 这里面有诸多炒作, 尽力去区分哪些仅仅是空话, 哪些事物切实有效, 以及到底能够起到多大的作用。并且要认识到, 衡量技术进步的标准始终在变动。可以往后退一步, 回忆过去一年乃至五年, 瞧瞧技术、经济以及社会究竟是以怎样的速度产生了变化。

必然会跟着发生改变的, 是你的角色以及职责。你得心甘情愿地投入时间, 还有精力, 主动去了解跟你的专业紧挨着的领域, 以及岗位。

若你身为资深开发者, 别仅靠持续钻研技术寻觅安全感。可去理解用户体验, 做客户访谈, 还要了解所在行业内企业的商业战略。这将助力你更周全理解一款软件从构思至最终交付用户时究竟得完成多少工作, 不论以后你是否需亲自参与这些步骤。

要是你才刚开始进入这个行当, 又或者当前依旧属于初级开发者范畴, 那就理应进一步去领会软件到底是依照怎样的方式运行的。就算你所编写的是 , 对指针、递归以及内存层次结构加以理解也是会有一定助益的；就算你仅仅是在从事 插件的开发工作, 对网络协议以及 HTTP 的运行原理予以理解同样是具备效用的。哪怕当下并不会用到, 也能够去做一做 , 进而学习算法以及数据结构。不要惧怕去追问“为什么”, 也别惧怕持续追问“具体是通过怎样的途径实现的”。

底下这些书籍跟资源, 说不定能够给你带去些许启发: 《计算机程序的构造和解释》, 《程序员面试金典》, 《人月神话》, 《逆向工作法》, 《团队拓扑》, 《7 》, 《新机器的灵魂》, 《 》, 《设计心理学》, 《点石成金: 访客至上的网页设计秘笈》, 《持续发现习惯》以及《The 》。

还有一件事得说一下: 不管你究竟是何人, 千万别把自身的理解力, 以及判断力, 还有同理心与品位, 全都外包给人工智能。别丢弃自己该承担的责任, 更别沦为人工智能的人肉代理工具。

争议与回响

这篇文章一经发布, 随即在News评论区迅速引发颇为激烈的争论, 支持者一派, 反对者一派划分开来, 帖子然后便一路被顶至热榜首位。而在X上却发现, 共鸣的声音显著地更多了。

机器人开发者 写道：

终于是有人把这句话给说出了口。我觉着, 那些宣称“代码从来都并非难点”的人绝对是丧失了理智, 要不然就是存心去讲这种话以激怒全部程序员。

具备推荐系统以及搜索领域创始身份的机器学习工程师Vicki, 同样作出了表达:

多谢你撰写出这篇文章, 要成为一名卓越的程序员, 的确还得拥有诸多有别于代码的能力, 然而哪怕仅是妥善编写代码, 向来都并非轻而易举之事。

数字营销从业者 Baar 则用数学作类比：

编代码之所以困难, 恰似数学之所以困难那般。你或许领会所有数学概念, 可有可无仍然解不佳方程；你同样可能把控了设计一款优良应用所需的全部知识点, 真正着手编代码之际却始终混乱无序, 状况百出。

不过，也有人赞成“写代码很容易”。

有一位身为 News 用户且做过多年前端开发的人表示, 在过去, 百分之九十的工作都称不上代码存在多大难度, 绝大多数时候仅仅是将网络功能连接至已有的 UI 元素上。让他真正感兴趣的部分是编写 GPU 着色器以及优化可视化性能。

当今时, 他转而投身于GPU以及内核的编程工作, 在那般复杂的任务范畴之内, AI如今也已然开始超越他。但是呢, 他持有这样的观点, 知晓论文之中所涵盖的前沿算法, 判别内存带宽瓶颈等诸般专业知识, 依旧是决定着人能不能够有效地驾驭AI这一情况的关键所在。

那条在评论区内部可以算得上是最为精彩的回复, 实际上源自一位自称拥有将近40年编程经历的News用户, 此位专业人氏提出: LLM出台之后, 编程搞不准真的就再不会属于最难搞弄的范畴领域了。

他列举了一个自身经历过的事例, 他维护着一套核心算法, 该算法是25年前编写的用于金融系统的, 他每晚都要负责处理机构间数十亿美元的资金流转, 代码从77转换到C语言后, 仅有十来屏, 然而却充满了goto、复杂分支以及二十多个并行数组, 其运行速度极快, 可是人却几乎难以读懂。

存在这样一套系统, 其所需要解决的是实际方面的问题, 仅用三句话便能够将其概括, 然而因为上下文管理极为复杂, 所以真正把它写出来是十分困难的。故而, 客户宁可长时间支付授权费, 也不愿意自己去进行开发。可是到了如今, 该客户觉得LLM也许已经有能力从一开头就写出同样的系统。

依其看来, 往昔编码的一大棘手之处, 源于两种理念间的冲突: 其一, 开发者期望预先开展周全设计, 以便为未来或许会出现的需求做好筹备；其二, 却不可过度设计, 甚者亦不该编写“往后可能会用得着”的代码。

敏捷开发渐趋流行, YAGNI 原则（即不要提前去实现那些尚未明确所需的功能）也跟着流行起来, 在它的影响下把复杂的项目拆解成一个个的用户故事 , 在这样的框架范围之内, 编码看上去简单好多, 开发者只要遵循当下的用户故事就能实现功能 , 然而新的问题跟着就出现了 , 当需求持续发生变化的时候, 开发者又不得不返回到昨天那个用户故事最后遗留下来的代码进行重构。

我觉得、这恰为当下众人唏嘘不已的缘由、资质卓越的工程师已不被需求了。

如今, 我能够径直就让 LLM 去编写代码。鉴于需求愈发复杂起来, 它会满心欢喜地持续不断去重构代码, 还能帮我管着上下文。所以如此, 我们不必再忧虑代码是不是“整洁”了, 也不用再对所谓的“代码质量”揪着不放了。只要 LLm 写下的代码契合规范, 我们便满意了。

我觉着, 编程切实的‘难点’始终在于料理上下文, 然而我们所要料理的上下文自身也是持续变动的。善于料理上下文的人, 将善于运用LLM进行编程；不善于料理上下文的人, 依旧不会。

然而，放权给 AI 已成大势所趋？

争议的要点在于, 人类程序员是不是擅长进行上下文管理, 然而事实上, Code已然又迈进了一步, 那就是, 就连Agent执行哪些命令能够予以放行, 哪些命令需要加以阻止, 也都开始交给模型去判断了。

宣告, 自 8 月 14 日起始, Auto Mode 将变为 Code 针对 Pro、Max 以及 Team 用户的默认权限模式。用户、API 以及云平台当前依旧需要手动去开启, 预估在未来一个月之内会逐步拓宽默认范围。

Code 用户当前会批准 97% 的权限请求, 这是研究数据所显示的。在另一项覆盖 1000 多名测试者的实验中, 测试者仅仅能识别出 13.6% 的危险命令, 可 Auto Mode 却能够识别出 89%。随着权限提示持续不断增多, 测试者的判断能力会快速下降, 连续处理 50 次请求之后, 他们只可以发现其中 5% 的危险命令。

觉得, 降低权限提示反倒能够使开发者以更为审慎的态度去对待那些确实需要人工介入的操作。在 Auto Mode 这种情况下, 一旦分类器判定某一命令具有危险性, 系统就会径直进行阻止执行, 转而能够去寻觅更为安全的替代方案, 或者回到用户那里去请求明确的授权。要是某一项操作接连遭到三次阻止, 或者在单次会话里头累计被阻止二十次, 系统就会自动退出 Auto Mode, 恢复手动审批。

自动模式变成默认模式, 这意味着 Agent 使用方式有了转变, 当 Agent 持续工作好几个小时, 开发者没办法一直待在屏幕前逐个批准每条命令 而且以前 Agent 做写代码的事, 开发者干逐行检查和批准的活, 现在连“哪些操作值得开发者留意”也是由另一个模型来筛选。

这般情形致使关于“写代码究竟难不难”的争论得以更进一步。往昔的时候, 人们起码还秉持着一种信念, 觉得AI能够承担执行方面的工作, 而人类负责进行监督以及把关；然而Auto Mode所揭示的情况是, 伴随Agent执行的任务变得愈发冗长, 哪怕监督也没办法涵盖每一个具体步骤。人类不会完全从开发流程当中撤离, 不过介入的位置正持续向后推移: 先是逐步从编写代码、检查代码以及批准操作等环节转出, 进而转向定义目标、划定边界、处置异常并且承担最终责任。

讲“写代码挺简单的”, 这是对那数以百万计的开发者, 一天天、一月月细细琢磨本领时所作的轻视之举；然而, 若只是将脑袋埋进沙堆里头, 装作一切都还照旧, 这同样起不到什么作用。真实的尊严所在之处, 并非在于去保卫某个固定的工作职位, 而是在于去承认变化已然切实发生了, 接着主动地去重新进行界定: 在由AI编写代码的这个世界当中, 程序员究竟还能够缔造出什么样无法替代的价值呢?

写代码或许真的变容易了，但写出对的代码，从来都不容易。

参考链接：