前两天刷到OpenAI发的一篇文章，标题叫”Harness Engineering”，讲的是他们内部一个为期五个月的实验。用Codex从零开始构建一个产品，100万行代码，3个工程师，0行手写代码。读完整篇文章我愣了好一会儿。
这个实验从2025年8月开始，往一个空Git仓库里提交了第一个commit。初始的项目脚手架、CI配置、格式化规则、包管理器设置，全部由Codex CLI用GPT-5生成。连指导agent如何工作的AGENTS.md文件都是Codex自己写的。五个月后，仓库里积累了一百万行代码，包含应用逻辑、基础设施、工具链、文档和内部开发工具。
数字说完了，说说让我觉得有意思的地方。
人不写代码了，那干什么？
OpenAI的团队发现，早期进度比预想的慢。不是因为Codex能力不行，而是环境不够完善。Agent缺少必要的工具、抽象和内部结构来推进高层次的目标。
工程师的工作内容发生了根本性的转变。他们不再写代码，而是专注于三件事：设计环境、表达意图、构建反馈循环。用原文的话说，”Humans steer. Agents execute.”
具体怎么做呢？团队采用深度优先的方式，把大目标拆成更小的构建块（设计、编码、审查、测试），然后让agent去执行这些小块。五个多月里开了大约1500个PR，平均每个工程师每天合并3.5个PR。有意思的是，团队从3人扩展到7人后，吞吐量反而增加了。
一个新工具值得关注：Sem
同一天HN上还有一个项目引起了我的注意。叫Sem，做的事情很简单：在Git之上提供语义级的代码理解。
普通的git diff告诉你哪一行变了。Sem diff告诉你哪个函数被添加了、哪个被修改了、哪个被删除了。它能做跨文件的依赖分析，告诉你改了一个函数会影响哪些其他代码。
这东西在agent-first的开发模式下价值很大。他们的benchmark显示，AI agent在拿到Sem输出后，准确率是原始line diff的2.3倍。我自己在用Claude Code做项目的时候，经常遇到agent改了一处代码却不知道会影响到哪里的问题。Sem这种思路算是从工具层面缓解了这个问题。
Meta的AI安全翻车：20,225个Instagram账户被黑
说到AI相关的事情，还有一个新闻值得关注。Meta确认超过20,225个Instagram账户被黑客通过其AI聊天机器人漏洞劫持。
黑客利用的是Instagram的AI辅助账户恢复系统中的一个漏洞。只要目标账户没有开启双因素认证，攻击者就能通过欺骗聊天机器人来重置密码。这不是什么高深的技术攻击，本质上就是跟AI聊天机器人”聊天”，让它帮你重置别人的密码。
这个事件暴露了一个很多人忽略的问题：AI系统本身就可能成为攻击面。我们花了很多精力讨论AI生成内容的安全性、幻觉问题，但对AI系统作为入口被社会工程学攻击的防范还远远不够。据TechCrunch报道，这次攻击持续了数月才被发现。
我的看法
OpenAI的实验让我想到了一个趋势：2025年下半年以来，AI编程工具从”辅助写代码”转向了”agent自主执行”。Cursor、Windsurf、Claude Code、Codex都在这个方向上推进。区别在于OpenAI这次走得更远，直接把”人不写代码”作为硬性约束。
我不认为所有团队都应该照搬这个模式。OpenAI有几个独特的优势：他们对自己的模型最了解，有足够的资源试错，而且这个产品本身就在公司内部使用。但对独立开发者和小团队来说，这篇文章至少证明了一件事：用好agent的关键不在于让它写更多代码，而在于你能不能把任务拆解得足够清晰、把环境搭建得足够友好。
至于Sem这个工具，我会继续关注。目前可以通过brew install sem-cli安装，支持diff、blame、impact、log四个核心命令，无需配置就能在任何Git仓库中使用。
如果你也在用AI编程工具做项目，我建议关注的不是哪个模型更强，而是怎么让自己的代码库对agent更友好。这才是拉开差距的地方。
