别再怀疑 AI 开发：用可靠性与信任评估真实成效
原题Stop being skeptical about AI for development with Charity Majors
推荐理由Charity Majors 把 AI 辅助开发从立场争论拉回工程系统：速度、代码量和部署频率都不能单独代表生产力。当工程师开始交付没有逐行读过的代码，团队就会透支「信任账户」，必须通过测试、确定性模拟、评测、护栏、可观察性和生产反馈重新积累信任。访谈同时承认提速与故障返工都可能真实存在，适合用来校准 AI 开发的收益与代价。管理者应共同记录客户价值、软件健康度、事故和返工，而不是只展示更容易被放大的局部效率数字。
看前速览
Charity Majors 与 The Pragmatic Engineer 认为，评估 AI 辅助开发应看团队是否交付可信结果，并以测试、评估、护栏和可观测性取代对生成代码的盲目信任。
用超越个人产出与速度的方式衡量工程成果
指标能揭示一些有用维度，却无法替代对个人职责、团队产出、软件质量，以及客户是否获得更好功能的具体理解。
把 AI 生成代码视为信任账户问题
使用无人读过的代码会从实施环节透支信任，因此团队需要通过测试、评估、护栏、可观测性和生产反馈把信任重新赚回来。
AI 带来的收益可以与可靠性成本同时存在
快速的本地迭代并不能否定粗制代码、故障、返工或质量下降的报告；团队应比较具体证据，而非按采用 AI 的身份立场争论。
转型期更需要资深判断与行动能力
工程师和管理者应学习这些工具，同时紧贴系统行为与用户价值，把不确定性转化为审慎行动，而不是被动焦虑。
完整摘要
这场长篇对谈将 AI 辅助开发视为工程系统问题，而非乐观派与怀疑派之间的立场之争。Charity Majors 质疑以个人产出或交付速度代替生产力判断的习惯，指出团队更应考察软件质量、客户价值与系统的真实健康度。讨论的核心框架是信任账户：当工程师依赖自己未读过的代码时，实施环节中的信任会被透支，必须通过测试、评估、护栏、可观测性和生产反馈重新积累。嘉宾也解释了为何 AI 拥护者能看到真实的迭代提速，而运维人员会遭遇粗制代码、故障和返工；两种观察可以同时成立。对工程师和管理者而言，可行的做法是持续实验、保留技术判断、共享收益与成本的证据，并在快速变化中建立行动能力。
文字稿
Stop being skeptical about AI for development
Charity Majors and The Pragmatic Engineer approach AI-assisted software development as a practical engineering question rather than a culture-war test. The conversation begins with an old problem that becomes sharper with AI: can anyone measure an individual engineer’s productivity? The answer is necessarily incomplete. Metrics can illuminate some dimensions, but they cannot substitute for understanding a person’s role, the team’s output, or the quality of the resulting system.
Speed is not the definition of better
The guests note that delivery speed is tempting because it is easy to count. Yet shipping more changes does not automatically create better functionality or happier customers. AI pushes organizations to ask more demanding questions: what does good look like, what does productivity mean, and what outcomes should a team optimize for? Those questions matter more than a headline count of generated code or deployment frequency.
Trust has to be earned with evidence
A central idea is that code written by AI should be treated as code produced by an unreliable actor. That is not wholly new: operations and reliability teams already build confidence in complex systems through tests, deterministic simulation, evaluation, guardrails, observability, and feedback from production. If engineers increasingly ship code they did not read line by line, the lost trust must be replenished somewhere else in the delivery system.
Two camps can both be seeing reality
Majors is sympathetic to both enthusiastic adopters and people alarmed by AI’s effects. One group sees practical wins and faster iteration; another sees slop, outages, extra work, and declining reliability. Neither perspective has to be fabricated for the other to be wrong. The useful response is to share concrete evidence about both gains and costs, then improve the system around the tool instead of arguing from identity.
Agency matters for careers
The discussion also turns to engineers, managers, and changing career paths. The durable advantage is not passive certainty about the future but staying close to real work, learning the new tools, and retaining judgment about system behavior and user value. The closing message is deliberately active: anxiety and excitement may feel similar, but agency changes what people can do with either feeling.