我不是软件工程师

# 我不是软件工程师 — huronbikes 来源：https://huronbikes.mataroa.blog/blog/i-am-not-a-software-engineer/ 我不是软件工程师。我知道这一点，因为23年前我刚入行时就有人这么告诉我。当时的同事说我是个"厉害的极客"，但算不上真正的工程师。 ## 我仍然不是软件工程师 23年过去了，仍然有人在告诉我什么是软件工程。我需要为"新的智能体范式"培养技能。据我所知，这些技能就是要求Waylon Smithers (https://en.wikipedia.org/wiki/Waylon_Smithers)机器不犯任何错误。告诉它它是一位专家级软件工程师。软件工程的未来，就是用一个输出不确定的程序来编写输出确定的程序。我看着老同事们走上了这条路。他们是软件工程师。 我不是软件工程师。我相信一些傻乎乎的东西。我相信代码应该对软件工程师来说可读且可理解（我提醒你，我不是软件工程师）。我相信代码可以高效且经过充分论证。我相信当机器编写代码时，相同的输入应该产生相同的输出。毕竟，在实时系统中实现可重复性已经够难的了，为什么还要让代码建立在流沙之上呢？ 我试图鼓励和我一起工作的人理解事物、质疑事物，就我们在做什么以及打算如何实现它建立对话。这似乎很傻，因为那些人都是软件工程师，而我不是软件工程师。他们太忙于做软件工程师，没空担心诸如由组合子查询构成的视图使用了聚合表达式，以及这些子查询会对查询性能产生负面影响之类的事情。他们太忙了，没空担心控制反转。他们太忙了，没空担心将功能从方法中提取出来以便独立测试。我担心这些事情，因为我不是软件工程师。 ## 我非常傻，而且不是软件工程师 在工作中，有人告诉我我们想要智能体驱动的用户流程。我不知道那是什么意思，因为我不是软件工程师。给出的一个例子是，正在构建的东西的用户界面会有一个文本框，人们可以用自然语言输入他们想要的内容。我看不出这比从极少数选项中选择要好在哪里，但话说回来，我非常傻，而且不是软件工程师。 我们希望在软件开发生命周期的每一个步骤都使用智能体。有人告诉我，手写代码会变得像写COBOL (https://en.wikipedia.org/wiki/COBOL)一样（COBOL是告诉我这句话的人特意选用的，不是我的比喻，所以各位COBOL大佬请别恨我）。我非常傻，而且不是软件工程师，所以我实在看不出增加的价值在哪里。智能体似乎是一种包装，用来提示LLM，并根据上下文评估输出。我不是软件工程师，所以我经常发现输出有所欠缺。 AI的使用正在被追踪作为KPI指标。我不是软件工程师，所以我不在乎KPI。23年来我都不在乎KPI。我在乎的是编写好代码。曾经有人说过，我写的代码看起来像是数学专业的人写的。我把这当作高度的赞扬，因为我不是软件工程师。在同一份工作中，有一位高级软件工程师正在实现我认为一团糟的东西。它缺少明确的接口。它将DI容器公开为公共静态成员。它用CSV进行配置，而CSV并不能很好地表达表格数据——选择CSV不是因为它是合适的交换格式，而是因为"业务用户用起来方便"。我认为这非常糟糕，我说了它非常糟糕，结果惹了麻烦。当然，这是因为我不是软件工程师。 ## 我不属于你的未来 我和一个我认为非常聪明的人聊了聊。他两次建议我应该拥抱这些AI的东西，因为它们是编写软件的未来。它们是行业的未来。 我不是软件工程师，所以这种看法在我看来相当轻率。我使用过的AI软件要么打断我的思路，要么主动占用我的思路。我担心这种占用。我担心AI软件是如何通过盗窃成为可能的。AI软件是如何通过大规模剥削成为可能的。轻率是贯穿这一切的暗流。 大型AI公司的领导者们对软件开发的这个未来津津乐道。他们得意洋洋地宣布，他们的产品将对就业产生毁灭性的影响 (https://fortune.com/2025/05/28/anthropic-ceo-warning-ai-job-loss/)。他们谈论"智能便宜到无需计量 (https://youtu.be/sTnl8O_BuuE?t=547)"，仿佛智能是可以计量的东西。这些领导者描绘的未来是可怕的，不是因为机器会把我们变成回形针，而是因为他们想象自己正在为思考本身建造护城河。 我的回应是：我不属于这个行业。毕竟，我不是软件工程师。