Unlimited AI Tokens Are a Process Test, Not a Coding Strategy

TL;DR: If Cisco really gave an engineer unlimited AI tokens to rewrite legacy code, the useful lesson is that token caps are the easy constraint, verification is the hard one.

What changes when the token budget disappears?

Hacker News surfaced the claim as “Cisco gives engineer unlimited AI tokens to rewrite legacy code.” I have not seen a Cisco first-party announcement in the supplied material, so I would treat the company-specific detail as reported chatter, not a settled case study.

Still, the setup is useful because it points at a real shift inside engineering teams.

For the last two years, a lot of AI coding policy has been framed around scarcity: keep usage under a token budget, limit model access, push engineers toward cheaper models, stop runaway agent loops. That made sense when the tooling was immature and nobody knew whether the monthly bill would explode.

But if you remove the token cap, the bottleneck does not disappear. It moves.

Now the scarce resources are codebase knowledge, reviewer attention, test coverage, build time, migration sequencing, and confidence that the generated change preserves behavior. That is much harder to buy than tokens.

Legacy code is the worst possible place to confuse volume with progress. Old systems often encode undocumented business rules. They contain dead-looking branches that exist because one customer, device, region, or integration depends on them. They pass through build systems nobody wants to touch. A model can rewrite syntax quickly. It cannot automatically know which weird behavior is accidental and which weird behavior is contractual.

Can AI safely rewrite legacy code?

Yes, sometimes. But “rewrite” is doing a lot of work.

There is a big difference between using an AI coding assistant to modernize small modules, add missing tests, translate one internal API call pattern, or remove deprecated dependencies, and asking it to convert a large legacy system in one sweep. The first class of work is already practical. The second is where demos turn into archaeology.

A useful AI-assisted rewrite should look boring from the outside. Pick a narrow slice. Freeze behavior with characterization tests. Generate candidate changes. Run the full test suite. Compare outputs. Review the diff. Ship behind a flag or in a low-blast-radius path. Repeat.

That does not sound as exciting as “unlimited tokens.” It is also how grown-up software gets changed.

The best use of large token budgets may not even be generation. It may be exploration. Ask the model to map dependency chains. Identify risky files. Explain call paths. Draft tests for behavior that is not documented. Find duplicated logic before a human starts moving code. In legacy systems, reading is often more expensive than typing.

That is where AI can pay off. Not by replacing the senior engineer, but by giving that engineer a tireless junior analyst who can read a million boring lines, propose a plan, and be wrong in ways the senior engineer can catch.

What should builders copy from this?

The wrong lesson is “give everyone unlimited tokens.” The right lesson is “do not manage AI coding only through usage limits.”

A team that wants to try this should start with a rewrite candidate that has three properties: clear owner, measurable behavior, and a rollback path. If any one of those is missing, the AI tool is not the problem yet. The project shape is.

Then track outcomes that matter. How many generated diffs were accepted after review? How many tests were added before code changes? How many regressions escaped? How much reviewer time did the process consume? Did the rewrite reduce operational risk, or did it just make the code look newer?

I also would not start with the fanciest agent stack. Use the tools engineers already trust. Pair them with strong repo search, CI, tests, and explicit instructions about preserving behavior. The model can be Claude, GPT, Gemini, Qwen, or a local code model depending on the environment. The discipline matters more than the logo.

Practitioner’s take: try AI on legacy code first as a comprehension and test-generation assistant, not as a full rewrite engine. Give it enough context to map the system, ask it to propose a migration plan, then make it prove behavior with tests before changing production code. The catch most readers miss: unlimited tokens only help if your verification loop is stronger than your generation loop.