Cisco AI code rewrite puts a 98% target behind unlimited tokens

Cisco reportedly gave a 27-year-old engineer unlimited AI tokens to pursue a rewrite of 98% of its legacy code within 24 months. The Cisco AI code rewrite pairs an unusually broad target with a small proposed team. Its significance depends on what Cisco intends to change and how it will establish that the changes work.

According to Tom’s Hardware, relaying Fortune’s reporting, president and chief product officer Jeetu Patel backed former startup founder Padmanabhan Krishnamurthy after a conversation in San Francisco. The assignment reportedly includes an initial four-week proof period. Those details describe an experiment and an ambition, rather than independently verified modernization results.

The central tension is unrestricted code generation versus accountable software delivery. Amazon has already described AI-assisted application upgrades, providing a useful comparison. Cisco’s reported ambition raises a broader question: how much organizational responsibility can a small engineering team absorb when generating changes becomes easier?

Cisco AI code rewrite begins with a target, not a finished migration

The reported assignment establishes executive backing; it does not establish that Cisco has modernized its software.

Tom’s Hardware’s account of the legacy code assignment identifies Krishnamurthy, known as Paddy, as the engineer behind the proposal. He reportedly suggested a two-person team. Patel supplied the backing, including unrestricted tokens, the text units AI models process when receiving instructions and generating responses.

The report says Krishnamurthy previously worked five organizational levels below Patel. Its account positions the project as a change in responsibility as much as tooling. A former founder would receive room to challenge established engineering assumptions.

There is independently verifiable acquisition history behind that connection. Cisco’s EzDubs acquisition notice says the transaction closed on November 25, 2025. Cisco described EzDubs as an AI software company specializing in real-time speech translation. Its stated rationale included expanding collaboration engineering talent.

That history supports the account of an acquired startup joining Cisco. It does not independently validate the rewrite proposal or its feasibility. The acquisition announcement concerns collaboration capabilities, rather than a published plan to transform Cisco’s legacy software.

The wording of the reported assignment also requires care. Refactoring means changing software’s internal structure while preserving its externally observable behavior. Rewriting can involve replacing an implementation, potentially introducing different design choices and compatibility risks.

Those terms can describe overlapping work, but they are not interchangeable measures of progress. An automated internal cleanup differs substantially from replacing a component that customers depend on. A modernization program needs to identify which category each change belongs to.

The public reporting does not provide a detailed inventory underlying the 98% figure. It also does not explain whether completion means generated changes, accepted changes, production deployment, or retirement of old implementations. Without those definitions, the percentage communicates ambition more clearly than operational scope.

The same caution applies to the schedule. Reporting published on October 30, 2026, does not establish that the project clock began that day. Readers should avoid calculating an exact completion date from the publication date alone.

The useful starting point is therefore narrow. Cisco’s president reportedly authorized an aggressive engineering experiment with a defined headline target. Whether that experiment becomes a repeatable modernization program remains a separate question.

Unlimited tokens move pressure toward review and ownership

Removing a generation limit changes where engineering work accumulates; it does not remove the work required to accept a change.

Unlimited AI tokens sound like unlimited engineering capacity because the visible output is code. Yet a generated patch, a proposed change to source files, still needs a reason to exist. Someone must establish what it changes, why it is safe, and who will maintain it.

Consider a hypothetical modernization of a shared authentication component. An AI tool might suggest clearer code, newer dependencies, and additional tests. That proposal would still need evaluation against existing permission rules and supported customer configurations.

This example is illustrative, rather than a description of Cisco’s project. It shows why generating plausible software and accepting responsibility for deployed behavior are different activities. Faster drafting can expose a shortage of reviewers rather than eliminate a shortage of programmers.

Engineering managers face the immediate pressure. If proposed changes arrive faster than teams can evaluate them, the review queue grows. Managers must then decide whether to narrow the work, increase review capacity, or change how evidence accompanies each proposal.

Security specialists face a related problem. They need to understand whether the process preserves access boundaries and handles sensitive information appropriately. A patch that looks cleaner can still change assumptions that were previously enforced indirectly.

Product owners must distinguish internal improvements from changes that affect customers. Replacing a dependency, an external software component, can introduce behavior beyond the files an AI tool directly edits. Acceptance therefore depends on the surrounding system, not simply the attractiveness of the replacement.

Executive sponsorship matters because these responsibilities cross reporting lines. A small central team can develop an approach, but affected teams still need a way to approve changes. Unclear authority would turn every successful demonstration into a negotiation about who accepts the consequences.

This is the organizational significance of Cisco AI code rewrite ambitions. The experiment tests whether a small team can create a process that other teams trust. Its output would need to include reproducible evidence, understandable change boundaries, and clear routes for handling failures.

Established maintainers remain central to that process. They often know why an awkward implementation exists or which customer requirement explains an unusual branch. That knowledge is useful evidence, even when it suggests that the current implementation should change.

Documentation becomes part of the engineering capacity question. Teams need access to design decisions, incident histories, and compatibility requirements before evaluating a proposed replacement. A searchable engineering knowledge base addresses that information problem alongside the coding workflow.

The resulting pressure falls on both sides of the experiment. The small team must make its work reviewable, while established teams must explain objections concretely. Neither unrestricted generation nor institutional experience supplies an automatic answer.

Amazon’s application upgrades offer a narrower comparison

A bounded migration provides clearer evidence than a percentage covering an undefined software estate.

Amazon supplies an industry precedent for AI-assisted modernization. In its December 2024 application transformation announcement, the company described upgrading internal applications to Java 17. Java is a programming language and runtime used for enterprise software.

Amazon said the effort covered tens of thousands of production applications and saved more than 4,500 developer-years of work. These are company-reported results, rather than an independent assessment. They nevertheless describe a more specific transformation than a general promise to rewrite legacy code.

That specificity matters. A version upgrade supplies an identifiable starting state and target state. Reviewers can examine whether an application builds, whether expected behavior remains intact, and whether the new runtime supports its requirements.

A broader rewrite can combine many different objectives. It might involve simplifying architecture, replacing dependencies, improving maintainability, or removing obsolete functionality. Each objective requires its own acceptance criteria, even when the same AI tools help produce the changes.

AWS’s Java upgrade workflow also preserves an explicit human acceptance step. Its documentation describes building the original code, performing a transformation, and asking the developer to verify and accept the results. It distinguishes language compatibility changes from additional dependency upgrades.

That distinction is useful because modernization is rarely a single operation. A successful language upgrade does not establish that every library is current. A passing build does not establish that every customer workflow behaves correctly.

Amazon’s example therefore supports a limited conclusion: AI-assisted transformation has concrete enterprise applications with describable boundaries. It does not establish that Cisco’s reported target is achievable. Nor does it show that a tiny implementation team can independently perform every associated acceptance task.

There is also a measurement lesson. Estimated developer time saved depends on an assumed alternative process. That estimate becomes more informative when accompanied by deployed applications, accepted changes, and continuing operational performance.

Cisco’s experiment would benefit from similarly concrete reporting. A description of the initial workload would reveal whether the team is testing a repeatable transformation or exploring a broader redesign. Both can be worthwhile, but they carry different uncertainty.

For enterprise buyers, that distinction affects how to interpret vendor claims. An internal demonstration is evidence about a particular process in a particular environment. A supported customer capability requires additional commitments around maintenance, documentation, and failure handling.

The competitive pressure concerns evidence as much as speed. Companies discussing AI modernization increasingly need to explain what was transformed and how acceptance worked. A dramatic headline percentage supplies less useful information than a clearly bounded result.

The comparison also keeps the Cisco story grounded. Its significance comes from testing whether aggressive executive sponsorship can expand the reach of AI-assisted engineering. Amazon’s experience supplies context without resolving that experiment in advance.

The 98% figure needs a definition before it becomes a useful metric

A modernization percentage becomes meaningful only when readers know what counts toward completion.

A percentage needs a denominator, the total quantity against which progress is measured. For this assignment, that quantity might be source lines, repositories, applications, or selected components. The reporting does not establish which interpretation applies.

Those choices can produce very different pictures of progress. Reformatting files can touch many source lines without changing maintainability. Replacing a small but central component can require extensive validation while affecting relatively little code.

The completion rule matters just as much. Generating a proposed change is an intermediate step. Accepting it into the source repository is another step, while deploying it and retiring the old implementation require further work.

This does not make the 98% ambition inherently unreasonable. It makes the ambition difficult to evaluate from the public description. Readers need scope and acceptance definitions before interpreting it as an engineering forecast.

The language of refactoring creates another measurement challenge. Behavior preservation is central to refactoring, but existing tests only examine the behavior they cover. A successful test run cannot establish that every untested condition remains unchanged.

That gap explains why review and operational observation matter. A regression, an unintended loss of existing behavior, can appear outside the scenarios represented in automated tests. Confidence comes from combining evidence rather than treating any individual check as conclusive.

Research also cautions against equating the feeling of speed with measured productivity. METR’s developer productivity experiment examined 16 experienced developers completing 246 tasks in familiar open-source projects. Allowing early-2025 AI tools increased completion time by 19%.

Participants nevertheless believed the tools had helped them finish faster. The finding illustrates why perceived convenience and measured delivery speed require separate evaluation. It does not predict Cisco’s results or establish that later AI tools have the same limitations.

METR subsequently emphasized that distinction. Its February 2026 experiment design update described difficulties interpreting newer measurements because participation and task selection had changed. The researchers considered improved speed plausible while warning that the available evidence could not precisely establish the gain.

Taken together, these findings support careful measurement rather than a universal verdict about AI coding. Tool capabilities change, and different tasks expose different constraints. Results from familiar open-source maintenance cannot simply be transferred to a large company’s modernization program.

For Cisco, the relevant question is whether the complete process improves. Faster generation would have limited value if review and correction consumed the saved time. Conversely, a reliable process could deliver value even if it deliberately left substantial code untouched.

A credible evaluation would therefore distinguish activity from outcomes. Proposed patches show activity; accepted transformations show progress through review. Stable deployment and reduced maintenance burden provide stronger evidence that the work achieved its purpose.

Unlimited tokens remove a potential constraint on experimentation. They do not settle these measurement questions. The reported target becomes more informative when Cisco explains how it will distinguish an impressive demonstration from sustained engineering improvement.

A small team still needs access to institutional knowledge

The strongest version of this experiment combines freedom to redesign with access to the reasons existing software behaves as it does.

The staffing story invites a simple generational interpretation. A young founder challenges assumptions that a large organization has accepted. That framing captures the reported change in opportunity, but it cannot establish which engineering judgments are correct.

Youth does not automatically produce sound architecture, just as tenure does not automatically justify preserving an implementation. The useful distinction is whether a proposal survives examination. A small team needs enough freedom to test ideas and enough context to interpret the results.

Krishnamurthy’s reported founder background is relevant to that organizational question. Startup experience can encourage attention to the whole problem rather than a narrowly assigned task. It still does not substitute for understanding the systems affected by a change.

Institutional knowledge can explain apparent inefficiencies. An unusual retry sequence might accommodate a particular operating condition. A redundant check might protect an older integration. These are hypothetical examples, not identified features of Cisco’s software.

Such explanations should become testable requirements wherever possible. Otherwise, modernization depends on locating the person who remembers an old decision. Capturing the reason allows a new implementation to preserve necessary behavior while challenging the original design.

The reverse obligation matters too. Established teams should distinguish documented requirements from habits that have survived without examination. An objection becomes actionable when it identifies a failure condition or an acceptance criterion.

This is where executive backing can help without replacing engineering judgment. Leadership can authorize access, resolve ownership disputes, and protect time for evaluation. It cannot establish correctness through enthusiasm or make a deadline substitute for evidence.

A small team’s most valuable contribution might therefore be a repeatable process rather than a large quantity of replacement code. That process would connect proposed transformations with relevant requirements and a clear approval path. Other teams could then evaluate similar work without rebuilding the procedure.

This possibility changes how to interpret the proposed staffing level. A compact team might develop transformation methods and coordinate adoption. That differs from claiming those people alone can assume every testing, security, support, and maintenance responsibility.

It also limits what the story says about entry-level employment. Giving an acquired founder unusual responsibility does not establish a general hiring pattern. The case offers evidence about a particular management decision, rather than a labor-market outcome.

For developers, the practical implication concerns the work that surrounds generated code. Understanding requirements, explaining tradeoffs, and establishing evidence remain necessary when drafting becomes easier. These responsibilities become more visible when a project attempts changes across organizational boundaries.

For knowledge workers more broadly, the parallel is access to context. An AI system can produce a plausible answer while missing the reason a previous decision mattered. Useful automation needs a way to retrieve that reason and expose uncertainty.

The Cisco experiment is therefore also a test of organizational learning. Its prospects improve if a small team can turn scattered knowledge into reusable acceptance evidence. They weaken if the project treats experienced maintainers solely as obstacles to faster output.

Watch the pilot evidence, production acceptance, and maintenance burden

The next useful update would explain what passed evaluation, who accepted it, and what happened afterward.

The Cisco AI code rewrite will become easier to assess through concrete evidence over the coming months. The reported four-week proof period gives readers a near-term reference point. However, the reporting does not establish its exact start date or promise a public release.

The first signal is a description of the pilot’s scope and results. Readers should look for an identifiable workload, a stated transformation objective, and acceptance criteria. Those details would show whether the team tested something representative of the broader ambition.

A successful demonstration would strengthen the case if it exposed both achievements and limitations. For example, reporting which changes required human correction would help establish the process’s actual demands. This is an evidence standard, rather than a prediction about what Cisco will disclose.

A demo showing only newly generated code would provide weaker support. It would demonstrate output without explaining compatibility or acceptance. The difference matters because the long-term target concerns changing existing software rather than producing a standalone example.

The second signal is acceptance into a production delivery process. Readers should look for confirmation that accountable teams approved a bounded transformation and deployed it. A rollback procedure, a defined way to restore an earlier version, would further clarify how the program handles failure.

This signal would strengthen the modernization case because it connects the experiment with operating responsibilities. It would show that affected teams can evaluate the work rather than merely admire it. Approval would still need to be interpreted within the scope of that deployment.

Conversely, repeated demonstrations without deployment would leave a central question unresolved. The process might generate useful proposals while struggling to satisfy acceptance requirements. That outcome would identify a delivery constraint rather than prove that every transformation lacks value.

The third signal is maintenance burden after deployment. Readers should watch for evidence about subsequent corrections, support demands, and whether the old implementation can be retired. These outcomes reveal whether modernization reduces work or simply moves it elsewhere.

A change that remains stable and simplifies future maintenance would support the project’s premise. A change requiring extensive recurring intervention would weaken it. Neither conclusion should rest solely on how quickly the first replacement appeared.

These signals also provide a better framework for enterprise buyers evaluating AI modernization claims. Ask vendors to separate proposed changes from deployed changes and deployed changes from durable improvements. Request enough detail to understand which workloads produced the reported result.

For engineering leaders, the immediate action is to examine a bounded maintenance problem in their own organization. Establish the existing acceptance standard, identify the people who understand its constraints, and measure the complete path to deployment. Compare review and correction effort alongside generation speed. Record the assumptions that would limit repeating the result elsewhere. The Cisco AI code rewrite deserves attention because it tests how far executive backing and unrestricted experimentation can extend software modernization. Its eventual importance will depend on what remains reliable after the initial excitement. When the next update arrives, ask a concrete question: which accepted change made the software easier to maintain, and what evidence supports that judgment?