一个研究 LLM for Code 的研究者，拿 400 美元做了个实验：给 Gemini 3.8 Flash、GPT Astra 6、Opus 5、Fable 5 四个前沿模型各 $100 预算，让它们自主开发一款「用户体验极好」的开源 PDF 编辑器——结果是「点几下就能在几乎每个里找到 bug」。作者 nielstron 据此提出：coding agent 不能像人一样和软件交互，所以它们永远造不出真正好用的人类软件。

实验设置很有意思：模型在自己的 harness 里、独占一台 VM，被明确要求去调研现有工具、搜索用户抱怨的痛点，钱没花完可以随时唤醒继续干。结果四个模型不约而同全部选择了做 web app——而这正是作者眼里第一个错误。PDF 编辑器原本应该是本地安装的默认查看器，做成网页后既不能封装成 Android 应用，也没有任何模型认真考虑过让产物可本地安装。

问题远不止于此。交互层面，Gemini 的第一版放图片是把图片插入到当前光标位置，但插入前看不到预览图、插入后无法选中删除；Claude 和 Codex 后来聪明地直接插到随机位置再让用户拖拽，但作者指出这更像是碰巧，因为它们未必真的「注意到」了这个问题。界面导航上，Astra 把每个按钮都加上文字说明——「这恰恰是直觉的对立面」；Gemini 则造了上百万个图标含义模糊的按钮。没有一个模型想到给设置加个搜索框，尽管安卓和 iOS 都早就证明了这是最直观的功能。

性能问题更典型。作者 fork 了一个被 agent 重度开发过的家谱管理工具 Gramps-Web，家族树里存 1500 人——对家族数据库算大，但对计算机工作量是零头——UI 就慢到不可用。查下去发现后端一堆请求要几秒、还在前端串行发送，后端把通用 SQL 和 Python 手写 join 混在一起。Codex 需要「明确的线索加两次推动」才能定位问题，而在此之前没有任何 agent 自己注意到这个性能坑。

作者对模型“功能目标”的观察也很犀利：四个模型做出来的基本就是 pdf.js 壳子加几个基础功能——插图片、签名、批注、遮挡、重排页面、压缩。Fable 极简到只能高亮和文字；只有 Opus 想到了编辑 PDF 里已有的文字，但依然缺了图片移动、OCR、矢量编辑这些更基础的东西。Bug 更是没断过：导出的 PDF 图片变形、暗色模式下颜色反相、文字编辑器改了字体、遮挡框点击取消后残留……

最后作者把这一切归结为：agent 不以人类的方式使用软件。人类带着目标、不耐烦、实时交互——而 LLM 是「看截图、动鼠标、再看静态截图」。所以他得出两个判断：第一，「没有免费的午餐」，开源社区期待的『每个商业软件都被克隆』不会很快发生，因为 OSS 最大的短板恰是可用性，而这正是 agent 最弱的一环；第二，程序员在 agent 时代剩下的价值，可能只剩下「当产品经理」——这份精力过去是白给的，未来有多少人愿意免费做，存疑。

来源：

• The Remaining Shortcomings of Coding Agents - nielstron
• The GreatOSS experiment - GitHub