最近一篇题为《“Code was never the hard part” is an insult to all programmers》的文章在 Hacker News 上引起了不少讨论。它主要讲是 AI Coding 之后越来越常听到的一句话Code was never the hard part——代码从来都不是软件开发里最难的部分。现在 LLM 已经能快速生成大量代码于是软件开发的难点似乎很自然地落到了理解用户、确认需求、决定做什么以及最后把产品交付出去。这些事情一点都不简单。但是按照这个逻辑把 Coding 描述成一种一直都很简单、接近机械劳动的工作就有点奇怪了。被低估的编码难度如果写代码一直很容易那过去几十年的很多事情都很难解释。为什么程序员长期是高需求职业为什么公司愿意花高薪招优秀开发者为什么技术招聘里会有算法题、系统设计和一轮又一轮技术面试甚至还出现了“10x Programmer”“Rockstar Developer”这样的词用来形容那些明显比普通开发者更强的人。软件行业也花了几十年研究怎么把代码写好。《计算机程序设计艺术》《计算机程序的构造和解释》《程序员修炼之道》《代码整洁之道》这些书能流传这么久本身就说明编程里有大量需要长期训练的东西。从数据结构、算法和抽象到并发、性能、内存管理、可读性和可维护性这些都发生在具体实现里。一个需求已经明确并不代表接下来只剩下把它翻译成某种编程语言。还有一个更直接的问题如果 Coding 真有那么简单为什么软件到今天还有这么多 Bug一个功能能跑起来只完成了很小一部分工作。边界条件、状态组合、并发、资源管理、异常处理、长期维护最后都会落到具体代码里。很多工程问题只有真正开始实现以后才会冒出来甚至实现过程本身就在不断改变我们对问题的理解。“做什么”也没有那么独立“写什么比怎么写更难”也是 AI Coding 之后很流行的一种判断。毕竟理解用户、找到需求、判断优先级确实很重要。但如果把这句话继续往下推就会出现一些挺有意思的问题。如果决定做什么始终比实现难得多公司为什么没有用类似招聘顶尖工程师的强度筛选产品经理、市场研究和用户研究人员销售提前向客户承诺了一个新功能开发团队是不是也该觉得轻松一些因为最困难的需求发现已经有人做完了现实里的开发往往没有这么简单。“客户想要这个功能”和“这个功能应该怎么进入现有系统”之间还隔着大量判断。它会不会和现有能力冲突数据模型要不要改会不会留下新的技术债以后由谁维护一次看起来很小的需求真正落到系统里可能会牵动很多已有设计。如果实现成本真的低到几乎可以忽略一个需求完全可以一次做五个、十个版本让用户自己选。但大多数团队不会这么干。每多一个版本就会多一份测试、维护和后续演进的成本。所以需求很重要怎么实现同样重要。两件事在真实开发里往往混在一起很难切成两个完全独立的阶段。不存在“典型程序员”讨论软件开发时还有一个很容易掉进去的坑先想象一个“典型程序员”再用他的工作状态代表整个行业。比如开发者每天大部分时间都在开会、和相关人员沟通、澄清需求真正写代码只占很少一部分。这样的工作状态当然存在但远远覆盖不了所有程序员。有些开发者每天都在和客户沟通有些人常年做编译器、数据库、基础设施和底层系统可能很少直接接触最终用户有人特别关注抽象、类型系统和代码结构也有人只想尽快解决眼前的问题一个简单脚本能完成任务就够了。这些都属于软件开发。做 SaaS、游戏、数据库、操作系统、嵌入式设备和企业内部系统面对的问题差异很大。有些项目确实卡在需求和沟通上另一些项目里算法、性能、并发和实现细节本身就已经足够困难。所以“软件开发最难的部分是什么”很难给出一个适用于所有人的答案。项目不同、岗位不同、阶段不同难点的位置也会跟着变化。软件开发的两端软件开发一直同时面对两个方向。向上一层是用户、需求和产品。开发者需要知道为什么要做这个功能谁会使用它它到底解决什么问题。向下一层是计算机、系统和代码。开发者也需要知道这个功能应该怎样进入系统数据怎么流动状态怎么管理失败以后会发生什么。这两部分缺一块都会出问题。只懂用户不理解系统很容易提出实现代价极高甚至根本无法落地的方案只懂代码不理解用户也可能做出技术上很漂亮、实际没人需要的软件。AI 开始大量参与编码之后这两个方向反而变得更值得关注。中间那些重复、明确、边界清晰的实现工作会越来越容易交给工具开发者需要投入精力的地方也会随之变化。不会消失的软件问题有些问题已经跟着软件工程几十年了AI 很难让它们一下消失。系统还是会越来越复杂软件还是要维护依赖、平台、硬件和协议还是会变化。今天运行得好好的系统过几年一样可能因为外部环境变化需要重新调整。用户也不会因为有了 AI 就突然更会提需求。买软件的人和真正使用软件的人依然可能是两拨人公司目标和用户体验之间依然会有冲突开发团队照样要在成本、时间、质量和功能之间不断取舍。技术行业的 Hype 也不会停。新的框架、方法论和开发范式还会一轮轮出现有些会留下有些几年后就很少有人再提。AI Coding 会改变软件怎么被做出来但复杂度、维护、沟通和取舍这些老问题还会继续存在。不断变化的编程技能程序员其实一直在自动化自己的工作。今天很少有人再用打孔卡大多数开发者也不需要直接写汇编。高级语言、编译器、运行时、垃圾回收和各种开发工具已经接走了大量过去必须由程序员手动完成的工作。一些曾经很重要的技能也会慢慢退出日常开发。过去开发者需要非常熟悉手动内存管理、某些数据库 API 或特定开发工具后来这些工作逐渐被新的语言、框架和基础设施吸收开发者也随之往更高一层抽象移动。AI Coding 很可能继续推动这个过程。未来程序员亲手输入的代码可能会越来越少一些今天看起来很基础的实现工作也会更多交给模型完成。软件开发史上已经发生过很多次类似变化每一次工具进步都会带走一部分旧工作再把新的问题留给开发者。真正值得关心的是新的抽象层出现以后我们还需要理解什么。开发者的适应路径对于已经做了很多年开发的人只继续钻研已有技术栈可能会越来越窄。往上多理解一些用户体验、Customer Interview、产品设计、商业模式和行业知识会更容易看清一套软件从想法走到真实用户手里的全过程。这些东西最终也会反过来影响架构、优先级和技术取舍。刚进入行业的人反而更值得把基础补扎实。Pointer、Recursion、Memory Hierarchy、TCP/IP、DNS、HTTP、算法和数据结构这些东西哪怕平时写业务代码不一定直接用到也能帮助你理解程序到底怎么运行以及出问题时应该去哪里找原因。这两条路刚好指向软件开发的两端向上理解用户和业务向下理解计算机和系统。当中间越来越多实现工作可以交给 AI开发者对这两端的理解会越来越影响自己能不能看懂、判断和修正模型给出的结果。理解、判断与责任AI Coding 最后会走到哪一步现在谁也很难说清。以后程序员还会不会像今天这样亲手写这么多代码也没有确定答案。但有些能力很难绕过去。你得理解系统为什么这样工作知道一个方案为什么合理能看出模型生成的代码哪里有问题也要对最终交付的软件负责。工具可以接走越来越多实现工作判断力、技术品味、对用户的理解和对系统的认识还是得靠长期积累。代码越来越容易生成以后真正值得重新考虑的是程序员接下来该把时间和注意力放在哪里。