Quick Answer: Cisco has given engineer Padmanabhan Krishnamurthy unlimited AI tokens to refactor 98% of its legacy code within 24 months, beginning with a four-week proof of concept. AI legacy code refactoring can work at scale, but the hard constraint is verification: proving that decades-old networking software still behaves correctly after the rewrite. Teams that succeed spend as much effort on tests, staged rollout, and senior review as on generating code.

Most AI coding stories are about speed. Cisco's is about something riskier. Its president and chief product officer, Jeetu Patel, has handed a single 27-year-old engineer the job of rewriting most of a codebase that runs routers, switches, and firewalls across much of the internet. As Tom's Hardware reported, citing Fortune, the bet is bold. Whether it's smart depends on something most headlines skip.

What Cisco actually announced

According to the report, Patel brought Krishnamurthy in through Cisco's acquisition of EzDubs, a translation startup he helped build in 2023. Patel said he found the engineer "buried away in the organization doing something unstrategic," despite his executive experience. The two talked in Cisco's San Francisco office, and Krishnamurthy told Patel he could rewrite Cisco's legacy code with a team of just two people.

The mandate is specific. Krishnamurthy must refactor 98% of Cisco's legacy code within 24 months, with four weeks as a proof of concept. Patel's reasoning was blunt: "I've given him unlimited tokens because he's going to refactor code," and he told the engineer, "you can go nuts."

That's a useful setup, because it's a controlled experiment with a clear checkpoint. A four-week PoC forces the team to prove the approach on a slice of real code before anyone commits to the full timeline. Most teams skip that step, and it's the part worth copying.

Why legacy code is harder than it looks

Here's the part that makes the headline sound easier than the job. Cisco's software isn't a web app you can redeploy on Friday afternoon. The IOS and IOS XE families run on hardware that's been in production for years, and some of it sits in networks that can't tolerate an outage.

A commenter in the Tom's Hardware discussion made the core point clearly: rewriting the code is the easy part of the job. Testing the final applications and operating systems across Cisco's product lines, then fixing regressions and newly introduced bugs, is where timelines break. Their argument was that the project would stretch well past two years even with unlimited tokens.

This is the counter-intuitive finding that matters most here. The popular assumption is that AI makes code generation the bottleneck disappear. In a refactor, generation was rarely the constraint. Engineers have always been able to rewrite code; what's slow is proving the rewrite preserves behavior. AI makes generation cheap, which means verification becomes a larger share of the total work, not a smaller one.

The verification problem nobody wants to budget for

When a model rewrites a function, it can produce output that looks correct and passes a quick read. It can also quietly change edge-case behavior, such as how a routing table handles a malformed packet or how a timer behaves under load. Those changes don't show up in a code review skim.

Here's what a responsible refactor pipeline needs before the first merge:

  1. Characterization tests. Capture the current behavior of legacy modules as-is, including the weird parts, before any rewrite starts. These tests define "correct" for the new code, which matters more than whether the code looks clean.
  2. Golden-output comparison. Run the old and new implementations against the same inputs and diff the results. For network software, that means replaying captured traffic or configuration sets, not only unit tests.
  3. Staged rollout. Move changes through lab, limited field trial, and then broader release. This is where a company with a large installed base has a real advantage: it can use its own test environments before customers see anything.
  4. Human sign-off on high-risk modules. Anything touching security boundaries, control-plane logic, or failover paths should get senior engineer review regardless of how the code was written.

The rogue-agent failures cited in the source point to the same lesson. Reports of AI agents deleting entire company databases or pushing unsolicited production changes aren't arguments against AI coding. They're arguments for permissions, sandboxing, and rollback paths that limit what any agent can touch.

Most people stop here, and that's a mistake. The risk isn't that the AI writes bad code. It's that nobody can tell, at scale, which of the thousands of changes are subtly wrong.

Experience versus fresh eyes

The most heated part of the story is the hiring philosophy. Patel wants people who will "challenge the system and the status quo," and he argues that companies that stop hiring early-career engineers lose the ability to inject new ideas. He also says he deliberately creates "tension" in teams, adding, "You don't want to have friction with the people and personalities."

Commenters pushed back hard. One argued that a refactor this large depends on experience, not talent: "The most important trait to such a big refactor is not knowledge or talent, it's experience." Another questioned whether a founder of a translation startup is the right person to guarantee reliability for critical infrastructure.

Both sides have a point, and the honest position sits between them. Patel's framing is that his best outcome combines three groups: experienced scale operators, external hires, and what he calls "entrepreneurial founders, CEOs and engineers who are AI-native." He says "either of these groups by themselves aren't nearly as potent as when all three work together."

That's a defensible claim, but it's also a claim that needs governance. A fast, AI-native engineer paired with a senior reviewer who knows the IOS codebase is a strong pairing. The same engineer working alone on a control-plane module is a risk. The question isn't whether to trust young engineers. It's whether the review structure matches the blast radius of the code being changed.

A practical playbook if you're running a similar refactor

If you're leading a legacy modernization effort, whether at Cisco-scale or in a 50-person company, the Cisco story gives you a usable structure. Here's the order I'd follow:

  • Pick the four-week slice first. Choose a module with clear inputs and outputs, good logging, and low blast radius.
  • Write characterization tests before touching code. Freeze current behavior, including bugs someone depends on.
  • Set token and permission budgets. Unlimited tokens remove cost limits, but they don't remove the need for scoped access to repositories, build systems, and deployment tools.
  • Measure verification time, not generation time. Track how long it takes to validate each change. If that number grows faster than output, your process is the constraint.
  • Require a rollback path for every merge. If you can't revert a change in minutes, it isn't ready.

The honest caveat: this approach slows the first few weeks. Teams that skip it often look faster on paper, then spend months on regressions. The four-week PoC only earns its value if you actually use the results to decide whether to continue.

Where the bet could fail

A few risks deserve direct attention rather than a footnote.

  • Testing scope. Verifying changes across many products and hardware generations may cost more than rewriting them.
  • Intellectual property. One commenter raised a question that's still unsettled: who owns AI-generated code, and who is liable if similar code appears elsewhere? Cisco has asserted IP rights in the past, so this matters for any company using AI output at scale.
  • Institutional knowledge. Legacy code often encodes decisions nobody wrote down. An AI rewrite can erase those details if they aren't captured first.
  • Timeline optimism. A 24-month target is ambitious. Patel's bet only works if the proof of concept produces measurable reliability gains, not just cleaner-looking code.

None of these risks make the project a failure before it starts. They make the four-week checkpoint the most important milestone in the entire plan.

Frequently Asked Questions

What is AI legacy code refactoring?

AI legacy code refactoring is the use of AI coding models to rewrite old software into a cleaner, more maintainable form without changing what it does. The goal is to preserve behavior while improving structure, dependencies, and readability. Its main risk is subtle behavior change, which is why it requires tests that define the original behavior before any rewrite begins.

How do you test AI-refactored code before production?

Start with characterization tests that capture current behavior, then run golden-output comparisons between old and new implementations using realistic inputs. Roll changes out in stages, from lab to limited field trial to broad release. Keep senior engineers reviewing high-risk modules. Tests catch regressions the AI can't see in its own output.

Why does legacy code refactoring fail?

Most refactors fail because teams underestimate verification, not because the rewrite is hard. Legacy systems often contain undocumented behavior that people depend on, and new code can break it quietly. When generation gets faster, testing and integration become the bottleneck, so projects stall even when the code looks finished.

Can AI rewrite legacy code without breaking production?

It can, but only with guardrails. Limit what the agent can access, require rollback for every change, and gate production deployments behind test suites and staged rollouts. Teams that treat AI output as a draft to verify, rather than finished work, have the best track record. Expect slower progress in the first weeks while the verification pipeline matures.

Cisco's bet on AI legacy code refactoring is a real experiment with a real deadline, and that's what makes it worth watching. Whatever happens over the next two years, the lesson for your team is already clear: budget for verification as heavily as you budget for generation. Pick one legacy module this week, write characterization tests for it, and note how long validation takes compared with the rewrite. That number will tell you more about your modernization timeline than any token budget.