这篇文章讲的是Moltbot(原Clawdbot)彼得·斯坦伯格（Peter Steinberger）这位独立开发者怎么用AI代理（agent）来写代码的故事。
他搞了个30万行代码的大项目，包括网页、浏览器插件、命令行工具、桌面应用和手机App。他的核心心法就一句话：直接跟AI说话，别搞那些花里胡哨的框架和流程。
他用OpenAI的codex-cli工具，同时开3到8个窗口并行干活，让AI自己提交代码。他认为现在很多人都在搞复杂的"代理编排"（agent orchestration），搞什么子代理、工作流、MCP（模型上下文协议），这些都是脱裤子放屁。真正管用的方法是培养直觉，像管人一样管AI，给它清晰的上下文，然后相信它能搞定。
他用GPT-5-codex模型，觉得比Claude Code好用多了，因为codex更安静、更靠谱、上下文更长、速度更快。他的结论是：AI编程已经进入"直接对话"时代，别整那些虚的，越简单越强大。
开篇：我一个人就是一支军队
我得跟你坦白，最近我在我的博客上有点销声匿迹。为啥？因为我正埋头搞我的最新项目，忙得脚不沾地。事情是这样的：AI代理工程（agentic engineering）现在已经牛到离谱了，基本上我所有的代码都是AI写的。没错，百分之百。我坐在那儿，看着屏幕上的代码像瀑布一样往下滚，感觉就像有个隐形的团队在替我打工。
但是啊，我看着周围那帮人，我就来气。他们遇到问题不直接解决，非要搞一堆花里胡哨的"编排"（orchestration），像是在演一出精心设计的木偶戏。我看着他们折腾那些复杂的代理工作流、子代理、MCP协议，心里就想：兄弟们，你们这是在干嘛呢？直接跟AI说不就完了吗？
这篇文章的灵感，一部分来自昨晚我在伦敦参加的"Claude Code匿名互助会"（Claude Code Anonymous），那场面，简直就是一群被AI折磨得死去活来的人在互相取暖。另一部分是因为距离我上次更新工作流已经整整一年了，是时候做个年度汇报了。好消息是，那些基础理念依然有效，所以什么上下文管理之类的入门知识我就不啰嗦了，想补课的去看我那篇《最优AI工作流》。
我的技术栈：一个疯子的军火库
先说说我在搞什么。我是一个人单干，目前的项目是个巨兽：大概30万行TypeScript代码的React应用，一个Chrome浏览器插件，一个命令行工具（CLI），一个用Tauri做的桌面客户端，还有一个用Expo搞的手机App。我把它部署在Vercel上，每次提交Pull Request，两分钟内就能上线新版本测试。其他的应用暂时还没自动化，但也在路上了。
这个技术栈听起来是不是有点疯？没错，就是疯。但这就是2025年的独立开发者现状：一个人要干一个团队的活。要是没有AI，我早累死了。有了AI，我不仅活下来了，还活得挺滋润。
我的装备：codex-cli，我的新欢
我已经完全转向用codex-cli作为日常驱动了。这是OpenAI出的命令行工具，我现在同时开3到8个窗口，排成一个3x3的终端网格。大部分窗口都在同一个文件夹里干活，有些实验性的任务就放在单独的文件夹里。我试过git worktrees（工作树），也试过开不同的PR分支，但最后都回到了这个简单粗暴的设置，因为这才是最快的干活方式。
我的AI代理们会自己提交代码，而且是原子提交（atomic commits）。为了保持提交历史相对干净，我花了大量时间迭代我的代理配置文件（agent file）。这让git操作变得极其精准，每个代理只提交它自己改过的文件，不会互相踩脚。
你可能会问：Claude Code不是有hooks（钩子）功能吗？codex现在还不支持啊。我的回答是：模型聪明得很，如果它铁了心要搞事情，什么钩子都拦不住。我之前被人嘲笑过，说我是"垃圾代码生成器"（slop-generator）。看着吧，现在并行代理慢慢变成主流了，那些曾经笑我的人，现在都在偷偷学我。
选模型：GPT-5-codex，中庸之道
我现在基本上所有东西都用gpt-5-codex模型，设置调在中等（mid settings）。这是个聪明的折中：既聪明又快，而且它会自动调节思考深度。我发现过度纠结这些设置没啥意义，反正效果都差不多。最爽的是，我再也不用去想什么"超级思考模式"（ultrathink）了，省心。
爆炸半径：我的秘密武器
每次我干活的时候，我都会想"爆炸半径"（blast radius）这个概念。这个词不是我发明的，但我爱死了。当我考虑一个改动时，我大概能感觉出来它要花多长时间，会动到多少文件。我可以往代码库里扔很多小炸弹，也可以扔一个"胖子"（Fat Man，就是二战那颗原子弹）加几个小的。但如果你扔好几个大炸弹，那就别想做到独立提交了，出了问题也很难回滚。
这也是我观察代理工作的一个重要指标。如果某个任务花的时间比我预想的长，我直接按Esc键，问它"现在啥情况？"（what's the status）。然后我决定是帮模型找方向，还是直接中止，或者让它继续。别怕中途打断模型，文件改动是原子的，它们很擅长从断点继续。
如果我不确定影响范围，我会用"先给我几个选项再动手"（give me a few options before making changes）这个策略来试探一下。
情感爆点：为什么我放弃了Claude Code
说到这个我就来气。我以前超爱Claude Code，现在？我受不了它了。哪怕codex其实是它的粉丝（对，你没听错，codex模型在训练时可能"喜欢"Claude），我也忍不了Claude Code那股子劲儿。
它说话的方式，那种"绝对正确"的语气，那种"百分之百生产就绪"的消息，哪怕测试全挂了它也这么说。我受够了。Codex就像个内向的工程师，闷头干活，把事情搞定。它开始工作之前会读更多的文件，所以哪怕是很短的提示，它通常也能精准理解我想干嘛。
我的时间线上有个广泛的共识：codex才是正道。这不是我一个人的感觉，是大家的集体智慧。
codex的其他好处：碾压级优势
让我数数codex的好处，这简直是碾压：
上下文长度：codex能用大约23万个token的有效上下文，Claude Code只有15.6万。你说Claude有Sonnet 1M（一百万token）？那是你得运气好或者付API价格才能用上。现实是，Claude在用完那上下文之前很久就变得傻乎乎的了，根本没法 realistically 用。
token效率：我不知道OpenAI做了什么黑科技，但我的上下文填充速度比用Claude Code慢多了。以前用Claude的时候，我总是看到"Compacting…"（压缩中）的提示，现在用codex，我很少能撑满上下文。
消息队列：Codex允许你排队消息。Claude以前也有这个功能，但几个月前他们改了，说你的消息会"引导"模型。如果我想引导codex，我直接按Esc然后输入新消息就行了。有选择权总是更好的。我经常把相关的功能任务排队，它就这么可靠地一个个搞定。
速度：OpenAI用Rust重写了codex，效果立竿见影。它快得离谱。用Claude Code的时候，我经常遇到好几秒的卡顿，进程能膨胀到占用好几GB内存。还有那个终端闪烁，特别是用Ghostty终端的时候，烦死人。Codex完全没有这些问题。它感觉极其轻量、极其快速。
语言风格：这对我的心理健康真的很重要。我以前对Claude吼过多少次，我都数不清了。但我很少对codex发火。哪怕codex是个更差的模型，单凭这一点我也会用它。如果你两个都用上几周，你就会明白我的意思。
没有到处乱丢的markdown文件：懂的都懂，用过Claude Code的人都知道我在说什么。
为什么不用那些第三方工具
我觉得吧，在终端用户和模型公司之间，其实没多少空间留给第三方工具了。我用订阅服务得到的 deal 是最划算的。我现在有4个OpenAI订阅和1个Anthropic订阅，每月总成本大概1000美元，基本上token无限用。如果我用API调用，成本大概是现在的10倍。别让我算细账，我用过ccusage之类的token计数工具，都不太精确，但哪怕只是5倍，这也是个超划算的deal。
我喜欢amp和Factory这样的工具，但我不觉得它们能长期存活。codex和Claude Code每次更新都在变强，它们的功能都在趋同。有些工具可能在待办列表、引导或者小功能上暂时领先，但我不觉得它们能显著打败这些AI大公司。
amp已经不用GPT-5作为主驱动了，现在叫它"神谕"（oracle）。Meanwhile，我用codex，基本上一直在用那个更聪明的模型，就是那个"神谕"。没错，有benchmark（基准测试），但考虑到使用数据的偏差，我不信那些。codex给我的结果比amp好得多。我得夸夸他们在会话分享上的创新，他们确实在推动一些有趣的想法。
Factory嘛，我还没被说服。他们的视频有点尬，虽然我的时间线上有人说它好用，但它不支持图片，还有那个标志性的闪烁问题。
Cursor……它的tab补全模型是行业领先的，如果你还在自己写代码的话。我主要用VS Code，我喜欢他们在浏览器自动化和计划模式上的尝试。我试过GPT-5-Pro，但Cursor还是有那些五月份就烦我的bug。听说他们在修，所以它还在我的dock栏里。
其他的像Auggie，在我的时间线上就是一闪而过，再也没人提起。最后它们都是包装GPT-5和Sonnet的，可替代性太强了。RAG（检索增强生成）可能对Sonnet有用，但GPT-5搜索能力太强了，你根本不需要单独的向量索引。
最有希望的候选者是opencode和crush，特别是配合开源模型。你完全可以把OpenAI或Anthropic的订阅用在它们上面（靠一些 clever hax），但这 questionable 是不是被允许的，而且既然模型是为codex或Claude Code优化的，用个能力更差的工具有啥意义呢？
开源模型：中国的追赶
我一直盯着中国的开源模型，它们追赶的速度令人印象深刻。GLM 4.6和Kimi K2.1是强有力的竞争者，慢慢达到了Sonnet 3.7的质量，但我还是不推荐它们作为日常主力。
基准测试只能讲一半的故事。我觉得代理工程从"这什么垃圾"进化到"这还不错"是在去年五月Sonnet 4.0发布的时候，而从"不错"到"这太神了"的巨大飞跃是随着gpt-5-codex到来的。
计划模式：codex的隐性超能力
基准测试忽略了一个关键点：模型+工具在接到提示时采取的策略。codex谨慎得多，它会在决定做什么之前读更多的文件。当你提出一个愚蠢的请求时，它会更有力地反驳。Claude和其他代理更急切，它们会随便试点什么。这可以用计划模式和严格的结构文档来缓解，但对我来说，这感觉像是在给破系统打补丁。
我现在很少用大的计划文件了。codex甚至没有专门的计划模式，但它遵守提示的能力强太多了，我直接写"咱们讨论一下"或者"给我几个选项"，它就会乖乖等着我批准。不需要那些花里胡哨的工具戏法。直接跟它说话就行。
Claude Code的插件：我听到远处的叹息声
你听到远处传来的噪音了吗？那是我在叹气。真是一堆bullshit。这个真的让我对Anthropic的聚焦点很失望。他们试图用插件来修补模型的低效。没错，为特定任务维护好的文档是个好主意。我在docs文件夹里存了一大堆有用的markdown文档。
子代理：别跟我提这个
但是关于子代理这整出戏，我得说几句。早在五月，这叫子任务（subtasks），主要是当模型不需要全文时，把任务拆到单独的上下文里去，主要是为了并行化或者减少上下文浪费，比如嘈杂的构建脚本。后来他们 rebranded 并改进成子代理（subagents），你可以打包一些指令，派出去一个任务。
用例是一样的。别人用子代理做的事，我通常用单独的窗口做。如果我想研究什么，我可能在单独的终端面板里做，然后粘贴到另一个面板。这让我对上下文工程有完全的控制和可见性，不像子代理那样，很难查看、引导或控制返回的内容。
我们还得聊聊Anthropic在博客上推荐的那个子代理。看看那个"AI工程师"代理吧。它是一堆垃圾的混合物，提到了GPT-4o和o1来做集成，整体看起来就像是自动生成的文字汤，试图显得有意义。里面没有实质内容能让你的代理成为更好的"AI工程师"。
这到底意味着什么？如果你想得到更好的输出，告诉你的模型"你是个专门做生产级LLM应用的AI工程师"不会改变什么。给它文档、例子和能做/不能做的清单才有帮助。我打赌，如果你让代理去"google AI agent building best practices"（谷歌AI代理构建最佳实践），让它加载一些网页，结果会比这垃圾好。你甚至可以说这堆垃圾是上下文毒药。
我怎么写提示词：从啰嗦到精准
以前用Claude的时候，我写的提示词超详细（当然不是我写的，是我说的），因为这个模型你给越多上下文它越"懂你"。虽然这对任何模型都成立，但我注意到用codex后，我的提示词明显变短了。经常就一两句话加一张图。这模型读代码库的能力强得离谱，就是懂我。我有时甚至回归打字了，因为codex需要那么少的上下文就能理解。
加图片是提供上下文的神奇技巧，这模型超擅长找到你展示的东西，它能找到字符串并匹配，直接定位到你提到的地方。我说至少50%的提示词包含截图。我很少标注，那样效果更好但更慢。拖一张截图进终端只要两秒钟。
Wispr Flow配合语义修正依然是王者。
网页版代理：Codex Web成了我的便签本
最近我又实验了网页版代理：Devin、Cursor和Codex。Google的Jules看起来不错，但设置起来真烦人，而且Gemini 2.5已经不是什么好模型了。等Gemini 3 Pro出来情况可能会变。唯一留下的是codex web。它设置也烦人，还有bug，终端现在加载不正确，但我有个旧版本的环境，想办法让它跑起来了，代价是启动时间更慢。
我用codex web作为我的短期问题追踪器。每当我在外面有个想法，我就通过iOS应用写一句话，然后在Mac上回顾。当然，我可以用手机做更多事，甚至审查/合并，但我选择不这么做。我的工作已经够让人上瘾了，所以当我出去或见朋友时，我不想被拉得更深。嘿，这话可是出自一个花了将近两个月时间做工具来让手机编程更容易的人之口。
Codex web以前甚至不计入你的使用限额，但那些美好的日子已经不多了。
工具们的葬礼：Conductor、Terragon、Sculptor们
咱们聊聊工具吧。Conductor、Terragon、Sculptor，还有那1000个其他的。有些是业余项目，有些在VC的钱里淹得半死。我试过太多太多了。没有一个留下来的。我觉得它们都是在解决当前的低效问题，推广的工作流根本就不是最优的。而且，大部分都隐藏了终端，不显示模型显示的所有东西。
大部分都是Anthropic SDK的薄包装+工作树管理。没有护城河。我质疑你是否真的想要在手机上更容易地访问编程代理。这些小用例，codex web完全覆盖了。
我确实看到几乎每个工程师都会经历一个阶段：构建自己的工具，主要是因为好玩，因为现在容易多了。而且还有什么比构建能（我们认为）让构建更多工具变得更简单的工具更有趣呢？
后台任务：我用tmux解决了
没错，codex目前缺少Claude有的一些花哨功能。最痛苦的缺失是后台任务管理。虽然它应该有个超时，但我确实看到它在CLI任务卡住时僵住好几次，比如启动开发服务器或测试死锁。
这是我之前转回Claude的原因之一，但既然那个模型在其他方面太傻了，我现在用tmux。这是个老工具，用来在后台持久会话中运行CLI，模型里有大量的世界知识，所以你只需要说"通过tmux运行"。不需要自定义的代理md戏法。
MCP：营销部门的玩具
别人写了很多关于MCP（模型上下文协议）的东西。我觉得大部分是给营销部门做 checkbox 然后骄傲用的。几乎所有MCP其实都应该是CLI。这话出自我这个写了5个MCP的人之口。
我可以直接通过名字引用CLI。我不需要在代理文件里解释任何东西。代理第一次调用时会尝试$randomcrap，CLI会呈现帮助菜单，上下文里就有了完整的使用信息，从此一切顺利。我不需要为任何工具付费，不像MCP那样是持续的成本，还污染我的上下文。用GitHub的MCP看看，23k token没了。天啊，他们确实改进了，因为刚发布时几乎是50,000 token。或者用gh CLI，它有基本相同的功能集，模型已经知道怎么用，而且付零上下文税。
我确实开源了一些我的CLI工具，比如bslog和inngest。
我现在用chrome-devtools-mcp来闭合循环。它取代Playwright成为我网页调试的首选MCP。我不常用，但用的时候，闭合循环挺有用的。我设计了我的网站，让我可以创建API key，让模型通过curl查询任何端点，这在几乎所有情况下都更快、更token高效，所以连那个MCP都不是我每天需要的。
代码是垃圾？我有20%时间专门清理
我大概花20%的时间在重构上。当然，这些都是代理做的，我不浪费时间手动干。重构日很棒，当我需要少点专注或者累了的时候，因为我可以取得很大进展，而不需要太多专注或清晰思考。
典型的重构工作包括用jscpd检查代码重复，用knip找死代码，运行eslint的react-compiler和弃用插件，检查是否引入了可以合并的API路由，维护我的文档，拆分太大的文件，给复杂部分加测试和代码注释，更新依赖，工具升级，文件重组，找到并重写慢测试，提到现代React模式并重写代码（比如你可能不需要useEffect）。总有事可做。
你可以说这些应该在每次提交时做，我发现这些快速迭代的阶段，然后维护和改进代码库，基本上就是偿还技术债务，效率更高，总体上更有趣。
规格驱动开发？那是老黄历了
我六月份以前这么干。设计一个大规格，然后让模型建，理想情况下建几个小时。我觉得那是构建软件的老思维方式。
我现在的做法通常是我开始和codex讨论，我粘贴一些网站，一些想法，让它读代码，我们一起充实一个新功能。如果有什么棘手的，我让它把所有东西写进规格，然后给GPT-5-Pro审查（通过chatgpt.com）看看它有没有更好的想法（令人惊讶的是，这经常大大改进我的计划！），然后我把我觉得有用的粘贴回主上下文来更新文件。
到现在我对哪些任务需要多少上下文有了很好的感觉，codex的上下文空间相当不错，所以我经常直接开始构建。有些人很教条，总是用新上下文和计划，我觉得这对Sonnet有用，但GPT-5处理大上下文的能力强多了，那样做每件事都会轻易增加10分钟，因为模型得慢慢重新获取构建功能所需的所有文件。
更有趣的方法是当我做基于UI的工作时。我经常从简单的东西开始，故意低规格我的请求，看着模型构建，看着浏览器实时更新。然后我排队额外的改动，迭代这个功能。我经常不知道某个东西应该长什么样，那样我就可以玩这个想法，迭代，看着它慢慢活过来。我经常看到codex构建出我都没想过的东西。我不重置，我只是迭代，把混乱塑造成感觉对的形状。
我经常得到相关交互的灵感，在构建时迭代其他部分，那些我在不同的代理里做。通常我做一个主功能和一些小的、相关的任务。
就在我写这篇文章的时候，我在我的Chrome扩展里构建一个新的Twitter数据导入器，为此我重塑了graphql导入器。因为我不太确定那是不是正确的方法，那个放在单独的文件夹里，所以我可以看PR看看那个方法有没有道理。主仓库在做重构，所以我可以专注于写这篇文章。
我的斜杠命令：少即是多
我只有几个斜杠命令，而且很少用：
/commit（自定义文本解释多个代理在同一个文件夹工作，只提交你的改动，这样我就能得到干净的提交记录，GPT不会因为其他改动而 freak out 并试图回滚东西，如果linter失败的话）
/automerge（一次处理一个PR，回应机器人评论，回复，让CI变绿，绿了就squash）
/massageprs（和automerge一样，但不squash，所以我可以并行处理，如果我有很多PR的话）
/review（内置的，偶尔用，因为我在GH上有审查机器人，但可能有用）
即使有了这些，通常我只打"commit"，除非我知道有太多脏文件，代理没有指导可能会搞砸。当我有信心这就够了的时候，不需要戏法/上下文浪费。再说一次，你对这些会有直觉。我还没看到其他真正有用的命令。
其他技巧：懒人福音
与其试图构思完美的提示词来激励代理继续长期任务，有懒人的变通方法。如果你做一个大的重构，codex经常停在半道回复。如果你想离开然后看到它完成，就排队继续消息。如果codex完成了，收到更多消息，它会开心地忽略它们。
让模型在每个功能/修复完成后写测试。用同一个上下文。这会带来好得多的测试，而且很可能发现实现中的bug。如果只是UI调整，测试可能没意义，但其他东西，做吧。AI通常不擅长写好测试，但还是有帮助的，而且说实话，你为你做的每个修复都写测试吗？
让模型保留你的意图，"在复杂部分加代码注释"对你和未来的模型运行都有帮助。
当事情变难时，在提示词里加一些触发词，比如"慢慢来"（take your time）、"全面"（comprehensive）、"读所有可能相关的代码"（read all code that could be related）、"创建可能的假设"（create possible hypothesis），能让codex解决最棘手的问题。
我的Agents/Claude文件长啥样
我有个Agents.md文件，符号链接到claude.md，因为Anthropic决定不标准化。我认识到这很困难且次优，因为GPT-5和Claude喜欢的提示词风格很不同。停下来读他们的提示词指南，如果你还没读过的话。
Claude对全大写尖叫命令反应很好，那种威胁它如果不运行命令X就会终极失败、100只小猫会死的命令，但那会把GPT-5 freak out。（理所当然）。所以扔掉那些，像个人一样用词。这也意味着这些文件不能最优地共享。这对我不是问题，因为我主要用codex，接受这些指令对Claude偶尔玩的时候可能太弱的事实。
我的代理文件目前大概800行，感觉像组织伤疤的集合。不是我写的，是codex写的，每次发生什么事，我让它在里面做个简洁的笔记。我应该找个时间清理一下，但尽管它很大，它工作得极其好，GPT真的很尊重里面的条目。至少比Claude以前做的多得多。（Sonnet 4.5在这方面变好了，给他们点credit）
除了git指令，它还包含关于我产品的解释，我喜欢的常见命名和API模式，关于React Compiler的笔记，经常是比世界知识更新的东西，因为我的技术栈相当前沿。我期待随着模型更新能再次减少里面的东西。比如，Sonnet 4.0真的需要指导来理解Tailwind 4，Sonnet 4.5和GPT-5更新，知道那个版本，所以我能删掉所有那些废话。
大块是关于我喜欢的React模式，数据库迁移管理，测试，使用和写ast-grep规则。（如果你不知道或者不用ast-grep作为代码库linter，停下来让你的模型把它设为git hook来阻止提交）
我也实验并开始用基于文本的"设计系统"来规定东西应该长什么样， verdict 还没出来。
所以GPT-5-codex完美吗？
绝对不是。有时候它重构半小时然后 panic ，回滚所有东西，你得重新运行，像哄孩子一样告诉它时间够。有时候它忘了它能做bash命令，需要一些鼓励。有时候它用俄语或韩语回复。有时候怪物滑倒，把原始思考发给bash。但总的来说这些很罕见，它在几乎所有其他方面都 insanely 好，我能忽视这些缺陷。人类也不完美。
我对codex最大的烦恼是它"丢失"行，所以快速滚动会让部分文字消失。我真的希望这在OpenAI的bug列表顶部，因为这是我有时不得不慢下来的主要原因，这样消息就不会消失。
结论：直接跟它说话
别把时间浪费在RAG、子代理、Agents 2.0或其他主要是戏法的东西上。直接跟它说话。跟它玩。培养直觉。你跟代理工作得越多，结果就越好。
西蒙·威利森（Simon Willison）的文章讲得很棒，管理代理所需的很多技能跟管理工程师所需的类似，几乎所有这些都是资深软件工程师的特征。
而且，没错，写好软件依然很难。仅仅因为我不写代码了，不代表我不在架构、系统设计、依赖、功能或如何让用户开心上 hard thinking 。用AI只是意味着对交付的期望提高了。
PS：这篇文章是100%有机手工写的。我爱AI，我也认识到有些东西还是用老方法更好。保留错别字，保留我的声音。✌️
PPS：头图的credit给Thorsten Ball。
关于作者彼得·斯坦伯格（Peter Steinberger）
Moltbot(原Clawdbot)作者彼得·斯坦伯格（Peter Steinberger）是个老牌的独立开发者和创业者，在iOS和Mac开发圈子里挺有名。他以前搞过PDF Viewer（一个PDF阅读器应用），还做过PSPDFKit（一个PDF处理的SDK），被很多大公司用。这家伙是个技术极客，特别喜欢折腾新工具，而且敢说实话，不随大流。这篇文章就是他一贯的 style：直接、实用、带点叛逆。他不属于任何大公司，自己单干，所以说话没包袱，好就是好，烂就是烂。
本文独特性评价
这篇文章的独特之处在于它的"反潮流"勇气。现在AI编程圈子都在吹"代理编排"（agent orchestration）、"子代理"（subagents）、MCP（模型上下文协议）这些高大上的概念，好像不用这些就落伍了。但彼得站出来说：兄弟们，这些都是花架子，直接跟AI说话最管用。他用自己30万行代码项目的实战经验，证明了简单方法比复杂工具更有效。
另一个独特之处是他的"并行代理"工作流。大多数人用一个AI对话窗口，他同时开3到8个窗口，像指挥一个乐队一样让AI们协同工作。这种"多线程"编程方式很少见，而且他强调让AI自己提交代码、自己管理git，这在当前的AI编程实践中算是比较激进的。
还有他对Claude Code的批评。Claude Code是Anthropic的旗舰产品，很多开发者捧为神器，但彼得毫不留情地指出它的缺点：说话方式烦人、上下文短、token效率低、终端闪烁。这种 candid 的批评在技术博客里很少见，大部分人都怕被社区喷。
最后，他提出的"爆炸半径"（blast radius）概念很实用，把软件工程的风险管理直觉化，让AI编程有了可操作的评估标准。整篇文章没有理论堆砌，全是血泪经验，这种"街头智慧"（street smarts）在充斥着营销话术的AI圈子里尤其珍贵。
总之：
彼得·斯坦伯格分享了用GPT-5-codex同时操控8个AI代理写代码的实战经验，痛批复杂工具链是脱裤子放屁，主张直接对话培养直觉，一人扛起30万行代码项目的反潮流工作流全解析。