Cisco Lets 27-Year-Old Engineer Rewrite 98% of Code with Unlimited AI Tokens — Will It Work?

Title

Cisco Lets 27-Year-Old Engineer Rewrite 98% of Code with Unlimited AI Tokens — Will It Work?

Meta Description

Cisco's president gave a 27-year-old engineer unlimited AI tokens to refactor 98% of legacy code in 24 months. This article breaks down the fact gaps, three successful AI migration cases, a four-stage safety pipeline, and the judge mechanism that determines success.

Article Content

Cisco President Jeetu Patel told Fortune that he gave a 27-year-old engineer unlimited AI tokens, with the goal of refactoring 98% of the company's legacy code within 24 months — with a team of just two people and only four weeks to prove feasibility. Once the news broke, public attention focused on the "unlimited tokens," but what truly determines success or failure has never been tokens.

Fact Check: What We Actually Know

According to an interview published by Fortune on October 30, this engineer joined in 2025 through Cisco's acquisition of real-time translation startup Easydubs. Patel said he had previously been "buried in the organization doing unimportant things." After the two talked in Cisco's San Francisco office, the engineer proposed that two people could rewrite Cisco's legacy code. Patel's response was: "You can go full throttle."

But key information is largely missing: no budget, no specified models or programming tools, no indication of which code is involved, which languages, or how many lines. More subtly, you may not have noticed the difference in verbs — the engineer said "rewrite," while the goal is written as "refactor." Refactoring keeps behavior unchanged and only changes structure; rewriting throws away old code and starts over. These are completely different kinds of work.

This is also not Cisco's first foray into AI programming. Previously, Cisco partnered with OpenAI, where Codex increased defect-fixing throughput by up to 15x, saving over 1,500 engineering hours per month; and a three-month pilot with Sonar closed about 27,000 technical debt issues. The toolchain is real; the question is scale.

Why Engineers Are Wary of "Rewriting"

In 2000, Joel Spolsky wrote that rewriting code from scratch is the worst strategic mistake a software company can make. His example was Netscape: throwing away the browser code and starting over, nearly three years passed from version 4 to version 6 beta, and the market was lost.

Old code is hard to replace because ugly old code is stuffed with fixes. That strange check on line 400? That was a bug someone found in production at 3 a.m. in 2011, and it was never recorded anywhere else. Delete the code, and you delete the lesson.

There's also Hyrum's Law: with enough users, every observable behavior of a system will be depended upon by someone — not just the documented promises, but also the format of error messages, the order of results, the timing of calls. Change a sort that preserves the order of equal elements, and some report will quietly reorder. New code can be cleaner and still break customers.

Michael Feathers gave the definition most engineers adopt: legacy code is code without tests. That's the real problem. If nothing checks the behavior of the old code, nothing can tell you the new code behaves the same.

Hyrum's Law (also known as Hyrum's Law) was proposed by Google engineer Hyrum Wright. Its core is: when an API has enough users, no matter what you promise in the documentation, all observable behaviors of the system become de facto contracts — because there will always be users depending on these behaviors. "Observable behavior" here includes not only return values, but also the text of error messages, the timing of exceptions, the ordering of results, the execution time of functions, and even log formats. This means that any seemingly harmless internal change, as long as it alters these undocumented behaviors, can break downstream systems. In the context of AI rewriting legacy code, Hyrum's Law is the biggest hidden trap: new code can be logically equivalent yet crash a customer's production environment because of a wording change in an error message or an extra network call — and tests often fail to cover these details.

Three Successful Large-Scale AI Migrations

There are public success stories of large-scale AI migrations, with numbers.

Airbnb migrated about 3,500 test files from Enzyme to React Testing Library. Manual estimates required a year and a half; it was actually completed in six weeks. The first batch run had 75% of files passing within four hours, then tuning for four days reached 97%, and the final 3% were manually fixed by engineers, taking about another week.

Google published a paper on 39 migrations involving 595 code changes, where the model wrote about 74% of the changed code, and engineers estimated total time was halved.

Amazon upgraded tens of thousands of Java applications to Java 17. Andy Jassy said one upgrade went from about 50 developer-days to a few hours, and developers committed 79% of generated changes without editing.

What these cases have in common: each had a clear target (old framework in, new framework out), each had automated checks (tests pass, build compiles, linter satisfied). And none was a rewrite from scratch — they were all migrations: same behavior, new framework.

The Ignored Key: The Judge Matters More Than the Model

Every victory had a judge that wasn't human: a machine that thousands of times a day, for free, judged "this change is correct." The model was never the bottleneck; the judge was.

This changes how you interpret "unlimited tokens." Tokens make attempts cheap. Airbnb retried most files up to 10 times, and the hardest 50 to 100 times — that's exactly what unlimited tokens buy: the ability to fail repeatedly without anyone counting. But failing a thousand times only helps if something tells you which attempt was right.

Do the math: suppose the model gets a hard file right one in ten times. If a machine checks every attempt, 20 attempts give about an 88% chance of passing; without checks, 20 attempts just give you 20 plausible-looking answers.

For test migrations, the judge is simple: run the tests. For legacy code without tests, the judge doesn't exist yet. So the zeroth step of any AI rewrite is not writing new code, but building the judge.

Golden Master is a black-box testing technique popularized by Michael Feathers in "Working Effectively with Legacy Code" to establish a behavioral baseline for legacy code lacking tests. The approach: call the old code with a large number of real or randomly generated inputs, serialize every output (including return values, exceptions, even logs) to files and commit them to version control. Thereafter, any new version of the code that produces even a one-character difference under the same inputs will fail the build. The philosophy of Golden Master is "don't judge whether behavior is right or wrong, only whether behavior has changed" — it defines "correct" as "consistent with the old code," thereby bypassing the lack of specifications. For AI rewrite tasks, Golden Master is an ideal automated judge: low generation cost (AI excels at generating inputs in bulk), strong determinism (byte-by-byte comparison), and it can capture the undocumented behaviors described by Hyrum's Law.

How Two People Could Actually Try: A Four-Stage Pipeline

Stage one, freeze behavior. Before touching anything, write characterization tests: run the old code with real inputs and record its behavior today — including bugs. These records become the definition of "correct." For example, a 40-line price formatting function: call it with 10,000 recorded inputs, store every output in a file and commit it. Thereafter any new version that changes one character of output will fail the build. This file is called a golden master. AI is exactly good at this part: reading old code and generating thousands of input cases.

Stage two, slice. Don't replace the whole system; use the Strangler Fig pattern: put a router in front, migrate one module to new code and route traffic to it, while the rest continues running old code. If a slice breaks, route back.

Stage three, agent loop. For each slice, the model writes a new version, and the machine checks: does it compile? Do characterization tests pass? Lint? Types? Security scan? Any failure goes straight back to the model with the error to retry. Humans only look at what passes.

Stage four, prove in production. Tests never cover everything, so run the new code in shadow mode: real traffic goes to both versions, users get the old answer, and a diff tool compares the two. Only after outputs match for several consecutive weeks do you switch traffic.

The four stages are: freeze, slice, loop, shadow. Most tokens are spent in stages one and three.

Strangler Fig Pattern was proposed by Martin Fowler, named after the growth of strangler figs in tropical rainforests: the fig seed lands on a host tree, and its roots gradually wrap around and eventually replace the host. In software migration, the pattern places a routing layer (such as an API gateway) in front of the old system, gradually switching traffic from old modules to new ones, migrating one slice at a time while the rest of the old system keeps running. If a new slice fails, you simply route back to the old implementation to roll back. This pattern contrasts sharply with "big bang rewrites": the latter requires replacing the entire system at once, with concentrated and irreversible risk; the strangler fig pattern allows incremental validation, limiting the impact of failure to a single slice. For AI-driven rewrites, the strangler fig pattern provides natural experiment boundaries — each slice can independently have characterization tests and shadow validation, making the goal of "two people refactoring 98% of code" decomposable and measurable in engineering terms.

Five Traps Money Can't Solve

Trap one, review. The more code generated, the more human PRs. Sonar's article on Cisco calls it the "productivity paradox": AI gets faster, but reviewers get flooded. Two people cannot read a rewrite of this scale line by line. Either the judge must be trustworthy enough to skip most reviews, or review becomes the bottleneck.

Trap two, the long tail. Airbnb went from 0 to 75% in four hours, but the last 3% took a week of manual work. Easy code goes first, and a 98% goal means the hard bones are the real work.

Trap three, behaviors no one recorded. Timing, memory limits, code that talks to hardware. Hyrum's Law strikes again: characterization tests only record what you thought to test.

Trap four, security. New code means new bugs, some of the kind tests never check.

Trap five, people. A rewrite at this scale touches every team that owns old code. Two engineers can write it, but hundreds of owners must trust it, deploy it, and be woken up at night for it. This is a coordination problem, not a token problem.

Can It Actually Work?

The honest assessment: refactoring most of Cisco's code in slices, with machines doing the checking — credible, as every stage of the pipeline has been validated at scale somewhere. Two people rewriting 98% from scratch in two years — there is no public evidence anywhere close to this. The two-person team is the variable worth watching.

What would change my mind? If the proof shows that most code has a usable judge, and shadow mode finds almost no differences, then two people plus unlimited tokens really could beat a hundred-person migration team. That would be the real news.

What should the four-week proof demonstrate? Not how many lines were written — lines are cheap now. Three numbers: what percentage of target code has a usable judge, how many slices pass shadow mode, and how many human review hours per thousand lines.

For every developer, the real lesson of this story is: the scarce skill is not writing code, but building the thing that proves code is correct — tests, test harnesses, diffs. AI has not devalued this work; it has made it more valuable.

Freeze behavior, slice the system, let agents loop, prove in shadow, let tokens drive the loop — the judge decides everything. One habit you can steal today: before letting AI rewrite anything, write the test that will catch it when it goes wrong.

One-line Summary

Cisco's two-person team uses unlimited tokens to refactor 98% of legacy code, but the automated judge — not tokens — determines success.

Paragraph Summary

Cisco President Jeetu Patel told Fortune that a 27-year-old engineer and a teammate received unlimited AI tokens to refactor 98% of the company's legacy code within 24 months, proving feasibility in four weeks. Public attention focused on "unlimited tokens," but the article points out the real bottleneck is the "judge" — tests, compilation, and linters that automatically determine whether AI-generated code is correct. The article checks key gaps in public information (such as the verb difference between "rewrite" and "refactor"), reviews Joel Spolsky's classic argument against rewrites and Hyrum's Law, and uses three successful large-scale AI migrations at Airbnb, Google, and Amazon to show they were behavior-preserving migrations rather than from-scratch rewrites. It proposes a four-stage pipeline (freeze behavior, slice migration, agent loop, shadow validation) as a viable framework, and lists five traps tokens can't solve: review bottlenecks, the long tail, unrecorded behaviors, security, and cross-team coordination.