智能体时代，软件工程基本功的价值反而更高
这是一篇个人随笔，作者从冒充者综合征谈起，反思智能体编程热潮中被忽略的软件工程基本功。作者认为 agent harnesses 已经跨过“能不能做到”的门槛，但要写出可调试、可维护、分层且可组合的软件，仍然需要大量细致的人类判断。LLM 并不真正推理，只是在预测压缩后的人类知识，因此关键是给它简洁、及时的数据，并用带有自然语言反馈的确定性验证工具来纠错。文中引用了 The Illusion of Thinking 论文、JEPA 模型与 Yann LeCun 的研究，也提到 Simon Willison 提出的 lethal trifecta，说明模型无法区分好建议与坏建议、难以抵御提示注入。作者强调，无论是否有智能体辅助，评审、规划并修补软件接缝都是核心技能，当下更需要关注这些基本功。适合关注 AI 编程工具与软件工程质量的一线工程师阅读。
The manifestation of my imposter syndrome, for me and today, is what does it mean to be a software engineer. There’s a lot more noise than signal on the Internet about agentic engineering, what can be accomplished, and its implications for the future. The title I chose rather gives it away; it’s about choosing — carefully — all the things you need to choose when you’re solving the puzzles of software and systems development.
对我个人来说，今天冒充者综合征的体现就是：软件工程师到底意味着什么？互联网上关于智能体工程、它能实现什么、以及对未来的影响，噪音远多于信号。我选的标题已经透露了这一点——这篇文章讲的是，在解决软件和系统开发的难题时，需要谨慎地做出各种选择。
Beyond the hype and junkie-like marketing fervor of “major model providers”, I found a really interesting power tool with the combination of harness and models. I’ve been following how friends have been using these tools, and learning a ton. As usual, the folks doing some of the most amazing things aren’t the ones crowing about it, or posting narrative blurbs in social media about the end of this profession. They found a “big damn stick”, they’re exploring the fulcrum points, and they’re representing good ole Archimedes to lean into that lever, moving the world.
抛开“主流模型厂商”上瘾般的营销狂热，我发现‘框架+模型’的组合是一个真正有趣的强力工具。我一直在关注朋友们如何使用这些工具，也学到了很多。一如既往，做出最惊人成就的人并不是那些大声嚷嚷的人，也不是在社交媒体上发布‘这个职业终结’叙事短文的人。他们找到了一根‘大棒’，正在探索支点，像老阿基米德那样撬动杠杆，推动世界。
In the past year, agent harnesses crossed the “can it be done” rubicon. (yep, jumping forward to Roman references). I would not have wished for the world’s knowledge to taken without permission and regard, or the lunatics to delve into economic self-dealing that’s peanut buttering over the otherwise tanking US economy. The economic models for the large models aren’t viable from any report that I’ve seen, but the capability isn’t going away. Instead it’s shrinking (fast!). Open weight models are making (beefy) personal computers quite capable of doing the same. They’re not quite as effective, but the delta in time and capability isn’t large.
过去一年里，智能体框架跨过了‘能不能做到’的卢比孔河。（没错，我又跳到罗马典故了。）我不希望看到世界的知识未经许可、不被尊重地被拿走，也不希望那些疯子沉溺于经济上的自肥交易，给本已下滑的美国经济抹上一层花生酱。据我所见过的所有报告，大模型的经济模式都不可行，但能力不会消失，反而在（快速）变小。开放权重模型正让（性能强劲的）个人电脑足以做到同样的事。它们的效果不是完全一样，但在时间和能力上的差距并不大。
“Can it be done” is only the start, not even close to the majority a software or system engineer’s profession. It’s like when I learned to weld in my 20’s – I quickly created things that I couldn’t lift or even get out the door of the shop. (thank goodness for acetylene torches). What I learned then is I think the same lesson, different medium: How something goes together is what makes all the difference.
If you use agentic harnesses to develop with a bit of foresight, you can get not only “it works”, but also “it’s testable” (I heavily lean into the prompt “develop with red/green TDD”). But it’s not very solid much above that. The seams — how your code works, it’s “API”, and how it fits with other software — are as much art as science. It is made up of subjective measures that rely on your viewpoint (and experience, as well as your guesses) for both what you’re solving now, and how to live with that software over a long period of time.
‘能不能做到’只是起点，甚至还算不上软件或系统工程师工作的大部分。这就像我二十多岁时学焊接——我很快做出了一些自己都搬不动、甚至拿不出车间门口的东西。（幸好有乙炔割炬。）我那时学到的道理，换了个媒介依然成立：事物如何组合到一起，才是决定性的。
如果你想得稍微长远一点，用智能体框架来开发，得到的就不仅是‘能跑’，还有‘可测试’（我非常强调‘用红/绿 TDD 来开发’这样的提示）。但再往上就不太靠谱了。接缝——你的代码如何工作、它的‘API’是什么、以及它如何与其他软件配合——既是科学也是艺术。它由各种主观尺度构成，取决于你的视角（以及经验和猜测），既关乎你眼下要解决的问题，也关乎你如何长期与这个软件相处。
Making software debuggable, maintainable, layered, and composable – that’s still quite a trick. Quite a lot of that work requires extensive, thoughtful reasoning. And that’s where the LLM’s today, even the leading edge of the “capability” from frontier models, fall short.
让软件可调试、可维护、分层清晰、可组合——这依然是个不小的本事。其中相当大一部分工作需要广泛而缜密的推理。而今天的 LLM，即便是前沿模型中最顶尖的能力，也正是在这里败下阵来。
It helps to know that LLMs don’t “reason”. They predict, and the models themselves are effectively written human knowledge compressed. So if it’s in human knowledge that was encoded, it can echo out the human reasoning. For agents focused on software development, those reasoning traces are the precious data for the models. There’s a very approachable research paper on just how bad LLMS are at reasoning called The Illusion of Thinking. There is some research I’m following that includes prediction of results of actions, but that’s not what we have today with coding agents. It’s a pretty different – and fascinating – area of research. If you want to explore, go digging on how “JEPA models” work, LeWorld Model, and recent talks by Yann LeCun.
知道这一点会有帮助：LLM 并不‘推理’。它们是在预测，而模型本身实际上是被压缩的人类书面知识。所以，如果某种人类推理被编码进了知识，它就能把这种推理复述出来。对于聚焦软件开发的智能体来说，这些推理轨迹正是模型的宝贵数据。有一篇非常易读的研究论文，专门讨论 LLM 的推理能力有多糟糕，题目叫《The Illusion of Thinking》。我还在关注一些涉及‘预测行动结果’的研究，但今天的编码智能体并不具备这个能力。那是一个相当不同、也相当迷人的研究领域。如果你想探索，可以找找‘JEPA 模型’是如何工作的、LeWorld Model，以及 Yann LeCun 最近的演讲。
While you’re working with LLMs though, there’s still a ton of ways to make them more effective. I think there’s a lot of advances that we haven’t even really begun to eek out. Most of the wins I’m seeing today involve providing it good, concise data to work from, at the right time, and providing deterministic validation tooling with natural language feedback that the LLM can use to correct itself. The amazing thing to me isn’t that it can predict what to write, but that it is effective at tool calling and following instructions.
不过，在使用 LLM 的时候，仍然有无数办法可以让它更高效。我觉得还有大量进展等着我们去挖掘。我最近看到的大部分成功，都源于在正确的时机给它提供简洁、优质的数据，同时提供确定性的验证工具，并用自然语言反馈让 LLM 能自我修正。对我来说，真正神奇的并不是它能预测写什么，而是它在调用工具和遵循指令上极为高效。
Another downside of this instruction following is what Simon Willison coined as the lethal trifecta. Basically – LLM models can’t distinguish between good advice and bad. They’re foundationally incapable of always and consistently preventing prompt injection attacks. “Alignment work”, safety harnesses, and sandboxes all help to add barriers against the worst, but there are fundamental gaps. And frankly, something that tirelessly follows instructions without having good reasoning is nightmare fuel to me.
这种遵循指令还有另一个坏处，就是 Simon Willison 命名的‘致命三重奏’。基本上，LLM 模型分不清好的建议和坏的建议。它们从根基上就无法始终如一地防范提示注入攻击。‘对齐工作’、安全框架和沙箱都有助于设置屏障、抵御最坏情况，但仍存在根本性的缺口。坦率地说，一个不知疲倦地照令行事、却缺乏良好推理能力的东西，对我来说就是噩梦燃料。
I hope there will be near-term nadvances in how models are trained to include the equivalent of reasoning traces for post-training (RLHF). In my ideal future, these include more of what it means to build software with clean interfaces, that’s debuggable, and and that’s maintainable as a key part of the reinforced evaluations. Carefully reviewing, planning, and fixing the seams of software (and systems) is one of the critical skills we both can, and need to, employ when developing software – with or without agentic assistants. And as I see the wave of “Oh, that’s easy to implement…” and people reaching for clankers to get it done, I think it’s more important than ever.
我希望在不久的将来，模型训练方法能够进步，在后续训练（RLHF）中融入等价的推理轨迹。在我理想中的未来，这些轨迹会更多地体现‘构建接口干净、可调试、可维护的软件’意味着什么，并把它作为强化评估的关键部分。仔细审查、规划并修补软件（和系统）的接缝，是我们在开发软件时能够、也必须运用的一项关键技能——无论有没有智能体助手的帮助。而当我看到‘哦，这实现起来很简单……’的浪潮，看到人们随手抓起粗糙的工具就想把事情搞定时，我愈发觉得这项技能比以往任何时候都重要。
It’s a great time to be following folks who write, talk, and share about the craft of software, and how we can be better artisans. Hopefully it’s obvious, but there’s never a single answer — a panacea. It’s always about tradeoffs, choosing what makes sense for the problem at hand. With the help of a lot of great minds sharing their thoughts — both now and going back decades — we have a great tool chest for this work. It’s about picking, or reworking to move to a better choice, the right abstractions. It’s core is managing the cognitive load, learning which pieces we need to be stable, and where we want our work to flex and bend (and how).
现在正是关注那些写作、交流和分享软件工艺、探讨如何成为更好匠人的人的好时机。希望这很明显：从来不存在唯一的答案——没有万灵药。一切都在于权衡，在于为手头的问题选择合理的方案。在众多聪明头脑的分享支持下——无论是当下还是过去几十年的积累——我们为这项工作准备了一个丰富的工具箱。关键就在于挑选合适的抽象，或者重新打磨出更好的选择。其核心是管理认知负荷，知道哪些部分需要保持稳定，希望在哪些地方留有弹性和余地（以及如何弹性）。
And yes, I wrote the damn em-dashes myself. I’m too in love with a recursive parenthetical in my writing, and I like a break from commas and parentheses.
没错，那些该死的破折号是我自己写的。我实在太喜欢在行文中用递归式插入语了，而且我也想从逗号和括号中换换节奏。