当代码近乎免费，瓶颈跑去了需求、集成、验证、对齐

当代码生产近乎免费，软件交付的瓶颈就从”写代码”跑到了别处：定义对的问题、把片段拼成能跑的整体、验证它确实是对的、让组织对齐。 这是约束理论（Theory of Constraints）在软件业的一次重演。制造业 40 年前就趟过这条路：每当一道工序变便宜，瓶颈不会消失，它只是挪到下一道最贵的工序。看懂这一点，你就能解释一个普遍的困惑：AI 编程工具全公司铺开了，写代码明显快了，交付速度却没怎么变。

一位制造业集团的 CIO 给我看他过去半年的数据。IT 团队 80 多人，全面上了 AI 编程工具，单看代码产出，人均提交量和合并速度都涨了三成以上。但业务侧的体感完全不同：一个智能排产的小功能，从立项到上线还是 3 个月起。他原以为工具能带来 2 倍提速，结果只买到了”代码写得快”。他的话很直：”我花了几百万买 license，买到的却是开发更忙、业务更急。”

一、制造业 40 年前就知道：瓶颈会跑

要理解当下，先借制造业一副戴了 40 年的眼镜。

1984 年，物理学家出身的以色列顾问 Eliyahu Goldratt 写了本小说《目标》（The Goal），讲一个濒临破产的厂长怎么救活一座工厂。全书的核心就一句话：任何系统的产出，由它最窄的那个环节（约束，也就是瓶颈）决定。 加宽非瓶颈环节，对总产出毫无帮助；只有加宽瓶颈本身，整体才会变快。而一旦你加宽了瓶颈，瓶颈立刻挪到下一个最窄的地方。这就是约束理论（Theory of Constraints，TOC）。

他假设错了瓶颈的位置。他的真实瓶颈是另一回事：每一个新功能都要穿过 MES、ERP、质检系统、车间终端，外加一套监管报送口径，集成和联调吃掉了大部分工期；而 AI 生成的代码，没有任何一道正式的验收关卡挡在它和生产环境之间。代码写得再快，也只是在错误的瓶颈后面排队。

自动化的瓶颈之谜

制造业过去 40 年的自动化史，几乎是一部”瓶颈搬家史”。当数控机床让切削变便宜，瓶颈挪到了换模和质检；当柔性产线让换模变快，瓶颈挪到了排产和供应链协同；当 MES 让排产变准，瓶颈挪到了需求预测和跨厂调度。每自动化掉一段，下一段就浮上来。自动化从不消灭瓶颈，它只给瓶颈换了个位置。

这条规律不是制造业的专利。2026 年 7 月，a16z 播客《Software in the Age of Agents》里，前微软 Windows 总裁 Steven Sinofsky 用企业软件的例子，独立得出了同一条结论。他的原话是：

“The long tail got no shorter. It just got longer in a different way.”（长尾一点没变短，只是换了个方式变得更长。）

机器人取代人类工作的谬误

他举了 Amazon 客服：砍掉电话、让 chatbot 直接补发商品，看似省了人力，可后端立刻冒出”怎么防止同类问题再发生”的根因分析需求，比接电话更复杂。报销流程也一样：OCR 自动入账之后，财务要做的变成了差旅绩效优化、动态比价——工作没消失，只是从”录入”上移到了”分析决策”。一位微软老兵、a16z 合伙人，没用 Goldratt 的理论，却得出了和制造业 40 年前一样的判断。一个来自车间，一个来自企业软件，两条独立路径指向同一条规律。

不过要给这条规律补一个限定，免得被读成绝对真理。确实有瓶颈是被永久消灭的：打字员、电话接线员、铅字排版工——这些工种没有”上移”，是真切消失了。判断一种工作会被搬家还是被消灭，关键看自动化释放的产能是催生了新需求（经济学叫杰文斯悖论），还是单纯让这块需求萎缩。企业核心系统周围的多数工作属于前者：账算得越快，老板想看的分析就越多越细。所以这里的结论不是”自动化能裁掉多少活”，而是”把人和预算，从被自动化的那层，搬到新冒出来的那层”。（企业软件视角的长尾搬家，番外篇《企业软件粘性》有完整展开。）

用制造业的瓶颈思维看软件

这件事和软件的距离，比你想的近。2013 年，Gene Kim 把 Goldratt 的工厂故事几乎原样搬进了 IT 运维，写出《凤凰项目》（The Phoenix Project）：一个 CIO 怎么用约束理论救活一个快要拖垮整家公司的 IT 部门。所以”用制造业的瓶颈思维看软件”是条已经验证过的路径，不是临时找来的比喻。

回到软件：写代码正在变成最便宜的一环

三组数字，把”代码生产成本趋零”说清楚。

AI 技术博客

Copilot、Stripe 和 NVIDIA：生产一行代码的单位成本正在快速逼近零

Copilot：GitHub 自己的研究测出，在启用 Copilot 的文件里，约 46% 的代码由 Copilot 完成。注意口径，这是”启用文件内”的占比，不是全 GitHub 所有代码的 46%。
Stripe：内部自研的 coding agent “Minions”，每周产出并合并的 PR 超过 1,300 个（早期 1,000，持续上涨）。这里有个关键细节值得记住：每一个 PR 都要经过人工 review 才合并。Stripe 把”写”自动化了，把”验收”留给了人。这一点第四节会用到。
NVIDIA：黄仁勋公开说过，100% 的 NVIDIA 工程师都在用 Cursor 这类 AI 编程工具，”不用 AI 工作”在 NVIDIA 已经不被接受。

把三组数字叠在一起，结论很硬：生产一行代码的单位成本，正在快速逼近零。

尖锐的问题随之而来：既然写代码几乎不要钱了，为什么软件还是这么贵、这么慢、这么难交付？答案正是约束理论给的：你加宽了”写代码”这道工序，瓶颈只是挪走了。它挪去了哪里？

三、瓶颈跑去了四个地方

这一次，瓶颈集中在四道工序上。每一道，都是 AI 短期内碰不到的。

第一道：定义对的问题。 AI 能在几秒内写出”你嘴上说的那个功能”，但它写不出”你真正需要的那个功能”。多数软件项目失败，根子在做出来的东西没人用，一开始就没把要解决什么问题想透。代码生产变便宜之后，”把一个模糊的业务困扰，拆成一个清晰、可解、值得解的规格”（problem formulation）成了最稀缺、也最贵的能力。制造业同行对此不陌生：工艺路线和工程图纸定错了，车间加工得再高效，也是批量生产报废品。

第二道：系统集成。 AI 擅长生成”一段代码””一个函数””一个页面”。可一个能上线的系统，是几百个片段的集成，它们要互通数据、处理边界、保持一致、扛住异常。生成片段便宜，把片段拼成一个可靠的整体昂贵。这道成本，根子在组织和架构对齐上，正是康威定律和团队拓扑关心的事（见本系列前两篇）。回到开篇那位制造业 CIO：他的工期没耗在写代码上，耗在了 MES、ERP、质检、报送这几套系统的联调上。

Aula 3: Verificação. O código aumentou drasticamente, mas a confiabilidade é irregular. Quem decide que “isso está certo”? Testes, revisão de código, observabilidade e lançamento em gradiente são as tarefas de verificação que não param de crescer. Essa é a maior barreira subestimada e a mais profunda da indústria. A quarta seção será abordada separadamente.

Aula 4: Alinhamento de Organização. Quando a equipe tem vários agentes de IA, quem decide o que fazer, quem revisa e quem é responsável pelos resultados? Isso é uma extensão da Lei de Conway e da topologia da equipe, e o alinhamento da organização se tornou uma barreira. A série será abordada na 11ª parte: quando os nós da organização não são apenas humanos, como a governança se torna uma vantagem competitiva.

4、A maior barreira: Verificação, e o que a Toyota está ensinando sobre “Autonomização”

Das quatro barreiras, a verificação é a mais fácil de ser mal interpretada. Muitas pessoas a entendem como “se o AI escreve rápido, vamos fazer mais testes”. Isso só está correto pela metade. Para entender por que a verificação está se tornando mais cara, precisamos entender a concepção da Toyota que é frequentemente citada e errada: Autonomização (Jidoka).

Antes de corrigir um erro comum, vamos esclarecer. A autonomização não é “usar AI ou máquinas para substituir humanos” ou “fazer com que humanos sejam como máquinas, trabalhando sem parar”. Essas duas direções estão erradas.

自動化的真谛：人在场，质量在每道工序

自働化的字面就藏着答案。日语里”自動化”是普通的自动化，丰田特意用”自働化”，那个”働”带了人字旁，强调的是”带人字旁的自动化”（GPT/Token/CoT 等保留原文或按术语表）。它的准确含义是：当机器或产线检测到异常，自动停下来，让人介入、把根因解决掉，再恢复生产。 它有两个机制并行：机器自己装了异常检测，会自己停；产线上任何人发现不对，拉一下安灯绳（andon），整条线立刻停。质量不在末端检，而是嵌在每一道工序里、就地解决。

这里有个反直觉的结论，正是它直接对应软件：自动化越深，质量关卡和人介入的分量只增不减。 自働化把人从”重复操作”里解放出来，重新摆到”发现异常、停线、解根因”这个位置上。丰田给一线工人拉停整条产线的权力，恰恰是因为它清楚：自动化再强，也得有人能在出问题时喊停。这才是”赋予机器人的智慧”那句口号的真正所指：让机器具备停下来呼叫人类的能力。人始终在场，负责解根因。

自动化的风险：质量控制的重要性

软件正在经历快速的自动化进程，GitClear 对 AI 辅助代码的质量研究已经观察到重复代码块增加、短期 churn 代码上升的迹象：AI 写得快，但也写得”看起来都对”。当大量代码没人逐行写过，传统的”开发心里有数”这种信任机制就失效了。这时候你要的，就是软件版的安灯绳和停线机制：

测试（单元、集成、端到端）从”尽量做”升级为硬门槛，没过不许合并；
Code review 的重点从”检查写法”转向”检查意图和边界”：这段代码到底想解决什么，边界条件覆盖了没；
可观测性（监控、日志、追踪）成标配，因为线上行为比代码本身更能说明问题；
灰度发布 / feature flag 让 AI 生成的东西先在小范围验证，确认没问题再放量。

回头看第二节 Stripe 那 1,300 个 PR：写归 agent 写，合并这道关全留给了人工 review。这就是自働化在软件里的活样板：把生产自动化，把验收留在人手里，并且赋予人”挡住它”的权力。生产变便宜了，质量控制变贵了，这是一条 40 年没变过的规律。

五、”定义问题”的溢价：比 prompt 更值钱的能力

如果说验证是被低估的瓶颈，“定义问题”就是被严重低估的能力。

prompt engineering 火过一阵，不少人以为“会写 prompt”就是核心能力。可 prompt 只是“把问题表达出来”的技巧。真正稀缺的是再往前一步：problem formulation，把一个模糊的业务困扰，拆成一个清晰、可解、值得解的问题。这一步，AI 短期内做不到，因为它得等你先告诉它“问题是什么”。

制造业老法师对这一步的分量最有体感。一张工程图纸、一条工艺路线定错了，下游加工和装配再高效，也是批量生产错误。软件同理：需求规格定错了，AI 帮你以十倍速度造出一堆没人要的东西。

判断一条：别再卷“写代码的速度”，去练“拆问题的清晰度”。 在组织里，这意味着把“需求定义”和“验证验收”摆成正式岗位，别再让开发顺手做。AI 把实现变便宜之后，这两个岗位的回报上升最快。

六、四个行业的真实瓶颈长什么样

把“瓶颈转移”套到四个行业，每个行业的瓶颈都不在写代码上。

制造业。主线就是开篇那位 CIO。智能排产、质量追溯、能耗优化这些功能，技术上都不难，模型不少是现成的。瓶颈卡在 MES / ERP / 质检 / 报送几套系统的集成联调，以及车间终端的实地验证上。这类项目的代码往往写得很快，可 MES/ERP 几套系统的联调要吃掉数倍于写代码的时间；只有把验收岗摆到车间终端和集成环节，缺陷才能就地拦下来，而不是流到投产才暴露。

电信 / 运营商。一个套餐变更或政企专线的开通流程，要穿过渠道、计费、CRM、网络开通、装维排程好几个域。AI 让各域的开发都快了，可跨域的端到端联调和一致性验证才是工期大头。运营商还有一个独特瓶颈：合规与对账。计费差一分钱都是事故，验证的分量比任何行业都重。以政企专线开通为例，AI 把各域开发都加快了，端到端联调加上计费对账，往往仍要占去工期的大半。

金融。一个信贷风控或反洗钱规则的调整，跨 App、核心系统、风控引擎、数据中台、监管报送。这里验证的权重极高，因为错一笔就是合规事故。瓶颈在可解释、可审计、可回溯：AI 写的规则再准，过不了监管那一句”为什么这么判”，照样上不了线。反洗钱规则迭代就是典型：AI 加快了规则编写，可模型的可解释性审核和监管报送对齐加在一起，常常吃掉整个周期的一大半。

电商。一个促销或大促功能，跨商品、交易、营销、仓储、客服。AI 让页面和接口写得飞快，瓶颈挪到了压测、库存一致性、风控防薅羊毛、对账上。大促当晚挂的，从来不是写得不快的代码，是没验证到的边界。大促准备就是个缩影：促销页 AI 很快就能生成，可端到端压测和库存一致性验证，常常要占去备战的大半工时。

四个行业的共性很清楚：AI 加速的是”写”，卡住的是”拼、验、对齐”。 把省下来的开发产能投到这三件事上，才是真提效。

七、判断错了会怎样：三种最常见的错配

第一种：把”代码写得快”当成”交付变快”。 这是最普遍的错觉。代码只是交付链上的一环，加宽它不会让整条链变快，只会让瓶颈后面堆更多半成品。约束理论管这叫库存，软件里叫未验收的 PR 和没联调的分支。结果就是开发更忙、业务更急、产出没变，正是开篇那位 CIO 的处境。

第二种：生产提速的同时，拆掉了质量关卡。 这是违反自働化的典型错误。有人觉得”AI 写得又快又好，code review 可以简化、测试可以砍”。恰恰相反，生产越快，安灯绳越要紧。砍掉验收关卡，等于让没人在场的流水线全速空转，缺陷会以更快的速度涌向生产环境。

第三种：在非瓶颈上砸钱。 集成是瓶颈，你却去买更多 AI 编程 license；验证是瓶颈，你却去招更多开发。约束理论早就讲透：在非瓶颈上加投入，对总产出零贡献，只会让账面更难看。正确的顺序是先定位瓶颈，再把资源压到瓶颈上。

八、对决策者的启示

启示一：购买工具之前，先绘制瓶颈图。 把你最近三次卡住的交付拆开看，时间到底花在哪。是写不出代码，还是拼不起来、没人验、需求没想清？标不出来的，就是在按技术层瞎猜。瓶颈图比任何工具采购清单都值钱，它能挡掉大企业至少一半的无效 IT 投资。

启示二：把节省的产能，投入到需求和验证上。 AI 让开发变快，意味着你能释放出更多的人手。把这些人正式编进”需求定义”和”验证验收”两个岗位，别让他们继续埋头写更多代码。这两个岗位的回报，在 AI 时代上升最快。

启示三：为软件安装一道安全门槛。 自动化最直接的落地，是在你的 CI/CD 里设硬门槛：测试不过不许合并、review 必须查意图和边界、灰度先小范围放量、可观测性成标配。生产越自动化，这道关越要牢。这是在防止”代码免费”变成”事故免费”。

启示四：重新调整人的位置，别把人撤掉。 自动化指向同一个结论：自动化越深，人越要被摆到”判断、验收、解根因”的位置上。把人从重复操作里解放出来，重新部署到验证和对齐上，这是 AI 时代组织设计的核心动作，也是本系列后面几篇要展开的内容。

九，你可能想问

“我们只是局部试点 AI，没必要画全公司瓶颈图吧？” 试点也得先看清：试点的这个环节，到底是不是真正的瓶颈？如果卡点其实在集成或验证上，那在”写代码”这个环节试点 AI，就是在非瓶颈上砸钱，正好踩中第七节讲的第三种错配。先做一次小范围的瓶颈诊断，工具的钱才花得值。

“验证关卡会不会拖慢交付？” 短期会有摩擦，长期是加速。没有验收关卡的”快”，是把缺陷推向生产环境的快，返工成本十倍起。自働化的经验是：就地解决一个缺陷的成本，是让它流到下游再解决的零头。

“这和我们正在搞的 AI 转型什么关系？” 关系很直接。AI 转型最常踩的坑，就是假设瓶颈在”写代码 / 产能”上，然后买一堆工具去加宽这一环。先做瓶颈诊断，再决定钱花在哪。这也是我把”能力评估”和”价值场景识别”放在《AI 转型 7 步教练框架》靠前位置的原因：先看瓶颈在哪，再谈工具。

Auto-revisão inversa (não embellish na resposta): A última vez que você ficou preso em uma entrega, onde foi gasto mais tempo: escrevendo código, ou montando, verificando e alinhando? Dos códigos gerados por suas ferramentas de IA, quantos chegam de forma estável ao produção e são realmente usados pelos usuários? No seu CI/CD, existe uma barreira rígida que impede o merge se os testes falharem? Se você se sentir inseguro ao responder qualquer uma dessas três perguntas, não corra para comprar mais ferramentas de IA — primeiro identifique seu gargalo. # Próximo passo
Esta é a terceira de 15 partes da série “Transformação da Engenharia de Software na Era da IA”. Passamos da Lei de Conway (organização define arquitetura) e Team Topologies (como projetar organizações) para o deslocamento de gargalos (quando o código é quase gratuito, para onde vão os gargalos?). O próximo artigo (número 4) adota uma perspectiva mais prática: como escolher as principais ferramentas de programação com IA. Mas a conclusão pode ser contra-intuitiva: a escolha é, no fundo, uma decisão organizacional — deve ser feita com base em seu nível de maturidade e governança, não em “qual ferramenta gera código mais impressionante”. —
Nota sobre a série: Esta série acompanhará continuamente as últimas evoluções em ferramentas de programação com IA, arquiteturas organizacionais e paradigmas de engenharia de software, como as novas implicações da Lei de Conway na era dos agentes de IA (2026) e a maturidade do ecossistema de ferramentas mais recentes. Siga a série para obter insights atualizados continuamente. # Sobre esta série

A transformação da engenharia de software na era da IA é uma série de estudos aprofundados destinada a CIOs/CDOs/CTOs e responsáveis por digitalização em setores como telecomunicações, finanças, manufatura e comércio eletrônico, composta por 15 artigos. Baseada em mais de 200 artigos acadêmicos e relatórios industriais, oferece referências decisórias com marcação de nível de evidência.
Sou ex-engenheiro da IBM e coach certificado pela ICF, com experiência na implementação de projetos de IA e digitalização em operadoras e grandes empresas. Tudo o que escrevo aqui são julgamentos práticos frutos de experiências reais, acompanhando empresas na superação de desafios reais.

Fontes de referência (todas verificadas)

a16z (2026). Software in the Age of Agents. The a16z Podcast. (Citação icônica de Steven Sinofsky, ex-presidente global da Windows da Microsoft: “The long tail got no shorter, it just got longer in a different way” — perspectiva independente de software corporativo que confirma a Lei da Mudança de Localização do TOC; fonte primária — áudio original do podcast. Marcação de posição: parceiro da a16z / ex-executivo da Microsoft, posição de VC. Convidados verificados: Seema Amble, parceira da equipe corporativa da a16z; Steven Sinofsky, ex-presidente da Windows da Microsoft (board partner); Elena Burger, redatora da a16z; lançado em julho de 2026.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Fonte original da Teoria das Restrições (TOC); fonte primária; romance ambientado em uma fábrica de manufatura.)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Transplanta a TOC de Goldratt diretamente para a operação de TI; ponte entre manufatura e software; fonte primária.)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = automação com o radical “humano”; parada automática em anomalias + intervenção humana para resolver causas raiz; sistema Andon; fonte primária.)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot ativa conclusões internas de arquivos em cerca de 46% dos casos; métrica definida como “file-level enabled”; fonte primária.)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ relata mais de 1.300 PRs por semana, todos revisados manualmente (fonte primária + secundária.)
NVIDIA / Jensen Huang. Declaração pública de que 100% dos engenheiros usam ferramentas de programação por IA como Cursor. (Declaração direta.)
GitClear (2025). AI-Assisted Code Quality Research. (Observa aumento em código repetitivo e churn de curto prazo sob assistência de IA, sustentando a tese de que “validação está ficando mais cara”; fonte secundária.)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Desempenho de entrega determinado por cultura, velocidade de fluxo e feedback — não pela velocidade individual de codificação; fonte primária.)