Cisco Gave One Engineer Unlimited AI Tokens to Rewrite 98 Percent of Its Legacy Code

Fortune and India Today reported on October 30, 2026 that Cisco president and chief product officer Jeetu Patel gave engineer Padmanabhan Krishnamurthy, 27, unlimited AI tokens to attempt a rewrite of 98 percent of the company's legacy code within 24 months, using a two person team. Patel found Krishnamurthy five levels below him in the org chart and described him beforehand as "buried away in the organization doing something unstrategic." Krishnamurthy had joined Cisco in 2025 when Cisco acquired EzDubs, a real time translation startup he co founded in 2023. Patel's quotes to Fortune are direct about the intent: "I've given him unlimited tokens because he's going to refactor code," followed by, "you can go, you can go nuts." No codebase name, language, or size was disclosed, and no results have been reported. Krishnamurthy set himself a four week proof period to test whether the approach works at all before the 24 month target becomes a real commitment.

It is worth being precise about what this story actually is before drawing lessons from it. It is a stated goal with a defined proof period, not a completed project, and 98 percent of an undisclosed legacy codebase is a target Cisco has not yet validated internally, let alone demonstrated externally. Treating it as proof that agentic coding tools can now rewrite enterprise legacy systems at that ratio would be reading further into the story than Cisco itself has claimed. What makes it worth analyzing anyway is the structure of the bet Patel made, which mirrors a decision enterprise engineering leaders are increasingly facing in smaller, less publicized form: how much autonomy and resourcing to hand a small team attempting agentic modernization of a system too large for a full team to tackle conventionally.

Why unlimited tokens and a two person team is the actually interesting variable

Most enterprise AI coding pilots fail or stall for a specific, boring reason: they are resourced like experiments rather than like bets. A team given a capped budget, a part time allocation, and a mandate to "explore" agentic coding tools on a legacy system typically produces a proof of concept that never survives contact with the actual codebase's edge cases, because the team runs out of budget or attention before the agent's output has been tested against enough of the system to be trustworthy. Patel's structure removes exactly that failure mode by removing the budget constraint entirely and compressing the team to two people who can move without the coordination overhead a larger team would require.

That tradeoff has a real cost, concentration risk. A two person team with unlimited tokens can move fast precisely because almost no one else needs to review or understand what they are doing in real time, which is also what makes the approach risky at the scale of a legacy system that likely has decades of undocumented business logic embedded in it. Coordinating multiple agentic coding sessions against a shared codebase without stepping on each other's changes is already a solved but nontrivial problem at smaller scale, using git worktrees and similar isolation techniques to let agents work in parallel without corrupting a shared branch. A two person team attempting a 98 percent rewrite is almost certainly running many more parallel agent sessions than that comparison implies, which means the tooling and process discipline around isolating, reviewing, and merging agent generated changes matters more here than the raw capability of whichever model they are using, even though Cisco disclosed neither.

The four week proof period is the detail that separates this from reckless experimentation. Krishnamurthy chose that window himself, before committing to the full 24 month target, which means the actual decision point enterprise leaders should study is not "should we give a team unlimited AI budget" but "what does a credible four week proof period for agentic legacy modernization actually need to demonstrate" before scaling the bet. A proof period that only shows an agent can generate plausible looking replacement code is not the same as one that shows the replacement code passes the legacy system's actual test coverage, handles its documented edge cases, and does not regress behavior that downstream systems depend on even when that behavior was never intentionally designed.

What a credible proof period for this kind of bet should actually test

Three things distinguish a proof period that earns a 24 month commitment from one that just produces a demo. First, test coverage parity against the legacy system, not just successful compilation or passing a handful of new tests the team wrote themselves, since legacy systems frequently encode business rules nowhere else, and an agent rewriting code without exposure to the system's actual historical test suite and production behavior will silently drop rules it was never told about. Second, a clear permission and review structure for what the agent can change autonomously versus what requires human sign off, which matters more at the pace unlimited tokens enables. The permission sandboxing work that has gone into recent agentic coding tool releases exists specifically to make this distinction enforceable rather than a matter of team discipline alone, and a team running this kind of bet without equivalent guardrails is relying entirely on two people's judgment holding up over 24 months. Third, a rollback and parallel run plan, since a 98 percent rewrite of anything load bearing cannot simply replace the original in one cutover; it needs a period where old and new systems run side by side against real traffic before the legacy system is actually retired.

Enterprise teams running multiple engineers against agentic coding tools concurrently on shared systems have converged on specific coordination patterns for exactly this reason, and a two person team operating at Cisco's scale will eventually need equivalent discipline even if it starts without it, simply because the volume of agent generated change will outpace what two humans can personally review line by line within the stated timeline.

When this applies to your stack

If your organization is considering a similarly structured bet, a small team with heavy AI tooling resourcing against a legacy modernization target, the actual lesson from Cisco's experiment is in the shape of the commitment, not the 98 percent number, which is unproven. Define a short proof period before committing to the full timeline, specify what that proof period must demonstrate against real test coverage and documented edge cases rather than a demo, and build in the permission boundaries and parallel run plan before the token budget, not after. Teams evaluating whether their own legacy systems are candidates for this kind of agentic rewrite, or that need help structuring the coordination and review process around multiple concurrent agent sessions, should treat the proof period design as the actual engineering problem worth solving first.

FAQ

Has Cisco actually rewritten 98 percent of its legacy code with AI? No. As of the October 30, 2026 report, this is a stated 24 month target, not a completed or measured outcome. A two person team led by engineer Padmanabhan Krishnamurthy had set itself a four week proof period to test the approach.

What AI tools did Cisco use for this? Cisco has not disclosed specific tools, models, or platforms. The only disclosed resource is unlimited AI tokens given to the team by president and chief product officer Jeetu Patel.

Why does team size matter for a legacy code rewrite like this? A small, two person team can move without the coordination overhead a larger team requires, but that speed concentrates risk, since fewer people are reviewing agent generated changes against a legacy system that likely has undocumented business logic embedded in it.

What should a company test during a proof period before committing to a similar legacy rewrite? Test coverage parity against the legacy system's actual historical behavior, a clear permission structure for what an agent can change without human sign off, and a rollback or parallel run plan before any cutover, rather than treating a working demo as sufficient evidence.

Sources:

• Cisco's Patel Gives 27 Year Old Unlimited AI Tokens to Rewrite Legacy Code
• Cisco Gives 27-Year-Old Engineer Unlimited AI Tokens to Rewrite 98% of Legacy Code in 24 Months