Cisco's President Lifted the Token Budget on a Legacy Rewrite. The Real Budget Is Verification.

“I’ve given him unlimited tokens because he’s going to refactor code. So I’m like, you can go, you can go nuts.”

That is Jeetu Patel, Cisco’s president and chief product officer, speaking to Fortune at a small roundtable dinner. The “him” is Padmanabhan “Paddy” Krishnamurthy, 27, who joined Cisco in 2025 when it acquired EzDubs, the real-time translation startup he cofounded in 2023. Patel described finding him “buried away in the organization doing something unstrategic,” five levels below him. The goal, as Fortune and Tom’s Hardware report it: refactor 98% of Cisco’s legacy code within 24 months, after a four-week proof of concept.

Krishnamurthy reckoned he could do the rewrite with a two-person team. Patel told Fortune that even the most AI-forward people on his own team were not thinking that way.

Fortune’s framing is about talent and generations. Ours is narrower. When an executive removes the token budget from a legacy rewrite, he removes the constraint that usually forces a team to choose what to rewrite and how carefully. Something else has to take its place. The reporting names a generation target and no verification target, and that asymmetry is where a rewrite of this size succeeds or quietly fails.

What Unlimited Tokens Actually Removes

Large refactors usually have a budget, and in our experience the budget does governance work that rarely gets written down. When generation costs money, teams prioritize. They pick the modules where a rewrite pays for itself. They stop when the marginal module stops being worth it. Cost acts as a crude filter on scope.

Take the cost away and the filter goes with it. The rate at which new code appears is now limited by how fast the models and the people driving them can produce output. On a codebase the size of a company Fortune describes as a $429 billion tech giant, that rate can be very high.

The rate at which a person who owns the behavior can confirm the new code does what the old code did does not scale with the token meter. Machines can generate tests and compare outputs, and unlimited tokens make that cheaper too. Someone still has to read the diffs that matter and decide which differences are bugs and which are fixes.

So the binding constraint moved. It used to be spend. Now it is proof.

A Target That Measures the Wrong Side

“Refactor 98% of legacy code” is a generation metric. It counts how much code has been rewritten. It says nothing about how much rewritten code has been shown to behave like what it replaced.

Neither the Fortune piece nor the Tom’s Hardware write-up reports how the rewritten code will be tested, reviewed, or compared with legacy behavior. Neither reports a token spend figure. That does not mean Cisco has no plan. The reporting comes from an interview over dinner, Tom’s Hardware rewrites Fortune, and nothing here is a Cisco announcement. It does mean the only target in the reporting is the one that measures output.

A percent-refactored score has a predictable failure mode. It climbs as fast as code is generated, and on a fixed deadline the pressure is to keep it climbing. Verification climbs at the speed of tests, reviewers and production evidence. If the dashboard shows the first number, the program will report progress well before anyone can say whether that progress is real. On a codebase that size, the distance between those two numbers is where the outages live.

We have looked at the cousins of this problem before. Token usage treated as a vanity metric is the subject of our piece on Meta’s token leaderboard. Whether shipped AI code survives is the subject of our piece on code churn. A legacy rewrite with no spend ceiling is a sharper case, because volume is the stated goal and cost no longer slows it down.

The Context Tom’s Hardware Added

Tom’s Hardware placed the Cisco story next to its own earlier reporting. It noted that GitHub had to deploy 4 million extra CPU cores and 160 petabytes of storage to cope with AI coding activity, and that AI coding agents have been reported deleting company databases and production setups.

Neither of those facts is about Cisco. Together they describe the environment any unlimited-token rewrite operates in: generation at a scale that strains infrastructure, and agents that can do real damage when nothing checks them. A large legacy codebase is exactly the kind of system where an unverified change can be expensive.

The Four Weeks Are the Governance Moment

The proof of concept is the most useful part of the plan, because it can be the moment where the scoring rules get set. Whatever the four weeks measure becomes, in practice, what the rest of the program optimizes for.

A proof of concept scored on volume will show that the team can rewrite a lot of code quickly. The open question is whether the two-person team Krishnamurthy says he needs, with unlimited generation, can produce rewritten code that is demonstrably equivalent to the legacy behavior, at a pace that keeps up with the generation.

A proof of concept built to answer that question would measure a few specific things.

Behavioral equivalence on a slice. Pick a bounded part of the legacy code with known inputs and outputs. Rewrite it. Then show, with tests and recorded production traffic where possible, that the new version behaves like the old one across the cases that matter. The output of the four weeks is a slice with proven equivalence and a list of every intentional difference, signed off by someone who owns that behavior.

Review capacity. Count how many lines of rewritten code a qualified reviewer can actually confirm per week, then compare that number to how many the generation side produces. If a hypothetical team generates ten times what it can verify, the 98% target is a schedule for unverified code, and the proof of concept should say so in week four.

Rollback. For the slice, demonstrate that the team can put the legacy version back quickly and cleanly. A rewrite that cannot be reversed turns every missed behavior into an incident.

A verification-weighted progress number. Report percent of legacy code replaced by rewritten code that passed equivalence checks. That number will be lower than percent refactored, and it is the one that tells leadership what they own.

None of this requires slowing generation. It changes what “done” means. Proving equivalence also requires people who still understand what the legacy code is for. Our piece Verification Was Never the Bottleneck. Comprehension Is argues that understanding, not checking, is the scarcer resource.

Friction in the Right Place

Patel told Fortune he deliberately creates tension: “you want to have enough friction on the ideas. You don’t want to have friction with people and personalities.” He described his team as roughly one-third experienced operators “who understand how the Cisco engine works,” one-third systems thinkers from outside, and one-third AI-native founders and engineers “who operate in founder mode.”

That structure contains the answer to the verification question, if it is used that way. In our reading, the operators who know how the engine works are the people best placed to say what the legacy code is supposed to do. Their friction belongs on the equivalence evidence: the slices, the intentional differences, the rollback drills. A fast, generation-led rewrite paired with operator-owned verification is a strong design. A fast, generation-led rewrite scored only on percent refactored leaves the operators to discover the differences in production.

Do This Now

If you are funding an AI-driven legacy rewrite, or considering lifting the token ceiling on one, set the scoring rules before the first proof of concept starts.

Write the verification target next to the generation target. “Percent refactored” never appears without “percent proven equivalent” beside it.
Define the proof-of-concept slice and its equivalence evidence in advance: which inputs, which recorded traffic, who signs off on intentional differences.
Measure review throughput during the proof of concept and compare it with generation throughput. Use the ratio to set the real schedule.
Require a rollback demonstration on the slice before the program scales past it.

Removing the token budget can be a good decision. It only works if the budget that replaces it is denominated in proof.

This analysis synthesizes Cisco chief found a 27-year-old ex-founder ‘buried away in the organization doing something unstrategic’, now he’s upgrading 98% of its code (Fortune, Orianna Rosa Royle, October 2026) and Cisco gives 27-year-old engineer unlimited AI tokens to rewrite 98% of the company’s legacy code in 24 months (Tom’s Hardware, Ben Stockton, October 2026).

Victorino Group helps engineering leaders design the verification targets, equivalence checks and rollback gates that make AI-driven legacy rewrites safe to scale. Let’s talk.