Just Talk To It - the no-bs Way of Agentic Engineering
这是一篇 Peter Steinberger 于 2025-10-14 发布的 workflow 文章。它延续了《Shipping at Inference-Speed》的个人方法论，但立场更激进：随着 gpt-5-codex 这一代 agent 变强，很多围绕 plan mode、subagents、RAG、MCP、worktrees 和复杂 harness 的“编排戏法”都开始显得像补丁，作者主张回到更直接的方式: Just talk to it.
- 作者当前的默认工作流是
codexCLI，多窗口并行，通常在同一仓库目录里直接推进，而不是严格拆成 worktree、分支和多套 dev server。 - 他把一个非常实用的判断标准讲清楚了：
blast radius。也就是一个变更大概会波及多少文件、持续多久、是否适合和别的改动并行推进。 - 这种
blast radius意识直接影响调度方式：小改动可以并行丢给多个 agent，大改动则要更频繁地中途打断、询问状态、调整方向或直接终止。 - 文中对
codex的核心偏好不是 benchmark，而是它默认会读更多文件、更谨慎地下手、更容易在没有显式 plan mode 的情况下先讨论再实施。 - 这也是标题里 “Just talk to it” 的真实含义：如果模型足够稳，很多以前要靠 plan mode、严格 spec、额外 harness 才逼出来的行为，现在可以直接靠自然语言对话得到。
- 作者对很多流行做法持强烈怀疑态度：认为 subagents 往往只是“单独开一个窗口”这一动作的产品化包装；MCP 常常比 CLI 更重、更贵、更吃上下文；RAG 对强模型的必要性也在下降。
- 他特别强调“不要把 Agent.md/Claude.md 写成 screaming all-caps 的威胁脚本”，因为这更像是在修补弱模型；对 GPT-5 这一代，更好的方式是像人一样写清楚约束和偏好。
- 文中另一个重要判断是：随着模型变强，长 spec 驱动开发的收益在下降，更多时候应该是先对话、先看选项、先开始做，再在同一上下文里不断迭代和塑形。
- 这套方法的前提并不是“代码质量不重要”。作者明确说自己约
20%时间花在 refactor、测试、整理注释、拆文件、清理死代码和维护 docs 上，只是这些工作也交给 agent 来做。 - 文章最后把 agent 管理和工程管理连起来：很多有效使用 agent 的能力，本质上和管理工程师类似，仍然要求人保留架构判断、系统设计、依赖选择和产品手感。
ℹ️ Conflict:
- 这篇文章极度依赖作者的个人工作条件：单人开发、订阅成本可承受、终端优先、对同目录并行 agent 和直接提交有较高容忍度，团队场景未必成立。
- 它对 MCP、subagents、plan mode 和 RAG 的否定带有明显“强模型 + 熟练用户 + 高频实战”的前提，不应直接外推到更弱模型或更重协作流程。
- “直接对话替代更多编排”并不等于不要结构化文档；文章本身也依赖一个很长的
Agents.md，只是它反对把这类文件写成上下文毒药式的模板废话。
- Peter Steinberger, “Just Talk To It - the no-bs Way of Agentic Engineering”, 2025-10-14.
- 原文摘录：[llm-wiki/raw/peter blog/Just Talk To It - the no-bs Way of Agentic Engineering](/raw/peter blog/Just Talk To It - the no-bs Way of Agentic Engineering.md)