How to code with AI agents - Advice from OpenClaw creator | Peter Steinberger and Lex Fridman

How to code with AI agents - Advice from OpenClaw creator | Peter Steinberger and Lex Fridman

如何使用 AI 智能体编程 - OpenClaw 创始人的建议 | Peter Steinberger 对谈 Lex Fridman

Lex Clips21 位订阅者

35 分钟阅读Podcasts

【实战进阶】OpenClaw 创始人对话 Lex Fridman:如何与 AI Agent 协同编程? 当编程从“打字”转向“调教”,开发者该如何适应?OpenClaw 创始人 Peter Steinberger 分享了与 AI 代理协作的深度技巧。视频探讨了如何构建稳健的反馈环,以及为什么理解底层的系统架构比掌握具体的语法细节在 Agent 时代更为重要。 🎙️ 访谈人物介绍 Peter Steinberger:OpenClaw/ClawdBot 创建者,资深开发者。他致力于通过 AI Agent 消除软件工程中的重复性劳动。 Lex Fridman:MIT AI 研究员,全球顶级技术播客主持人。 核心议题:AI Agent 的编排逻辑、Vibe Coding 实战心法、从代码实现者到架构决策者的转型、AI 开发的信任边界。 关键词:OpenClaw、AI Agent、Lex Fridman、编程范式、Peter Steinberger

章节 1:开发环境的演进与“Agentic”曲线

📝 本节摘要:

本节中,Peter Steinberger 分享了他从依赖 IDE(集成开发环境)转向以终端(Terminal)为核心的工作流演变过程。他指出,随着对 AI 工具的熟练掌握,程序员不再需要逐行阅读“无聊的代码”,因为大部分软件本质只是数据的搬运。对话重点讨论了“Agentic Programming(代理编程)”的复杂度曲线:从初学者的简单提示词,到中级阶段过度复杂的“代理陷阱”(Agentic Trap,即试图通过复杂的编排自动化一切),最后回归到“Zen(禅)”状态的极简提示词。此外,Peter 幽默地将严谨的“Agentic Engineering(代理工程)”与随意的“Vibe Coding(氛围编程)”区分开来,后者往往带来次日的“悔恨”。

[原文] [Lex Fridman]: you've been uh documenting the evolution of your uh dev workflow over the past few months there's a really good blog post on August 25th and October 14th and the recent one December 28th i recommend everybody go read them they have a lot of different information in them but sprinkled throughout is the evolution of your dev workflow so I was wondering if you could speak to that

[译文] [Lex Fridman]: 你在过去几个月里一直在记录你开发工作流的演变,在8月25日、10月14日以及最近的12月28日都有很棒的博客文章。我推荐大家都去读一读,里面包含了很多不同的信息,但贯穿其中的是你开发工作流的进化,所以我想知道你能不能谈谈这一点。

[原文] [Peter Steinberger]: i started my my first touch point was cloud code like in April it was not great but it was good and this whole paradigm shift that suddenly work in the terminal was very refreshing and different um but I still needed the IDE quite a bit because it's just not good enough and then I experimented a lot with cursor um that was good i didn't really like the fact that it was so hard to have multiple versions of it so eventually I I I went back to cloud code as my my main driver and that got better and yeah at some point I had like seven subscriptions like was burning through one per day because I was I got I really comfortable at running multiple windows side by side all CLI all terminal,

[译文] [Peter Steinberger]: 我刚开始……我的第一个接触点是大概四月份时候的 Cloud Code(云代码),那时候它还不算太好,但也还行。这种突然在终端(Terminal)里工作的范式转变非常令人耳目一新且与众不同,但我当时还是很需要 IDE(集成开发环境),因为工具还不够好。之后我试了很多次 Cursor,它很不错,但我不太喜欢它很难保留多个版本这一点,所以最终我又回到了以 Cloud Code 为主力驱动,它后来也变好了。是的,在某个时间点我有大概七个订阅,每天就能用完一个,因为我已经非常习惯并行运行多个窗口,全都是 CLI(命令行界面),全都是终端操作。

[原文] [Lex Fridman]: so like what how much were you using ID at this point

[译文] [Lex Fridman]: 那么在这个阶段,你使用 IDE 的频率是多少?

[原文] [Peter Steinberger]: um very very rarely mostly a diff viewer to actually like I got more and more comfortable that I don't have to read all the code i know I have one blog post where I say I don't read the code but if you read it more closely I mean I don't read the boring parts of code because if you if you look at it most software is really just like data comes in it's moved from one shape to another shape maybe you store it in a database maybe I get it out again I'll show it to the user the browser does some processing or native app some data goes in goes up again and does the same dance in reverse we're just we're just shifting data from one form to another and that's not very exciting or the whole how is my button aligned in Tailwind i don't need to read that code other parts that maybe something that touches the database um yeah I have to do I have to read and review that code

[译文] [Peter Steinberger]: 嗯,非常非常少,主要是作为一个差异查看器(Diff Viewer)。实际上我越来越适应不再必须阅读所有代码。我知道我有一篇博文说“我不读代码”,但如果你仔细读那篇文章,我的意思是“我不读代码中无聊的部分”。因为如果你仔细看,大多数软件真的只是:数据进来,从一种形状移动变成另一种形状,也许存进数据库,也许我又把它取出来展示给用户;浏览器做些处理,或者原生应用里数据进来又上去,反向做同样的动作。我们只是在把数据从一种形式转换成另一种形式,这并不怎么令人兴奋。或者是像“我的按钮在 Tailwind 里是怎么对齐的”这种,我不需要读那部分代码。至于其他部分,比如涉及数据库操作的,嗯,是的,我必须做,我必须阅读并审查那部分代码。

[原文] [Lex Fridman]: can you actually there's in one of your blog post uh the just talk to it the no BS way of agentic engineering you have this graphic the curve of agentic programming on the x- axis is time on the y-axis is complexity uh there's the please fix this where you prompt a short prompt on the left and in the middle there's super complicated eight agents complex orchestration with uh multi-checkouts chaining agents together custom subation workflows library of 18 different slash commands large full stack features you're super organized you're super complicated sophisticated software engineer you got everything organized and then the elite level is uh over time you arrive at the zen place of once again short prompts hey look at these files and then do these changes i actually call it the agentic trap you I saw this in a in a lot of people that have their first touch point and maybe start vibe coding i actually think vibe coding is a slur you prefer agentic engineering

[译文] [Lex Fridman]: 你能具体谈谈吗?在你的一篇博文中,关于“直接跟它对话:Agentic Engineering(代理工程)的无废话指南”,你放了一张图表,展示了“Agentic Programming(代理编程)”的曲线。X轴是时间,Y轴是复杂度。最左边是“请修复这个”,你输入一个简短的提示词;中间是非常复杂的八个智能体(Agents),复杂的编排,包含多重检出(Multi-checkouts)、智能体链式协作、自定义子任务工作流、18种不同的斜杠命令库、大型全栈功能——你非常有条理,你是个极其复杂且老练的软件工程师,你把一切都组织好了;然后精英级别是,随着时间推移,你到达了一个“禅(Zen)”的境界,再次回归到简短的提示词:“嘿,看看这些文件,然后做这些修改”。其实我把中间那个叫“Agentic Trap(代理陷阱)”。我在很多人身上看到了这一点,他们刚开始接触,可能开始搞“Vibe Coding(氛围编程)”。我其实觉得“Vibe Coding”是个贬义词,你更倾向于“Agentic Engineering(代理工程)”?

[原文] [Peter Steinberger]: yeah i always tell people I I do agentic engineering and then maybe after 3:00 a.m i switch to vibe coding and then I have regrets on the next day,

[译文] [Peter Steinberger]: 是的,我总是告诉人们,我做的是“Agentic Engineering(代理工程)”,然后也许凌晨3点以后,我会切换到“Vibe Coding(氛围编程)”,然后第二天我就后悔了。

[原文] [Lex Fridman]: yeah well a walk of shame you just have to clean up and like fix your shit we've all been there

[译文] [Lex Fridman]: 是啊,那简直是“羞耻之行(Walk of Shame)”,你不得不去清理并修好你搞的一团糟,我们都经历过。

  1. 章节 2:像乐器一样掌握AI:告别“氛围编程”
  2. 章节 3:像技术主管一样思考:与Agent的协作心态
  3. 章节 4:激进的工作流:语音交互与主干开发
  4. 章节 5:核心竞争力:对AI的共情与人类直觉
  5. 章节 6:赋予机器灵魂:`soul.md`与哲学思考

正在加载后续章节…