Harness 工程：在 agent-first 世界中利用 Codex

规模与吞吐量主张

• 许多人对这样的说法印象深刻：约 100 万行代码、约 1,500 个 PR、一个小团队，以及“数量级”更快的速度。
• 一些人把这与大型、成熟的项目（Firefox、Python stdlib）相比，认为 LOC 数字不太可能，至少作为炫耀性指标也显得可疑。
• 也有人把它看作一个有用的演示，说明 agents 可以在约 100 万行代码的代码库中工作，而不是产品质量的证明。

代码质量、可维护性与技术债务

• 对于如此快速、由 agent 驱动的产出是否能够干净或可维护，存在强烈怀疑；人们担心会出现“意大利面代码”和长期退化。
• 也有人注意到文章声称进行了系统性的清理和技术债务偿还，但在没有仓库访问权限的情况下仍不信服。
• 还有人担心大型、冗长、面向 agent 的代码库会变得难以理解，或者对人类来说毫无意义，从而推动走向仅由 AI 维护。

架构、Harness 与护栏

• 许多人把重点放在“harness engineering”上，认为这才是真正的创新：严格的分层、导入规则、CI 检查，以及确定性的工具（linters、tests、依赖规则）。
• 一些评论者报告了类似的设置：把所有计划/文档/日志都放在仓库内，让 agents 更新文档，进行大量自动化验证，并使用领域驱动或分层架构。
• 据称，较小的文件、较低的 LOC 和良好的模块化能显著提升 agent 表现和上下文利用率。

指标与 LOC 到底意味着什么

• 普遍共识是，LOC 是一个很差的生产力指标，并且会激励“钻空子”。
• 也有人认为，它仍然是一个简单、易于传达的代理指标，用来向非技术受众展示“做了很多事”。
• 另一些人强调，优秀工程应优化更少、更密集、更一致的行数，并建议使用更好的指标（测试、可靠性、功能正确性）。

经济与劳动方面的担忧

• 一些人认为，这隐含地表明更少的工程师可以交付更多，从而威胁到初级和资深角色。
• 另一些人则认为，资深工程师在架构、harness 设计和领域理解方面仍然很有价值；初级工程师可能受到的冲击最大。
• 少数人把文章斥为营销，并质疑这类 agentic 系统的真实可靠性、成本和 ROI。

采用、限制与成本

• 多位实践者表示他们尝试过类似的“agent-first”工作流；结果从令人印象深刻到混乱的“vibe coding”不等。
• 成本和 token 限制被认为是完全自主化方法的主要障碍，尤其是在资金充足的环境之外。