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.

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.

> While I certainly don't work at Cisco, I've come to the conclusion that I need to re-examine my priors when it comes to code rewrites and general maintainability.

One of the reasons to avoid rewriting has long been that the time spent rewriting code that works is time not spent writing code to meet new business needs. In other words, it's usually a huge opportunity cost, rarely balanced out by sufficient gains to be net positive.

I do think AI does challenge this prior, as the time needed to do a rewrite shrinks dramatically. It's not zero, of course, but it now becomes worth asking if it's worth doing, rather than defaulting to avoiding rewrites in nearly all cases.

Does the coding assistant demonstrate any tricks to improve the likelihood of success for such rewrites?

They also seem to crave everything that has the word AI in it.

Or perhaps the lack thereof if you are one of the unsuccessful companies. In the 90s, I worked for a company that competed with Cisco I worked for a company that competed with Cisco. story was in the mid 80s an executive went to Silicon Valley. His report was that Cisco was a bunch of nobodies that would never go anywhere, which they'd go down the street and buy Vitalink instead. You have heard of Cisco and not Vitalink for a reason.

It doesn't, but Cisco was great and they've just evolved into a laughing stock. Their stuff is really bad these days.

And they've overstretched their product line to too many things, trying to be the "be all" company. Fortinet is making the same mistake, but they're earlier in that process.

I mean, it's not really a mistake on their parts, their primary goal is to get rich and they are succeeding.

Citation: I've been working with Cisco technologies since the mid-1990s. At my current job, we are a few weeks away from phasing out the last of our Cisco junk. And since people will ask: to Juniper/Mist and Arista.

True. There were few (no other?) options for routers back then. I have fond memories of locking myself out of an ISP's core router then having to power cycle it.

I don't want to sound racist (which I'm not), but in my experience Indian software developers have often been less careful and concerned about quality than the average developer; it probably comes from many only becoming so for the job prospects, and not having much computer experience before college.

So it's not surprising if they embrace AI.

There's also that Indian cheaper outsourcing companies risk being displaced by AI, if they don't adopt it extensively to further reduce their pricing.

The date picker example is perhaps the best worst they could have picked.

Anyone who has used the built in date picker knows why everyone rolls their own.

His job isn’t to rewrite all the code. His job is to make the market satisfied that Cisco is “more AI” than competitors.

You forgot to mention the translation company he helped found was also acquired by this same CEO. :))

Regression tests?

I think people are assuming the worst but AIs most helpful contribution beyond churning out code is explaining the code base.

Who knows if they will do a good or bad job that's down to the engineers and not the tools imo.

Documentation in "plain english", architecture diagrams, comments, and documentation are notorious for being unreliable, out-of-sync, and not as precise a specification as the code itself.

The issue with using "the code as the spec" is that humans can't read 100K lines of code in a day, can't hold the entire ball of unstructured mud in their brains all at once, and generally require hierarchical "structure".

Modern AIs just don't have these issues! Their context windows are big enough to encompass an entire codebase, so they can "see everything", all at once.

Each line of new code they write is compared against every relevant line of code in the original, which they treat as a spec.

My main issue in my experience is that that AIs tended to reproduce the legacy behaviour "bug for bug", which was not my intention.

Similarly, the AIs were hamstrung by external constraints: I typically prefer to leave the DB schema unchanged, which meant the torturous workarounds were needed for design errors in some stored procedures, etc.

The older the code, the bigger the issues with baked-in assumptions about transactions, stateful sessions, data types, string formats, etc.

This trips up AIs just as much as humans. You can't trivially maintain backwards compatibility and modernise the codebase! Those are conflicting goals, no matter what.

"Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back

https://www.reddit.com/r/programming/comments/eaqgk/java_is_...

"XML is like violence: if it doesn't solve your problem, you aren't using enough of it." -Chris Maden

https://www.reddit.com/r/ProgrammerHumor/comments/1mbgih/xml...

"XML is a giant step in no direction at all" -Erik Naggum

https://quotefancy.com/quote/1643080/Erik-Naggum-XML-is-a-gi...

I'm probably not describing the scale of the issue adequately. Lots of these bugs only show up when you have a specific bit of hardware on a specific version of code, and it's connected to another specific bit of hardware running another specific version of code.

Lots of this stuff should work in theory, you only find out that it doesn't in practice when you try it on real hardware. And there are thousands of bits of hardware.

I'm talking about heterogenous legacy hardware that isn't owned by Cisco, not complex topologies.

Not that straightforward. Similar to CPUs and other HW, there are errata and interop quirks between devices.

There are also tight time budgets (basically SLAs) that must be met along with memory considerations (both in SW and on the NPU/HBM), not to mention how the device needs to respond to load and various failure scenarios.