A rewrite is a slam dunk for any decent frontier AI. It has a penchant for maintaining API/etc contracts to a fault in the absence of instructions to the contrary. It can easily validate its work and loves building exhaustive test cases. You can tell it to get 100% code coverage if you want. It will laborously accurate document every accumulated edge case and help you find a better overall cohesive structure.
A rewrite has historically been a huge mistake in many situations, some of which I've personally had the agony of witnessing firsthand, powerless to stop it. But AI completely changes the calculus because it doesn't waste significant developer time or energy crawling back to the previous working state, it just does it while you go get coffee. And this I've found to be a huge benefit, that I can continue making my codebases nicer to work with and better documented/integrated with bugs stamped out for free. There are upsides to a rewrite, and they're now much more likely to be worth it as the downsides are automated away.
> It has a penchant for maintaining API/etc contracts to a fault in the absence of instructions to the contrary.
AI has no magic powers to figure out what the “API/etc contracts” are in a nasty old codebase. This problem is fundamentally hard and not always well defined.
AI is also (at least for now) not consistently good at writing tests that test the behavior that matters. Recent models seem to be getting slightly less bad, but again, this is a hard problem.
I’ve personally used AI to rewrite gnarly code where the goal is to have exactly identical results to the old code. GPT-5.6 Sol could do this correctly with some extra help guiding it to rest the right things, and I haven’t tried this particular task on a newer model.
But ancient code like in the article is probably an enormous buggy mess full of accidental behaviors and implementing protocols in ways that do not fully match the spec. Some, but not all, of the mismatches will be cases where the spec is wrong. Sure, an AI can probably generate a new implementation with a similar set of bugs, but is this what is actually wanted? Also, depending on the gnarly set of bugs, a clean implementation may be unable to reproduce the bugs, leading to a messy implementation instead.
If this was true then Python would already have been rewritten to be GIL-free, and the entire ecosystem of Python packages would have been rewritten to respect its API.
Absence of evidence is not evidence of absence! We're on this thread because Cisco is sponsoring piles of tokens at the problem. No such megacorp sponsor exists for this problem for Python. The megacorps have decided not to sponsor that specific problem.
> Absence of evidence is not evidence of absence!
I'm not a lawyer and don't like writing sentences with "probability bordering on certainty", etc.
Absence of evidence is evidence, it's just not very strong evidence.
What would be the Python megacorps of choice ? Trading firms ? Not a regular pythoner (pythonist ? pythonian ?) myself.
Google has their own dialect of Python that they use internally that could stand to be faster. Microsoft also uses Python all over the place. (GvR has worked at both of them.) Both of them have, at one time or another, sponsored teams to make Python faster, along with Meta. Just not for the above specific cause.
Pythonista
I imagine it has been, but they didn't release it because the diff is too big to be accepted into regular Python and it would cost more to fix it than use it as is.
With the current sota models code is free.
In my experience it's been much simpler to rewrite programs from Python to <insert lower level language of choice here>
I hope everyone that reads this can understand why it's a ridiculous argument.
Could you explain for those of us who are a bit slower? Why would the absence of a rich sugar daddy for python be evidence that it can't be done?
I'd even argue AI is better for maintaining/moderninzing existing code than writing it, just because there is so much less input from developer about architecture it requires, as it has it in the code itself.
But there is pretty big risk of false positives and negatives; some "bugs" are design decisions that were not documented well/at all, and inevitably some new ones will appear when it reasoned something wrong.
The entire point of a rewrite is to get rid of the behaviour you don't want, while you keep the behaviour you do want. Consider the pathological case: Rewriting your FORTRAN codebase in Rust would obviously be useless if you had to reimplement every bug in the rewrite.
An LLM doesn't have enough context to know what you so and don't want. If you give it call logs for every function that was called and how, maybe, but a seasoned engineer will have more context around what the company needs.
Not necessarily, a rewrite can just move to a language that's easier to maintain (off C / cobol).
Honestly though, it's pretty clear the AI rewrites work, we have a ton of high profile examples. It's just a holdover attitude about rewrites from before AI. In reality, AI is going to make the code better when it rewrites
> we have a ton of high profile examples
Such as?
Defining the legacy bugs and porting them as features during the rewrite is actually one of the most difficult parts of enterprise rewrites.
You don't get to pick what parts of the API you're porting during something like that, it has to work the same or some of the ecosystem around it will break.
Usually you’d choose to port features in slices end to end so that you don’t have to pull in bugs as side effects. Strangler fig.
Obviously this fails if this is a large org with many teams and microservices, but for a leaner org this isn’t really a problem.
I realize this thread is about Cisco so my comment doesn’t apply here haha.
The thing is, to get rid of unwanted behavior the first step is to document all the behavior and be able to reimplements it. Then you can pick and choose what to keep vs what to dump.
And AI is really good at all the stages here.