为什么优秀的开发者对智能体开发如此警惕？

简而言之：优秀开发者对智能体式开发保持谨慎，是因为他们知道，构建出来不等于能在生产环境中正常运行。TL;DR
Good developers’ caution about agentic development comes from knowing that built isn’t the same as working in production.

令我惊讶的是，竟有这么多优秀的开发者迟迟不愿全力投入编码智能体。这些人通常会比其他人更早尝试新的工作方式，而且很多时候还会创造出新的工具和实践，帮助更好地构建应用程序。那么，为什么大家会如此犹豫呢？I’ve been surprised by how many excellent developers have been hesitant to go all in on coding agents. These are people who usually try new ways of working before anyone else and in many cases invent new tools and practices that support building the application well. So why have we had so much reluctance?

简单（也许是懒得多想？）的答案是，他们热爱编写代码，或者担心自己的工作。我相信，有些人在某些时候确实如此。我也知道，我交谈过的一些开发者确实是这样，但我一直觉得还有别的原因，某种藏在这些显而易见的担忧背后的恐惧。每隔六个月编制一次《技术雷达》时，我都会尽量腾出一段时间，让大家参加开放空间讨论。九月，我们围绕智能体式开发展开了一场讨论，把它推到了极限；这场讨论终于让我清楚地看到了那种恐惧究竟是什么。The easy (lazy?) answer is that they love writing code, or they’re worried about their jobs. I’m sure that’s true for some people, some of the time. And I know it is true for some of the developers I talk to but I always felt there was something else, another fear hiding behind those obvious ones. When we put together the Technology Radar every six months I try to block out a chunk of time for us to do an open space. In September, a discussion we had on agentic development, which pushed it to its limits, finally helped me see clearly what that fear is.

正确地构建它Building it right

Thoughtworkers 非常重视做正确的事，并把事情做好。这几乎就是我们默认的工作和思考方式，也是我们发明并倡导的许多实践和技术的源头。我们希望打造的软件实用、有帮助，明年仍然可以修改，而且在生产环境中不会崩溃。我们的开发人员很早就采用、倡导或发明了持续集成、结对编程、自动化测试、持续交付、微服务等许多技术的早期版本，因为这些技术帮助我们把软件做好。Thoughtworkers care deeply about building the right thing and building it right. It’s pretty much our default way of working and thinking and it’s where many of the practices and technologies we invented and championed came from. We want software that is useful and helpful, can be changed next year, and doesn’t fall over in production. Our developers adopted, championed or invented some of the first versions of continuous integration, pairing, automated testing, continuous delivery, microservices and many others early because they helped us build the software right.

早期的编码智能体让生成代码变得轻而易举，其中也包括那些我们绝不希望出现在生产环境中的代码——这些代码出自尚未认识到构建某样东西与安全地让它在生产环境中运行之间存在鸿沟的人之手。工具已经有了巨大的进步，但经验丰富的开发者仍然会提出疑问。我们能确定它的行为正确吗？它是否按预期工作？这些边界划分得对吗？我们能否持续演进它？它是否遵循了我们历经艰辛才学会的原则和实践，让我们确信它能满足客户需求，并在生产环境中持续稳定运行？出了故障会怎样？另一个团队能否接手并维护它？诸如此类。Early coding agents made it very easy to produce code, including code we wouldn’t have wanted anywhere near production, written by people who have not learned about the chasm between building something and making it run in production safely. The tools have improved enormously, but experienced developers still have questions. Are we confident this is the right behaviour? Does it work as expected? Are these the right boundaries? Will we be able to evolve it? Does it abide by the principles and practices we learned the hard way to give us confidence it will meet the needs of the customer and stay up in production? What happens when something fails? Will another team be able to live with it? And so on.

所有这些问题背后，都有一个更大的问题：当没人有过以这种方式构建系统的经验时，我们能在多大程度上信任这样的系统？换句话说，几乎所有目前投入生产的系统，都是过去那种方式手工构建的，由我们可以信任的人（但愿如此）完成。如今我们构建的一切都采用新方式，而我们还没有真正经历过这种方式。Underneath all of those sits a bigger question. How much can we trust a system when nobody has experience of building it this way? Let me state that another way. Nearly every system we have in production now was built the old way, by hand, by people we could trust (hopefully). Everything we build now is the new way and we have not lived with that yet.

在科技行业工作了 25 多年后，我逐渐懂得珍视人们通过经验积累起来的判断力。我经常向模型以及 Thoughtworks 的资深技术人员提出类似的问题。遇到难题时，我仍然能从人类那里得到更有用的答案；或者说，拥有非常具体经验的人往往能给出更深刻的见解，帮助我更好地理解问题的要点。他们会质疑问题的前提，从十年前出过差错的事情中认出某种模式，或发现技术问题背后隐藏的组织问题。如今，我可以获取海量信息，但我仍需要有人帮助我理清什么才真正重要；我仍需要智慧和洞见。这种判断力，正是心存疑虑的资深开发者试图守护的东西。After more than 25 years in technology, I’ve come to value the judgment people develop through experience. I regularly put similar questions to models and to senior technologists at Thoughtworks. For the difficult questions, I still get more useful answers from the humans or maybe more insightful with very specific experience that helps me better understand the point. They challenge the premise, recognise a pattern from something that went wrong ten years ago, or spot the organisational problem hiding inside the technical one. I can now access an extraordinary amount of information. I still need people who can help me think through what matters, I still need wisdom and insight. That type judgment is exactly what hesitant experienced developers are trying to protect.

我想明确一点：他们并不排斥使用编码助手；他们犹豫的是全盘投入，让智能体执行所有任务。他们不敢放手，是因为他们没有充分信心，确信这些智能体已设置好适当的护栏，能够独立运行。And I want to be clear: they are not hesitant to use a coding assistant, they are hesitant to go all in and let the agents do all the execution. They are hesitant to take their hand off the wheel because they don’t have full confidence the agents have the right guardrails in place to run off on their own.

白板前的一周A week at the whiteboard

最近，我们的欧洲区首席技术官 Giles Alexander 召集了资深工程师、基础设施顾问和产品人员，按照这种方式一起工作了一周。没人写一行代码，一切都由智能体构建。重点并不是证明一款航空公司应用程序可以在一周内开发出来。（有趣的是，他们完成了 80%，而我们都知道这意味着什么……这事儿可不是瞎编的！）这次实验旨在了解，当所有代码都由智能体编写时，团队的工作会发生什么变化。你可以在这里读到他们的一些心得。Recently, Giles Alexander, our Regional CTO for Europe, brought senior engineers, infrastructure consultants and product people together for a week of working in exactly this way. No code written by anyone. Everything built by agents. The point wasn’t to prove that an airline application could be built in a week. (Funnily enough they got 80% done and we all know what that means… you can’t make stuff up!) The purpose of the experiment was to learn what happens to the team’s work when agents do all of the coding. You can read some of what they learned here.

在我们的交谈中，最令我印象深刻的是，他们花了大量时间在白板前工作：梳理领域，划定边界，决定接下来该做什么，并制定智能体可以执行的计划。与此同时，智能体在团队下班后仍不断产出代码。What struck me in our conversations was how much time they spent at the whiteboard. Working out the domain. Drawing boundaries. Deciding what should happen next and making plans the agents could act on. Meanwhile, the agents kept producing code beyond the team’s working day.

人类也在围绕这项工作设计反馈机制：测试、契约、架构检查和交付流水线。他们在摸索如何给予智能体足够的自由来推进工作，同时又能对结果保持信心。在键盘前的大部分工作，都是引导智能体将这些经验融入工具框架，这样负责构建和测试的智能体下次运行时就能做对，让他们对构建出来的东西更有信心。有趣的是，最后提交功能代码最多的竟然是产品负责人。The humans were also designing the feedback around that work: tests, contracts, architecture checks and a delivery pipeline. They were working out how to give agents enough freedom to make progress while keeping confidence in the result. Most of the work at the keyboard was directing agents to put this learning into the harness, so the building and testing agents got it right on the next run and they could have more confidence in what they built. Interestingly in the end the product person committed more feature code than anyone else on the team.

我让他们估算了一下，他们说自己大约三分之二的时间花在白板前，三分之一花在测试框架上。这或许能让我们对开发者未来的工作方式有所了解；不过，在你急着重新设计团队之前，事情还没完……When I asked them to estimate they said they spend about ⅔ of their time at the whiteboard and ⅓ on the harness, which could give us some clue as to how developers will work in the future, but before you get ahead of yourself redesigning your team, that’s not the end of the story…

应用运行了。构建失败了。The application ran. The build was red.

应用程序运行了，但构建却经常失败。它在他们的机器上能跑——这事儿简直荒唐得让人想编都编不出来！构建老是失败，真让人膈应。构建失败应该代表着什么：停下来，查明原因，把问题修好。如果失败太频繁，以至于大家都不再留意，那我们怎么发现下一个真正的故障？而且，如果我们无法信任这些检查，构建通过也就不再让人安心了。这正是持续集成本该消除的不确定性，而我们倡导持续集成已经超过25年了。The application ran, but the build was frequently red. It worked on their machine - again you couldn’t make this up if you tried! A constant red build gives me the ick. A red build should mean something: stop, investigate, fix it. If it’s red so often that people stop paying attention, how do we spot the next real failure? And if we can’t trust the checks, a green build stops being reassuring too. That’s exactly the uncertainty continuous integration was supposed to remove, and we’ve been advocating it for over 25 years.

我们仍在摸索如何应对这个问题。请记住，这次实验旨在将智能体开发推向极限前沿。是不是有太多智能体并行工作，彼此妨碍了对方的改动？系统是否还不够模块化，无法让智能体分别处理不同部分？还是改动到来的速度超过了检查完成的速度？又或者，这些因素以及其他因素共同造成了问题？无论如何，我们确实需要重新思考如何解决最后一英里的挑战。我能看到，随着智能体时代颠覆开发生命周期的其他环节，持续交付/DevOps 这一运动也正在重新兴起，并经历一番重新思考。而且这并非只有我们的实验才会遇到的问题。DORA 的 2025 年研究发现，如今采用 AI 与更高的交付吞吐量相关，但也与较低的交付稳定性相关。这恰恰是持续交付和 DevOps 一直致力于解决的问题！We’re still working through how to address it. Remember this was an experiment to push the very edge of agentic development. Were too many agents working in parallel and stepping on each other’s changes? Was the system not yet modular enough for agents to work on separate parts? Or were changes simply arriving faster than the checks could finish? Or was it a combination of all of these and more? Either way we definitely need to rethink how we will solve the last mile challenges. I can see continuous delivery/DevOps as a movement having a resurgence and a rethink in the agentic era in the same way the rest of the development life cycle is being upended. And it isn’t just our experiment. DORA’s 2025 research found AI adoption is now linked to higher delivery throughput, but to lower delivery stability. Exactly what continuous delivery and DevOps were trying to solve for!

所有这些挑战都引发了团队内部一些很有价值的讨论。当你不会逐行阅读代码，而且测试也是由智能体和代码一起创建时，测试驱动开发应该发挥什么作用？验收测试、契约测试以及系统边界处的检查，在哪些地方能让我们更有信心，同时又不至于过于脆弱？考虑到我们可以如此迅速地修改方案，在放手让智能体自主开展工作之前，应该做多少设计？我们能否找到一个合适的判断标准，知道自己是否做得太过了？这一切中最大的难题之一，是批次的规模。我听说很多团队正在从故事转向史诗。这有利于提升开发速度，但你的 CI 流水线能否快速并行地处理这么大规模的工作单元？All of these challenges prompted some good arguments internally. What role should test-driven development play when you aren’t reading every line and the agent created the tests alongside the code? Where would acceptance tests, contract tests and checks at system boundaries give us more confidence without being too brittle? How much design should we do before setting an agent loose, given how quickly we can revise an approach? Is there an appropriate point we will know we have gone too far? One of the biggest puzzles in all this is the size of the batch. I have heard many teams are moving from Stories to Epics. Great for speed of development but can your CI pipeline handle that size unit of work at speed and in parallel?

实验团队并没有在一周甚至两周内就把这些问题全都敲定（他们让不同的团队各做了一次）。如果有人声称自己做到了，我不会相信。但这恰恰是我希望有经验的开发人员参与的工作：开展实验、提出质疑，并帮助我们找出哪些实践经得起检验，以及哪些地方需要新的做法。The experiment team didn’t settle all of this in a week or even two (they ran it twice with different teams). I wouldn’t trust anyone who claimed they had. But this is exactly the kind of work I want experienced developers involved in: experimenting, questioning and helping us discover which practices hold up and where we need some new ones.

离开修整过的雪道Off the groomed slopes

和参与这次谈话的几位资深开发者聊过之后，我一直在想学滑雪这件事。孩子们往往会毫无畏惧地径直冲下山坡，有点像刚入行、从未把软件部署到生产环境，也从未在凌晨三点处理过值班故障的新手开发者。（那次经历我永远忘不了；还有我亲手造成的每一次生产故障，以及从中吸取的教训，也都永远刻在我的脑海里。）我成年后第一次尝试滑雪时，脑子里想的却是自己可能会摔坏什么。我很想滑雪，它看起来既有趣又让人无拘无束，但我已经足够成熟，知道后果可能有多严重，也不想拖着一条断腿——或更糟——在伦敦四处跛行。最大的问题是，我还没学会如何有效地转弯和停下来；不会这些，我在雪坡上就像一列失控的火车。After coming away from this conversation with some of the senior developers involved I kept thinking about learning to ski. Kids will often head straight down the hill without fear, kind of like a new builder who has never put software into production and has never fixed an on-call issue at 3am (something I will never forget, right up there with every production issue I personally caused and the resultant learnings from those, which are burned in my brain forever). When I first tried to ski as an adult, I was thinking about what I might break. I wanted to ski, it looked so fun and freeing, but I was old enough to see the consequences and I didn’t fancy hobbling around London with a broken limb or worse. My biggest issue was I hadn’t yet learned how to turn or stop effectively and without that I was a runaway train on a ski slope.

我把这篇文章的草稿分享给了 Martin，他也和我一样是很晚才学会滑雪的。他指出了这个类比不成立的地方（和所有类比一样，我喜欢把它推到极限，双关一下）。在滑雪道上，你见过无数人顺利滑到底，没摔断过骨头。教练已经在同一条雪道上教过成千上万的人。他们知道哪些技能重要，也知道如何教会别人这些技能。如今的智能体开发，更像是一次穿越未知地带的野外旅行。我们还不知道哪些技能最重要。几乎没人——如果真有的话——安全走完了这趟旅程，而关于如何应对的反馈来得很慢，甚至根本没有。正如 Martin 所说，只有当一个由智能体大量构建的系统在生产环境中运行了一段时间，经历过几轮变更，而且没有把我们所有的飞机都派去阿伯里斯特威斯，我们才能知道它是否真的可用。构建完成，不等于在生产环境中正常运行。或者用 Charity Majors 的话说：“预发布环境不过是台经过美化的笔记本电脑。只有生产环境才是真正的生产环境。”这就是为什么有人说“它在我的机器上能跑”时，通常是在开玩笑。至少我每次都会笑。When I shared a draft of this post with Martin, who also learned to ski late, he pointed out where the comparison breaks down (like all analogies I like to push them to the edge, pun intended). On a ski slope you’ve watched countless people reach the bottom with no broken bones. The instructors have taught thousands of people before you on the same slope. They know which skills matter and how to teach them. Agentic development right now is more like a backcountry trip across unknown territory. We don’t yet know which skills will matter most. Not many people, if any, have finished the trip safely and the feedback on how to navigate it is slow or non-existent. As Martin put it, we won’t know whether a heavily agent-built system works until it has run in production for a while, survived a few rounds of change, and not sent all our planes to Aberystwyth. Built is not the same as working in production. Or as Charity Majors puts it, “staging is just a glorified laptop. Only prod is prod”. Which is why when someone says “it works on my machine” it’s usually intended as a joke. Or at least I always laugh.

这让我对一种现象愈发感到不安：无论是技术出身还是非技术出身的领导者，都声称开发者缺乏好奇心，或是行动迟缓、接受新事物太慢，并把这归因于那些显而易见的担忧，比如怀念写代码（我也一样），以及担心自己的工作（现在谁不担心呢？）。我们最优秀的开发者，并不是站在一条别人早已征服的初级滑雪道上的惶恐新手。他们面对的是一片尚未标明路线的地形，并在认真地询问该怎么走。叫他们别那么谨慎，根本没抓住重点。他们需要加入负责绘制这片地形地图的团队。That solidified a nagging discomfort I have had with leaders, technical or non-technical, claiming devs aren’t curious, or are laggards slow to adopt, and putting that down to easy-to-point-at fears like missing writing code (I do too) and fearing for our jobs (who isn’t right now?). Our best developers aren’t nervous beginners on a nursery slope that everyone else has already mastered. They’re looking at unmarked terrain and asking sensible questions about the route. Telling them to be less cautious misses the point. They need to be on the team that maps it.

当然，经验也可能让我们过于依赖熟悉的做法。在经过整备的雪道上学到的一些东西，在野外未必适用，我们需要愿意检验自己的假设。Of course, experience can also make us too attached to familiar practices. Some of what we learned on the groomed slopes won’t hold out there, and we need to be willing to test our assumptions.

双方都面临的挑战A challenge for both sides

因此，领导者和开发者都面临着挑战。领导者需要认真倾听，分辨哪些担忧确有价值，哪些只是对改变的抗拒，并为实验创造真正的空间。这意味着要留出时间、允许犯错，也不能用智能体生成了多少代码来衡量成功。开发者则需要把自己的经验带入这些实验，并做好准备，接受一些原有假设可能已不再成立。So there’s a challenge here for both leaders and developers. Leaders need to listen carefully enough to tell useful concerns from reluctance to change, and to create real room for experimentation. That means time, permission to get things wrong, and not judging success by how much code the agents produced. Developers need to bring their experience into those experiments and be prepared to find that some of their assumptions no longer hold.

一些熟悉的做法会变得更加重要。另一些则需要以不同的形式呈现。没人会先把地图交到我们手上。Some familiar practices will become more important. Others will need a different shape. Nobody is going to hand us a map first.

如果你真正在意的是做对的事，并把它做好，那么你的判断力正是这种全新工作方式所需要的。带上你的谨慎吧。接下来，让我们出发，走进雪地。If you care deeply about building the right thing and building it right, your judgment is exactly what this new way of working needs. Bring the caution. Then let’s set off into the snow.