最近，Hacker News 上一篇题为《“Code was never the hard part” is an insult to all programmers》的文章引发了广泛讨论。

文章聚焦于 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 最后会走到哪一步，现在谁也很难说清。

以后程序员还会不会像今天这样亲手写这么多代码，也没有确定答案。

但有些能力很难绕过去。

• 你得理解系统为什么这样工作

• 知道一个方案为什么合理

• 能看出模型生成的代码哪里有问题

• 也要对最终交付的软件负责

工具可以接走越来越多实现工作。

但判断力、技术品味、对用户的理解和对系统的认识，还是得靠长期积累。

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