Clawd的创造者：“我只管写代码，不负责读代码”

这就是 WorkOS 推出 MCP Auth 的原因，它让团队能够为 AI 代理提供具有明确权限、可审计性和企业级安全性的身份验证方式。

That's why WorkOS introduced MCP Auth, which gives teams a way to authenticate AI agents with explicit permissions, auditability, and enterprise grade security.

你不需要共享范围受限的 API 密钥，而是可以明确定义代理可以访问的数据范围以及可以执行的操作。

Instead of sharing over scoped API keys, you can define clear boundaries for the data that agents can access and the agents they can perform.

如果你正在构建 AI 驱动的功能，并希望在不牺牲安全性的前提下快速迭代，请访问 workerwas.com/mcp。

If you're building AI powered features and want to shift fast without compromising security, check out workerwas.com/mcp.

好了，让我们继续回到彼得和企业定价的话题。

And with this, let's get back to Peter and enterprise pricing.

但这也是在这种模式下唯一真正有效的方法。

But that's also the only thing that that really works on on on a model like this.

是的。

Yeah.

你指的是企业销售，没错。

You mean enterprise sales specifically, Yeah.

也就是定制化定价。

Meaning custom pricing.

所以，你能告诉那些访问供应商网站、看到‘请联系我们’或‘预约会议’而没有明确标价而感到沮丧的开发者们，这是为什么吗？

So so can you tell us for for for you know devs listening who go to

哦，这就是原因，因为我们得评估你们公司的情况，然后大致估算一个你们可能愿意支付的价格。

a vendor's website and they're frustrated that there's no price that says call us or schedule a meeting, why that is?

这听起来很糟糕，但当你有一个产品无法简单用一个具体数字来定价时——比如自由职业者联系我们和财富500强企业联系我们，情况是完全不同的。

Oh, that's that's why because we're look at your company and then just take the dice and and and think about a number that you're probably willing to pay.

而且当产品无法简化为一个具体数字时——比如自由职业者联系我们和财富500强企业联系我们，情况确实会有很大差异。

And that sounds horrible, but also when you have a product where you can't really tear it down to a specific number, like it it's It makes a difference if a freelancer contacts us or one of the big Fortune five hundreds.

我们就不提名字了。

Let's not say names.

是的。

Yeah.

因为使用情况会不同，他们从中获得的价值也会不同，如果收费相同，就会排除其中一方。

Because the usage will be different, the value they get out of it will be different, and charging the same, you would either exclude one or the other.

如果我价格定得太低，他们会觉得这很可疑。

If I if I if I go too low, they're gonna see this fishy.

对于500美元的采购，我们根本不会启动这个流程。

It's like procurement for like $500, we're not gonna even start the process.

如果我们定价太高，就会失去这部分用户。

And if we target it too high, we're gonna lose those people.

所以，尽管这个过程听起来很糟糕且不公平，但对于某些类型的产品来说，这终究是最公平的方式。

So so as horrible and unfair this process seems, for some kind of products it is the it's the most fair way after all.

你知道，在软件领域，我认为有四个维度。

You know you know on software, there is I would say there's like four axes.

一个是容易和困难，另一个是有趣和无趣。

There's like easy and hard, and interesting and not interesting.

我们当时正处于无趣且困难的那部分。

We were very much in the not interesting and hard part.

如果你开发的东西是每个开发者都想做的，那会很难卖出去。

If you build something that every developer wants to build, it's gonna be a hard sell.

不管怎样，这都很难推销。

It's it's a hard sell anyhow.

是的

Yeah.

向开发者销售任何东西都很困难。

Selling anything to developers is a hard sell.

是的

Yeah.

但如果太简单或太有趣，那就祝你好运了。

But if it's if it's too easy or too interesting, good luck.

但如果它让你觉得天啊，我真不想做这个，而且天啊，这太难了，那反而是个好位置。

But if it's, oh god, I don't wanna do this, and oh my god, this is hard, that's a good spot to be in.

所以我找到了一个非常有趣的细分领域，那里有无数复杂的难题。

So so I found a really interesting niche and there were just an infinite number of complex problems.

你得告诉我解析PDF一两个困难的地方。

You need to tell me tell me one or two hard things about parsing PDF.

能有多难？

How hard could it be?

是的。

Yeah.

如果有规范，我是个工程师，我懂规范，这有什么难的

If there's a specification, I'm an engineer, I know specifications, I what's so hard about

我的意思是，有一个例子，你知道，PDF里有链接。

I mean, there was this one example where, you know, like PDFs, they have links.

比如有个目录，你点击一下，它就会跳到第37页。

Like there's like there's like a table of contents and you click on it and it goes to like page 37.

所以我构建了整个模型，假设嗯，可能里面就一百个或者几百个链接。

So I built this whole model with the assumption, oh, yeah, maybe there's like a 100 or a few 100 links in there.

然后我们有个客户付了很高的费用，结果他们说，哦，加载这个PDF要四分钟。

And then we got this one customer who like paid really good money and then they said it was like, oh, it takes four minutes to load the PDF.

天哪，这是怎么回事？

What the heck, guys?

我一看，原来是一本来自加拿大的五万页文本版《圣经》。

And I looked at it and it was like a 50,000 page text bible from Canada.

而且它有

And it had like

2000页。

2,000 pages.

每页有超过100个链接。

It had like more than 100 links per page.

五十万个链接？

500,000 links?

我的数据模型完全崩溃了，因为我的假设偏差了整整一千倍？

My data model completely exploded because my assumptions were off by a number of what, 1,000?

但到那时，你已经有了一个成熟的、带API的产品。

But by then you have like a mature product with an API.

那么，你该如何在不破坏所有人使用体验的情况下，彻底重构内部架构？

So like, how do you how do you completely redesign the internal part without breaking things for everyone?

突然间，所有东西都必须变成懒加载了——以前解析101个链接很容易，但现在要让系统继续正常运行，变得异常困难。

Like suddenly everything has to be lazy where where before parsing 101 was easy, but now they were like, this was like so difficult to keep it working for people.

我觉得我花了整整两个月的时间来彻底重设计内部架构，确保对用户来说依然简单易用。

I think I spent like two months just on that completely redesigning like the internals and like making sure it's still easy for people.

他们不需要知道我们哪些内容是立即加载的，哪些是懒加载的，但当你复制这个东西时，它仍然必须保持某些连接。

They don't have to know what we what we load easy, what we load lazy, or if you copy the thing it it still has to like have to keep some connection.

它需要保持引用，是的。

It needs to keep the references Yeah.

而且这些事情中的一些。

And and some of those things.

我真的很喜欢做支持工作。

So I I I I I I love to do support.

我认为这正是公司能够成功的一个关键因素。

And I think that that that was a confining factor why the company worked.

因为如果你提交了一个工单，然后首席执行官亲自回复并帮助你，这会产生很大的影响。

Because if if you send a ticket and then the the the CEO replies and helps you out, that has impact.

我的策略一直都是反向排序，因为如果你提交了一个工单，五分钟内就收到回复，那简直太神奇了。

And my my strategy was always like, I always used to list in reverse, because if you if you send a ticket and you get a reply within five minutes, that's magical.

如果你等一两天，差别不大。

If you wait one or two days, not much difference.

是的。

Yeah.

所以，没错，这正是我遇到的一个问题，我花了两个月时间，终于把它优化到了几乎这样。

So yeah, and this this was one of the problems where I worked two months and I finally got it down to almost like this.

嗯。

Mhmm.

那

That

一定很

must have

令人满足。

been satisfying.

而且确实非常令人满足。

And and it was it was very satisfying.

而且你写了大量的代码，或者参与了很多代码的工作。

And you were writing a lot of the code or you were involved in in in a bunch of the code.

比如，虽然现在团队规模很大，但你仍然在某种程度上 overseeing（监督）着它。

Like, obviously, big big team was now here, but you were still kind of overseeing it.

对吧？

Right?

或者深入细节。

Or in the details.

我的意思是，我当然有一支非常棒的团队，有些部分我参与得更多。

I mean, of course, I had a really great team and and some parts I was more involved.

我始终更专注于移动端，因为那是我的热情所在，但我一直深度参与技术工作。

I was always more involved in mobile because that's where my my heart was, but I was always very deep in the tech.

至于营销和业务方面，我有乔纳森的帮助，也有马丁的帮助。

And and the marketing side, the business side, I had like Jonathan's help, I had Martin's help.

这些方面，我找到了合适的人。

Those I I I found good people.

关键是，如果你喜欢写博客，分享你是如何解决有趣而困难的问题的，这会吸引那些也想解决有趣问题的人才。

The the thing is if you like the blogging and writing about how you solve interesting hard problems will help you hire interesting people that wanna solve interesting problems.

我记得在PSPDFKit的时候，你的博客时不时会上Hacker News，读起来非常有趣。虽然我不太懂PDF，但如果让我提到PDF，我第一个想到的就是PSPDF，因为只有你们写过这么有意思的技术博客，讲你们是怎么优化和发布产品的——而且到现在还在呢。

This is what I remember at PSPDFKid that your blog was every now and then it made it to hacker news as well, but it was just interesting to read and I couldn't name, again, I'm not one into PDFs, but if I had to say something like PDF I would've said PSPDF because they're the only ones where I read interesting entering blogs about how you optimise or ship it's still there by the way.

我自己有时候也会想，是不是很多公司都没意识到这一点？或者问题在于，你必须是个既是CEO、又热爱写博客的开发者？顺便问一下，你写这些文章时，是想着能帮到别人，还是纯粹因为自己从中获益，比如通过分享解决了某个难题？

I myself also sometimes ask myself like, interesting, do more companies not see this or is the question that you need to be a developer who's either the CEO or up there who just likes doing this and by the way, did you ever write this thinking this will be helpful or you just wrote because you got something out of it, like putting out that you solved this hard problem?

我喜欢分享，也喜欢激励别人。

I like sharing and and and like inspiring people.

有时候甚至会有争议，比如我们会不会该写这个？

There was sometimes even conflicts where we were like, should we write about this?

因为这有点像是我们的独家秘方。

Because it's like a little bit of secret sauce.

但我从来不太在意这些声音。

But I just never listened to those voices too much.

而且当你把东西写下来的时候，就体现了这样一个原则：你觉得自己懂了，但如果你想教别人，你就必须真正彻底地理解它。

I just And then there's also like when you when you write something down, this is this principle of like, you understand it, but then if you wanna teach it, you really have to understand it.

所以对我来说，这就像，哦，是的，我确实花了很大力气解决这个难题，现在我想把它保留下来，帮助别人。

So to to me it was also a little bit like, oh yeah, worked on this really hard problem, and now I wanna like preserve it and like help others.

所以我从中获得了不少收获。

So so so I I got I got a gig of it.

当然，我也喜欢这种关注，但真正重要的是，有时候我会在一年后回头参考自己的文章，心想：是的，这既是公司文档，也是我的个人笔记，它在很多方面都很有帮助。

Of course of course I liked the attention, but really it it was this sometimes I just referenced a year later to my own post, it's like, yeah, this this is a This is both company documentation, this is like my own logbook, it's helpful in so many ways.

很多大公司呢，他们流程太繁琐了，很多开发者其实并不喜欢写作。

And a lot of those bigger companies, oh, they put on too much red tape, there's a lot of developers who don't really like to write.

所以我曾经强制要求每个人每月抽出一整天时间写一篇博客文章。

So I I I forced everyone once a month, a full day just to write a blog post.

但你

But you

给了他们时间。

gave them the time.

你意思是，那天你不用

You're like, that day you don't

不需要做任何其他工作，只管写点东西。

need to do any of work, but write something.

是的。

Yeah.

你确实有。

Have yeah.

你有一天时间来写出一篇帖子。

You have a day to come up with a post.

一天其实挺多的。

A day is is quite much actually.

我的意思是，现在我只想写帖子，仍然需要好几个小时。

I mean, when I'm now I just wanna write posts, it still takes me a few hours.

我不想过多关注公司初期的启动时间，我觉得成长阶段才最有趣。

I don't wanna dwell too much on like the I think the the starting time of the company is the most interesting, the growth phase.

你遇到的官僚程序更多了，人也更多了，这时更像是在精心培育产品，而不是做疯狂的快速原型，而是更渐进式的迭代。

You get more red tape, you get more people, it's much more gardening your product instead of like doing doing wild hacks, and more iterative.

所以这些年它变得没那么有趣了，还出现了更多的人际纠纷。

So so so it got a little bit less interesting over the years, and there was like more people drama.

因为人越多，问题就越多。

Because the more so the more people you have, the more issues there are.

我并不太享受这个过程，而且真的非常疲惫。

And I didn't enjoy it that much, and I was really really burned out.

你觉得是什么让你精疲力尽？

What what burnt you out, do you think?

我只是 burn out 太厉害了。

I was just burning too hard.

我大多数周末都在工作，还试图处理所有管理上的事务。

I was working most weekends, I I I tried to shuffle all my managerial needs.

作为CEO，你本质上就是个垃圾桶。

And you know as a CEO you're basically the waste bin.

因为其他人处理不了、做不好或搞砸的事情，都得你来收拾。

Because everything everything that other people don't manage or or can do or or mess up, you have to fix.

而且这也很孤独，因为你不能公开谈论很多事。

And it's also quite lonely because you you can't openly talk about a lot of things.

我的意思是，我特意把公司打造得相当开放。

I mean I I I I structured the company to be quite open.

但即便如此，你也不能表现消极。

But still, like you cannot you cannot be negative.

即使真的发生了很糟糕的事情，你也必须保持积极。

You have to even if even if like even if like really bad stuff happens.

我记得有一个周末，我的联合创始人凌晨五点给我打电话，说有个大型飞机公司，因为我们的软件崩溃，他们的飞机全都停飞了。

I know there was like there was like one weekend where my my co founder called me at at 5AM and told me like, yeah, there's this big airplane company and their planes are down because our software is crashing.

那真是个特别的周末。

That was a very interesting weekend.

直到我拆解了他们的应用，证明他们篡改了我们的源代码，触发了许可证密钥的回退机制，最终导致他们损失惨重。

Until I could like I disassembled their their app and did prove that they messed around with our source code to triggering a a a license key fallback that eventually like cost you shit they had.

但那确实是一个关乎公司生死的时刻。

But that was like a if this was, company's gone, and more moment.

所有这些额外的压力叠加在一起，还有不少类似的情况。

And that's just on top to all the additional stress, and there were quite a few of those things.

你可以这样坚持一段时间。

You can do that for a while.

我也相信，倦怠并不一定源于工作太多。

And I I also believe like, burnout doesn't necessarily come from working too much.

它更多来自于——至少对我而言——当你在做一件事，却不再相信它，或者你面临太多冲突，而我们团队内部也确实经常发生争执。

It it comes more from Or at least for me, when you when you work on something, but you don't believe in it anymore, or you have like too many conflicts, and and we also had we did fight a lot in the team.

那是在管理团队层面。

It was like management team.

当我犯下这个错误，以为必须更民主地领导公司时，这也让我感到精疲力尽。

And by the time I I made this mistake and I thought you have to like lead a company more democratically, so that was also something that burned me out.

不过，我绝不会用任何东西来换这段经历。

I wouldn't I wouldn't wanna miss it for the world though.

是的。

Yeah.

所以，从外部来看，你卖掉了股份，赚了足够的钱，即使不再工作也能生活，对很多刚开始创业或未来想创业的人来说，这听起来简直是梦想——我们知道现实中大多数人无法成功，但如果你成功了，那就相当于完成了所有目标，就像爬墙时敲响了钟，一切就结束了。

So, you know, from from the outside, it seems you sold your shares, you made enough money to not have to work again should you not choose, and for a lot of people like, you know, people who are starting out their business or one day want to start a business, this sounds like the absolute dream, like this is, I guess, what we know realistically that most people will not make it, but if you make it, I mean, you've kind of, like, I guess, checkbox done, you're kind of it's a little bit if you're climbing on a wall and you ring the bell, you're done.

然后，我注意到，从外部来看，你的博客在好几年里完全停止更新了。

And then, what I noticed is from the outside again on your blog, the blog post completely stopped for several years.

在这段时间里你做了什么？学到了什么？在回到我们现在这个状态之前？

What did you do in this time and what did you learn in this time, you know, before you came back to where we are now?

我需要很多时间来放松。

I needed a lot of time to decompress.

我补上了很多我觉得错过的事务。

I catched up a lot on things I thought I missed.

我参加了大量的派对。

I I partied a lot.

有好几个月我甚至都没打开过电脑。

There were months where I didn't even turn on my computer.

有一段时间，我完全不知道接下来该做什么。

And for a while there was I just didn't have this feeling of like, what should I do now?

我当时真的在想，何必呢？

Like like I definitely was like, why bother?

你知道，你不该这么早就退休，也不该有这么好的退出结果，以至于再也不用工作了，这让我心里很混乱。

You know, you're not you're not supposed to to retire so early, or like have so much have such a good exit that you never have to work again, that messes my mind quite a bit.

那几年真的很难熬。

That was some that was some hard years.

然后在四月的时候，我想起了几年前的一个想法，还有一个我刚开始的副项目，于是我心想，对啊，我想继续做下去。

And then in in April I was like, I There was this idea that I had years ago and even a side project that I started, I was like, oh yeah, I wanna I wanna continue on that.

过了三年多，我重新坐回电脑前，再次开始编程。

And then after after after more than three years I just sat back at my computer and started hacking again.

但问题是，这个项目原本是个推特分析工具，用的是Swift和SwiftUI，而那时我就知道，如果把它做成网站，效果会好得多。

But the thing was, this was like a Twitter analytics thing and it was written in in Swift and SwiftUI and back then I already knew this would've would be so much better if I would build as a website.

所以，这是你一直藏在心里的一个想法吗？关于推特分析的那个？

So so was this an existing idea that you kind of had at the back of your your mind something something Twitter analytic?

是的。

Yeah.

这只是一个我想为自己打造的东西。

It was just like something I wanted to build for myself.

是的。

Yeah.

因为当时根本不存在，甚至三年后还是不存在。

Because because it didn't exist, and then even three years later it didn't exist.

它现在依然不存在。

It still doesn't exist.

严格来说它有点存在了，但我有点跑偏了。

It it it kinda does, but I got a bit sidetracked.

所以我回去重新开始，想用网页技术来构建它。

So I I went back and I I wanted to build it in in this web tech.

但网页开发一直都是我最不关注的领域，即使在公司里，因为我请了一位非常聪明的人来负责这块，就是马丁。

But Web was really was always even at the company the one thing that I looked into the least, because I had I had someone really smart who took care of that side in the company that I brought in, Martin.

所以我从来不需要操心这个。

So I never had to worry about it.

那是其中之一

That was one of the

你并不亲自参与 React 或者那一侧的开发。

You're not hands on with React or any of that side.

是的。

Yeah.

当我回来时，我就想，什么是 prop？

And when I came back I was like, what's a prop?

你知道，就是那种级别的东西，而且你知道，这是我看到很多开发者掉进的陷阱。

You know, that that level where you really And you know this is like, this is a trap I see with many developers.

你在一个技术上越精通，就越难跳到其他技术上。

The better you get at one technology, the harder it is to jump somewhere else.

并不是说你做不到，而是过程太痛苦了。

It's not that you can do it, but it hurts so much.

你会想，我可以在苹果的技术栈里闭着眼睛编程，但在这个新栈里，我却得去查最基础的东西，这感觉真的太难受了？

You're like, like I can I can program in Apple's tech, can program blind, but then in that stack I have to Google the most mundane stuff and it just like, it just hurts?

你又觉得自己像个傻瓜。

You feel like an idiot again.

是的，我觉得经验越多，这种感觉就越糟糕，我知道你总说要拥抱变化之类的，但说实话，这真不怎么样。

Yeah, and I guess the more experience you have, it kind of sucks feeling, I mean I'm sure you say embrace and all that, but it's not great.

你没那么高效了，你知道自己本可以更快，等等。

You're not as efficient, you know that you could be faster, etcetera.

是的。

Yeah.

所以我回来后就想，天啊，一定有什么东西，这AI到底是什么？

So I came back and I was like, gosh, there has to be there has to be What is this AI?

这个被人们忽视的AI到底是什么东西？

What is this AI stuff that people are dismissing?

我们来了解一下吧。

Let's look into this.

四月份的时候，我们很多人都在忽视它。

And in April a lot of us were dismissing it.

可能是对的，但是而且

Probably rightfully so, but And

我呢，我确实要承认，在那三年里我基本没碰过电脑，因为那段时间你们已经试过AI，发现它其实一无是处。

I and I like give And I To a degree, I I credit those three years where I basically didn't turn on my computer because in those years you guys checked out AI and learned that it's crap.

是的。

Yeah.

那些人，就像我刚才说的，你错过了GitHub Copilot的早期版本，那不过是高级自动补全工具，可能是GPC3，甚至可能还没到，然后当然有GPT-3.5，那是个巨大的飞跃，它的表现甚至比GPT-4还好，所以当你回来的时候，你最先用的是什么工具？

The the people who, like, as I was to say, so you missed out on, you didn't do the beta of GitHub Copilot, glorified autocomplete, is GPC three or maybe not even, there was then of course 3.5 which is a big jump and it got Inkranzy better than GPT four, and so by the time you came back, what tool did you first use?

因为你错过了开发者们过去两年对AI的试用、质疑和发现一些小众应用场景的过程。

When you because you missed out on like two years of like devs Us devs using, dismissing, finding some niche use cases for it.

哦，Cloud Code。

Oh, Cloud Code.

那你一开始用的是Cloud Code？

So you started with Cloud Code?

那就是在说

That that's It talking about

五月份才发布，但之前已经有测试版了。

out of May, but there was a beta beforehand.

是的。

Yeah.

对。

Yeah.

好。

Yeah.

我觉得他们二月份就已经有东西了吧？

I I think they had something didn't they have something in February already?

他们二月份就有了测试版。

They had a beta from February.

没错。

Correct.

是的。

Yeah.

所以，Clockcode 是你经历一段时间停顿后回归的第一个项目，你一回来就立刻投入了 Clockcode，其他所有事情都抛在脑后了。

So so So Clockcode was your first you you you come back after, like, you know, hiatus and you immediately turned on Clockcode and you missed everything else before.

你知道，我记得我接手了一个非常混乱的副项目，我开发了一个浏览器扩展，可以把一个 Git 仓库转换成一个巨大的 Markdown 文件。

And you you know it was like I I remember I took this big messy side project that I built, and I have this browser extension where that that converts a git repository into one big markdown.

那个 Markdown 文件有 1.3 兆字节大，我把它拖进了 Google 的 AI 工作室，用了 Gemini 2.5 或者类似的版本，然后输入了‘帮我写一份规格说明’。

There was like a 1.3 megabyte markdown file, and I dragged it into into Google's AI studio with Gemini 2.5 or two to something, and I typed write me a spec.

它生成了 400 行的规格说明，我又把这个文件拖回了 Cloud Code，然后说：‘构建吧。’

And it generated those 400 lines of spec, and I dragged this back into Cloud Code, and I was like, build.

然后我不断点击继续，继续，继续，继续。

And then I continue, continue, continue, continue.

而我当时还在忙别的事情，你知道的。

And while I was like working on other stuff, you know.

最后它告诉我：‘已经 100% 准备好投入生产了。’

And eventually it told me like, it's 100% production ready.

我启动了它，结果它崩溃了。

And I started it and it crashed.

我相信我们都能理解AI说代码已准备好上线，结果却崩溃的故事。

I'm sure we can all relate to the story of the AI saying the code is production ready then crashing.

这是一个有趣又天真的故事，但我个人不会轻易信任AI生成的代码，除非亲自验证过。

This is a pretty funny and innocent story, but I personally don't trust code that AI generates without verifying it.

这自然引出了我们的资深赞助商Sonar。

And this leads us nicely to our seasoned sponsor Sonar.

让我们来看一些数据。

So let's look at some data.

Sonar发布的一项新报告——开发者代码状态调查报告发现，82%的开发者认为使用AI可以更快地编写代码。

A new report from Sonar, the state of code developer survey report, found that 82% of developers believe they can code faster with AI.

但有趣的是。

But here's what's interesting.

在同一项调查中，96%的开发者表示他们并不高度信任AI代码的准确性。

In the same survey, 96% of developers said they do not highly trust the accuracy of AI code.

这一点我也深有同感。

This checks out for me as well.

虽然我用AI代理写代码更快，但我并不完全信任它生成的代码。

While I write the code faster with AI agents, I don't exactly trust the code it produces.

这在代码审查阶段会成为一个严重问题，因为所有这些AI生成的代码都必须经过严格的安全性、可靠性和可维护性验证。

This really becomes a problem at the code review stage where all this AI generated code must be rigorously verified for security, reliability, and maintainability.

SonarQube 正是为解决这一代码验证问题而设计的。

SonarQube is precisely built to solve this code verification issue.

Sonar 在自动化代码分析领域已领先十七年，每天分析高达7500亿行代码。

Sonar has been the leader in the automated code analysis business for over seventeen years, analyzing 750,000,000,000 lines of code daily.

这相当于每秒超过800万行代码。

That's over 8,000,000 lines of code per second.

我实际上早在2013年，也就是十三年前，在微软/Skype工作时就第一次接触到了Sonar，当时已经有一大批团队在使用SonarQube来提升代码质量。

I actually first came across Sonar thirteen years ago in 2013 when I was working at Microsoft slash Skype, and a bunch of teams already used Sonar cube to improve the quality of their code.

从那时起，我就一直很推崇它。

I've been a fan since.

Sonar 提供了一个不可或缺的独立验证层。

Sonar provides an essential and independent verification layer.

它是一个自动化的安全护栏，能够分析所有代码——无论是开发者还是AI代理生成的，确保在代码进入生产环境之前就符合你的质量和安全标准。

It's the automated guardrail that analyzes all code whether it's developer or AI agent generated, ensuring it meets your quality and security standards before it ever reaches production.

要免费开始使用，请访问 sonarsource.com/pragmatic。

To get started for free, head to sonarsource.com/pragmatic.

好了，让我们回到彼得的话题，谈谈为什么AI代理并不能完全被信任。

With this, let's get back to Peter and how AI agents cannot exactly be trusted.

但后来我添加了一个MCP，让它能够使用浏览器。

But then I had then I added added an MCP so it could use the browser.

我觉得当时MCP的演示已经存在了，它又运行了几个小时，然后我看到了一个Twitter登录页面，它确实做了一些事情。

I think a play with MCP was already there, And it looped a few more hours, and then I had a had a Twitter login page, and it it did something.

我的意思是，效果并不好，但它确实做了一些事情。

I mean, was not great, but it did something.

对我来说，这简直是我人生中‘卧槽’般的震撼时刻。

And to me to me this was my holy fuck mind blowing moment.

是的。

Yeah.

这发生在今年四月或五月，是的。

This And this was like in April or May this year, Yeah.

它已经好到足以让我看到潜力，我明白了，没错，这就是未来的发展方向。

It was it was it was just good enough that I could see the potential, and I I understood it's like, yeah, this is this is where it's going.

从那一刻起，我有几个月睡不好觉，而且在

And and from that moment on I I had a few months where I had really trouble sleeping, and I in

我记得有一次在Twitter上，我给你发了私信，我早起是有正当理由的，比如孩子什么的，但当时是早上五点，我给你发了条Twitter消息，你立刻就回复了。

I I remember because once on on Twitter I sent you a direct message, I was up early for valid reasons, know, my kids or something like that, but it was 5AM and I sent you a message on Twitter and you replied immediately.

我当时就想，你怎么这么早就醒了？

And I was like, why are you up?

你说，哦，这很正常，我通常都醒着，我就问，为什么？

And it's like, oh, this is usual, I'm still usually awake and I asked like, why?

你说，哦，我只是在用Clot，真的特别上瘾，我当时说，真的吗？

And you said oh I'm just using clot and it's really really addictive and I was like really?

你说，对，不是开玩笑，真的很好。

And you're like yeah, not joking, it's really good.

我觉得就是这样，你曾经说过或写过类似‘再试一个提示’这样的话，你告诉我是什么让它如此上瘾？

And I think that was the thing, you said something or wrote something like just one more prompt, Like you told me how, like, what made it so addictive?

或者是什么仍然让它如此上瘾？

Or what still makes it so addictive?

哦，这和你去赌场的经济学原理是一样的。

Oh, it's the same economics as as you go to casino.

这就像是我的小型老虎机，你知道，按下触发键，就会叮叮叮叮响，然后你会发现：不对劲。

That's that's it's my little slot machines, you know, press the trigger and it's like, ding ding ding ding and it's like, nope.

你输入提示词时，它有时会输出一堆垃圾，但有时却会做出让你惊掉下巴的东西。

You're typing the prompt and it it was like, and it does it does crap or it does something that actually blows your mind.

就是这种感觉。

And it's this

你说它让你惊掉下巴，但你可是个经验丰富的开发者，要让你感到震惊可没那么容易。

And and you're saying it it blows your mind as like you're a really experienced developer, like it's it's not easy to blow your mind.

对吧？

Right?

就像你见过好代码，你能分辨出垃圾代码、还行的代码、够用的代码，你心里有标准，对吧？

Like you've seen good code, you can differentiate like crap code, decent code, good enough code, you have a bar, right?

这真的很有趣，你知道的。

It's so funny, you know.

在我公司的时候，我曾经 obsess 于每一个细节，每一个空格、每一行换行、每一个命名。

In my company I used to obsess over every detail, every spacing, every new line, the naming.

我花了太多时间在无谓的细节上纠结。

I spent so much time bike shedding.

现在回头想想，我简直想不通。

And in retrospect, I'm like, what the heck?

我为什么要那样做？

Why did I do that?

这有什么意义呢？

Like, what's the point?

客户根本看不到这些内部细节。

The The customer doesn't see the insights.

当然，它必须达到某些标准。

Of of course, like, it has to meet certain certain standards.

它必须能运行，必须快速，应该安全，但我在那些无关紧要的细节上浪费了多少时间啊，

It has to work, it has to be fast, it should be secure, but, like, how much did I bike shit there is like,

太傻了。

stupid though.

你这么说，但你刚才还说人们喜欢PSPDF，因为它最精致、运行得最好。

You say that but then you also just said that people loved PSPDF because it was the most polished, it worked the best.

难道你不觉得，你所说的那种执着、那种琐碎的纠结，实际上是在控制技术债务吗？你知道， obsessing over white spaces 不会让代码变得混乱，我们都知道这不仅仅是空格的问题，你还会关心测试等等。在我看来，PSPDFKit 所展现的，不只是优秀的用户体验，更是一种极佳的代码卫生，而这正是它能实现高性能的原因。

Do you not think that amount of carrying, bike shedding as you call it being obsessed, it sounded like you were keeping tech debt at bay, you know, like being obsessed with white spaces is not gonna be messy and we know it's not just the white spaces, we know you're gonna care about testing and all that, like, it sounds to me that PSPDFKit, you know, like what I see is you were not just building a product that was great UX, but you built something that had a really good hygiene and that's how it could be high performance and all that.

你怎么看？

How do you think about it?

是的，是的，是的，是的，在某种程度上，没错。

Yeah yeah yeah yeah, to a degree, yes.

甚至到现在，我最近的一篇博客文章还坦白了我直接在生产环境提交代码的事。

And and even now like I I I mean like my my last blog post was a confession that I I shipcoded on the read.

是的。

Yeah.

我们得谈谈这个。

We have to talk about that.

同时，我花了大量时间进行重构。

And at the same time I spent so much time to like restructuring.

我的意思是，即使今天，我也非常想合并这个PR，它涉及15000行的改动——在我的列表项目中，我把所有内容都迁移到了插件架构，我对此非常兴奋。

I mean I mean, even even today like I I really wanted to get this PR in where it was like 15,000 line change where In my list project I moved everything over to a plugin architecture, which I was so excited about.

我非常在意代码结构。

And I care a lot about the structure.

我读过全部代码吗？

Did I read all the code?

没有。

No.

因为很多代码其实只是枯燥的底层 plumbing。

Because a lot of code really is just boring plumbing.

那么，大多数应用程序是什么样的呢？

Well, what are most apps?

比如，数据从 API 以某种形式进来，你解析它，打包成另一种形式，存入数据库时又变成另一种形式，再以不同形式输出，可能是 HTML 或其他格式，你输入内容时又变成另一种形式，你整个应用其实就是在不断转换数据的形式。

Like, data comes in from an API in one form, you like, you parse it, you package it into a different form, you store it in your database, and it's a different form, it comes out again in a different form, then it's like HTML or whatever, and you type in something, it's a different form again, and all you do is like you're massaging data in different forms throughout your app.

大多数应用就是这样，我们其实就是 JSON 打印机。

This is what most apps are, we are pretty JSON printers.

而真正困难的部分，早在三十年前就被 PostgreSQL 的一些极客解决了。

And the and the the really, the hard part is solved by Postgres thirty years ago by some neck birds.

这其实正是很多软件的本质。

That's that's really what a lot of software is.

当然总会有一些有趣的部分，但我并不需要关心这个按钮怎么对齐、用了哪个 Tailwind 类，很多细节很无聊，而另一些细节才有趣。

Like, there's always some interesting parts, but I don't have to care how this button is aligned or which Tailwind class is used or or, like many details are boring and many other details are interesting.

但我认为，这更多是关于系统架构，而不是必须读完每一行代码。

But I think it's much more about system architecture than having to read every single line.

现在跳到下一步，你的工作流程是怎样的？

Right now jumping forward, what is your workflow like?

当你在开发 Cloudbot 时，你是用终端、多个终端吗？用哪些工具？就像你之前说的，你其实并不在逐行审查代码，但你仍然在思考架构，那么你日常的工作流程是什么样的？你能向一个可能加入团队的开发者描述一下吗？

Like when you're working on Cloudbot are you using a terminal, multiple terminals, which tools and how are you, you know, like you said you're not, you're kind of like not reviewing the code but you're still thinking about architecture, like what does your average day look like in terms of tooling, you know, you have explain to a developer who might join the team, you know, at one point you think, like, what does it look like?

这很有趣。

It's interesting.

我们稍微深入一点吧。

Let's let's let's go a little bit.

我们在四月份开始用 Cloud Code，然后我很快就上瘾了。

We were we were in in in April with Cloud Code, and then I got really hooked.

之后我经历了一段用 Cursor 的阶段，接着又用了一阵子 Gemini 2.5，然后我们又进入了 Opus 4 的阶段。

And then I did some I had a a phase where I did cursor, and then I did a I I used Gemini 2.5 a bit, then we had this phase with Opus four.

我拉了很多朋友一起用。

I hooked up a lot of my friends.

我知道 Armin 和 Mario 都来自维也纳。

Like, I know I know both Armin and and Mario from Vienna.

他们也被 AI 『上瘾』了，因为我自己太沉迷了。

They got they got AI peeled because I I was addictive.

你知道吗，我的最终用户一开始被搞糊涂了，但后来他们试了试。

You know, my my end user was like confusing them and then they tried it out.

然后他们最终也熬到了凌晨五点，我就管这叫‘黑眼圈俱乐部’。

And then and then eventually they also were up at 5AM and I called it like the Black Eye Club.

我的意思是，我之所以在伦敦发起一个名为‘Cloud Code匿名会’的线下聚会，是有原因的。

I mean, there's a reason, like I started a meetup in London that I called called Cloud Code Anonymous.

因为这确实有点像上瘾。

Because because it's it's a little bit like a drug.

因为它实在太有趣了。

Because it's so It's so much fun.

让我最震惊的是，我意识到现在我可以构建任何东西了。

To me what blew my mind so much was this realization that I can build everything now.

以前你必须仔细挑选要做的个人项目，因为软件开发很难。

Before you had to really pick which side project you build, because software is hard.

是的。

Yeah.

这仍然很难。

It's still hard.

但现在，就像我之前提到的那些摩擦，我对这项技术非常熟练，但对另一些方面却很糟糕，于是我心想：不如用 Go 来做个命令行工具吧。

But now, like I I am This friction that I talked about, where I'm so good at this technology, and I'm like so bad at this, and I'm like, oh, let's make the CLI in Go.

我对 Go 完全不懂，但我有很好的系统理解力，一旦有了这种理解，你就会培养出一种直觉，知道什么是对的，什么是错的。

I have no clue about Go, but I have I have a good system understanding, and once you have that it's like you you develop a feeling what's right, what's wrong.

这本身也是一种技能。

Like it's a skill in itself.

我记得有条推文说，当你写代码时，如果能感受到阻力，那就是你在构建良好的架构。

I remember there was this tweet where someone said, oh, when you write a code, you feel the friction, and that's how you make good architecture.

我在进行提示时也有同样的阻力感，因为我看到代码飞快地生成，看到需要多长时间，看到代理是否提出反对。

I feel the same friction when I prompt, because I I see the code flying by, I see how long it takes, I see if if like the agent pushes back.

我能看到它生成的内容是杂乱无章的，还是有逻辑、有意义的。

I see if what it creates looks like messy or like makes sense.

我在进行提示时，心里已经有个预判，知道它会花多长时间。

When I prompt, I I have a hinge already how long it's gonna take.

如果花费的时间长得多，我就知道我哪里搞砸了，你总会有点感觉。

If it takes much longer, I understand that I messed something You kinda feel

这个模型。

the model.

你知道，是的。

You you know Yeah.

你知道，是的。

You know Yeah.

通常它会是这样，或者它是否能运行。

How usually it's like this or if it runs.

我觉得这完全是一种共生关系，我学会了去表达，甚至可以说，更敢于使用这种语言。

I feel I feel it's very much a symbiosis, like I I learned to to talk, may I even say dare, or that language more.

所以，我使用这些工具的能力提升了，模型本身也在进步。

So it's like my my knowledge how to use those things improved, and also the models improved.

然后，在四月到现在这段时间里，我觉得转折点是在夏天，那时技术变得如此强大，你甚至可以不亲手写代码就能创建软件。

And then and then like over the time between between April and now, I would say that inflection point was summer, where it just got so good that you could create software without actually writing code by hand.

但真正让我信服的改变是GPT 5.2。

But the real the change that like sold it for me is was again GPT 5.2.

那一次，我觉得它被低估了。

That was again I think it's underrated.

我不明白为什么还有那么多人在用Cloud Code。

I don't I don't know why why all these people still use Cloud Code.

我有点能理解。

I I I kinda get it.

这是一种不同的工作方式。

It's it's a different way of working.

但OpenAI在那里做出的东西简直太棒了。

But whatever OpenAI cooked there is insanely good.

我输入的几乎每个提示都能得到我想要的结果。

Pretty much every prompt I type gives me the result I want.

这太不可思议了。

Which is insane.

就像，在Cloudbot上，我最近的项目，我并行使用了五到十个代理。

Like like, on on Cloudbot, my latest project, I use between five and ten agents in parallel.

如果你非常依赖云端代码构建，你必须忘记很多为了用Cloud Code产出好结果而不得不做的繁琐事情。

If you're very much cloud code build, you have to forget quite a lot of the silliness that the things that you have to do to create good output with Cloud Code.

我的意思是，我也见过那个团队，他们开创了一个全新的类别。

I mean, I also met met that team and and they created a whole new category.

就像Cloud Code是一个定义类别的产品，它在通用计算机工作方面非常出色，而且对编程也非常好用，我几乎每天都还在用它。

Like Cloud Code is is a category defining product, and it is amazing for general purpose computer work, and it is is really good for coding, and I I I I still use it almost every day.

但对于在复杂应用中编写代码，Codex要好得多，因为它需要花费十倍的时间。

But for writing code in complex applications, Codex is just so much better because it it takes 10 times longer.

Cloud会读取三个文件，然后足够自信地直接创建代码。

Cloud would read three files, and then be confident enough to just, like, create code.

然后你真的需要引导和推动它，让它读取更多代码，这样它就能看到代码库的更大图景，从而更好地融入新功能，而codecs则会保持沉默，只是花十分钟读取文件。

And then you really have to steer it and push it so it reads more code, so it gets it sees a bigger picture of your code base, so it it weaves in new features better, and codecs will just, like, be silent and just read files for ten minutes.

如果你只在一个终端上工作，我完全理解你为什么觉得这难以忍受。

And if you're If you only work on one terminal, I completely understand how you how you find this unbearable.

但我更喜欢那种不需要你明确告诉它该做什么的工具。

But I'd rather have something where It's also you don't tell it what to do, you know.

这一点很多人也不理解，我会和模型进行对话。

This also something that people don't get, like, I have a conversation with the model.

哦，我们来看看这个。

It's like, oh, let's look at this.

对于这个结构，我们有哪些选择？

What what what what options do we have for this structure?

你考虑过这个功能吗？

Did you consider this feature?

因为每次会话开始时，模型对你产品的理解都是零，你有时只需要给它一点提示。

And it's like, because every every session is like, the model starts from having no understanding about your product, and you have And and sometimes you have to just give it a little bit of pointers.

这个和这个怎么样？这样它就能探索不同的方向。

What about this and this, so it explores different directions.

你不需要计划模式。

And you don't need plan mode.

我只是在进行一场对话。

Like, I'm just having a conversation.

直到我说‘构建这个’，它才不会去构建。

Until I say, build this, it will not build this.

有一些触发词，因为它们都对触发词有点敏感，但只要我说‘我们来讨论一下’或‘给我几个选项’，它们就不会在我说‘构建’之前做任何东西。

There's some trigger words because it it is they all are a little trigger hungry, but as soon as I say let's discuss or give me options, they will not build things until I say build.

所以，你的很多提示，或者说大部分提示，其实都是一场对话，在这场对话中，你和代理几乎是在共同规划。

So a lot of lot would you say a lot of your prompting or a good part of it is this conversation conversation where where you you are are pretty much planning together with the agent.

是的。

Yeah.

比如我会说，提醒他们：我们需要文档，哪里是合适的位置？能不能给我一些建议？他们会说：不，这个应该单独成页。我们需要配置吗？这个怎么融入其他功能？

It's like what about like I say, remind them it's like okay, we need documentation, what would be a good spot, it would like give me some recommendations, they say, no, this should really be its own page, do we need configuration, how does this fit into this other feature?

我是在设计整个系统，因为我对我的产品架构、整体形态有清晰的理解。

It's like, I am designing the system because I have this I have this system understanding about how how is my my product, how are the shapes looking.

我不需要逐行理解代码——那是Codex的工作；但我是架构师，你知道的。

I don't have a line by line code understanding that's that's what Codex does for me, but I'm the architect, you know.

听起来你有点像几十年前那种所谓的‘大写的架构师’，那时候这种角色很流行，但后来就过时了。那时候的架构师原本是软件开发者，但不再亲自写代码，而是花大量时间理解业务，下面有一群开发人员为他们工作。一些公司至今仍保留这种模式，但大多数现代公司已经不再这样了，不过像银行这样的机构里，我确实遇到过一些‘大写的架构师’——他们负责系统规划，与其他架构师交流，拥有完整的设计蓝图，然后把任务直接交给团队执行。这种模式显然不受欢迎，因为架构师从不负责线上问题，实际操作中这种模式很容易崩溃，很多大公司现在都转向了‘高级工程师’模式，大家共同协作，当然，有些人会拥有更多话语权。

It sounds a little bit like you're almost, you know, for years back this totally came out and got out of style but there was this idea that you would have the architect with a capital A who used to be a software developer but they're not hands on anymore because they spend a lot of time understanding the business and they have these developers working underneath them and some companies still kind of work a little bit like this but most modern companies don't, but some banks etcetera, I met people there who are capital architects, they do the system plan, they talk with fellow architects, they have the blueprint, and then they literally pass it down to the team and everyone hates this model obviously because, you know, again, like, I think as people you kinda want more, the architect is never on call for this stuff and so it just kinda breaks down in practice and a lot of large companies just move to the staff engineer model where you're kind of all working together, of course, there's people who make who might have more input.

但听起来，你更像是一个架构师，身边有一群小助手帮你写代码，但在这个体系里，你依然完全负责，因为你仍然是一个独立贡献者，不是什么‘代理经理’之类的角色。代码是你写的，责任在你身上，如果你推送的代码导致Clobbots宕机——这最近确实发生了——你就要负责，对吧？

But sounds like, it's almost like this world where you are the architect who kind of, you know, you have your little agents who do the code except in this case you are of course fully responsible because you're still an individual contributor, you're not like a, okay, you might say you're a manager of agents or whatnot, but the code is yours, it's your responsibility, you're gonna be on call if, you know, if you push out code that takes down Clobbots, which it did just recently, you're on the hook for it, right?

我认为，在传统公司体系中，架构师的工作成果往往被层层保护，因为人多、流程复杂，他们很少直接面对结果。

And I think the difference in this system when it was in companies, the architect was kind of shielded from the output of their work because there's so much people and so much process etcetera.

我不太喜欢用‘架构师’这个词，我更喜欢用‘构建者’。

Well, wouldn't say architect, I like the word builder.

构建者，没错。

Builder, yeah.

而且我觉得，对于那些在使用AI方面非常成功的人，我可以分成几类：一类人更关注最终成果和产品体验。

And I think also that's There's a few categories that I see for people that are highly successful using using AI people I who really care more about the outcome, the product.

我当然也很在意产品的使用感受和整体体验，但至于底层的实现细节，我更关注的是整体结构。

I very much care about how it feels and everything, but how the plumbing works underneath, I care structurally.

但并不是要深入到每一个最细微的环节。

But you know, not to the not the biggest detail.

还有一类人特别喜欢攻克复杂的编码问题，比如思考算法，但他们并不喜欢做产品开发。

And then there are people who really love to to code on hard problems, like think about algorithms, don't really like the I'm building a product.

这简直就是全部的市场营销。

This is like all the marketing.

他们更喜欢解决难题。

They they more like They like to solve hard problems.

而这些人往往在面对AI时感到挣扎，甚至排斥AI，或变得非常沮丧，因为这正是AI擅长的工作。

And those are the people who really struggle and and and often reject AI or get really sad because that's exactly the job where that AI does.

AI正是在解决这些难题。

Like, it solves the hard problems.

有时候我会给它一些提示，但今年我学到的关于软件架构和设计的知识，比过去五年加起来还多。

Sometimes I give it some pointers, but many times I learned I learned more this year than the last five years around around software architecture and designing.

那些大型模型里面蕴含着海量的知识。

There's so much inside those monsters on knowledge.

一切问题都能通过提问得到解答，但你必须知道该问什么问题。

And everything is just a question away, but you have to know what question to ask.

当然，我也做了这个 Twitter 小项目，但还没完成，我真的希望有一天能回去继续做。

Of course I also built this Twitter thing, and it's still not done, and I and I really hope I'll get back to it at one one time.

所有功能都正常，但当我用得多了，系统就会变得特别卡顿、奇怪，然后又恢复正常。

Everything worked, but if I used it more at some point, things got really laggy and weird, and then it worked again.

我完全搞不懂原因，调试起来特别困难，因为问题很难复现——就是你用得越多，系统就越慢。

And I just couldn't figure it out, and it was like really difficult to debug because it was not easy to reproduce, it was just like you use it more and things got really slow.

我基本上在 Postgres 数据库里写了些 SQL 软件，当某些插入操作发生时就会触发，导致数据库变得特别繁忙。

I basically had like software in in in in PSQL, like in Postgres that would be triggered when certain inserts were were doing, and then the database would would get really busy.

而模型根本看不到这个问题，因为它和所有其他部分都隔得太远了。你知道，这些模型很擅长追踪代码流程，但这个副作用太隐蔽了，它只存在于一个文件里的一个函数中，这个函数和别的部分毫无关联，名字也不容易引起注意，我直到最后才问对了问题：‘我们这个系统有没有什么副作用？’

And the model couldn't see it because it was it was it was so far extracted from all the You know, like those models are really good at tracing through, but this was a side effect that was so hard to see because it was only in this one file, a function that had no connection to anything else, with a name that was not easy grabbable, I just never asked the right question until I was like, do we have any side effects for this and this?

我找到了问题，并修复了它。

And I found it and I fixed it.

所以说，一切问题都只差一个正确的问题。

And it's like, but I Everything is just the right question away.

是的。

Yeah.

但你需要具备知识和专业技能，是的。

But you need to have like knowledge, expertise Yeah.

对。

Yeah.

经验。

Experience.

你

You

我的意思是，那些拒绝这样做的人，而另一些人不太关心内部如何规划，只是热衷于构建东西，他们非常成功。

you I mean, so so so these are the people who reject it, and then the people who care a bit less about how it's being planned internally, but are just excited to build things, they are really successful.

另外一件帮助我的事情是，当你经营一家公司并雇佣员工时，你不可能时刻盯着每个人，强迫他们写出完全符合你要求的代码。

And one thing that also helped me is, you know when you run a company and then you hire people, you can't breathe on everyone's neck, and like make them have the line of code exactly that way.

有很多人没有管理过团队，他们经历了如何稍微放松一点，理解到：也许这段代码不是我理想中的样子，但它能让我更接近目标。

And there's a lot of people who who didn't manage a team, they had this experience how to how to relax a little bit and understand that yes, this maybe is not exactly that code that I want, but it will get me closer to my goal.

对于任何不够完美的东西，我们总可以改进，投入更多时间去完善。

And for anything that is like not perfect, we can always make it better and like put more time into it.

我非常相信这种迭代改进的方式。

I very much believe into this iterative improvement.

我不得不学会稍微放手我的公司。

I had to learn to let go a little bit of my company.

所以当我做Cloud Code的时候，感觉我身边是一群不完美、有时很傻，但有时又非常出色的工程师，我需要引导他们，我们一起朝着共同的目标努力。

So so so then when I when I had Cloud Code, kinda felt like I have like I have like imperfect, sometimes silly, but sometimes very brilliant engineers that I have to steer, and where we where work together on a common goal.

这让我感觉又像回到了当老板的时候。

It felt a lot like being the boss again.

这很有趣。

And interesting.

你现在是传统方式构建软件，我猜是在AI之前，已经做了十五年，甚至更久，你非常擅长带领团队，也对工艺标准要求很高，而你现在大概已经用‘氛围编码’或与智能体协作了一年。

Now, you you built kind of software, I guess, the traditional way, you know, pre AI for fifteen years, or even more than fifteen years, and you got really good at being also leading a team and then how to have high standards, you really cared about the craft there as well, you've now kind of been, I guess, vibe coding or working with agents for a year.

你在对比这两种方式，你觉得真正改变了什么？你觉得有哪些东西尽管发生了这么多变化，却依然保持不变？

You're comparing the two, what do you think what do you think really really changed and what do you think are things that kind of stayed the same despite all

首先，我不喜欢‘氛围编码’这个说法。

of First of all, I don't like I don't like the term vibe coding.

好的。

Alright.

那我们该怎么称呼它呢？

How should we call it?

我觉得我觉得我

I I think I think I

我觉得‘氛围编码’这个词现在已经几乎成了一种潮流。

think vibe coding is by now almost a star.

哦，是的。

Oh yeah.

我称它为，我告诉别人我做的工作是带星号的智能体工程。

I I I call it I tell people I do What I do is agentic engineering with a little star.

氛围编码是从凌晨三点开始的。

Vibe coding starts at 3AM.

现在，因为编写代码中所有琐碎的部分都被自动化了，我可以变得快得多，但同时也意味着我必须思考得更多。

Now like, because all the mundane stuff of writing code is automated away, I can move so much faster, but also means like, I have to think so much more.

我仍然完全沉浸在状态中，这种感觉对我来说和我以往进入心流状态时完全一样。

I'm still very much in the flow, like it it is it is completely the same feeling as, for me, as as I very much get in this flow state.

但这种状态在精神上更加耗费精力，因为我不是只管理一个员工，而是有五到十个都在同时处理不同的任务，我需要不断在这部分、那部分、另一部分之间切换。

But it is mentally even more taxing because I have I don't have one employee that I manage, have like five or 10 that all work on things and I switch from this one part to this other part to this other part to this other part.

主要是因为我正在设计某个子系统或某个功能，而我知道构建它可能需要四十分钟到一个小时。

Mostly because of I'm designing this in subsystem or like this feature and then I know that it will probably take codecs like forty minutes or or one hour to build.

所以我想先制定好计划，然后再去构建它。

So like, I wanna like have the plan right and then I build it.

然后我会转去做别的事情。

And then I'll I'll move on to something else.

但这时候这个任务在运行，我就去忙那个，接着那个也在运行，这个也在运行，过一会儿那个也在运行，这个也在运行，最后我再回到这个任务上。

But then this is cooking, and then I work on this, and then this is cooking, and then this is cooking, and then at some point, this is cooking, and then this is cooking, and then I go back to this one.

所以我在脑子里频繁地来回切换。

So like, I I I switch around a lot in my head.

我希望不用这样，我相信这只是一个过渡性的问题，总有一天我们会拥有速度足够快的模型和系统，让我能少一些这种停顿。

I wish I wouldn't have to do that, like I'm sure this is a transitionary problem and at some point we have we have models and and systems that are so fast that that I can paralyze a little less.

但为了保持这种心流状态，我必须大幅减少干扰。

But to stay in the float flow state I need to massively paralyze.

所以这就是它的运作方式。

So that that's that's how it works.

然后我会回到那里，稍微调整一下，但通常只是试着运行一下。

And I go back to there, and and maybe tweak it a little bit more, but usually just like try it out.

也许这个就完成了，因为这个只花了二十分钟左右。

Maybe then this is ready because this took only took like twenty minutes.

所以我一直在不断切换。

So like I I constantly jump around.

通常有一个主要项目占据我的注意力，还有一些次要项目也需要关注。

Usually there's there's one main project that has my focus and I have like some satellite projects that also need attention.

但在那些我只需要花五分钟的地方，它会运行半小时，然后我试一下，不需要占用太多精力。

But where I can maybe spend five minutes, it does something for half an hour and then and I try it and it doesn't need so much capacity up there.

这听起来几乎像是，你

This almost sounds, you

你知道，有两件事浮现在我脑海里。

know, like two things come to mind.

一个是有一些游戏，你需要管理一个厨房，里面有员工，你会看到食谱出来，然后你得跳来跳去地完成任务，而且……

One is there's these like games where you have to manage a kitchen with the employee and and you see like the recipes or something come out and you need to jump and do it And

就像《星际争霸》一样，你知道，你有一个主基地，还有一些副基地为你提供资源。

you're like Star craft, you know, you have your main base and you have your side bases to give you resources.

这一点也适用。

That as well.

还有另一件事，当你说到我过去看看，然后做决定时，我想起了国际象棋特级大师同时下多盘棋的情景，你知道，有时候他们同时应对二十盘棋，他们总是走过去，看看每盘棋的局面，做出决定，有些棋局他们花的时间更长，我猜是因为对手更强或者自己下得更好。

And also one thing that just came to mind as you said, like, I go there and I watch this and I make a decision is when I see the chess grandmasters play multiple boards at once, you know, see see, sometimes they hear 20 boards and they always all, you know, they go there, they kind of you can see that they just like see what's on that board, they make a decision, and for some boards they suffer longer, I guess, better players or better opponents.

感觉上，你知道，他们完全占据了他们的注意力，你也完全占据了你的注意力，

It feels, you know, both they're occupying a 100% of their bay, you're occupying your bay,

只要你能快速切换上下文，你就能扩展自己的能力。

and you're you're kinda scaling yourself as long as you can context switch.

不同之处在于，直到现在还是云代码的时候，你得用不同的方式工作，因为速度更快，但输出往往第一次尝试就无法正常运行。

The difference the difference was up until this was cloud code I You have to work a little different because it is much faster, but then the output often doesn't work on the first try.

所以它会生成一些东西，但却忘了更新另外三个地方，导致崩溃，或者你得告诉它如何有效使用编码代理——关键总是要闭环。

So like, it makes something, but then it forgot to update three other things, it crashes or you give it The good thing How to be effective with coding agent is always like you have to close the loop.

它必须能够自行调试和测试。

It needs to be able to debug and test itself.

这才是关键所在。

That's the big secret.

这听起来也是我变得高效得多的原因之一。

That's also sounds something I I think that's part of why I got so much more effective.

但很明显，使用云代码时，我经常得回头去修正那些代码。

But the obvious With Cloud Code, I often had to go back and like fix up the stuff.

或者需要反复迭代很多次。

Or it just takes a lot of iterations.

所以最终，速度并没有快多少。

So in the end it's not that much faster.

只是更具交互性而已。

It's just more interactive.

而如今，使用代码助手几乎总能正确完成。

And these days with codecs it just almost always gets it right.

我的通用策略始终是：先开发一个功能，当然，然后让AI自动生成测试，并确保它能运行，它确实能运行。

My my general strategy is always I build a feature, of course you And then of course you always let it write tests, and you make sure that it runs It runs

运行它们，是的。

them, yes.

所以，即使我开发Mac应用时，我昨天刚调试过一个功能，那个Mac应用找不到远程网关，但同样的TypeScript代码却可以。Mac应用调试起来挺烦人的，因为它要编译、启动、观察，然后你会发现：不对，这功能没生效。

And so even even when I write a Mac app, I don't know, like I I just yesterday I debugged this feature where the Mac app couldn't find a remote gateway, but like the the same code in TypeScript could, but Mac app is kinda annoying to debug because like it builds it, you have to start it, you have to look at it, you have to like, hey, no this is not working.

所以我现在会直接写一个用于调试的命令行工具，它调用所有相同的代码路径，你可以自己运行它，然后反复迭代、自己修复，这样它就能顺利运行了。

So now I just started like, you know, you're gonna build a CLI just for debugging that invokes all the same code paths that you can call yourself, and then you just iterate and you fix it yourself and then it will just cook.

它运行了一个小时，最后告诉我：是的，这里和这里存在竞态条件，还有配置错误之类的。

And it just cooked for an hour and it was done and it told me like, yeah, there was a race condition here and here and like a misconfiguration blah blah blah.

但确实，听起来很合理，我不需要看代码，就像那样。

But yeah, sounds sensible, I don't need to I don't need to see the code, it's like.

但你不需要看代码，因为你已经设置了验证循环，并且信任它，毕竟它已经运行过了。我想这跟在大公司做大型项目时有点类似——所有测试都通过了，虽然不能保证100%完美，但已经相当可靠了，而且所有新代码都有测试，有人确实考虑过这些。

But you don't need to see it because you set up the validation loops and you trust that because it ran it, I mean this is, I guess it's not too dissimilar to like sometimes when you work on a large project in a large company, when all the tests pass, I mean it doesn't mean that a 100% it's there, but it's a pretty good and and all the new new code has tests as well, you know, someone thought about

然后测试了它，所有这些都做了。

it and tested it and and all that.

所以在我的最新项目中，我们一直遇到一些奇怪的问题，比如反重力功能在循环中处理工具调用的方式有些异常，因此你必须做一些过滤。

So even on my on the very latest project, we always had bugs for like anti gravity has like a certain a certain weirdness with how it takes tool calls in the loop, in format, so you have to do like some filtering.

是的。

Yep.

这导致了很多问题，我花了太长时间才意识到：我到底在做什么？

And that broke a bunch, it actually took me way too long to realize like, what am I doing here?

我只需要自动化这个过程。

I just need to automate this.

于是我直接让Codex帮我设计一套实时测试，启动一个Docker容器，安装整个系统，启动一个循环，使用我从这个和那个文件中获取的API密钥，然后让模型读取一张图片，生成一张新图片，再分析图片内容，看看它看到了什么——我不是只告诉循环‘去调用工具’，而是让它自己去搞定。

So I was just going to Codex, it's like, design live tests that spin up a Docker container, install the whole thing, spin up a loop, use my API keys from this and this file, and then you tell the model to read an image, create an image before, and then look into the image and see what it sees, so I I don't not just tell the loop, I'll still tell tool calling, Make it work.

然后它自己解决了问题，虽然花了很长时间，但它测试了我所有的API密钥，从Entropic到Satai再到GLM，全都覆盖了，并修复了那些细微的问题，比如工具调用有时失效、顺序不对，因为我把整个流程闭环了。

And then it solved itself, it took forever, but it it it tested all my API keys, like from from Entropic over Satai over GLM, like everything, and it fixed all those little intricacies where where sometimes the tool calling didn't work or the ordering was wrong, because I closed the loop.

而且这正是

And and that's that's

闭环的意思是，让代理能够验证自己的工作。

And closing the loop, you mean just have a way to to have have the agent be able to validate its work.

是的。

Yeah.

这就是为什么我们目前拥有的这些模型在编程方面表现得如此出色，但在创意写作方面却有时只是中等水平。

That's why, that's the whole reason why why those models that we currently have are so good at coding, but like, sometimes mediocre good at writing creative.

因为没有简单的方法来验证。

Because there's no easy way to validate.

对吧？

Right?

但代码不同，我可以编译、检查语法、执行并验证输出。

But code, I can compile, I can lint, I can execute, I can verify the output.

如果你设计得当，就能实现完美的闭环。

If you design it the right way, have a perfect loop.

即使是现在，对于网站，我也以可以通过命令行运行的方式构建了核心，因为我有一个完美的执行循环，而浏览器的循环实在太慢了。

Like even now even now for for websites, I built the core in a way that can be run via CLI, so it's like I have this I have this perfect execution loop because the the browser loop is insanely slow.

你需要一个能够快速循环的系统。

You want something that that loops fast.

所以听起来，和以前相比，有一件事其实没变：我们以前就有这种后端或业务逻辑繁重的东西，它们更容易被验证，哦，惊喜！

So it sounds like one thing that is not really changing from like before is we had this before like back end or business logic heavy heavy thing could easily be or more easily be verified that it's Oh, surprise!

实际上，使用智能体解码能让你成为一个更好的程序员，因为你必须更深入地思考你的架构，使其更容易验证，因为验证正是让事物变好的方式。

Actually using agent decoding makes you a better coder because you have to have to think harder about your architecture so that it's easier verifiable because verifying is the way how to make things good.

那么，回想一下，在AI出现之前，对于复杂系统，当有人之前构建过这些东西时，他们一开始是怎么让它可测试的呢？

Well then remember back even before AI, for complex systems, like once you got someone who built these things before what they started with, how do we make it testable, right?

比如，你需要设计接口、类，使其可测试，要考虑是否要模拟某些东西，是否使用模拟对象，是否使用端到端测试，而后者会很耗时等等。

Like you need to design interfaces, classes, testable, need to think about am I going to fake things, will I use mocks, will I use end to end testing, which will be long, etc.

但这些都是非常困难的架构决策，一旦做出，就很难再改变了。

But these are like really hard architectural decisions and once you make them they're guess harder to change.

用你的话说，如果你让模型做一次大规模的重构，它会‘烹饪’更久，但如果你已经测试过了，它就能搞定，对吧？

In your word, you know, like the model would cook a lot longer if you ask it to make a massive refactor and if you have tested it'll get it, right?

但你知道，我们仍然面临这些权衡。

But you know how these we still have these trade offs.

这是软件，我想说我现在写的代码更好了，虽然我不再亲自写代码，但我以前写过非常棒的代码。

It's software, it's I would say I write better code now, that I don't write code myself anymore, and I wrote really good code.

但即使在公司的时候，测试也常常非常枯燥，你要想出各种边界情况和分支逻辑。

But but like, even back at the company, sometimes testing was so tedious, and you come up with all those edge cases, and and and the branching.

我的意思是，除了我非常敬重的肯特·贝克——他上过这个播客，我们聊过，他仍然坚持测试驱动开发，他还告诉我他并不因为我没这么做而生气，但如果你想写出糟糕的代码，那只能怪你自己。

I mean outside of Kent Beck, who I deeply respect, and he was on the podcast and we we talk like he he still writes test first and he tells me that he's not mad at me for not writing it, but if you wanna write like, you know, poor quality code that's on you.

但我不认识多少开发者，包括我自己，我从来就不喜欢写测试。

But I don't know many developers, myself included, I never liked writing tests.

即使当我假装喜欢的时候，我也只是敷衍了事，写文档和写测试对我来说从来都不是一种创造性的表达。

And even when I pretended that I did, I just never did this a little bit, like writing documentation and writing tests, to me it was never a creative expression.

现在真的太好了，就说我的上一个项目，我有非常棒的文档，而我连一行都没亲自写过。

It is so good now, like, I I would say from my last project I have really good documentation, and I didn't write a single line myself.

我不写测试，也不写文档，我只是向模型解释架构权衡，说明我们为什么这样设计，然后让它去写，比如写一个面向初学者的入门部分，再在最后加上更技术性的细节。

Like, no, I don't write the test, I don't know documentation, I explain the model the trade off, so like why we did something like this, and then tell it like like write that, write the entrance section beginner friendly, and then add more technical detail at the end.

效果真的非常好。

And it is so good.

我从未参与过如此高质量文档的项目，每次设计功能时，这都是流程的一部分。

I never had a project with that good documentation, just by Every time I design a feature this is a part of this is a part of the process.

还有测试，我几乎会想：好吧，我们已经构建了这个，该怎么测试它呢？

And also like testing, I'm almost like, okay, we built this, how are gonna test this?

是的，我们可以这样做、这样做和这样做。

Yeah, we could do this and this and this.

如果我们以这种方式构建呢？

What if we build it this way?

哦，对，那样我们就能更好地测试它了。

Oh yeah, then we can test it better.

这现在已成为我的习惯，因为我总是会想：我该如何闭环？

This is now part of my singing because I I always think like how do I close the loop?

我如何让模型始终能够自行验证工作？这自然引导我走向更优的架构。

How do I The model always needs to be able to verify the work itself, which automatically steers me to better architecture.

所以为什么

So why do

你觉得，有很多有经验的开发者仍然对AI能完成大量这类工作的观点持强烈反对态度吗？

you think there's, you know, a bunch of like experienced devs who are still pushing quite a bit back on on just like the idea that AI can do a lot of this?

就在一周前，我偶然看到一篇由Nick Gallagher写的博客文章，Coco with Love，我非常尊重他，也从他那里学到了很多。

It was a week ago I I stumbled over a blog post by Nick Gallagher, Coco with Love, that I deeply respect and learned a lot from.

这篇博客文章完全是批评当前模型的工作方式。

And this blog post was just was a dissing of the current way how models work.

他测试了五六个模型，包括一些根本说不通的，比如那个OpenAI的1200亿参数开源模型，它根本写不出像样的代码，你知道的，他就只是写了一个提示词。

And and what he did was he he tested like five or six models, including some that make no sense, like the the OpenAI 120,000,000,000 open source one, that is not good enough to write good code, you know, it's like, and he just He wrote a prompt.

据我理解，网站上并没有太多信息，但在我看来，他似乎是写了一个提示词，放到Claude Web上，然后点了发送。

As far as I understand it, there was not a lot of information on the website, but I To me it sounded like he wrote a prompt, he put it on Claude Web, and and he pressed send.

然后他拿输出结果去运行，结果无法编译。

And then he took the output, and ran it, and it didn't compile.

他感到很失望。

And he was disappointed.

但他又说，当然不会成功。

But he's like, of course it will not work.

你觉得我第一次尝试就能写出没有bug的代码吗？

Do you think I can write bug free code on the first attempt?

而且这些小模型是我们人类集体知识的幽灵。

And that those little Those models are ghosts of our collective human knowledge.

它们在很多方面的工作方式都非常相似。

They work very similar in many ways.

当然，你第一次不可能完全正确。

Of course you don't get it right the first time.

肯定会有一些错误。

Like there will be mistakes.

这就是为什么你需要闭环反馈。

That's why you have to close the feedback loop.

而且你也不是仅仅把提示发给模型。

And also you don't just send a prompt to the model.

你是在开启一场对话。

You start a conversation.

嘿，这正是我想构建的东西。

Hey, is what I wanna build.

他抱怨说用的是旧版 API。

It's like you He complained that it used old API.

嘿，你没说明 macOS 的版本。

Hey, you didn't specify the macOS version.

所以它只能默认使用旧版 API，因为缺少这些信息，而且它训练所用的数据量很大，不只是最近两年的。

So it made an assumption to default to like old API because that information was missing, and it it is trained on a lot of data, not just the last two years.

而且旧数据比新数据多得多。

And there's just more old data than new data.

所以，你越了解这些小家伙的思维方式，就越能更好地进行提示。

So this is like, the more you understand how those little beasts think, the better you get at prompting.

然后他花了大概一天左右的时间试用，之后就决定这项技术其实并不怎么样。

And then and then he spent maybe, I don't know, a day or or so on playing with it, and then just decided that this technology is not really good.

但要想有效使用，你必须投入多得多的时间。

But to be effective, you have to spend significantly more time.

你知道，这就像是你会弹吉他，然后把你放到钢琴前，你试了试，觉得：这玩意儿太差了，我还是回去弹我的吉他吧。

You know, it's it's like it's like you know how to play guitar, and I put you on piano, and you try it a bit, it's like, oh, this sucks, I'll go back to my guitar.

不，不，这是一种完全不同的构建方式，是一种不同的思维方式。

No, no, it's like, it's a different way of building, it's a different way of thinking.

你不知道我有多少次在凌晨三点对着Claude Code大喊大叫，因为它干了点蠢事。

You have no idea how often I screamed at like 3AM to Claude Code, because it did something silly.

我慢慢开始理解，为什么这些工具会以我告诉它们的方式去做事情。

I slowly started to understand why those things do what they do, with like exactly the way I tell it to do things.

有时候你真的可以问，就在去年，比如我上一个项目CloudBoard，我感觉自己就像一个人肉合并按钮，因为社区活跃得不得了，而我只负责审核PR。

And sometimes you can literally ask, you can Even even last year, like I For this project, last project like CloudBoard, I feel like a human merge button, because the community is like blowing off, and all I do is like reviewing PRs.

我现在几乎没有时间亲自写代码了。

I I I have very little time to actually write code myself anymore.

刚开始的时候，它经常只是挑挑拣拣，然后直接关闭PR，真是让人火大。

And in the beginning it would often like just cherry pick things and would close the PR, and it was like so annoyed.

所以我就在想：你为什么要这么做？

So it was something like, why are you doing this?