只须软件工程照旧团队相助，咱们就需要一种形貌让东说念主知说念系统怎么运作、为什么作念了某些决定、领域在那边，这个需求不会因为AI运转写代码就灭绝，有时违反，它变得更要津了。

往时大无数团队靠代码审查来经管这个问题，当有东说念主审查你的销毁苦求时，他们不单是在查残障，更是在经受高下文，相识某些决定为什么被作念出，这便是团队的隐性常识。在DevEx相通者社区The Hangar，咱们经常盘问代码审查。把柄《Looks Good to Me: Constructive Code Reviews》一书的作家Adrienne Braganza Tacke的不雅点，代码审查最紧迫的功能其实是记录留存：记录代码库是如何演变的、为什么这样变，而不单是是持bug。

那段对话刻下看来依然像是另一个时期了，咱们所熟知的通盘软件修复人命周期，不仅在加快，更在坍缩和被重新界说，我最近说过，咱们应该干掉代码审查，AI生成代码的速率远超东说念主类能审查的速率。销毁苦求堆积如山，或者被橡皮印记一盖了事，那说念审批关卡依然不再匹配咱们当下作念软件工程的形貌了。

但如果AI刻下生成了大部分代码，而莫得东说念主能读完通盘代码，常识该怎么传递?

在代码互异之上作念决策

我建议的经管代码审查瓶颈的决策是：把东说念主工查验点前移，去审查意图，审查代码应当得志的条约：规格诠释、决策、不停条款和验收步骤，常识传递这部分也通常适用。

如果团队在生成代码之前就审查了意图和验收步骤，常识传递就会在磋议过程中当然发生，你不需要从500行的代码互异里反推决策。你是在职何东西被构建之前，就对皆少数几个要津遴荐。审阅者读的是10行决策，而不是500行代码。

岂论是轻量级规格文档、一组验收步骤，照旧从prompt对话中提真金不怕火的重心，原则都一样：让决策可见、可审查，常识就在那里。

当修复者使用Cursor或Claude Code时，他们在继续作念决策：架构遴荐、活动量度、领域判定，这些决策存在于prompt对话中，存在于与智能体的往还交互里，但当销毁苦求提交时，这些高下文就没了，代码在，背后的推理不在。

在结束之前体式化意图这个办法并不新，活动驱动修复(BDD)、测试驱动修复(TDD)和按条约缱绻(Design-by-Contract)这些方法，都试图在写代码之前，用结构化的、东说念主类可读的规格来界说活动。BDD尤其要求团队用当然话语形容系统应该作念什么，写成连非技艺关连东说念主都能读懂和考据的场景，况且是在写任何代码之前。

这些方法往时常被视为支出，写体式化的活动形容和条约需要秩序和时辰。在寄托压力下，团队经常跳过它们。AI让它们变得更实用，而不是更伪善用。AI不错匡助生成结构化的验收步骤、活动规格，致使条约式形容。它也能匡助践诺这些步骤。

AI软件工程不是单东说念主领路

咱们时经常会听到有些工程师在外面跑智能体编排器，一天能产出10万行代码，比如Steve Yegge和他的Gas Town。有东说念主说这便是软件修复的畴昔——单东说念主修复者带着一群agent，但我不这样觉得。构建软件，即便有智能体加持，鲸鱼直播也不是单东说念主领路。

如果阿谁东说念主被车撞了，别东说念主能接办这个技俩吗?他们相识通盘作念过的决定吗?不成。在企业环境中，你需要冗余。多个关连东说念主、多个团队、相助。

常识传递的功能不会因为AI接管率高涨而变得不紧迫，它变得更紧迫了，因为系统实践作念的事和任何个东说念主对它的相识之间的差距，正在以前所未有的速率拉大。没东说念主但愿我方的高等工程师成为瓶颈，因为只须他们知说念我方是怎么从AI那里获得经管决策的。

当AI参与到历程的每一个方法时，相助的社会条约正在改变。存在作家身份腌臜——一个东说念主审查共事提交的代码时，不知说念对方花了若干元气心灵去相识这段代码的细节。审查员可能用AI来帮我方相识代码并发表辩驳，而作家可能用AI来恢复这些辩驳，却莫得花时辰简直阅读和相识它们。

在AI出现之前的团队里，一个低级工程师的销毁苦求会产生：

• 高等工程师就习用法模式给出4~8条辩驳

• 对于领域情况的往还盘问

• 一堂隐含的"我会怎么想考这个问题"的课

• 一位刻下知说念这部分代码存在的高等工程师

而在AI重度使用的团队里，通常的变更是：

• AI生成，稍作裁剪

• AI审查，稍作通过

• 销毁，零个东说念主对它造成了心智模子

新式债务：融会债务

我最近和磨真金不怕火、相关员Margaret-Anne Storey聊过，她为此创造了一个术语：融会债务(cognitive debt)，她当先是在一组用AI快速构建的学生身上留神到这个征象的，某个时刻，学生们告诉她，他们依然没法再对居品作念篡改了。磨真金不怕火一运转怀疑是技艺债务、代码紊乱，成果发现学生们蕴蓄的是一种新式债务。

他们依然搞不清我方在作念什么功能、为什么作念，他们不知说念团队里谁知说念什么，其中一个团队里，只须一个东说念主了解通盘代码并相识它，因为是他在监督生成代码的AI，而团队其他东说念主作念不到这少许，况且就连生成代码的阿谁东说念主，也并不简直相识生成了什么。

这便是团队运转用AI快速构建时的风险：因为现实中不可能审查数千行AI生成的代码而毁灭代码审查，却什么都不作念来替代常识传递的功能。

Anthropic的相关揭示了过度依赖AI编程助手在代码相识方面的缺点，他们对52名工程师的相关发现，AI扶持在职务速率上莫得带来统计显赫的提高，但在随后的相识测试中得分低了17%。降幅最大的是调试才略，见解相识和代码阅读也有小幅下落。论断很明确：被迫地甩给AI("让它能跑就行")对学习的毁伤，弘远于用它来发问和相识代码。

哪怕只是在用主智能体写完代码后触发一个招架性智能体，问一些诸如"你为什么这样作念?""你预期什么活动?""你考虑了哪些量度?"这样的问题，也能在很猛进度上减少融会债务，它迫使修复者在代码往前鼓吹之前，先把相识说了了。

让常识传递变得特意为之

那些判断和那些决策——这才是咱们看成东说念主类在AI优先的全国里简直提供的中枢价值。你致使不错说，大部分写出来的代码都是样板代码。咱们简直在作念的主如果架构决策、活动决策和技艺决策。这些才是咱们需要看成输入提供给AI系统的东西，而每一次变更都需要对这些决策有澄莹的融会。

往时通过代码审查发生的许多常识传递是附带产生的，工程师经受高下文，是因为他们必须看代码智力批准它。跟着咱们逐渐淘汰审查，狠恶审查这些决策变得愈加紧迫。

归根结底，工程师仍然要对我方创建的变更老成。通盘这些决策都必须被跟踪，必须有东说念主狠恶审计它们、追问为什么作念了某些决定，这便是你的简直起首。我觉得团队相助和常识传递便是这样演进的，即便我说过咱们应该干掉代码审查。

出产力的提高是竟然的，值得追求鲸鱼直播2026世界杯赛事直播入口，但每个隧说念以销毁苦求迷糊量为优化指方向企业，都是在拿我方的工程文化作念实验。五年后，简直赢下来的不会是那些寄托最多AI代码的企业，而是那些工程师依然相识我方寄托了什么的企业。