Cisco, a $429 billion company, has handed a 27-year-old engineer unlimited AI tokens and told him to "go nuts" on its legacy code, according to Fortune's October 30, 2026 report. The stated target: rewrite 98% of that code within 24 months. The proof period: four weeks.
It makes a good story and a thin evidence base. This post lays out what Fortune reports, what nobody has shown yet, and what engineering leaders can copy from the experiment without believing the headline number.
TL;DR: the claims at a glance
| Question | Answer from Fortune's report |
|---|---|
| Who is leading it? | Padmanabhan "Paddy" Krishnamurthy, 27, former EzDubs cofounder (acquired by Cisco in 2025) |
| Who sponsors it? | Jeetu Patel, Cisco president and chief product officer |
| What is the goal? | Rewrite 98% of legacy code in 24 months |
| What does he get? | Unlimited AI tokens and four weeks to prove the approach |
| Team size claim | Krishnamurthy believes a two-person team could do it |
| Evidence of results? | None reported yet |
What Fortune reports
Per Fortune, Patel found Krishnamurthy while visiting Cisco's San Francisco office. The engineer had cofounded EzDubs, a real-time translation startup from 2023 that Cisco acquired in 2025, and sat five levels below Patel in the org chart doing work Patel called "unstrategic." Patel gave him unlimited tokens so he could refactor code without rationing usage and told him to "go nuts."
The target is the 98% rewrite within 24 months, with a four-week window for Krishnamurthy to prove his method. Krishnamurthy believes a two-person team could do the job, and Patel said even Cisco's most AI-forward staff were not thinking at that scale.
Patel's wider team is split into thirds, per the article: experienced Cisco operators, outside systems thinkers, and AI-native founders and engineers. He also described a Stanford scholarship student, Baya, who emailed him monthly about what she learned on AI, earned an internship and redesigned something veterans had not solved. His argument: companies that stop hiring early-career people lose fresh ideas and the basic questions veterans stop asking.
What is a stated goal and what is evidence
It is important to be precise here, because "rewrite 98% of legacy code" sounds like an accomplishment and is not one.
- Stated goal: 98% in 24 months. No baseline is given for how many lines or services count as legacy, so the percentage has no stated denominator.
- Stated process: unlimited tokens and a four-week proof period. No model, tool or workflow is named.
- Missing: tests passing, behavior parity with the old code, security review, performance numbers, cost.
Rewriting code is the easy half. The hard half is proving the new code behaves the same as the old, especially in networking software where odd edge cases are the product. We saw the same gap in experts doubting AI COBOL migration claims: the translation step is quick, the verification step decides whether anything ships.
Why unlimited tokens matters
Most companies ration AI usage with per-seat caps and cost dashboards. Giving one person no cap is a deliberate signal: the constraint should be the engineer's judgment, not the budget. For large migrations that is rational, because agents that read, plan, edit and test burn many tokens per file and the work parallelizes across a codebase.
It is also a risk. Without any cap, a loop that goes wrong can burn money quickly, and without review a confident but wrong rewrite can slip into production. A sensible version of the idea keeps the generous budget but adds guardrails: per-run limits, sandboxed execution, required tests, and human review of anything touching security or protocol behavior. Teams running agents unattended can look at AgentBeam, the agent security platform from the explainx.ai team, for stopping agents before dangerous actions.
How a large AI-assisted rewrite usually runs
Fortune does not describe Krishnamurthy's method, so this section is general background on how teams typically approach a migration of this kind, not a description of Cisco's plan.
Step one is inventory. Before any agent touches code, someone has to map what exists: services, languages, build systems, owners, and which parts have tests. Legacy estates at large companies often include code nobody on the current team has read. An agent can help produce this map by summarizing modules and dependency graphs, but a human has to decide which pieces matter.
Step two is characterization tests. For old code with weak tests, the safest approach is to record what it currently does (inputs and outputs, logs, packet traces for networking software) and turn that into a regression suite. The rewrite then has to match the recorded behavior. Without this step, "rewrite" quietly turns into "change behavior and hope."
Step three is slice-by-slice translation. An agent proposes a new version of one module, runs the characterization tests, fixes failures, and opens a change for review. Because the work is mechanical and repeated, it parallelizes well, which is where a large token budget pays off.
Step four is review and rollout. Reviewers focus on the risky parts: concurrency, memory handling, security boundaries and protocol corner cases. Rollouts go behind flags, with the old path kept until the new one has run in production without regressions.
Where it breaks. Agents tend to produce plausible code that passes the visible tests while missing unwritten behavior. Long-running sessions drift, and reviewers get fatigued by large diffs. The cheaper the generation becomes, the more the bottleneck shifts to verification and review, which is why a headline percentage tells you little without the verification story behind it.
Why a young, AI-native lead might genuinely help
There is a fair argument for Patel's choice that does not depend on the 98% figure. Engineers who grew up with coding agents often have different defaults: they start by asking the agent to plan, they write tests first so the agent has something to check against, and they are less attached to the old structure of the code. Veterans bring knowledge of why the code looks the way it does. Putting both on one team, which is what Patel describes with his thirds, is a sensible way to get speed without losing institutional memory.
The counter-argument is just as fair. A four-week proof is long enough to show a promising demo on a well-behaved module and too short to show the hard cases. Success on a clean module does not predict success on the tangled, undocumented parts that make up much of any legacy estate. The right reading of a good four-week result is "worth funding the next phase," not "the 98% is in reach."
The jobs angle
The article is as much about hiring as about code. It cites a figure that about 40% of bosses plan to hire fewer graduates because AI can do the work more cheaply, and contrasts it with Patel, Thrive Capital's Josh Kushner, Tastewise CEO Alon Chen and will.i.am, who it says are leaning into young talent.
That fits a wider pattern in our coverage. Anthropic examined junior hiring and agents; a report on UK employers cutting entry-level jobs pointed the other way; and the debate over India IT entry-level hiring shows how contested the numbers are. A study we covered in AI adoption and entry-level hiring adds more data. The Cisco story is an executive's stated bet, not a dataset, so weigh it as opinion plus anecdote.
What engineering teams can copy
You do not need Cisco's budget to apply the useful parts.
- Pick one owner with real latitude. The experiment works because one person can make decisions without a committee.
- Search below the org chart. Patel's find was five levels down. AI-native skill often sits where nobody is looking.
- Set a short proof window. Four weeks forces a demo, not a plan.
- Define done before you start. Decide the denominator for "legacy," the tests that must pass, and how parity is checked.
- Migrate in slices. Start with modules that have good tests and low blast radius, then widen.
- Track cost per merged change, not just total spend, so unlimited does not become unexamined.
- Pair the newcomer with a veteran reviewer. Patel's "reverse mentor" idea works in both directions.
Questions to ask before believing the 98%
- 98% of what, measured how: lines, services, repositories?
- Does "rewrite" mean translated to a new language, refactored in place, or replaced with new design?
- How is behavior parity tested, and who signs off?
- What is the token bill for the proof period, and who approves scaling it?
- What happens to the engineers who maintain the old code?
We will update this post if Cisco or Krishnamurthy publish numbers from the four-week proof.
Related reading
- AI COBOL migration: experts doubt the 87% legacy-code claim
- Anthropic on junior hiring and agents
- UK employers cut entry-level jobs
- India IT entry-level hiring and AI
- AI adoption and entry-level hiring study
- Cisco Antares: open-weight SLMs for vulnerability localization
- Cisco's own announcements: newsroom.cisco.com
Details are as reported by Fortune on October 30, 2026; Cisco has not published its own write-up of the project that we could find.