代码从来不是软件开发的难点？

最近，一篇题为《“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 最后会走到哪一步，现在谁也很难说清。以后程序员还会不会像今天这样亲手写这么多代码，也没有确定答案。

但有些能力很难绕过去。你得理解系统为什么这样工作，知道一个方案为什么合理，能看出模型生成的代码哪里有问题，也要对最终交付的软件负责。

工具可以接走越来越多实现工作，判断力、技术品味、对用户的理解和对系统的认识，还是得靠长期积累。

代码越来越容易生成以后，真正值得重新考虑的，是程序员接下来该把时间和注意力放在哪里。