Cisco gives engineer unlimited AI tokens to rewrite legacy code (fortune.com)

https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fv...

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.

Cisco did provide updates via CCO and anonymous ftp server. They quite openly told that just download new image and test in your lab, and then if feature set did require licensing, please do it before deploying production. Trust was put on customers and they did very little to check and verify if customers did comply. Which is quite contrary to what for example Oracle practise is been.

>If history has taught us anything. It’s that the measure of a successful product is usually more to do with its sales people.

As someone who worked Cisco gear over thirty years I still remember why us networking did want cisco instead of many other brand devices and it hadn't anything to do with marketing and sales people did.

The Cisco IOS text based configuration was in early days of internet which made it so popular.

Many other manufacturers like HP, 3Com, Cabletron, Madge (IBM), Bridge, etc. did not get why we wanted and complained “give us textual configuration format like IOS has”.

With a plain text based configuration it was easy to adapt configuration from one model to have ready made templates for each model, upgrades and migration to new models were easier, you could use version controls (rcs,cvs, svn,... long before git) and then when RANCiD came it was easy to automate config backups, revert and rollback changes, pass audit with human readable configs and what was in production even long time after etc. In short text based configs made it possible to build large network scale configurations management tools.

IOS has compact, but quite easy to read config snippets made it much easier emailing others, posting examples newsgroups, opening TAC at Cisco CCO, books with examples, learning and teaching etc.

It took quite long before for example HP understood and switched text formats right after turn of century. Juniper seemed to understood right from beginning. But some like Fore, Nortel, Alcatel (ATM-switch makers) and many others did not understand before going out of business. Most of these others had either menus (3Com, HP) or a lousy CLI with obscure unique for just that device model and quite often not even option to print config or if they had not just with changes from default config but printing everything and providing no means to drop showing default. This made it manually while online very hard without external version control to even know what is current status and what had been changes.

BTW, this is still an issue with some manufacturers haven't understood and makes their devices much worse than they understand. Fortigate firewalls CLI is still like this. You can select a subsection of config to print, but it will no indication what differs from default configs. And the whole firewall config is hundreds of kilobytes. Good luck finding what's been changed unless you had saved default config when you started using that device!

When you have thousands to even tens of thousands of network devices in use as many were working you need to be rely that even when you encounter device failure and you don’t have same model any more available, you are able to adapt and find working fix configuring something else doing what is needed.

Binary and any non textual configurations may fit the purpose SOHO category devices, but when network grows even bit larger and configurations more complex there isn’t anything better than text base configs as far as us humans will need to configure and maintain those devices.

Cisco have had issues with software quality for sure, but it was Cisco IOS that was the reason it became so popular and we wanted to use it.

And we did put more weigh on manageability which that IOS text based configuration provided than for example speed some manufacturers got with their devices (Madge, etc.) and even when some Cisco switches dropped some Network World tests more packets we still wanted that manageability more and relied Cisco will fix those issues with software upgrades which it often did.

Juniper when it came end of 90's did understand this and made even better configuration system for Junos than IOS was and still is. Cisco have improved things with IOS-XR, but it's still not up to what Junos is currently.

e: fixed few typos and added that manageability chapter near end. Places where I did work none were always everything Cisco places. No, but either so called ABC (Anything But Cisco) places either. Cisco was and is still popular for those reasons mentioned above.

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

It doesn’t matter if it’s satire. Developers seem to be so vulnerable to all these AI promises of ‘automating’ everything.

BTW it’s terrible. It gave two very hollow suggestions that did not solve the real problem. Hour wasted, angry colleagues, no code change.

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.

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.

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.

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.

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.

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.

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.

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.

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...