Cisco AI 代码重写：无限 tokens 背后的 98% 目标

据报道，Cisco 向一名 27 岁工程师提供了无限 AI tokens，以在 24 个月内完成其 98% 遗留代码的重写。Cisco 的 AI 代码重写计划将异常宏大的目标与一个拟议中的小型团队结合起来。其意义取决于 Cisco 打算改变什么，以及将如何证明这些改动能够正常运行。

据 Tom’s Hardware 援引 Fortune 报道，Cisco 总裁兼首席产品官 Jeetu Patel 在旧金山的一次交谈后，支持了前创业公司创始人 Padmanabhan Krishnamurthy。据报道，这项任务包含最初为期四周的验证期。这些细节描述的是一项实验和一份雄心，而非经过独立验证的现代化改造成果。

核心矛盾在于不受限制的代码生成与可追责的软件交付之间。Amazon 已经介绍过 AI 辅助应用升级，提供了一个有用的对照。Cisco 据称的雄心提出了一个更广泛的问题：当生成变更变得更容易时，一个小型工程团队能承接多少组织责任？

Cisco AI 代码重写始于目标，而非已完成的迁移

这项据报道的任务表明获得了高管支持；但并不代表 Cisco 已经完成软件现代化。

Tom’s Hardware 对这项遗留代码任务的报道指出，外号 Paddy 的 Krishnamurthy 是该提案背后的工程师。据报道，他提出组建两人团队。Patel 提供了支持，包括不受限制的 tokens；tokens 是 AI 模型在接收指令和生成回复时处理的文本单位。

报道称，Krishnamurthy 此前所在的组织层级比 Patel 低五级。报道将该项目定位为责任分配的改变，与工具层面的变化同等重要。一名前创始人将获得空间，以挑战既有的工程假设。

这一关联背后存在可独立验证的收购记录。Cisco 的EzDubs 收购公告称，该交易于 2025 年 11 月 25 日完成。Cisco 将 EzDubs 描述为一家专注于实时语音翻译的 AI 软件公司。其列出的理由包括扩充协作工程人才。

这段历史支持一家被收购的创业公司加入 Cisco 的说法，但并不能独立验证重写提案或其可行性。该收购公告涉及协作能力，而非一项已经公开的、改造 Cisco 遗留软件的计划。

据报道的任务措辞同样需要谨慎理解。重构指在保留软件外部可观察行为的同时，改变其内部结构。重写则可能涉及替换实现，从而可能引入不同的设计选择与兼容性风险。

这些术语可以描述存在重叠的工作，但不能互换作为进展衡量标准。自动化的内部清理，与替换客户依赖的组件，存在实质性差异。现代化计划需要明确每项变更属于哪一类。

公开报道并未提供支撑 98% 这一数字的详细清单。它也没有说明“完成”是指已生成变更、已接受变更、已部署至生产环境，还是已淘汰旧实现。缺少这些定义时，这一百分比传达的是雄心，而非清晰的运营范围。

同样的谨慎也适用于时间表。2026 年 10 月 30 日发布的报道，并不能证明项目计时从当天开始。读者不应仅根据发布日期计算确切的完成日期。

因此，有用的出发点是有限的。据报道，Cisco 总裁授权了一项目标明确、标题激进的工程实验。该实验是否会成为可重复的现代化计划，仍是另一个问题。

无限 tokens 将压力转移至审查与责任归属

取消生成限制会改变工程工作累积的位置；它不会消除接受一项变更所必需的工作。

无限 AI tokens 听起来像无限的工程产能，因为可见产出是代码。然而，生成的补丁——即对源文件提出的修改——仍需要有存在的理由。必须有人确认它改变了什么、为何安全，以及谁将维护它。

设想一个共享身份验证组件的现代化改造。AI 工具可能会建议采用更清晰的代码、更新的依赖项和更多测试。该提案仍需依据现有权限规则及受支持的客户配置进行评估。

这个例子仅用于说明，并非对 Cisco 项目的描述。它说明，生成看似合理的软件与为已部署行为承担责任，是不同的活动。更快的草拟速度可能暴露审查人员不足，而非消除程序员短缺。

工程经理面临直接压力。如果提议的变更到达速度快于团队的评估速度，审查队列就会增长。届时，经理必须决定是缩小工作范围、增加审查能力，还是改变每项提案所附带的证据方式。

安全专家面临相关问题。他们需要了解这一过程是否保留访问边界，并恰当地处理敏感信息。一个看起来更整洁的补丁，仍可能改变此前以间接方式得到执行的假设。

产品负责人必须区分内部改进与影响客户的变更。替换一个依赖项——即外部软件组件——可能引入超出 AI 工具直接编辑文件范围的行为。因此，验收取决于周边系统，而不只是替换方案是否美观。

高管支持之所以重要，是因为这些责任跨越汇报链路。一个小型核心团队可以开发方法，但受影响的团队仍需要一种批准变更的方式。不清晰的授权会让每一次成功演示，都变成一场关于谁来接受后果的协商。

这正是 Cisco AI 代码重写雄心的组织层面意义。这项实验考验的是：小型团队能否建立一套让其他团队信任的流程。其产出需要包括可复现的证据、可理解的变更边界，以及处理故障的清晰路径。

既有维护者仍是这一过程的核心。他们往往知道为何某个笨拙的实现仍然存在，或者哪项客户需求解释了某个异常分支。即使这些知识表明当前实现应当改变，它们仍是有价值的证据。

文档也成为工程能力问题的一部分。团队在评估拟议替换方案前，需要获取设计决策、事故历史与兼容性要求。一个可搜索的工程知识库可在编码工作流之外，解决这一信息问题。

由此产生的压力落在实验双方。小型团队必须让自己的工作可供审查，而既有团队必须具体说明反对理由。无论是不受限制的生成，还是机构经验，都无法自动给出答案。

Amazon 的应用升级提供了更有限的对照

边界明确的迁移，比覆盖未定义软件资产的百分比更能提供清晰证据。

Amazon 为 AI 辅助现代化提供了行业先例。在其 2024 年 12 月发布的应用转换公告中，该公司介绍了将内部应用升级至 Java 17 的工作。Java 是一种用于企业软件的编程语言和运行时环境。

Amazon 表示，这项工作涵盖数万个生产应用，并节省了超过 4,500 个开发者人年的工作量。这些是公司自行报告的结果，而非独立评估。尽管如此，它们描述的转型比“重写遗留代码”的笼统承诺更为具体。

这种具体性很重要。版本升级提供了可识别的起始状态和目标状态。审查者可以检查应用是否能够构建、预期行为是否保持完整，以及新运行时是否支持其需求。

更广泛的重写可能结合许多不同目标。它可能涉及简化架构、替换依赖项、提升可维护性，或移除过时功能。即使同一批 AI 工具有助于产出变更，每个目标也需要各自的验收标准。

AWS 的Java 升级工作流同样保留了明确的人工验收步骤。其文档描述了构建原始代码、执行转换，以及要求开发者验证并接受结果的流程。它区分了语言兼容性变更与额外的依赖项升级。

这一区分很有用，因为现代化很少是单一操作。成功的语言升级并不代表每个库都已更新。构建通过也不代表每个客户工作流都能正确运行。

因此，Amazon 的案例支持一个有限结论：AI 辅助转换在企业中具有边界可描述的具体应用。它并不能证明 Cisco 据报道的目标可以实现，也不能说明一个极小的实施团队能够独立完成所有相关验收任务。

其中也有一个衡量方面的启示。估算节省的开发者时间，取决于对替代流程的假设。若附带已部署应用、已接受变更及持续运营表现，这一估算会更具参考价值。

Cisco 的实验也将受益于类似的具体报告。对初始工作负载的描述，可以揭示团队是在测试可重复的转换流程，还是在探索更广泛的重新设计。两者都可能有价值，但不确定性不同。

对于企业买家而言，这一区别影响其如何解读供应商主张。内部演示是特定环境中特定流程的证据。受支持的客户能力，则需要在维护、文档与故障处理方面作出额外承诺。

竞争压力不仅关乎速度，也关乎证据。讨论 AI 现代化的公司越来越需要说明：转变了什么，以及验收如何完成。戏剧化的标题百分比，提供的信息不如边界清晰的结果有用。

这一对照也让 Cisco 的故事保持落地。其意义来自于检验激进的高管支持能否扩展 AI 辅助工程的覆盖范围。Amazon 的经验提供了背景，但无法预先解决这项实验。

在成为有用指标之前，98% 这一数字需要先有定义

只有当读者知道哪些内容被计入完成度时，现代化百分比才有意义。

百分比需要一个分母，即衡量进展时所依据的总量。对于这项任务，这个总量可能是源代码行数、代码仓库、应用程序或选定组件。相关报道并未明确采用哪一种口径。

不同选择可能呈现出截然不同的进展图景。重新格式化文件可能涉及大量源代码行，却并未改善可维护性。替换一个规模较小但处于核心位置的组件，可能需要广泛验证，同时影响的代码却相对有限。

完成规则同样重要。生成一项拟议变更只是中间步骤。将其接受并纳入源代码仓库是另一步，而部署该变更并淘汰旧实现还需要额外工作。

这并不意味着 98% 的目标本身不合理。但根据公开描述，这一目标很难评估。在将其解读为工程预测之前，读者需要了解范围和验收定义。

重构这一表述还带来了另一项衡量挑战。行为保持是重构的核心，但现有测试只能检验其覆盖到的行为。一次成功的测试运行无法证明每一种未经测试的情况都保持不变。

这也解释了为什么审查和运行观察十分重要。回归问题，即既有行为发生非预期丢失，可能出现在自动化测试未覆盖的场景之外。可靠性来自多种证据的结合，而不是将任何单项检查视为定论。

研究也警告，不应将速度感受等同于经测量的生产率。METR 的开发者生产率实验考察了 16 名经验丰富的开发者在熟悉的开源项目中完成 246 项任务的情况。允许使用 2025 年初的 AI 工具后，完成时间增加了 19%。

尽管如此，参与者仍认为这些工具帮助他们更快完成了工作。这一发现说明，感知到的便利性与实际交付速度需要分别评估。它并不能预测 Cisco 的结果，也不能证明后续 AI 工具具有同样的局限性。

METR 此后强调了这种区别。其 2026 年 2 月的实验设计更新描述了对较新测量结果进行解读的困难，因为参与者和任务选择都发生了变化。研究人员认为速度提升是可能的，同时警告现有证据无法精确确定提升幅度。

综合来看，这些发现支持审慎测量，而不是对 AI 编程作出普遍性的结论。工具能力会变化，不同任务也会暴露不同的限制条件。针对熟悉的开源维护工作的结果，不能直接套用于一家大型公司的现代化项目。

对 Cisco 而言，相关问题在于完整流程是否得到改善。如果审查和修正消耗了节省下来的时间，更快的生成速度价值有限。反过来，即使有意保留大量代码不作改动，可靠的流程也可能创造价值。

因此，可信的评估应区分活动与结果。拟议补丁体现活动；获得接受的转换则体现审查后的进展。稳定部署和维护负担的降低，则能更有力地证明这项工作实现了其目标。

无限 token 消除了实验中的一项潜在约束，但并不能解决这些衡量问题。当 Cisco 说明将如何区分令人印象深刻的演示与持续的工程改进时，所报道的目标才会更具信息价值。

小型团队仍需要获取组织知识

这一实验最有力的形式，是将重新设计的自由与理解现有软件为何如此运行的能力结合起来。

人员配置的故事很容易引发一种简单的代际解读：一位年轻创始人挑战了大型组织长期接受的假设。这种框架捕捉了报道中所说的机会变化，但无法证明哪一种工程判断是正确的。

年轻并不自动意味着架构合理，任职时间长也不自动意味着某种实现应被保留。真正有用的区别在于，一项提议能否经受检验。小型团队既需要足够的自由来测试想法，也需要足够的背景来解读结果。

据报道，Krishnamurthy 的创始人背景与这一组织问题有关。创业经历可能促使人关注整体问题，而非狭义的指派任务。但它仍不能替代对受变更影响系统的理解。

组织知识能够解释看似低效的设计。某种不寻常的重试序列可能是为了适应特定运行条件。一项冗余检查可能是在保护较旧的集成。这些是假设性例子，并非 Cisco 软件中已被确认的特性。

在可能的情况下，此类解释应转化为可测试的需求。否则，现代化工作将依赖于找到那个记得旧决策的人。记录其中原因，能让新实现保留必要行为，同时挑战原有设计。

反向义务同样重要。既有团队应区分有文档记录的需求与未经检验却延续下来的习惯。当一项反对意见指出失败条件或验收标准时，它才具备可执行性。

这正是高管支持可以发挥作用、却不能取代工程判断的地方。领导层可以授权访问、解决所有权争议，并为评估留出时间。但它无法通过热情来确立正确性，也无法让截止日期替代证据。

因此，小型团队最有价值的贡献或许是可重复的流程，而不是大量替换代码。该流程会将拟议转换与相关需求及清晰的批准路径连接起来。其他团队随后便能评估类似工作，而无需重新搭建整套流程。

这种可能性改变了对所提人员规模的解读。精简团队可能负责开发转换方法并协调采用。这不同于声称这些人单独承担全部测试、安全、支持和维护责任。

它也限制了这个故事对初级岗位就业所能说明的内容。赋予一位被收购公司的创始人不同寻常的责任，并不能证明存在普遍的招聘模式。该案例提供的是有关特定管理决策的证据，而不是劳动力市场结果。

对开发者来说，实际启示在于生成代码周围的工作。当起草变得更容易时，理解需求、解释权衡以及建立证据仍然必不可少。当项目试图跨越组织边界推动变更时，这些职责会更加显眼。

对更广泛的知识工作者而言，对应的问题是获取背景信息。AI 系统可以给出看似合理的答案，却可能遗漏先前决策为何重要。有效的自动化需要能够检索这一原因并揭示不确定性的机制。

因此，Cisco 的实验也是对组织学习能力的一次测试。如果小型团队能将分散知识转化为可复用的验收证据，其前景将会改善；如果项目只将经验丰富的维护者视为加快产出的障碍，前景则会减弱。

关注试点证据、生产验收与维护负担

下一次有价值的更新应说明哪些内容通过了评估、由谁接受，以及之后发生了什么。

未来几个月，Cisco AI 代码重写项目将能通过具体证据得到更容易的评估。据报道，四周的验证期为读者提供了一个近期参照点。不过，报道并未确定其确切开始日期，也未承诺会公开发布结果。

第一个信号是对试点范围和结果的说明。读者应关注可识别的工作负载、明确的转换目标和验收标准。这些细节将表明团队测试的内容是否能代表更广泛的目标。

如果一次成功的演示同时披露成果与局限性，将更能强化其论据。例如，报告哪些变更需要人工修正，将有助于厘清该流程的实际要求。这是一项证据标准，而非对 Cisco 将披露何种信息的预测。

只展示新生成代码的演示，所提供的支持会更弱。它能证明存在输出，却无法解释兼容性或验收情况。差别很重要，因为长期目标涉及修改既有软件，而不是生成一个独立示例。

第二个信号是被纳入生产交付流程。读者应关注是否确认由负责团队批准了一项范围受限的转换并完成部署。回滚流程，即恢复先前版本的既定方式，也能进一步说明该项目如何应对失败。

这一信号会加强现代化论据，因为它将实验与运行责任联系起来。它表明受影响的团队能够评估这项工作，而不只是欣赏它。不过，批准仍需结合该部署的范围来解读。

相反，反复演示却不部署，仍会留下一个核心问题未解。该流程可能能够生成有用提议，却难以满足验收要求。这种结果将识别出一项交付约束，而不是证明每一项转换都没有价值。

第三个信号是部署后的维护负担。读者应关注后续修正、支持需求，以及旧实现能否被淘汰的证据。这些结果揭示现代化究竟是在减少工作，还是仅仅将工作转移到别处。

一项保持稳定并简化未来维护的变更，将支持该项目的前提。需要广泛且反复干预的变更则会削弱这一前提。两种结论都不应仅仅建立在首次替换出现得有多快之上。

这些信号也为评估 AI 现代化主张的企业买家提供了更好的框架。要求供应商区分拟议变更与已部署变更，并区分已部署变更与持久改善。索取足够细节，以了解哪些工作负载产生了所报告的结果。

对工程负责人而言，眼下的行动是在自己的组织中审视一个范围受限的维护问题。明确现有验收标准，找出理解其约束的人，并衡量通向部署的完整路径。在比较生成速度的同时，也比较审查和修正所需的工作量。记录那些会限制在其他场景复制结果的假设。Cisco AI 代码重写值得关注，因为它测试了高管支持和不受限制的实验能将软件现代化推进到何种程度。它最终的重要性将取决于最初热潮过后，哪些成果依然可靠。下一次更新到来时，请提出一个具体问题：哪项获得接受的变更让软件更易维护，又有什么证据支持这一判断？