为什么优秀的开发者对智能体开发（Agentic Development）如此警惕？
英文标题：🔶 Why are good developers so wary of agentic development?
面对席卷而来的 AI 编码智能体浪潮，许多资深开发者并未盲目全力投入（Go all-in），这并非源于守旧或职业焦虑，而是出于“能构建出来不等于能在生产环境中稳定运行”的技术审慎。Thoughtworks 团队通过完全交由 Agent 编码的极端实验发现，虽然开发速度大幅提升，但频繁变红的 CI 构建揭示了交付稳定性下降的严峻现实（正如 DORA 2025 报告所示）。在 Agent 时代，工程重心正从键盘编写转向白板架构设计、测试约束与 Harness 构建，而优秀开发者的生产实战经验与谨慎判断，恰恰是探索未知无人区不可或缺的安全指引。
6.7 KB
84.4 KB
2.2 MB
10.8 KB
中文
TL;DR
优秀开发者对智能体开发（Agentic Development）的警惕，源于他们深刻懂得：能够构建出来，和在生产环境中稳定运行完全是两码事。
令我感到意外的是，竟然有如此多的优秀开发者对全力投入（go all in）编码智能体（Coding Agents）持保留态度。这些开发者通常是新技术的最早尝试者，在很多情况下，他们甚至亲手发明过推动软件高质量构建的新工具和新实践。那么，为什么大家会产生如此大的顾虑？
最简单（或者说最偷懒？）的解释是：他们热爱亲手写代码，或者担心被抢走饭碗。我相信对某些人而言，在某些时刻确实如此。我交流过的部分开发者也确实有这种想法，但我总觉得背后还潜藏着更深层的东西——一种隐匿在显而易见的借口之后的担忧。每半年当我们筹备 技术雷达（Technology Radar） 时，我都会专门留出一块时间进行开放空间研讨（Open Space）。今年 9 月，在一场将智能体开发推向极限的讨论中，我终于看清了这种恐惧究竟源于何处。
把事情做对（Building it right）
Thoughtworks 的团队极度关注“做正确的事，并且把事情做对（building the right thing and building it right）”。这几乎是我们默认的工作方式与思考逻辑，也是我们发明并倡导的众多工程实践和技术的源头。我们追求的是既实用又有价值、在未来依然易于迭代、且绝不会在生产环境中崩溃宕机的软件。我们的开发者之所以很早便采纳、倡导甚至发明了最早版本的持续集成（CI）、结对编程、自动化测试、持续交付（CD）、微服务等工程方法，正是因为它们能帮助我们把软件“做对”。
早期的编码智能体使得代码生成变得极其容易，但这其中也充斥着大量绝不该出现在生产环境中的劣质代码——它们由那些根本不懂“做出东西”与“让其在生产环境中安全稳定运行”之间存在巨大鸿沟的人所生成。尽管如今的工具已经有了极大的飞跃，但经验丰富的开发者依然心存疑问：我们能确信这是正确的业务行为吗？它真的按预期工作了吗？模块边界划定是否合理？系统后续还能演进吗？它是否遵循了我们付出惨痛代价才总结出的原则与实践，从而让我们确信它既能满足客户需求又能在生产中扛住压力？当故障发生时会发生什么？后续接手的团队能维护得了吗？诸如此类。
在所有这些疑问的底层，潜藏着一个更巨大的问题：当没有任何人拥有以这种方式构建系统的成功经验时，我们到底能在多大程度上信任它？ 换句话说：如今我们在生产环境中运行的几乎每一套系统，都是以旧方式由我们（期望中）可以信赖的人工手工构建出来的；而如今我们所构建的一切都在采用一种全新的范式，而我们尚不具备长期与之共处的经验。
在技术领域深耕 25 年以上之后，我愈发看重人们通过经验所沉淀出的判断力。我经常把同样的问题分别抛给大模型和 Thoughtworks 的资深技术专家。面对棘手难题时，我从人类那里获得的答案往往更有用，或者更具洞察力，他们凭借极其具体的实战经验帮助我更好地理解核心要点。他们会挑战前提假设，能认出十年前踩过的坑并识别出熟悉的故障模式，或是敏锐发现隐藏在纯技术问题之下的组织架构根源。现在我已经可以接触到海量的信息，但我依然需要能够帮我理清“什么才重要”的人，我依然需要智慧和洞察力。而这种关键的判断力，恰恰是那些心存谨慎的资深开发者正在极力保护的核心资产。
我想把话说得更明白一些：他们绝非抗拒使用编码助手（Coding Assistant），他们抗拒的是盲目地“All-in”，把所有执行过程完完全全拱手让给智能体。他们不敢轻易把双手完全脱离方向盘，因为他们没有十足的把握确信智能体已经拥有了足够完备的护栏（Guardrails）来让其自行狂奔。
在白板前度过的一周
最近，我们的欧洲区 CTO Giles Alexander 召集了资深工程师、基础设施顾问和产品人员，进行了一周完全按照这种范式工作的实验。所有人一行代码都不写，全部交由 Agent 智能体构建。实验的目的并不是为了证明“一周内能不能搭出一个航空公司应用”（有趣的是，他们完成了 80%，大家都知道这在现实中意味着什么……有些规律你编都编不出来！）。这场实验的核心目标，是为了探究当 Agent 包揽所有编码工作时，团队的工作形态会发生怎样的演变。你可以点击 这里 阅读他们的部分实践沉淀。
在我们的交流中，最触动我的是他们花在白板前的时间之长。梳理业务领域、划定上下文边界、决定下一步的演进路径，并制定出 Agent 能够落地执行的严密计划。与此对应的是，智能体甚至在团队下班后还在持续不断地生成代码。
人类团队同时也在围绕这些工作设计反馈回路：编写测试、定义契约（Contracts）、进行架构检查以及配置交付流水线。他们一直在苦思冥想，如何在给予 Agent 足够推进自由度的同时，依然对产出结果保持信心。键盘前的大部分工作，实际上是在指导智能体将这些学习到的规则沉淀到开发环境与约束骨架（Harness）之中，以便构建和测试智能体在下一次迭代中能正确执行，从而对构建出的软件更有把握。有趣的是，最终团队中提交业务功能代码最多的人，反而是产品经理。
当我让他们估算时间分配时，他们表示大约花了 ⅔ 的时间在白板前，⅓ 的时间花在 Harness 约束框架上。这或许能为开发者未来的工作模式提供一些线索。但先别急着去彻底重组你的研发团队，故事还远没有结束……
应用跑起来了，但构建频繁标红
应用确实能跑起来，但 CI 构建却频繁变红。在他们本地机器上明明跑得好好的——说实话，这名场面真是编都编不出来！持续不断变红的构建令我感到极度不适。红色的构建必须代表着某种严肃的信号：停下来、排查问题、把它修好。如果构建红得太频繁以至于大家对此麻木，我们以后还如何及时察觉到真正的严重故障？而如果我们连检查机制都不再信任，绿色的构建也同样失去了让人放心的意义。而这恰恰是 持续集成（Continuous Integration） 在过去 25 年中极力主张并致力于消除的不确定性。
我们目前仍在深入探索如何解决这一问题。请记住，这本就是一场探寻智能体开发边界的极限实验。究竟是由于太多 Agent 并行工作导致彼此的代码修改相互践踏冲突？还是系统的模块化程度还不足以支撑 Agent 分工负责独立模块？亦或是代码变更的涌入速度已经完全超过了测试检查的执行速度？抑或是所有这些因素兼而有之？无论如何，我们都必须重新思考如何攻克这“最后一公里”的挑战。我甚至预见到，持续交付 / DevOps 运动在 Agent 时代将迎来一场全新的复兴与重构，正如整个软件开发生命周期正在被重塑一样。而且这不仅局限于我们的实验，DORA 2025 年度报告 的研究也证实：AI 的采纳与更高的交付吞吐量直接挂钩，但同时也会导致交付稳定性的下降。而这正好是持续交付和 DevOps 从诞生之日起就在努力解决的问题！
所有这些挑战都在团队内部引发了激烈的交锋。当你不再逐行审查代码、且测试用例完全由 Agent 随代码一同生成时，测试驱动开发（TDD）该扮演怎样的角色？验收测试、契约测试以及系统边界上的校验应该部署在何处，才能既增强信心又不至于过于脆弱易碎？鉴于我们可以极快地推倒重构，在彻底放手让 Agent 编写之前，我们到底该做多少前置设计？我们能否明确感知到究竟在哪一个临界点上我们已经走得太远失控了？其中最大的难题之一莫过于交付批次（Batch Size）的大小。我听闻许多团队正在从细粒度的 Story（用户故事）转向粗粒度的 Epic（史诗）。这对于开发推进速度而言或许是件好事，但你的 CI 流水线是否有能力快速且并行地消化如此大体量的工作单元？
实验团队并没有在一两周内彻底解决所有这些疑难（他们换了不同的团队进行了两次实验）。如果有人声称自己已经完全搞定了，我绝不会相信。但这恰恰正是需要资深开发者深度介入的工作：在实践中实验、质疑，并帮助我们发现哪些老工程实践依然历久弥坚，哪些领域亟需创造全新范式。
离开平整的压雪道
在与几位参与实验的资深开发者深入交流后，我的脑海中不断浮现出学滑雪的场景。小孩子们滑雪往往无所畏惧地直接往山下猛冲，这很像那些从未将代码部署到生产环境、也从未在凌晨三点被紧急 On-call 叫醒处理故障的新手开发者（那种深夜排障的经历我毕生难忘，它与我亲手引发过的每一次生产故障以及由此沉淀的教训一样，永远烙印在我的脑海深处）。而当我作为一个成年人第一次尝试滑雪时，我满脑子想的都是自己会不会骨折。我也很想滑雪，它看起来如此充满乐趣和自由，但到了这个年纪，我已经能清醒地预见到鲁莽的后果，我可不想断着腿甚至遭受更严重的伤在伦敦一瘸一拐。当时我最大的问题是尚未掌握如何有效转弯和急刹，缺乏这些控速手段，我无异于雪坡上一列失控脱轨的列车。
当我把这篇博文的草稿分享给同样很晚才学滑雪的 Martin 时，他指出了这个比喻的局限所在（就像对待所有比喻一样，我总喜欢把它推向极限）。在滑雪场上，你亲眼目睹过无数人完好无损地滑到了山底；教练们也曾在同一条雪道上教会过成千上万的前人；他们清楚地知道哪些技能至关重要，以及该如何传授。但如今的智能体开发，更像是一场穿越未知无人荒野的野雪探险（Backcountry Trip）。我们至今尚不清楚哪些核心技能最为关键；成功安全走完全程的人寥寥无几；关于如何导航的反馈更是极其缓慢甚至付之阙如。正如 Martin 所言，除非一套深度由 Agent 构建的系统已经在生产环境中稳定跑了一段时间、成功挺过了数轮业务变更演进，且“没有把我们的所有航班都阴差阳错地发往阿伯里斯特威斯（Aberystwyth）”，否则我们根本无法断言它是否真正管用。能够构建出来，和在生产环境中稳定运行完全是两码事。 正如 Charity Majors 所言：“预发布环境（Staging）不过是一台被美化了的笔记本电脑。只有生产环境才算真正的生产环境（Only prod is prod）。”这就是为什么当有人说“在我电脑上明明是好的”时，通常只是在讲一句自嘲的笑话——至少每次我听到都会笑出声来。
这也加深了我一直以来的某种隐隐不安：许多无论是技术还是非技术背景的管理者，动辄指责开发者缺乏好奇心、是抗拒采纳新技术的落后者，并将其归咎于诸如“怀念写代码的感觉”（我也怀念）或“担心被抢饭碗”（如今谁不担心呢？）这类显而易见的借口。我们最优秀的开发者绝非初级练习道上那些面对他人早已驾轻就熟的坡道却战战兢兢的新手，他们面对的是一片毫无路标的陌生险境，并在认真理性地审视行进路线。要求他们“放下戒心少些谨慎”，完全是本末倒置；相反，必须让他们成为那支负责绘制安全地图的核心先锋队。
当然，经验有时也会让我们对熟悉的旧习惯产生过度依赖。有些在平整压雪道上学到的技巧，在荒野中确实不再适用，我们同样需要勇于去检验和颠覆原有的假设。
双方共同面临的挑战
因此，这对于管理者和开发者双方来说都是一场硬战。管理者需要保持敏锐的倾听，准确区分有价值的技术审慎与消极的抗拒变革，并为团队创造出真正的试错探索空间。这意味着给予时间、允许失败犯错，并且绝不以 Agent 输出了多少行代码来评判成功与否。开发者则需要将自己深厚的实战经验倾注到这些实验中，并做好心理准备去面对某些既有认知不再适用的现实。
有些熟悉的工程实践将变得愈发关键；有些则必须演变出截然不同的全新形态。在未知的荒野前行，没有人会提前递给你一张现成的现成地图。
如果你坚守“做正确的事，并且把事情做对”，那么在这个全新的工作范式中，你的敏锐判断力恰恰是不可或缺的基石。带上这份审慎与警惕，让我们一同踏入风雪深处。
English / 原文
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 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.
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
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.
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.
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!
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.
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.