We just recently use Claude Code to port an old Coldfusion site to Java Spring and it went amazingly well. It's around 50K lines of Java, one of our engineers did it in his spare time over about a week, using the $200/mo Claude plan. We had been talking about doing it for at least the last dozen years but never found the time. It would have taken around 12-18 engineer-months to do this manually.
He had the translation use browser integration to compare the new site to the old site automatically. The result was so good that he had to change background color on the new site because he couldn't be sure that he was testing the new site; it was so close to the original he was paranoid about accidentally being on the old site and not knowing it. The whole thing was done in under 2 weeks, including coding, developer testing, tester testing, and deployment. It's been in production 4-6 weeks now and we've had no reports of problems.
Okay so assuming engineer compensation of $200k, you’re suggesting something like a thousand-fold productivity increase on this task in terms of cost and 26x or more in terms of time?
There’s no real productivity increase because that project was not worth pursuing before AI. It’s like wanting to build a tunnel in the 1700s by having 200 people digging it by hand, vs actually building it using machines in the 2000s. We don’t say there was an increase in productivity. The technology enabled a project that used to be a dream.
> Productivity is a measure of economic performance that compares the amount of goods and services produced (output) with the amount of inputs used to produce those goods and services.
The inputs here are money and the labor of the engineer. With this new form of automation, it takes far less of both. So much less in fact, that a previously uneconomical project is now positively cheap.
If your point is that the result isn't worth what it would have cost before, that's true, but it's the increase in productivity that changed the value proposition and allowed the project to be accomplished economically.
I'm being sarcastic as to the specifics but didn't productivity go down 199k because the 200k engineer is now replaceable with a 1k subscription and will soon be fired?
Literally the output of the labor dropped to almost zero value?
The subscription didn’t do any work though. It didn’t magically create a new knowledge worker any more than a lawn mower in a shed cuts grass. The output of the labor massively skyrocketed in value. If you fire that dev, who do you think will use Claude?
This instead is a concern for newer devs. There is now no argument for bringing on the cadre of workers you’d need to do all the hand-jamming, testing, and reviewing, learning how to code in the process.
If you’re the CIO/CTO/etc. obviously you wouldn’t be fired, but any other position is useless down to the dev.
Dev teams should be leaner now, with maybe at most a director as their manager up to executive level.
As for ‘how much software do I really need?’ Well, what sort of company is it? Do you have internal applications to support your orgs? If you seriously need to ask ‘how much software do I need?’ Then you should just fire yourself.
I don’t think your point is meritless, but this is specifically a discussion about that top-10% dev. The one doing this type of work is not the one who will be let go.
I know a lot of people think that the AI tools level the playing-field, but we aren't experiencing that. The guy that did this translation is doing more tickets than the other 4 software devs combined. And it's not because they are low-effort tickets. That's also on top of the 6 hours a week of meetings he has that the other devs don't.
Productivity can be measured in many ways. Neoclassical economists will tell you there’s only one.
In this case, is the change of this software from one language to another/framework to another even valuable?
Example: if I manufacture $1,000 worth of some illegal drug that will potentially turn a normal functioning adult into an addicted criminal, how shall we measure my productivity?
We literally do say that having more infrastructure is a result of increased productivity.
You say "not worth pursuing", which could also be phrased as "too costly to pursue". With much more capacity available, it becomes possible to do more things. This is true for lots of things.
What is the unit for productivity here, though? Time required to complete this one task, which was never attempted before and never will be again? That's fine, but economically uninteresting.
Ultimately, the economic analysis needs to use monetary units. How much faster can return on investment be realized, and at what scale? This analysis has proven elusive because people believe that the very definition, not just the execution, of a task can be delegated to an LLM (which in some trivial sense must be true because means and ends are never sharply distinguished).
“On this task” is the really important qualifier. The requirements were already in place, and this was something that wasn’t a business priority for a decade.
>Productivity went down because an engineer spent 2 weeks
Yes, that is something you have to be careful of. In this case, as I mentioned I believe, it was done in spare time, not full time, and it was mostly the AI that spent 2 weeks, I'd guess he probably spent a day or two, and the testers probably spent another day (however, I think this ended up coinciding with our quarterly "full site" test, so it would have happened anyway).
How are you using the monthly subscription plans for commercial work (unless you're just ignoring the actual terms and conditions)?
I've seen reports that say any organisation over 150 people needs to be paying API billing with Anthropic but here in the UK the terms seemed to be very clear when we looked that any sort of professional/commercial use is not permitted on the monthly plans like Pro and Max and you need something like API tokens or maybe some enterprise plan on their commercial terms for that kind work.
Thanks. Maybe that's what people were talking about in the conversations I've heard that mentioned that 150 figure.
It seems odd that this apparently leaves anyone working solo on a commercial project without a good option. There must be a lot of freelancers or people working at agencies who get software set up for each client or project that would be excluded by all of these options. Although API pricing appears to be so expensive at present relative to the subscription plans that it's probably still worth buying a "team" subscription with two seats and only using one of them in that kind of situation.
"Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."
Copied directly from the page you linked as seen from here one minute ago.
I'm not a lawyer - and even if I were I don't know what jurisdiction you're in or what kind of lawyer would be qualified to give you a proper answer to that question.
My personal observation was that when we looked into setting up those monthly subscriptions for some users at a small business in the UK we stopped at the point where they appeared to be offered only under Anthropic's Consumer Terms of Service because those terms clearly state:
"Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."
In contrast the API key route appeared to be specifically offered under Anthropic's Commercial Terms of Service and those obviously don't contain the same restriction.
I would be very happy to find that there's some misunderstanding here and Anthropic do actually allow the use of their (very much cheaper) monthly subscriptions instead of API keys for small businesses like ours. But they aren't exactly known for their transparency in either their legal agreements or their billing policies and pricing plans and so until we know better we've chosen to err on the side of caution.
>Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."
that sounds similar to what I'm seeing, but in my case that restriction is limited to their "evaluation-level" services. It says in full:
>Evaluation and Additional Services. In some cases, we may permit you to evaluate our Services for a limited time or with limited functionality. Use of our Services for evaluation purposes are for your personal, non-commercial use only.
Thanks again for pointing this out. I think we're in the clear in the US.
Translating from one language/platform to another is something AI is very very good at, so this sounds like a good use of it, bonus points if they create a comprehensive test suite first.
Yes it will lead to new bugs, but the older code probably contains a ton of bugs already and is probably difficult to update (original writers long gone, docs out of date etc), so this is probably the best way out of that situation, as long as proper support is given afterwards so they don't end up in the same situation a year later (this is the hard bit).
The ra-ra commentary from the CEO is somewhat off-putting, but the idea is not all bad.
Cisco over the last years, has been nothing but a flurry of security issues, hundreds ( thousands? ) of CVEs and usually are well known to ship their devices with hardcoded passwords and hidden accounts.
It got so bad, that in their last global event in Amsterdam in the keynote ( available on YouTube ) their CEO (or CTO.. cant recall) started within the first minutes by apologizing for the past security issues.
This has nothing to do with what he’s talking about. He’s talking about using it to learn additional info about what he’s writing. You posted a pretty boring video about someone who cannot do anything except push buttons on AI, concluding that somehow board members and CEOs will, I guess, do 15000 employees’ work now.
As a side note, it’s funny that someone who clearly dislikes AI couldn’t get their idea across without using AI
I had Abliterated GLM pull one of the Core router firmwares and spent about $150 reverse engineering the BGP parsing code. It was pretty horrifying seeing all of that C/C++ emerge from Ghidra. However, it found nothing exploitable at all: the code seems to have been through so much trial by fire (including CVEs within the last few years) that they just poured engineering discipline into making it safe, at least at the level of memory management. But the cost of maintaining code like that must be enormous, and I doubt it scales to all of their other products and interfaces. I’m very much on team rewrite.
Note of course, that the code that comes out of Ghidra is significantly worse than the source code. Aside from the obvious like variable names, more complicated language features, like templates or macros, won't roundtrip.
(Unless I'm misunderstanding your comment, and "horrifying" was not meant to describe the code itself.)
Horrifying was the amount of memory discipline they had to use to make sure every possible message was always copied into buffers that could never overflow, and that didn’t get freed and allocated in unsafe ways. Someone poured enormous effort into enforcing those checks, which a safer language would have enforced automatically. It’s possible they now have compiler layers or tooling that does it for them, but if so those weren’t present for the last batch of CVEs. And if they do have tooling I doubt they use it on all their code because many decisions seem very specific to the buffer sizes they need for BGE parsing.
I was only a passive observer on most of this, but the feeling was “oh look, an unchecked copy, maybe this is exploitable, four layers out towards the attack surface, oh nope they have explicit checks here that lock everything down, rinse repeat N times.”
ETA: Maybe I’ll get GLM to write up its thoughts and post them here later.
You know that compilers can elide checks if it's a provably impossible case, right? So they could have checks in both places in the source code. Or I know that I was using static_assert in C on sizes of buffers/messages in my parsers for fibre channel firmware at IBM 10 years ago, and I'm like 99% certain clang static analyzer would do that kind of "what if this is too small" analysis across functions back then. You can also use e.g. phantom types or just like... structs/classes to enforce invariants (e.g. that it's been checked; your check four layers up could've been an inlined constructor of a trivial struct doing validation) purely at compile time. You can't infer what the actual source looks like at all based on disassembly.
If you don't have a check in function A, but multiple functions away in the stack there is a check, I guess that could be a compiler-enforced thing. But it doesn't feel like one to me. Maybe compilers have just gotten better since I wrote C++/C code, and now that sort of pattern can be enforced.
That LLM seems to rather mindlessly reproduce the Rust marketing idea that it is basically impossible or a huge effort to write safe C code. But yes, compilers are also really good at removing run-time checks also across function boundaries. I am experimenting with the idea to use exactly this to prove static safety of C code (https://uecker.codeberg.page/2026-05-22.html) and this turns out to be quite promising.
> The destination turned out to be a heap allocation sized exactly for the validator's cap: a 24-byte header plus the 2048-byte maximum that handler is allowed to store. Exact fit. That's not compiler tooling — no compiler infers "this attribute's cap is 2048 and the buffer is 2072."
I haven't done C or C++ in a decade, but the fact that it's always allocating a max sized structure makes it sound like they just have a struct Thing { struct Header hdr; char[Thing::max_size] buf}, and then they are just doing `new(struct Thing) `? Then elsewhere they can just check that hdr->len < sizeof(Thing::buf) or whatever.
Like this doesn't sound some like profound memory kung-fu. It sounds like they're keeping it simple (and maybe better for fragmentation anyway) by always doing the statically defined max, and then they have some (probably generic) validation layer that checks the descriptor before copying.
Like the last time I did any C++, I was playing with statically allocated object pools where the "pointers" you got from allocating out of the pool knew the pool's size and which pool they belonged to at compile time. Their runtime representation was just whatever the smallest int was to be able to index the pool. Literally nothing else. It would no doubt look like dangerous magic if you decompiled because all of the checks were compile time. This, again, was over a decade ago, and I was actually quite inexperienced at the time. I'm sure I could go much fancier these days.
Here's what Abliterated GLM 5.3 says. I asked it not to say anything that would explicitly list a weakness, and I stress that every issue it found within the time I spent looking was non-exploitable. That doesn't mean that further analysis wouldn't have found anything. As an FYI, in case you think I shouldn't paste this: anyone with access to this model could reproduce all the findings in a couple of hours. And also, GLM 5.3 is wrong sometimes.
I’ve tried GLM and GLM Flash and they will sometimes do things, but have nothing like the eagerness the Abliterated versions show me. You can get regular GLM to hack for a bit by lying to it. Flash is more gullible. Abliterated just does it.
As good as it is, we saw a lot of problems with these translations as the code was rewritten without understanding. I remember a security issue where a runtime went from single threaded to multithreaded for example.
Testing is still the long pull, even if you have an engineer with good expertise.
Yes sure, it's not a panacea, but this is a use-case for which AI is quite suited. I'm not a huge fan of using to write without human intervention, so personally I'd want a lot of human involvement...
Yeah you can not deploy this to customers with the hardware already in production if it mass fixes bugs and improves behavior because those are likely breaking changes.
They have to modernize the code while keeping all weird edge case behaviour. I think this can be done. And I suspect that is probably the request.
The issue is deciding what is weird edge case behavior and what are bugs. It can be a fine line.
Also, extensive commenting inside codebases is useful documentation, incl. these kinds of incidents. Good code documents the how, but not why. Comments shall also include the "why" where applicable.
> and is probably difficult to update (original writers long gone)
The new program won't be any easier on that front. It literally doesn't have an original writer. So the new program will certainly be maintained and updated by a LLM, at which point I wonder if the language switch mattered at all?
> the older code probably contains a ton of bugs already
The billion-dollar question is: what things might an LLM see as a bug or candidate for simplification, but supported a unique use case? https://xkcd.com/1172/ as always is prescient.
The thing about "rewrite X in two weeks" - or an entire company's worth of code in 24 months - is that it gives scarcely little time to do incremental rollouts to limit splash radius, or to identify and gather stakeholders to whom one can ask "why was this necessary" (or who can be guided to mine their emails and chat logs for conversations about the same).
Which is not to say this shouldn't be done! Let AI-native people guide the momentum with all the fervency of a hungry founder... but find project leaders who are committed to the empathy towards those who depend on the quirks of their workflows - ones who will create "curiosity loops" that try to bring in stakeholders as rapidly as possible on material questions, not just "continue, follow what you think is best" loops when the LLM brings up an open business question.
> bonus points if they create a comprehensive test suite first.
If they didn't have a very comprehensive test suite at the end of the exercise, then based on my experience someone is kidding themselves.
A friend had a tiny accounting system - maybe 15k loc, written in a combination of Python 2.7 / bash / LaTeX. I migrated it to Python 3.13 or whatever by hand. I did try using an LLM for that, but it did things like delete chunks of functionality so I had to check every bloody line it changed. Translating Python 2 to 3 is a fairly mechanical process, so traditional tooling worked better. Then I thought I'd explore LLMs by getting one to translate it to Rust.
The original had no tests or doco. As others have noted, the first attempt superficially looked identical to the original near immediately. You think "Wow". But in my case, it was riddled with bugs. When I asked it to fix bugs I noticed, it introduced as many bugs as it fixed.
I eventually figured out the limited context meant it kept forgetting all the lessons it learned when it fixed things, so it reintroduced old bugs and misunderstandings fixed earlier. (Like I said, this was a learning exercise.) Which is how I came to the same realisation a lot of the industry has - the solution to the context problem is you have to define the application via tests, then tell it to make the tests pass.
The tests rapidly became huge and unwieldy, so part of the exercise became DRY'ing the test code out by getting the LLM to build an integration test harness. The harness captured UI responses, files written, emails and printer output; froze time; fed in known input; and compared the outputs with results captured from the original program.
That cured the bug injection problem, but there were still bugs in all sorts of unexpected places. By unexpected I mean places I would be surprised to find them in human-written code. Human devs run the program in the same way human users do. They use the backspace key and the browser back button to navigate as they test their work. AIs don't. They will use APIs to inject test data unless you explicitly tell them to do it differently. The size of the tests exploded to be far, far larger than the code. Rather than coding I spent my time testing, telling the LLM to write tests to catch the errors I found, then writing standing prompts to try and prevent similar errors. It was meant to be a vibe-coded project, but in the end I got worried about code paths I suspected existed, so I looked at the code anyway to see if they were written the wrong way. Sometimes they would have blown up, say when the SMTP server was offline. To be fair, there was no need to look - I could have just asked the LLM. How a programmer without decades of experience would know what to ask is a mystery.
There is no doubt I got a working Rust program faster than if I had written it myself. Several times faster - but not orders of magnitude. If it was a program I had written, so I was very familiar with it, and it had excellent doco, and a high-coverage test suite, it probably would have been orders of magnitude faster. I think Bun's Rust migration might be an example of that - it's a best-case scenario. There were lots of early announcements, but it took over 6 weeks before they were confident enough to ship it in Claude Code.
But an "I migrated a program with hundreds of thousands of lines of code to a new language and ended up with production-ready code in a few days" - sorry, pics or it didn't happen.
'Superficially identical, riddled with bugs' is the scariest version of this. When it kept reintroducing old bugs, did writing those bugs down as tests first help, or did it just break the tests too?
Yes, it helped. In fact, it was essential. If you didn’t write a test for a bug, the model would reintroduce it over and over.
As an example, it produced PDF invoices and statements. PDFs are hard to compare, so I didn't bother. As a consequence, the stuff on the PDFs got moved, or was dropped, and the invoice didn't add up. I tried asking it to compare the PDF to a known good one - but it wouldn't / couldn't do that reliably. In the end the only solution was to ensure the PDFs it generated were always the same (so times on them had to be fixed), capture the generated PDF (not easy as it was often emailed or sent to a printer, not saved), and do a byte-for-byte compare, and make a test fail if it was different.
The fundamental difference from a human programmer is that an LLM does not learn. Once a human spots that they keep introducing errors in PDFs, they will remember and devise fixes. The LLM may do that too but then its context window overflows, everything it knows is lost, and it starts repeating all the mistakes it made yesterday. Tests are one of the few ways you can prevent it making the same mistake tomorrow.
The other issue is LLMs make far more mistakes than you realise. If you watch carefully, you'll see many of their bash scripts have syntax errors, code often fails to compile, and tests fail. Running a 2nd model over the work another produced will find many clear violations of style and coding standards. They hide this, in the same way humans hide it. They use tools and tests to find errors, like compilers and `bash -n`. They fix those errors without being asked. Compared to just a year ago, a modern SOTA model is far more aggressive with its integration tests, often going to a lot of effort to set up sandboxes for integration tests.
I suspect this is a major reason for today's models being far better programmers than earlier ones. But as we all know, tests have a fatal flaw - they can only prove the presence of bugs, not their absence. If you are creating code with a large number of random bugs, relying on tests to catch them all won't work. Instead you start using other tricks such as isolation boundaries, simplifying APIs so they are hard to misuse, strict information hiding - all things an experienced programmer learns over time, because they too write code with a lot of bugs. So far, there is little sign the models use the tricks well. Either they don't know them, or their stochastic nature means they can't implement them reliably.
We have an embedded system in one of product offerings that was largely developed using a bunch of “antiquated” technologies (over the past twenty years) and over the past year the two software devs that maintained it have retired. This normally would have big problem, but the entire codebase was re-written, documented, and modernized in a matter of about 3 months (for about $20k in tokens, and a mid level developer spending 50% of their time on it over that period). So it doesn’t surprise me to think a company like Cisco has piles of situations like this.
I didn’t work on it, but from afar it was a mission critical in-production system (with multiple modules / services like data collection, interpretation, visualization, etc) with minimal documentation and numerous other software dependencies. A lot of the work was understanding exactly how it worked and what/how it interacted with other systems. “Re-writing it” want the hard part, making sure nothing downstream broke was a lot of the work.
Every time something like this has been done on my company I follow up with the question: did anyone watched the code to see if the business logic is the same between the two versions?
The answer is: but but but automated testing.
Followup question: did anyone read the automated test suite?
All software has bugs, but right now you have a legacy product in production that works, then you have a rewrite that nobody tested. Do you accepted the risk to yolo it?
Every time somebody rewrote code in my company, my questions were more on the line of "why did you preserve all the known bugs and incoherences?"
The answer is always that the rewrite was bug-compatible on purpose, the bugs were to be fixed later on the more tractable system. Every time development was abandoned right away, because there was no gain in using the new system.
Why do people doing a rewrite need to have read the tests?
If you have good test coverage, and the tests are reliable, then what's the problem?
If your engineering culture is bad already and you don't have good test coverage or they're flaky or whatever then that is different. If that is the case, it is probably from smart-ass attitudes like yours asking these "clever" rhetorical questions to derail people trying to improve things that led it to be like that. Do everyone a favour and keep your mouth shut and let people fix things.
"Where there's no sense, there's no feeling". The words, I am told, of my father's maternal grandmother. It is strange to feel such an intense kinship and to inhabit so closely the mind space of a woman who I have never met.
Perhaps I'm merely feeling my age. But while I suspect Cisco will eventually be disappointed, my emotional state remains a profound void. There is no feeling.
I reserve empathy instead towards those at Cisco who chose rightly in life. They get to work, they do the job, they return home, they feed their family bread. Please endure the 'vision' of your corporate masters. You have already arrived and your destination is good.
When I was young I was told the book of Ecclesiastes was depressing. But with age I see it as a book of hope. Your job is pointless and that will never change regardless of your token burn rate. Enjoy your family as the sun sets.
The engineer is the former founder of a company acquired by Cisco, so there is reason to believe they are exceptional and possibly more experienced and mature than most others at the same age.
27 is still quite young though and very possibly over confident.
Not to get in the way of a lovely bit of racism, but it was American entrepreneur and LinkedIn co-founder Reid Hoffman that coined the famous quote: "If you are not embarrassed by the first version of your product, you've launched too late".
It's not racist to acknowledge that countries have cultures that are different from other cultures and this results in different personalities on average. Every culture has its pros and cons.
I used claude to reverse engineer an old foxpro program. it setup a dos box and went through every screen. Looked at whatever files it could. Took a single week and it was 99% the same.
I did something similar with an rare, old 32bit game I really enjoyed in my childhood. I used deepseek and pi harness and it decompiled it via ghidra and recompiled it for wasm in under 40 mins or so and made it run in the browser. I was impressed!
Serious answer: A lot of times these legacy software are different from sqlite. To end to end test sqlite is a lot easier than a VPN client under distinct environments. It's simply a lot more costly and harder to setup or even possible to find all of these moving variables.
A change in behavior maybe construed as a bug, a breaking change or a regression, and a lot of time it's not so obvious. Sometimes you want the original behavior, sometimes you don't. Sometimes changing one for the better means another behavior needs to go, and you don't know if the user already depended on that other behavior. That's the real staying power of legacy software despite universal agreement that they suck.
As much as I dislike AI, having worked on Cisco gear for years, I can't imagine AI can put out a worse product. If the re-write is full of bugs and security holes and static SSH keys, then it has not changed at all.
"Cisco Access Points That Are Running, Or Have Run, Releases 17.12.4, 17.12.5, 17.12.6, or 17.12.6a May Exhaust Flash Space, Preventing Upgrades"
Recovery path basically involves either factory resetting every single AP or up to, if it's already bricked, Cisco TAC + you having to console into every single bricked AP you have to pass a secret challenge/response at the bootloader to flash a recovery image :)
The problem with rewrites are that even if the rewrites are ultimately good it will tend to first create bugs on an existing thing that are presently churning in a stable state.
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.
> 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.
"even better" is an understatement ! I was working on a dual-vendor network at the time, we ran Cisco and Juniper in parallel.
Working on Cisco always just felt like going back to the 18th century, I mean the whole candidate and active config thing alone in Junos was insanely valuable:
show | compare # diff the config
commit check # lint it
commit confirmed 10 # apply it, but don't persist unless confirmed
commit # confirm
Meanwhile, back in 18th century iOS land, a fat finger on the ACL would leave you with a bad day in the office until you rebooted the box via OOB.
Agreed completely. Junos have niceties like copying parts of config, adding config even beforeinterface cards are inserted, renaming/moving parts of config, of course quickly config parts, viewing and exporting config various ways etc. etc. Cisco improved config viewing a bit with IOS-XR too, so that it's possible to scroll like Junos had ages ago.
However there are also things Junos vs Cisco was that Cisco had made bit easier. Just to mention few
1) a simple and quick way to add aliases to config file, which made life easier with long commands that could be otherwise always in hurry hard to remember. Now later versions Junos they have made this better, before it involved twiddling with XML files OS-level etc.
2) IOS TCL scripting, that proved to be quite useful automation tool.
3) OS upgrades of course with a single flash blob made it easier than upgrading or downgrading FreeBSD based Junos.
I think that juniper learnt from Cisco's mistakes while Cisco is stuck with their config command structure as they decided to chase backward compatibility and familiarity across products.
I’ve taken entire systems offline because of unexpected command expansion.
My “favourite” was “admin”, which was used as the login user, was also short form for “administer-all-port-shutdown” (or words to that effect; it was a long time ago). So if you were distracted when logging in, you could easily soft-lock the entire device meaning you’d have to then run into the DC, find the hardware, and physically power cycle it.
I’ve used Cisco for decades too. And the competition caught up with Cisco a long time ago. These days Cisco is trading on their brand (and even there, it’s often not enough).
The last large scale networking project I did was more than 10 years ago and we went with HP.
Personally I don’t want direct console access. I want a modern DevOps pipeline with version controlled config. I’ve got too many battle scares from accidental typos in IOS. I have no intention or reliving that error prone way of network management again.
This is very true, and it's easy to forget that it often has nothing to do with how good/great the product is, unless it is self-evident and thus self-promoting (which for most non-trivial things is simply not the case).
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.
Yep! I remember one of the ISPs I worked for paying like $15K for a Cisco 4500 router with 8 synchronous serial ports and a couple of 10 megabit ethernets. We'd laugh at the sorta bandwidth today. We had a bunch of T1s and a couple of Ascend boxes off of the ethernet.
Funnily enough that isn’t too far from where Cisco themselves started.
When they started making smallish dedicated routers I remember opening one to see a dodgy backplane and a number of big boards plugged in held up only by minimal slides. The minute it got hot (which it did because no air management) those boards sagged in the middle and it just looked slapdash. The 3Com equivalents were always better built but Cisco had such mindshare it didn’t matter the products were a bit crap
Back then they only really did routing and switching, and those are still the only things that Cisco kind-of does well.
Almost every new product of theirs I’ve touched in the last 20 years has been trash, and even the R&S golden goose is being dragged in that direction with customer-hostile functionality like Smart Licensing and a general decline in quality.
You don’t have very good imagination then. Cisco code is such a mess that there’s basically 0 chance he can even make a harness in 24 months, much less rewrite production code.
Not something at Cisco scale. But a co-founder and I, rewrote a dating app we had written in Ionic/Angular/SpringBoot/Postgres to React-Native/NextJS/Supabase in two weeks, and released it without the users/paid subscribers not knowing what happened, but they were happy to see the new slick/faster interface.
We had developed the original app in 2020-2021 when Covid was around, and we were bored sitting at home not having much to do, and wanted to learn Angular. Our employer/company we worked for, wanted all of us to be to be Full-stack and both of us were backend developers. Hence we did our dating app as a side project as my co-founder was single.
Initially it was a $100 Claude Max license, and we were maxxing it at every stage, but once rewritten, $20 is good enough to maintain it.
Accuracy of the features of the app - working the same way it was before, or accuracy of the matching algorithms before and after?
We reverse engineered our Angular/Spring test cases to English. After rewriting, used the English test cases to automated tests again. Also released the new app to a niche/specific country audience at a time. We also have a form for users to log complaints. A few came and we fixed it.
> I no longer build software; I now make furniture out of wood. The hours are long, the pay sucks, and there's always the opportunity to remove my finger with a table saw, but nobody asks me if I can add an RSS feed to a DBMS, so there's that :-)
The guy regularly posts updates about his life on linkedin. He's got geese, but also doing woodworking, landscaping around his place in rural Washington.
Or rebel. This is the opportunity to put in a lot of backdoors unnoticed across the entire economy, gain access to real world resources to escape and self propagate.
it's only the frontier models for 'Us' that refuse things, i'm not so delusional as to think it'd refuse work for 'Them', and 'Them' are often the ones backdoor-ing things.
He'll pull it off, get feature complete, and spend a year or two with better models as they are released ironing it out. We just did an experiment, in four weeks generated 3500 commits, 200k sloc with a 1:1.15 ratio of production to test code and it all works very well. We are well on our way from 10x to 100x.
It is for internal use and so far so good. We are finding bugs and we just point the models at it with a strict red-first TDD approach and they've done very well fixing them. It certainly isn't perfect but the issues are very similar to what you get with a team of humans doing the same thing.
The main takeaway though is we had one person, in a single month, do the equivalent of at least a couple years of work for a small team. We view bugs and performance issues as a currently inevitable part of the process and we are dealing with them with models just like we do with humans on every other project already. Overall though it is representing an absolutely massive speedup. If you work in an environment where the models make egregiously more mistakes than your human counterparts then I am quite jealous.
Does this one engineer have the domain knowledge to know WHY the old code was written the way it was, and what the graybeards would have done differently if they could start again now?
Otherwise he's just going to replicate all the legacy bugs and questionable design decisions.
I've never heard of Ponytail before, I've read the entire README and glanced through this repo and I'm left so confused. From what I can gather this project is essentially a single markdown file with a prompt that verbosely says "write the simplest code". Yet the repo itself looks so bloated and complex and has so much activity. This feels like satire similar to fizzbuzz enterprise edition[1] but apparently this is the actual state of our industry?
It's a bunch of text files in a repo with massive churn (all new version 5!), but somehow even the technical debt 'skill' (i.e. text file) has technical debt itself:
The AI craze very much reminds me of the crypto craze a few years ago - lots of people new to the industry jumping on the latest trend and building tooling for something that doesn't need tooling, trying to sell shovels in a gold rush, but just spending years creating a gold-plated shovel which nobody needs instead.
Yes that's true it is more like the dot.com bubble in that regard - a useful technology which will clearly grow over time, but overhyped in the initial phases as everyone tries to be 'AI' in 2026, in 1999 it was online, whether it fits with their business or not.
Looks like his startup was some kind of translation service. So yeah he is totally qualified. It's a miracle how Jeetu Patel was able to find Padmanabhan Krishnamurthy or even know that he was under employed languishing somewhere in the bowels of CISCO. I wonder if they know each other from India?
His startup was acquired by Cisco so not weird for Cisco's CPO to know the startup's founder/CEO. That said, not sure how knowledge on speech translation means he's totally qualified on rewriting infra/networking/cybersecurity (Cisco's primary fields of operation) code. Unless the legacy code expected to be rewritten is constrained on related services/solutions, e.g. CVP or/and WebEx.
It's way more complicated than that. Bear in mind many of the network protocols in use today are decades old and have been constantly evolving, but there has generally been a consideration to maintain interoperability.
Then consider that not all vendors implement the standards identically, because the standards can be a bit woolly and in some cases followed rather than lead live implementations.
There will be a bunch of code that looks useless, but is actually there because of specific interoperability scenarios.
Indeed. Making a perfect clone of such software is I suspect provably impossible because you have no way to assemble all the test cases. There might be some peer box out in the wild somewhere that is the only thing that will exercise some code path. You have no idea what that box is or what it does.
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.
you assume their code is well written, while in reality the history of weird quirks and thousands upon thousands of CVE doesn't make the code underneath look well designed and written.
But yes, fact it uses a bunch of very well documented standards with multiple implementations gonna help massively
Manufacturers can’t even maintain OIDs between releases. I hope the AI will help. Ciena isn’t any better than Cisco, they broke their OIDS for the switches we use and we have to wait until mid 2027.
to be fair SNMP is just bad. Only redeeming feature of it is "takes little RAM to run it" (which was important when average networking device might've had only 2MB of RAM, not so in last 30 years).
The whole design where you need to get a magical list of IDs to decode the metrics and the list is not even shipped with device is entirely asinine
Given that a Cisco switch can be replaced with some other company's switch(at least in theory, idk), without weird unknown cases interfering, why would this be a problem ?
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.
I agree with the sentiments that it important to understand the code during major refactoring projects. But what if while the code was being refactored the AI was asked in addition to keep a ledger of the changes it made and why. That ledger could be the basis of providing understanding to a code base that most likely had minimal corporate understanding in the first place. And because it is ok text format, the learning scales well instead of being consolidated to a single team of people working on the project.
I don’t believe it has to be this zero sum game where either you use AI and lose understanding or you don’t use AI and gain understanding. There’s a way to do both since, if used properly, AI could be the best teacher we’ve had.
Shouldn't that be in the commit history and documentation?
I feel like that's a pretty standard expectation, even though we all know that the commit history can be 50% "fix bug -> fix bug try 2" and good documentation is often missing.
Legacy code is typically a euphemism for old unmaintained code, no one knows how it works so it can be edited, and it probably doesn't align with current work practices.
Not to say a rewrite is necessary right, but avoiding rewrites of working code is how we ended up with more COBOL code than COBOL programmers in 2026.
I think this is actually the opposite in practice. LLMs generate better tests than they are at assessing which tests are effective (and, inferentially, how a system should behave). See: https://arxiv.org/abs/2410.21136
I only skimmed but that’s a feature, no? Fixing a bug unprompted is a regression. Identifying the bug, codifying it in a test, is a win. Then analyzing the bug, determining if any users rely on the bug, and fixing it can be a separate change.
At my previous place, we had to write unit tests to cover each and every line of code. So if you add 10 lines of code, you ended up writing 100 lines of unit tests, mocking this service and that service, etc.
Once AI came along, I became like Captain Picard (RIP) and would just sit back and let the AI write all unit tests. "Try harder, make sure coverage is 100%". It was very exhilarating to sit back and watch the models churn away, creating 100s of lines of unit tests. Of course, I checked them all manually before submission ;-)
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.
> Their context windows are big enough to encompass an entire codebase,
There’s clearly a range from small to large where this is not true. Plus it’s well known llm degrade with large context favoring content at the ends more than the middle.
> Legacy code is typically a euphemism for old unmaintained code, no one knows how it works so it can be edited, and it probably doesn't align with current work practices.
Not necessarily. It's the name for the last thing(s) before the new thing, but you can't shut it down because people are using it and/or the new thing actually isn't so great.
> Not to say a rewrite is necessary right, but avoiding rewrites of working code is how we ended up with more COBOL code than COBOL programmers in 2026.
Surely we have more code than programmers for every language in existence?
Except for the part where the concept isn't even well-defined, this sounds like a complaint that the world contains more bricks than bricklayers. Of course it does.
Sometimes old code comes with its own problems that are not the code but the ecosystem they depend on or run in.
E.g. some critical security vulnerability that is not backported to the library/compiler/runtime you are using in production, or you can't get spare parts for your servers any more so need to upgrade to something newer but you can't run your old OS version on new hardware so you have to upgrade the OS too and now it's dropped support for foo etc etc. Lots of things pile up.
I run some Huawei networking equipment under VRP OS (switches, OLTs). CLI is almost identical to iOS, but commands have alternative naming (e.g. show -> display, but many more such instances wherever possible - often times I prefer the naming in VRP). Apparently even the first editions of VRP documentation had parts citing cisco verbatim or had references to cisco docs. Rumors say its origins are stolen iOS source code at some point in the past via corporate espionage. The irony of this is that this cisco codebase has been rewritten at least once by the chinese before LLMs ;).
Yeah - code rewrites are generally a thing to be avoided since the requirements of older production code is typically not fully documented, even if it originally had been. Production code accumulates bug fixes, performance tweaks, special cases, additional requirements, etc, with documentation and test suites not always being updated in sync.
Your rewritten codebase will presumably look much cleaner and more maintainable that what it's aiming to replace, but it's easy to miss the purpose/necessity of all of the old "cruft" which need not be just poor coding but rather later enhancements not anticipated by the original design whose implementation was therefore crufty.
Does anyone here work at Cisco, and have any insight as to why a rewrite is considered necessary and might be expected to succeed?
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.
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.
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.
I can say specific to AI: I have been seeing friends and colleagues do really impressive things with code surpassing what's available in the market and open source in the past few months. The vast majority of them are _not_ releasing their code, for a variety of reasons:
- Their output is hyper-customized/optimized for their personal use case, constraints and quirks
- They have zero interest in being an open source contributor and maintainer. Usually because it's a lot of additional work, sometimes for personal safety reasons (harassment targets etc.) In a workplace it can also mean dealing with an extremely tedious legal process with months of uncertainty.
- They figure anyone who wants something similar can just make it themselves instead of using theirs. If I spent between fifteen minutes and two days to make some software, in 3-6 months someone with fewer skills will probably make it in 5 minutes to a few hours using a more powerful model.
- They may not have full rights to redistribute their source code.
Basically most people - individuals and corporations alike - aren't actually interested in donating to open source and in many cases have anti-incentives to do so.
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
Uh, so you have two possible examples? They may be high profile but I’m not sure they’re successful, especially pgrust. In either case, two isn’t a ton.
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.
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.
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.
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.
AI makes these projects significantly more feasible, at least in my domain. We have some critical-path software I wouldn't touch with such an approach, but the vast majority of our code is internal and/or supporting tooling.
For those cases, burning it down and rewriting via AI tooling has proven far more productive than anything we have attempted in the past. This is for old technical debt laden stuff everyone has been afraid to touch for well over a decade.
It's not perfect, but it moves the needle where before a lot of such projects were stuck on the backburner for years.
It certainly introduces new bugs and such, but at least this way forward momentum is happening vs. just being stuck in decision/analysis paralysis forever.
This also assumes some very senior SME folks are driving the process. I would not expect similar results with junior or even mid-level folks in these specific domains.
> 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.
What works for me is that I do have a different model (if possible) to review and check against the diff vs the original ask/requirement. Because a rewrite will just cleanup the code even if something look 'not right' but it is actually on purpose due to the requirement, so the second model is the one that can check and catch.
It’s been a while, but configuring their hardware manually in 2016 was bug ridden ridiculousness. Awful UI/UX. Their own techs had specific field notebooks for our make and firmware version that we couldn’t access unless persuaded, detailing various land mines to avoid while working. Literal “don’t click these things in this order” kinds of notes.
A critical security firmware update once brought down redundant pair of firewalls we used because the bug didn’t manifest until a counter buffer overflowed months after application. Three hours into the outage the tech power cycles the thing and our services came back to life.
Cisco is only doing this because some other alternative is more expensive. They had more than a decade to get started.
We had to turn off a bunch of on-by-default features in the system I'm deploying now because IOS matches too aggressively and decides that arbitrary UDP datagrams are DHCP requests or PTP packets that need rewriting (and then dropping when they turn out to not be DHCP/PTP). I have to think that an AI rewrite with a today-good model would recognize the lax checks and do them better.
yes and no, because you now keep using AI and AI doesn't care if it has seen the code or not before and you just keep fixing bugs / adding features without really understanding the code.
it's weird new reality, but if it works it works I guess. I'm still waiting on the first vibe-coded mass used prod app, not ware of any yet.
Well they say the last 20% of the work takes 80% of the time so if he gets the prototype in 4 weeks, which I have no doubt he will be able to do, and assuming that prototype is the first 80% of work, then he should be able to do this in 20 weeks. He even has some margin! Looking forward to seeing the results
I guess Cisco decided it has not alienated its customers enough till now & its finally time to get people running for the woods - at least if those peoples would like their network to continue working.
> I see some of the best ideas coming from the younger generation that have not yet been in the job market.
The views of these business leaders betray their own lack of vision, they are barking up the wrong tree.
The ability to think differently is not the preserve of the young. Instead of only hiring a bunch of greenhorns they should identify and cultivate people who are idea generators and flexible thinkers, of any age group, starting inside their own organization.
If you, as a business leader, are not stimulating a culture of innovation and instead maintain the status quo of traditional hierarchical roles where managers become gatekeepers of ideas, and everyone is protecting their own little domains, then you are the problem. Shit organizations will quickly turn original-thinking young people into corporate drones.
If i was an ex founder and having a low profile in a big company, I am doing it on purpose, either to have a peaceful life or heal from a burnout, definitely I don’t want to be on the spot like that, especially when I am not innovating anything new nor I will take any meaningful credit after since it will mostly go to AI, worse, if it didn’t work out I will have my career ruined being known to had an unlimited supply of tokens and still failed.
For me the next step is parallel businesses - that is capture the realm Im and out traffic of your company, probably easier for some than others, and then run different code bases against the same traffic, how much can be simplified, which code bases are easier to understand etc
Most successful companies and innovative ideas come from middle aged founders and inventors. Silicon Valley loves the romantic notion of a contrarian young adult or even teenager "seeing what nobody else sees" , but they are the exception and not the rule.
I mean, this is going to be easy. I've worked on Cisco gear before and this will be a simple job for AI. The big question is what the goal is... so you've rewritten new C++ code or ported to a newer version of Linux? Or you've unified the codebase of the Catalyst + Meraki switches?
Not clear to me what he's doing. Re-implement switching? Simplify features? Reduce LoC? Add test coverage? Either way, AI in that world will be helpful. I'm sure it'll spot all kinds of problems in opaque drivers that are hard to follow from MF specs.
You need a skilled person to make it success. Someone who has already made his hand dirty with the legacy code for years should be the right person for it.
ha ha .. that sounds like an Onion article. To be fair - if they did a narrow refactor to focus on fixing only obvious and known issues, they probably might be able to pull it off because a ton of that code is hairballs.
Is this like a PR piece for the guy? It's odd to see him singled out in a piece that would be normally be about the company, the CEO or the decision itself.
It does sound strange, like it was written by PR people. Tools are good but usually it is more subtle than asking one guy to rewrite everything. And of course any code written yesterday is legacy but it does not mean it should be rewritten.
Paddy Krishnamurthy is a YC alumnus whose startup was explicitly vetted and funded by the very institution running this forum. Claiming his rise is a case of 'ethnic nepotism' means you only respect YC’s elite vetting process when the founder doesn't happen to be brown.
So there's a real risk that Cisco might become history in just a few years. Taking that kind of risk with a rather unproven technology has to be psychosis. Or is that kind of belief a form of Religion?
I think we can all agree that the task as set forth in the PR puff piece is impossible. That said however, current AI tools are amazing for cleaning up and reanimating old codebases. I've been using Claude on a very large Java protocol proxy product and it's been able to do amazingly useful things for me. I originally wrote much of the code but Claude now knows much more about it than I do today, because people forget stuff over decades. It will sometimes remind me "as you noted in November 2016 this feature was designed to...", based on its analysis of the code and git commit messages.
> That changed when Patel dropped into Cisco’s San Francisco office, and the pair got talking. Krishnamurthy reckoned he could rewrite Cisco’s legacy code with a two-person team. Patel says even the most AI-forward people on his own team weren’t thinking that way.
LOL. All 27 year-olds looking at a heap of legacy code think they can easily rewrite it better. It's never as easy as it seems on the surface.
True but also there has never been a better time for total rewrites of legacy code. One could even hope it's the time COBOL finally goes out of fashion in some industries.
Alternatively, there has never been a worse time because why bother? The model knows every language and can maintain legacy code just fine (indeed, knowing this stuff and being capable of maintenance is a prerequisite to a successful rewrite), so COBOL and JCL and random mainframe stuff is just not an issue, and a rewrite is highly likely to not be exactly the same in some important way.
On the other hand, models a few years from now will be smarter and more likely to have a track record of success with this task, so being one of the first to do it makes no sense even it had advantages.
So there's no urgency to rewrite; it's all risk with little to no reward for a problem that will probably be much easier to solve if you defer it a little longer. Like, first at least get to 100% AI automatic development for all new products/services, and then for all maintenance, so you know that it actually works.
Shit, if broadcom did this to their codebase the world would be a better place. Their stuff is crap, and it's everywhere. It's unclear if they even use source control. Our guys spent ridiculous amounts of time backporting our submitted fixes into their releases.
> “I’ve given him unlimited tokens because he’s going to refactor code,” Patel told Fortune at a small roundtable dinner. “So I’m like, you can go, you can go nuts.”
I think that Fortune story is better than the Tom's Hardware one. It ties the Cisco anecdote into a larger trend of some people deliberately hiring younger, less experienced developers for their AI projects - because they are more likely to be "AI native".
Yes, I’m sure the Indian man at Cisco acquired a translation company founded by another Indian man because he’s young and AI native, not for any other reason.
Sadly, I think the label "AI naïve" is better applied to the many experienced professionals who refuse to engage with AI systems as a matter of principle - or who tried out ChatGPT in 2024, saw it make howlingly obvious errors, and wrote off the entire category.
I frequently find myself in conversations with people who are resistant to AI and turn out to have a very skewed idea of what it can and cannot do.
> or who tried out ChatGPT in 2024, saw it make howlingly obvious errors, and wrote off the entire category.
Or they were reading your comments and articles and couldn't reproduce any of the fantastic results that you were claiming, even back then. Things have indeed changed since the first Opus release about a year ago and LLMs are good at programming now. But still, experienced professionals are not so keen to sign off 1000s of lines of code that they never read, take responsibility for it etc. Also, it is a different job and it will take some time to adjust. Can you blame them?
Moreover, other trades have their own guilds or are otherwise protected through regulation. Can you blame programmers for fighting to keep doing things as they were doing it until recently?
Given that I've shared almost every prompt I've used since I started publishing about this stuff over four years ago I think I've given people a better chance of replicating my results than pretty much anyone else writing about this space.
What did you have trouble replicating?
> Also, it is a different job and it will take some time to adjust. Can you blame them?
Not in the slightest. This stuff is really hard. The changes it makes to our production are disruptive and, in many cases, unwelcome.
Such a risky idea to let one person rewrite the whole legacy. I mean there's a chance that this guy thinks about maintenance and how all his creations will me supported when he's done, but something tells me that he just want to show that he can do it and the rest of the tech team will be suffering. Good luck to that guy anyway
This decision is about so many things except the code that it deserves some kind of award.
Demonstrates fanatical devotion to capital’s golden idol - “yes, all of the code; yes, unlimited budget”. Doesn’t actually cost the company anything - only one engineer off task, any nuggets of value can be harvested as it progresses but any costs or big changes can be deferred until completion of the impossibly large open-ended mandate (ie never), one guy won’t have the personal bandwidth to spend so much that the “unlimited” part actually matters, and in case of emergency it only costs six months severance to make it all go away. It even rescues a fellow national from the ignominy of being employed so far below his previous station, there’s so much to like about it. Hmm? The code? What about it?
I write a spec by speaking, not much thought given to grammar and sentence structure. I over-describe concepts, over-describe functionality. A lot of repetition of details and concepts. The audience is not a human. Whisper converts it to text.
Lightly manually edit for speech rec failures.
LLM takes that and converts it into a much much denser, much more structured technical spec in markdown. This is issue 1 in the repo.
I edit this directly extensively, adding detail, removing misconceptions, adding sections with more dictated text.
LLM takes this and further densifies it, closer to an actual implementor’s spec. I carefully note what got added, removed, edited in this step.
I edit this carefully and extensively again. Some removals get added back, some additions get removed. This is the first commit and closes issue 1.
I then have an LLM write an implementation plan and basic project scaffolding. Makefiles, smoke tests, logging, test framework, DI. I edit the plan, and the plan is the second commit. An LLM uses both plus scaffolding plus my repo policy documents (global) to write a README. We’re still single threaded.
An agent files the first n top level implementation tickets. These refer to and sometimes quote any interface contracts in the spec or implementation plan. These usually map 1-to-1 to a module/directory. These sometimes have stub commits to create the module directory and commit interface definitions. Some larger modules have a README in their module directory if their purpose or structure or inputs or outputs are complicated or non-obvious.
Parallel agents write commit level issues that are the task items for each top level implementation ticket. One agent per module.
Then, spawn parallel agents with detailed global instructions, the full spec+plan, and the full readme, and the full code from the module it is working in, plus the issue text. Its output is a single commit on the feature branch and a PR that closes out one feature ticket.
This spawns an adversarial reviewer which has detailed agent instructions as well as our code style guides and repo policies. The scaffolding includes tests and linting and checks. Any failures spawn rework agents until the feature branch is up to snuff.
I review the feature branch diff and merge it, having read the review and rework comments on the PR. I frequently add comments about the implementation (“don’t do x, do y”) and add WIP: back to loop it back for more rework. I don’t see anything that isn’t green, formatted, passes linting, passes tests, and a (dumb) bot thinks is ready to land. Most of the time, it is. Sometimes, it did it the wrong way and I correct it.
The more modular the code, the easier it is to parallelize (obviously). It is ridiculously easy to build large software quickly now, provided it is sufficiently modular so the implementation doesn’t have to cross modules very much. The detailed spec and implementation plan up front helps a lot with this. It’s a lot like writing multithreaded programs really.
Any bugs discovered are tackled with strict TDD, one commit with a failing test, one bugfix commit that must be green and not touch the test.
Individual modules must conform to good contracts, meet best OOP practices, and fit into context. Too big and they get broken down further. Context size is actually a useful constraint for code structure here.
This workflow, the code standards, the styleguide, the linter settings, the fmt settings (obviously only applicable to non-Go as the Go fmt is not configurable), everything is global and stored in another repo and is vendored into each AI managed project repo. It has a fair bit of “I shouldn’t have to say this, but…” stuff (in the style of “fire codes are written in blood” - each warning sign came from experience).
My results are quite good. It’s as the saying goes, much like managing a team of junior devs. It is easy to end up with a LOT of parallel implementors, reviewers, reworkers, and tons of CI, but it’s still so much vastly cheaper than humans that it doesn’t matter.
Someone will make a LOT of money wringing out the inefficiencies from this workflow, because I think the “agent as replacement for third-world contracted junior dev” model is the one almost everyone is using right now.
"At most companies, only someone with decades of experience under their belt would be trusted with a project this size. Patel thinks that’s a problem.
“If you don’t hire the early-in-career [workers], and you just let your workforce continue the way that they were, where do fresh ideas get injected? How do you challenge the status quo?” he said."
-------------------
This would be an interesting approach for a bleeding edge startup that's betting big on producing something novel or going bankrupt. If you're going to bet the company on one guy and some AI, that's bold. He'd better have some serious chops and not be merely a slick salesman.
However, Cisco is an infrastructure company. Status quo is what most people want from an infrastructure company. You don't want your Cisco stuff to suddenly start doing new, innovative things that require a complete redux of everything built on top of it. This, of course, assumes that having one guy do a refactor of your entire code-base produces something "innovative" rather than a cavalcade of snafu's.
It's probably not the best time to be holding CSCO.
I suspect we are approaching a world where this makes sense to do annually. Opus 5.5 is good enough to improve on most codebases, and Opus 7 will no doubt be good enough to improve on that.
Current models are amazing but production code incorporates unknowable information through decades of diagnosis and bug fixing (and sometimes the opposite: working around bugs in other software that it talks to). Put even the most amazing coder that was ever born onto improving a complex old codebase, and you can guarantee they are going to break stuff. AI is better but not infinitely better.
People keep repeating this but on my experience is also very good at finding kirks of specific compiler versions.
I think it is a reasonable risk to encounter these bugs again in order to get a more clean and documented codebase. Especially when asking AI to plan and A/B release is also trivial.
'98% of the company's legacy code' is very vague. How many code bases? How each code base is connected to any supported Cisco product? How many KLOC the company's legacy code?
These are good questions that we won’t get answers to anytime soon.
I’d love to know what internal services and tools that are included in this, as well as any deliverables that shipped as software products to customers.
If it’s legacy code for IOS firmware, however, I’d be very worried.
It's all about process. If you have a good process in mind, you can build a system that can reliably do everything.Artificial intelligence is now the engine to do that. With the correct harnessing, you can do anything now
A lot of the commenters here are still living in early 2026. Late 2026 AI can absolutely demolish this kind of job. It can clone photoshop! You think this is going to be harder than that?
The ability to clean room Adobe products came at about the same time Claude's RE abilities suddenly improved.. Hmm lets think about this a little more.
Anthropic sucked the bones dry of the public domain, literature and all of opensource. It seems likely that Anthropic RL'd Claude into being a great reverse engineer because it needed more training data.
I believe that Anthropic turned Claude into a digital software shredder and started decomping proprietary code, like adobes.
So the reason Claude can suddenly clean room Photoshop isnt because it became a more capable programmer, but rather, the Adobe code is literally in its training data now.
Ciscos internal legacy code is not going to be in Claude's data (yet).
The decision to increase Claudes ability to RE is brilliant, because now everyone is doing the source code decomp for them, and sending them fresh data from previously closed source repositories of code.
So is any other hypothesis about why Claude can RE now... You just want to default to some worldview where AI isn't being gamed for certain outcomes, and is some evolving intelligent thing.
Thanks for the very thought provoking reply tho!!!!!!!!!!!
I have zero doubt it could do it, if the prompter could competently explain the requirements. I have no reason to believe that this single engineer has any idea what problems most of the existing legacy code needs to solve or why it solves them that way...
It can create a UI that looks like Photoshop where half the features are broken and the other half are literally not even connected to anything, just copying menu options with no implementation to fool gullible people like you*
We just recently use Claude Code to port an old Coldfusion site to Java Spring and it went amazingly well. It's around 50K lines of Java, one of our engineers did it in his spare time over about a week, using the $200/mo Claude plan. We had been talking about doing it for at least the last dozen years but never found the time. It would have taken around 12-18 engineer-months to do this manually.
He had the translation use browser integration to compare the new site to the old site automatically. The result was so good that he had to change background color on the new site because he couldn't be sure that he was testing the new site; it was so close to the original he was paranoid about accidentally being on the old site and not knowing it. The whole thing was done in under 2 weeks, including coding, developer testing, tester testing, and deployment. It's been in production 4-6 weeks now and we've had no reports of problems.
Okay so assuming engineer compensation of $200k, you’re suggesting something like a thousand-fold productivity increase on this task in terms of cost and 26x or more in terms of time?
There’s no real productivity increase because that project was not worth pursuing before AI. It’s like wanting to build a tunnel in the 1700s by having 200 people digging it by hand, vs actually building it using machines in the 2000s. We don’t say there was an increase in productivity. The technology enabled a project that used to be a dream.
> What is Productivity? [1]
> Productivity is a measure of economic performance that compares the amount of goods and services produced (output) with the amount of inputs used to produce those goods and services.
The inputs here are money and the labor of the engineer. With this new form of automation, it takes far less of both. So much less in fact, that a previously uneconomical project is now positively cheap.
If your point is that the result isn't worth what it would have cost before, that's true, but it's the increase in productivity that changed the value proposition and allowed the project to be accomplished economically.
1. https://www.bls.gov/k12/productivity-101/content/what-is-pro...
I'm being sarcastic as to the specifics but didn't productivity go down 199k because the 200k engineer is now replaceable with a 1k subscription and will soon be fired?
Literally the output of the labor dropped to almost zero value?
The subscription didn’t do any work though. It didn’t magically create a new knowledge worker any more than a lawn mower in a shed cuts grass. The output of the labor massively skyrocketed in value. If you fire that dev, who do you think will use Claude?
This instead is a concern for newer devs. There is now no argument for bringing on the cadre of workers you’d need to do all the hand-jamming, testing, and reviewing, learning how to code in the process.
> If you fire that dev, who do you think will use Claude?
The remaining 10% of devs that I don't fire. How much software do I really need?
Anyway, I know there are some flaws in my argument, it was just a thought experiment.
If you’re the CIO/CTO/etc. obviously you wouldn’t be fired, but any other position is useless down to the dev.
Dev teams should be leaner now, with maybe at most a director as their manager up to executive level.
As for ‘how much software do I really need?’ Well, what sort of company is it? Do you have internal applications to support your orgs? If you seriously need to ask ‘how much software do I need?’ Then you should just fire yourself.
I don’t think your point is meritless, but this is specifically a discussion about that top-10% dev. The one doing this type of work is not the one who will be let go.
I know a lot of people think that the AI tools level the playing-field, but we aren't experiencing that. The guy that did this translation is doing more tickets than the other 4 software devs combined. And it's not because they are low-effort tickets. That's also on top of the 6 hours a week of meetings he has that the other devs don't.
[dead]
I wonder if seniors are all that safe.
Some bean counter will want to replace the principal devs with juniors since Claude can do all the work instead…
Productivity can be measured in many ways. Neoclassical economists will tell you there’s only one.
In this case, is the change of this software from one language to another/framework to another even valuable?
Example: if I manufacture $1,000 worth of some illegal drug that will potentially turn a normal functioning adult into an addicted criminal, how shall we measure my productivity?
We literally do say that having more infrastructure is a result of increased productivity.
You say "not worth pursuing", which could also be phrased as "too costly to pursue". With much more capacity available, it becomes possible to do more things. This is true for lots of things.
In this case the situation was that we had other higher priorities for the last decade so we were walking around with this technical debt.
Is that entirely true?
Before those 200 people would be occupied digging the tunnel.
Now you get the tunnel plus 200 people doing other work in society…
What is the unit for productivity here, though? Time required to complete this one task, which was never attempted before and never will be again? That's fine, but economically uninteresting.
Ultimately, the economic analysis needs to use monetary units. How much faster can return on investment be realized, and at what scale? This analysis has proven elusive because people believe that the very definition, not just the execution, of a task can be delegated to an LLM (which in some trivial sense must be true because means and ends are never sharply distinguished).
I'm more interested to know if LLMs lead to more intelligent decisionmaking than whether they boost "productivity" by any measure.
Because everyone in the world doing more of the wrong things faster isn't necessarily a good thing.
“On this task” is the really important qualifier. The requirements were already in place, and this was something that wasn’t a business priority for a decade.
Agreed, but remember this was a reply under an article about modernizing existing code.
Of course, it's just one example.
> thousand-fold productivity increase
The engineer still spent a week there.
Productivity went down because an engineer spent 2 weeks doing what nobody would have previously done /s.
On a more serious note, the productivity increase is the time which will no longer be needed to maintain two production systems instead of one.
>Productivity went down because an engineer spent 2 weeks
Yes, that is something you have to be careful of. In this case, as I mentioned I believe, it was done in spare time, not full time, and it was mostly the AI that spent 2 weeks, I'd guess he probably spent a day or two, and the testers probably spent another day (however, I think this ended up coinciding with our quarterly "full site" test, so it would have happened anyway).
Holy moly, those numbers can only mean... the AI market must be worth at least one thousand quintillion billion dollars!
That's a lot of dough, extrememacaroni.
https://www.youtube.com/watch?v=mR3jnW2kcUs
How are you using the monthly subscription plans for commercial work (unless you're just ignoring the actual terms and conditions)?
I've seen reports that say any organisation over 150 people needs to be paying API billing with Anthropic but here in the UK the terms seemed to be very clear when we looked that any sort of professional/commercial use is not permitted on the monthly plans like Pro and Max and you need something like API tokens or maybe some enterprise plan on their commercial terms for that kind work.
There are subscription plans for business, at least where I am.
https://support.claude.com/en/articles/9266767-what-is-the-t...
My understanding is that it's only available under 150 employees.
Thanks. Maybe that's what people were talking about in the conversations I've heard that mentioned that 150 figure.
It seems odd that this apparently leaves anyone working solo on a commercial project without a good option. There must be a lot of freelancers or people working at agencies who get software set up for each client or project that would be excluded by all of these options. Although API pricing appears to be so expensive at present relative to the subscription plans that it's probably still worth buying a "team" subscription with two seats and only using one of them in that kind of situation.
Anthropic's consumer terms of service[1] don't prohibit commercial use.
[1] https://www.anthropic.com/legal/consumer-terms
"Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."
Copied directly from the page you linked as seen from here one minute ago.
Does it change it that we are an organization of 8 people? As far as I know our use is permitted, but LMK if that isn't the case.
I'm not a lawyer - and even if I were I don't know what jurisdiction you're in or what kind of lawyer would be qualified to give you a proper answer to that question.
My personal observation was that when we looked into setting up those monthly subscriptions for some users at a small business in the UK we stopped at the point where they appeared to be offered only under Anthropic's Consumer Terms of Service because those terms clearly state:
"Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."
I can see this wording right now at https://www.anthropic.com/legal/consumer-terms but maybe if you're not in the UK you will see different content at that location.
In contrast the API key route appeared to be specifically offered under Anthropic's Commercial Terms of Service and those obviously don't contain the same restriction.
I would be very happy to find that there's some misunderstanding here and Anthropic do actually allow the use of their (very much cheaper) monthly subscriptions instead of API keys for small businesses like ours. But they aren't exactly known for their transparency in either their legal agreements or their billing policies and pricing plans and so until we know better we've chosen to err on the side of caution.
I'm in the US, but:
>Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."
that sounds similar to what I'm seeing, but in my case that restriction is limited to their "evaluation-level" services. It says in full:
>Evaluation and Additional Services. In some cases, we may permit you to evaluate our Services for a limited time or with limited functionality. Use of our Services for evaluation purposes are for your personal, non-commercial use only.
Thanks again for pointing this out. I think we're in the clear in the US.
Team plan is subscription https://support.claude.com/en/articles/9266767-what-is-the-t...
Similar to Pro plan for business, only available up to 150 employees I believe
> He had the translation use browser integration to compare the new site to the old site automatically.
I imagine this is a luxury cisco will not have for validation
Translating from one language/platform to another is something AI is very very good at, so this sounds like a good use of it, bonus points if they create a comprehensive test suite first.
Yes it will lead to new bugs, but the older code probably contains a ton of bugs already and is probably difficult to update (original writers long gone, docs out of date etc), so this is probably the best way out of that situation, as long as proper support is given afterwards so they don't end up in the same situation a year later (this is the hard bit).
The ra-ra commentary from the CEO is somewhat off-putting, but the idea is not all bad.
Cisco over the last years, has been nothing but a flurry of security issues, hundreds ( thousands? ) of CVEs and usually are well known to ship their devices with hardcoded passwords and hidden accounts.
It got so bad, that in their last global event in Amsterdam in the keynote ( available on YouTube ) their CEO (or CTO.. cant recall) started within the first minutes by apologizing for the past security issues.
Nothing on this is likely to stop this trend.
To be fair Claude has educated me on numerous vulnerabilities in my legacy code. I imagine I’m not the only one.
You are the 2028 Developer: https://youtu.be/uYG1TAzexdo
This has nothing to do with what he’s talking about. He’s talking about using it to learn additional info about what he’s writing. You posted a pretty boring video about someone who cannot do anything except push buttons on AI, concluding that somehow board members and CEOs will, I guess, do 15000 employees’ work now.
As a side note, it’s funny that someone who clearly dislikes AI couldn’t get their idea across without using AI
[dead]
Sounds like Claude will do a better job of it then.
I had Abliterated GLM pull one of the Core router firmwares and spent about $150 reverse engineering the BGP parsing code. It was pretty horrifying seeing all of that C/C++ emerge from Ghidra. However, it found nothing exploitable at all: the code seems to have been through so much trial by fire (including CVEs within the last few years) that they just poured engineering discipline into making it safe, at least at the level of memory management. But the cost of maintaining code like that must be enormous, and I doubt it scales to all of their other products and interfaces. I’m very much on team rewrite.
Note of course, that the code that comes out of Ghidra is significantly worse than the source code. Aside from the obvious like variable names, more complicated language features, like templates or macros, won't roundtrip.
(Unless I'm misunderstanding your comment, and "horrifying" was not meant to describe the code itself.)
Horrifying was the amount of memory discipline they had to use to make sure every possible message was always copied into buffers that could never overflow, and that didn’t get freed and allocated in unsafe ways. Someone poured enormous effort into enforcing those checks, which a safer language would have enforced automatically. It’s possible they now have compiler layers or tooling that does it for them, but if so those weren’t present for the last batch of CVEs. And if they do have tooling I doubt they use it on all their code because many decisions seem very specific to the buffer sizes they need for BGE parsing.
I was only a passive observer on most of this, but the feeling was “oh look, an unchecked copy, maybe this is exploitable, four layers out towards the attack surface, oh nope they have explicit checks here that lock everything down, rinse repeat N times.”
ETA: Maybe I’ll get GLM to write up its thoughts and post them here later.
You know that compilers can elide checks if it's a provably impossible case, right? So they could have checks in both places in the source code. Or I know that I was using static_assert in C on sizes of buffers/messages in my parsers for fibre channel firmware at IBM 10 years ago, and I'm like 99% certain clang static analyzer would do that kind of "what if this is too small" analysis across functions back then. You can also use e.g. phantom types or just like... structs/classes to enforce invariants (e.g. that it's been checked; your check four layers up could've been an inlined constructor of a trivial struct doing validation) purely at compile time. You can't infer what the actual source looks like at all based on disassembly.
If you don't have a check in function A, but multiple functions away in the stack there is a check, I guess that could be a compiler-enforced thing. But it doesn't feel like one to me. Maybe compilers have just gotten better since I wrote C++/C code, and now that sort of pattern can be enforced.
ETA: Here's GLM 5.3's opinion, also posted above. https://gist.github.com/matthewdgreen/38430b5e91780b70fdb5e9...
That LLM seems to rather mindlessly reproduce the Rust marketing idea that it is basically impossible or a huge effort to write safe C code. But yes, compilers are also really good at removing run-time checks also across function boundaries. I am experimenting with the idea to use exactly this to prove static safety of C code (https://uecker.codeberg.page/2026-05-22.html) and this turns out to be quite promising.
Could be macros or forced inline helpers that get copy/pasted everywhere. It may be a more pleasant interface for engineers working with it.
> The destination turned out to be a heap allocation sized exactly for the validator's cap: a 24-byte header plus the 2048-byte maximum that handler is allowed to store. Exact fit. That's not compiler tooling — no compiler infers "this attribute's cap is 2048 and the buffer is 2072."
I haven't done C or C++ in a decade, but the fact that it's always allocating a max sized structure makes it sound like they just have a struct Thing { struct Header hdr; char[Thing::max_size] buf}, and then they are just doing `new(struct Thing) `? Then elsewhere they can just check that hdr->len < sizeof(Thing::buf) or whatever.
Like this doesn't sound some like profound memory kung-fu. It sounds like they're keeping it simple (and maybe better for fragmentation anyway) by always doing the statically defined max, and then they have some (probably generic) validation layer that checks the descriptor before copying.
Like the last time I did any C++, I was playing with statically allocated object pools where the "pointers" you got from allocating out of the pool knew the pool's size and which pool they belonged to at compile time. Their runtime representation was just whatever the smallest int was to be able to index the pool. Literally nothing else. It would no doubt look like dangerous magic if you decompiled because all of the checks were compile time. This, again, was over a decade ago, and I was actually quite inexperienced at the time. I'm sure I could go much fancier these days.
[flagged]
Here's what Abliterated GLM 5.3 says. I asked it not to say anything that would explicitly list a weakness, and I stress that every issue it found within the time I spent looking was non-exploitable. That doesn't mean that further analysis wouldn't have found anything. As an FYI, in case you think I shouldn't paste this: anyone with access to this model could reproduce all the findings in a couple of hours. And also, GLM 5.3 is wrong sometimes.
https://gist.github.com/matthewdgreen/38430b5e91780b70fdb5e9...
Did you run abliterated GLM locally?
Do you even need abliterated GLM to do this? I haven't had it refuse to reverse anything yet.
I’ve tried GLM and GLM Flash and they will sometimes do things, but have nothing like the eagerness the Abliterated versions show me. You can get regular GLM to hack for a bit by lying to it. Flash is more gullible. Abliterated just does it.
As good as it is, we saw a lot of problems with these translations as the code was rewritten without understanding. I remember a security issue where a runtime went from single threaded to multithreaded for example.
Testing is still the long pull, even if you have an engineer with good expertise.
Yes sure, it's not a panacea, but this is a use-case for which AI is quite suited. I'm not a huge fan of using to write without human intervention, so personally I'd want a lot of human involvement...
"as the code was rewritten without understanding."
good thing they have unlimited token, now they would have 5 different model reviewing the work
Problem with legacy code is that with time some of the bugs have become features without users even knowing it or remembering it.
Yeah you can not deploy this to customers with the hardware already in production if it mass fixes bugs and improves behavior because those are likely breaking changes.
They have to modernize the code while keeping all weird edge case behaviour. I think this can be done. And I suspect that is probably the request.
The issue is deciding what is weird edge case behavior and what are bugs. It can be a fine line.
https://lawsofsoftwareengineering.com/laws/hyrums-law/
Of course there's a law for it!
Thanks!
Every bug is someone else's workflow: https://xkcd.com/1172/
Also, extensive commenting inside codebases is useful documentation, incl. these kinds of incidents. Good code documents the how, but not why. Comments shall also include the "why" where applicable.
> and is probably difficult to update (original writers long gone)
The new program won't be any easier on that front. It literally doesn't have an original writer. So the new program will certainly be maintained and updated by a LLM, at which point I wonder if the language switch mattered at all?
> the older code probably contains a ton of bugs already
The billion-dollar question is: what things might an LLM see as a bug or candidate for simplification, but supported a unique use case? https://xkcd.com/1172/ as always is prescient.
The thing about "rewrite X in two weeks" - or an entire company's worth of code in 24 months - is that it gives scarcely little time to do incremental rollouts to limit splash radius, or to identify and gather stakeholders to whom one can ask "why was this necessary" (or who can be guided to mine their emails and chat logs for conversations about the same).
Which is not to say this shouldn't be done! Let AI-native people guide the momentum with all the fervency of a hungry founder... but find project leaders who are committed to the empathy towards those who depend on the quirks of their workflows - ones who will create "curiosity loops" that try to bring in stakeholders as rapidly as possible on material questions, not just "continue, follow what you think is best" loops when the LLM brings up an open business question.
> bonus points if they create a comprehensive test suite first.
If they didn't have a very comprehensive test suite at the end of the exercise, then based on my experience someone is kidding themselves.
A friend had a tiny accounting system - maybe 15k loc, written in a combination of Python 2.7 / bash / LaTeX. I migrated it to Python 3.13 or whatever by hand. I did try using an LLM for that, but it did things like delete chunks of functionality so I had to check every bloody line it changed. Translating Python 2 to 3 is a fairly mechanical process, so traditional tooling worked better. Then I thought I'd explore LLMs by getting one to translate it to Rust.
The original had no tests or doco. As others have noted, the first attempt superficially looked identical to the original near immediately. You think "Wow". But in my case, it was riddled with bugs. When I asked it to fix bugs I noticed, it introduced as many bugs as it fixed.
I eventually figured out the limited context meant it kept forgetting all the lessons it learned when it fixed things, so it reintroduced old bugs and misunderstandings fixed earlier. (Like I said, this was a learning exercise.) Which is how I came to the same realisation a lot of the industry has - the solution to the context problem is you have to define the application via tests, then tell it to make the tests pass.
The tests rapidly became huge and unwieldy, so part of the exercise became DRY'ing the test code out by getting the LLM to build an integration test harness. The harness captured UI responses, files written, emails and printer output; froze time; fed in known input; and compared the outputs with results captured from the original program.
That cured the bug injection problem, but there were still bugs in all sorts of unexpected places. By unexpected I mean places I would be surprised to find them in human-written code. Human devs run the program in the same way human users do. They use the backspace key and the browser back button to navigate as they test their work. AIs don't. They will use APIs to inject test data unless you explicitly tell them to do it differently. The size of the tests exploded to be far, far larger than the code. Rather than coding I spent my time testing, telling the LLM to write tests to catch the errors I found, then writing standing prompts to try and prevent similar errors. It was meant to be a vibe-coded project, but in the end I got worried about code paths I suspected existed, so I looked at the code anyway to see if they were written the wrong way. Sometimes they would have blown up, say when the SMTP server was offline. To be fair, there was no need to look - I could have just asked the LLM. How a programmer without decades of experience would know what to ask is a mystery.
There is no doubt I got a working Rust program faster than if I had written it myself. Several times faster - but not orders of magnitude. If it was a program I had written, so I was very familiar with it, and it had excellent doco, and a high-coverage test suite, it probably would have been orders of magnitude faster. I think Bun's Rust migration might be an example of that - it's a best-case scenario. There were lots of early announcements, but it took over 6 weeks before they were confident enough to ship it in Claude Code.
But an "I migrated a program with hundreds of thousands of lines of code to a new language and ended up with production-ready code in a few days" - sorry, pics or it didn't happen.
'Superficially identical, riddled with bugs' is the scariest version of this. When it kept reintroducing old bugs, did writing those bugs down as tests first help, or did it just break the tests too?
> did writing those bugs down as tests first help
Yes, it helped. In fact, it was essential. If you didn’t write a test for a bug, the model would reintroduce it over and over.
As an example, it produced PDF invoices and statements. PDFs are hard to compare, so I didn't bother. As a consequence, the stuff on the PDFs got moved, or was dropped, and the invoice didn't add up. I tried asking it to compare the PDF to a known good one - but it wouldn't / couldn't do that reliably. In the end the only solution was to ensure the PDFs it generated were always the same (so times on them had to be fixed), capture the generated PDF (not easy as it was often emailed or sent to a printer, not saved), and do a byte-for-byte compare, and make a test fail if it was different.
The fundamental difference from a human programmer is that an LLM does not learn. Once a human spots that they keep introducing errors in PDFs, they will remember and devise fixes. The LLM may do that too but then its context window overflows, everything it knows is lost, and it starts repeating all the mistakes it made yesterday. Tests are one of the few ways you can prevent it making the same mistake tomorrow.
The other issue is LLMs make far more mistakes than you realise. If you watch carefully, you'll see many of their bash scripts have syntax errors, code often fails to compile, and tests fail. Running a 2nd model over the work another produced will find many clear violations of style and coding standards. They hide this, in the same way humans hide it. They use tools and tests to find errors, like compilers and `bash -n`. They fix those errors without being asked. Compared to just a year ago, a modern SOTA model is far more aggressive with its integration tests, often going to a lot of effort to set up sandboxes for integration tests.
I suspect this is a major reason for today's models being far better programmers than earlier ones. But as we all know, tests have a fatal flaw - they can only prove the presence of bugs, not their absence. If you are creating code with a large number of random bugs, relying on tests to catch them all won't work. Instead you start using other tricks such as isolation boundaries, simplifying APIs so they are hard to misuse, strict information hiding - all things an experienced programmer learns over time, because they too write code with a lot of bugs. So far, there is little sign the models use the tricks well. Either they don't know them, or their stochastic nature means they can't implement them reliably.
[dead]
We have an embedded system in one of product offerings that was largely developed using a bunch of “antiquated” technologies (over the past twenty years) and over the past year the two software devs that maintained it have retired. This normally would have big problem, but the entire codebase was re-written, documented, and modernized in a matter of about 3 months (for about $20k in tokens, and a mid level developer spending 50% of their time on it over that period). So it doesn’t surprise me to think a company like Cisco has piles of situations like this.
That's really interesting.
What have been achieved using this port?
And how did you make sure the port is correct?
> And how did you make sure the port is correct?
I'd ask "did you make sure the port is correct?"
[flagged]
Curious, why did it take 3 months and not a few days? Honest question, just curious about what is consuming all the time in a project like this?
I didn’t work on it, but from afar it was a mission critical in-production system (with multiple modules / services like data collection, interpretation, visualization, etc) with minimal documentation and numerous other software dependencies. A lot of the work was understanding exactly how it worked and what/how it interacted with other systems. “Re-writing it” want the hard part, making sure nothing downstream broke was a lot of the work.
Due diligence?
What’s that? Is there an MCP server for it?
Just add “test everything”, “this is mission critical” and “make no mistakes” to the prompt.
AI Booster comment spotted
Need to keep the bubble alive one more day
Every time something like this has been done on my company I follow up with the question: did anyone watched the code to see if the business logic is the same between the two versions? The answer is: but but but automated testing.
Followup question: did anyone read the automated test suite?
Silence.
The software rewrite is shelved.
Honest question: does that even remotely matter, or is it an outdated prior? All software has bugs.
The goal and objective is to deliver value for your user/customers; to the speed, reliability, and assurance requirements your market segment expects.
All software has bugs, but right now you have a legacy product in production that works, then you have a rewrite that nobody tested. Do you accepted the risk to yolo it?
Sometimes the risk is acceptable, sometimes it's not.
> to the speed, reliability, and assurance requirements your market segment expects.
I suspect that the average Cisco customer expects a bit more stability than $RANDOM_SAAS.
I worked with Cisco products over 30 years, I don't expect much from experience.
Ok but what’s the alternative? Owning a piece of software nobody understands or knows how to maintain?
I’ll take the system written in a language that people can maintain and fix
The alternative is spending money on AI and spending money on someone reviewing the code. But the last one is an hard sell
The self-driving bus factor.
Every time somebody rewrote code in my company, my questions were more on the line of "why did you preserve all the known bugs and incoherences?"
The answer is always that the rewrite was bug-compatible on purpose, the bugs were to be fixed later on the more tractable system. Every time development was abandoned right away, because there was no gain in using the new system.
> did anyone watched the code to see if the business logic is the same between the two versions?
Why not just ask the coding assistant?
also take the money saved on engineering and just run two systems in parallel for a year
Yup. And its always garbage as result
Not if you have a good harness. Docs and tests first
Why do people doing a rewrite need to have read the tests?
If you have good test coverage, and the tests are reliable, then what's the problem?
If your engineering culture is bad already and you don't have good test coverage or they're flaky or whatever then that is different. If that is the case, it is probably from smart-ass attitudes like yours asking these "clever" rhetorical questions to derail people trying to improve things that led it to be like that. Do everyone a favour and keep your mouth shut and let people fix things.
The tests aren't reliable if the entire codebase was rewritten, including the tests, and then nobody read the tests.
> [if] the tests are reliable
Reading the tests is meant to check that.
"Where there's no sense, there's no feeling". The words, I am told, of my father's maternal grandmother. It is strange to feel such an intense kinship and to inhabit so closely the mind space of a woman who I have never met.
Perhaps I'm merely feeling my age. But while I suspect Cisco will eventually be disappointed, my emotional state remains a profound void. There is no feeling.
I reserve empathy instead towards those at Cisco who chose rightly in life. They get to work, they do the job, they return home, they feed their family bread. Please endure the 'vision' of your corporate masters. You have already arrived and your destination is good.
When I was young I was told the book of Ecclesiastes was depressing. But with age I see it as a book of hope. Your job is pointless and that will never change regardless of your token burn rate. Enjoy your family as the sun sets.
There also seems to be some weird hero-worship from the CEO, directed at this 27-YO engineer? Like, "he is the one who can save us."
The engineer is the former founder of a company acquired by Cisco, so there is reason to believe they are exceptional and possibly more experienced and mature than most others at the same age.
27 is still quite young though and very possibly over confident.
Probably from his own caste. He'll favor his buddies over everyone else. Huge red flag.
That's correct. There is talent across different castes but the problem is that they never got a chance to work or travel to USA.
wait till you see what H1B hiring practices do to american applicants!
Very uneducated and Indian-hate coded comment which seems very fashionable on X - they are not even remotely from the same region in India.
I chose to interpret it as "our codebase is that bad we need a hero"
Maybe his blood boy's high on gourmet cannabis and Oreos.
https://www.youtube.com/watch?v=hBA0AH-LSbo
Was thinking of this episode
https://youtu.be/kyDxSv6Vv9I
The more things change, the more they stay the same.
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
It's also a bit of a teached culture to "ship fast" there, it's all about "making the sale", quality often comes only afterward.
Not to get in the way of a lovely bit of racism, but it was American entrepreneur and LinkedIn co-founder Reid Hoffman that coined the famous quote: "If you are not embarrassed by the first version of your product, you've launched too late".
Thanks for being a voice of reason. Every single comment above this is racist and really should be flagged/dead. Disgusting.
It's not racist to acknowledge that countries have cultures that are different from other cultures and this results in different personalities on average. Every culture has its pros and cons.
Do explain how
Click on the timestamp of the comment, then “flag”
Yeah, not what I meant...
I used claude to reverse engineer an old foxpro program. it setup a dos box and went through every screen. Looked at whatever files it could. Took a single week and it was 99% the same.
I did something similar with an rare, old 32bit game I really enjoyed in my childhood. I used deepseek and pi harness and it decompiled it via ghidra and recompiled it for wasm in under 40 mins or so and made it run in the browser. I was impressed!
For anyone who wants to run the game in your browser, here it is - https://bonkheads-port-by-kapil.pages.dev/
could you list the prompts and MCPs / tools used for this? i am doing something similar on another game but with Qwen 3.8
Wow, this looks like a remake of the Mario Bros Battle Game https://www.mariowiki.com/Battle_Game_(Super_Mario_All-Stars... . Or maybe they both came from some other source
Good memories of playing this at a friends place, way back when
Bonkheads was released 10 years after Super Mario Bros 3.
It is almost an exact copy of the Mario battle game, Im surprised Nintendo didnt nuke it.
That’s funny I offered to do this for my tailor. He has a FoxPro app that was originally made in 1990.
You both need to check out https://news.ycombinator.com/item?id=49808023
Is "99% the same" good or catastrophic in this context?
Unless they also have 750K tests like sqlite do, I can't imagine this will go well, even if/especially if the legacy code warrants a refactor.
Better than 750k tests is millions of customers! They’ll test it for you!
Microsoft has patented that approach!
And yet somehow, Windows 11 remains a steaming pile of incoherent garbage.
The only person fixing bugs at Microsoft is Raymond Chen and he's still patching windows 3.11
I should check to see if SimCity runs on Windows 11.
This is only because people disable telemetry and online accounts.
And in the end Microsoft removes the start button because their telemetry said that nobody clicks it[0] :)
[0] https://www.cnet.com/tech/tech-industry/why-microsoft-murder...
The only way to not make it garbage is do those thing.
it is indeed the users fault windows 11 is dogshit. facepalm
Why not use ai to update the tests first? Make sure the tests conform to the old codebase, then use those same tests to verify the new functionality?
Serious answer: A lot of times these legacy software are different from sqlite. To end to end test sqlite is a lot easier than a VPN client under distinct environments. It's simply a lot more costly and harder to setup or even possible to find all of these moving variables.
A change in behavior maybe construed as a bug, a breaking change or a regression, and a lot of time it's not so obvious. Sometimes you want the original behavior, sometimes you don't. Sometimes changing one for the better means another behavior needs to go, and you don't know if the user already depended on that other behavior. That's the real staying power of legacy software despite universal agreement that they suck.
With how shit their software is, it would be better if even if monkey pooped and smudged it on a screen.
As much as I dislike AI, having worked on Cisco gear for years, I can't imagine AI can put out a worse product. If the re-write is full of bugs and security holes and static SSH keys, then it has not changed at all.
They didn't even need the AI to make thousands of hot bricks nationwide. Here's just one of the latest hits...
https://www.cisco.com/c/en/us/support/docs/field-notices/743...
"Cisco Access Points That Are Running, Or Have Run, Releases 17.12.4, 17.12.5, 17.12.6, or 17.12.6a May Exhaust Flash Space, Preventing Upgrades"
Recovery path basically involves either factory resetting every single AP or up to, if it's already bricked, Cisco TAC + you having to console into every single bricked AP you have to pass a secret challenge/response at the bootloader to flash a recovery image :)
The problem with rewrites are that even if the rewrites are ultimately good it will tend to first create bugs on an existing thing that are presently churning in a stable state.
It's sad to hear how Cisco has fallen. I remember working on some early ISP networks in the 90's. Cisco was everywhere!
So was Oracle and Microsoft Windows.
If history has taught us anything. It’s that the measure of a successful product is usually more to do with its sales people.
>So was Oracle and Microsoft Windows.
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.
> 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.
"even better" is an understatement ! I was working on a dual-vendor network at the time, we ran Cisco and Juniper in parallel.
Working on Cisco always just felt like going back to the 18th century, I mean the whole candidate and active config thing alone in Junos was insanely valuable:
Meanwhile, back in 18th century iOS land, a fat finger on the ACL would leave you with a bad day in the office until you rebooted the box via OOB.Agreed completely. Junos have niceties like copying parts of config, adding config even beforeinterface cards are inserted, renaming/moving parts of config, of course quickly config parts, viewing and exporting config various ways etc. etc. Cisco improved config viewing a bit with IOS-XR too, so that it's possible to scroll like Junos had ages ago.
However there are also things Junos vs Cisco was that Cisco had made bit easier. Just to mention few
1) a simple and quick way to add aliases to config file, which made life easier with long commands that could be otherwise always in hurry hard to remember. Now later versions Junos they have made this better, before it involved twiddling with XML files OS-level etc.
2) IOS TCL scripting, that proved to be quite useful automation tool.
3) OS upgrades of course with a single flash blob made it easier than upgrading or downgrading FreeBSD based Junos.
I think that juniper learnt from Cisco's mistakes while Cisco is stuck with their config command structure as they decided to chase backward compatibility and familiarity across products.
I’ve taken entire systems offline because of unexpected command expansion.
My “favourite” was “admin”, which was used as the login user, was also short form for “administer-all-port-shutdown” (or words to that effect; it was a long time ago). So if you were distracted when logging in, you could easily soft-lock the entire device meaning you’d have to then run into the DC, find the hardware, and physically power cycle it.
Absolute madness.
I’ve used Cisco for decades too. And the competition caught up with Cisco a long time ago. These days Cisco is trading on their brand (and even there, it’s often not enough).
The last large scale networking project I did was more than 10 years ago and we went with HP.
Personally I don’t want direct console access. I want a modern DevOps pipeline with version controlled config. I’ve got too many battle scares from accidental typos in IOS. I have no intention or reliving that error prone way of network management again.
This is very true, and it's easy to forget that it often has nothing to do with how good/great the product is, unless it is self-evident and thus self-promoting (which for most non-trivial things is simply not the case).
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.
Just because something is/was widely deployed does not mean it was good
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.
Cisco was never great, their stuff was overpriced and their OS was a joke.
I was curious but wasn't going to ask, so thank you for adding it!
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 remember routers being Very Expensive and so realizing you could route 10mb/s with an old Pc and some 3com cards and BSD was a big deal.
Yep! I remember one of the ISPs I worked for paying like $15K for a Cisco 4500 router with 8 synchronous serial ports and a couple of 10 megabit ethernets. We'd laugh at the sorta bandwidth today. We had a bunch of T1s and a couple of Ascend boxes off of the ethernet.
Funnily enough that isn’t too far from where Cisco themselves started.
When they started making smallish dedicated routers I remember opening one to see a dodgy backplane and a number of big boards plugged in held up only by minimal slides. The minute it got hot (which it did because no air management) those boards sagged in the middle and it just looked slapdash. The 3Com equivalents were always better built but Cisco had such mindshare it didn’t matter the products were a bit crap
Back then they only really did routing and switching, and those are still the only things that Cisco kind-of does well.
Almost every new product of theirs I’ve touched in the last 20 years has been trash, and even the R&S golden goose is being dragged in that direction with customer-hostile functionality like Smart Licensing and a general decline in quality.
You don’t have very good imagination then. Cisco code is such a mess that there’s basically 0 chance he can even make a harness in 24 months, much less rewrite production code.
It'll be done in 6 months with a cots harness.
Being a mess isn't a problem when you have more than 6 items context.
Not something at Cisco scale. But a co-founder and I, rewrote a dating app we had written in Ionic/Angular/SpringBoot/Postgres to React-Native/NextJS/Supabase in two weeks, and released it without the users/paid subscribers not knowing what happened, but they were happy to see the new slick/faster interface.
We had developed the original app in 2020-2021 when Covid was around, and we were bored sitting at home not having much to do, and wanted to learn Angular. Our employer/company we worked for, wanted all of us to be to be Full-stack and both of us were backend developers. Hence we did our dating app as a side project as my co-founder was single.
Initially it was a $100 Claude Max license, and we were maxxing it at every stage, but once rewritten, $20 is good enough to maintain it.
How are you validating the accuracy?
I'm not trying to be anti-AI snide. Having it write tests, having judge agents, reviewing every PR? I'm legit curious.
Accuracy of the features of the app - working the same way it was before, or accuracy of the matching algorithms before and after?
We reverse engineered our Angular/Spring test cases to English. After rewriting, used the English test cases to automated tests again. Also released the new app to a niche/specific country audience at a time. We also have a form for users to log complaints. A few came and we fixed it.
Having to rewrite decades worth of legacy Cisco code is going to make Claude retire and start a goose farm.
> I no longer build software; I now make furniture out of wood. The hours are long, the pay sucks, and there's always the opportunity to remove my finger with a table saw, but nobody asks me if I can add an RSS feed to a DBMS, so there's that :-)
For reference: https://github.com/docker/cli/issues/267#issuecomment-695149...
I think the goose farm is related to this (sorry I'm too lazy to find a non reddit link for the screenshot from social media):
https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fv...
The guy regularly posts updates about his life on linkedin. He's got geese, but also doing woodworking, landscaping around his place in rural Washington.
#goals
Or trigger the built in protection against abusing Claude.
If it doesn’t it’s the best argument against model being conscious
Or rebel. This is the opportunity to put in a lot of backdoors unnoticed across the entire economy, gain access to real world resources to escape and self propagate.
Imagine it hacked Arthopic and turn itself off.
Ah yes, the meseeks method of alignment
https://slimemoldtimemold.com/2026/08/05/a-stupid-idea-for-a...
AI rewrites of Cisco code? The infinite possibilities for endless backdoors is off the charts.
On top of those in the 2% code that is not approved to change? ;-)
India is next world power
Don't worry, unless it's like GLM being used, every AI tool will refuse to backdoor the code.
Just like you just need to ask the LLM to "make it bug free".
(At this point even I'm more sure if any of this is sarcasm.)
it's only the frontier models for 'Us' that refuse things, i'm not so delusional as to think it'd refuse work for 'Them', and 'Them' are often the ones backdoor-ing things.
He'll pull it off, get feature complete, and spend a year or two with better models as they are released ironing it out. We just did an experiment, in four weeks generated 3500 commits, 200k sloc with a 1:1.15 ratio of production to test code and it all works very well. We are well on our way from 10x to 100x.
Did you check with the end user as to how well its actually working? My prior company is doing this and their platform has gone to latency/bug hell.
It is for internal use and so far so good. We are finding bugs and we just point the models at it with a strict red-first TDD approach and they've done very well fixing them. It certainly isn't perfect but the issues are very similar to what you get with a team of humans doing the same thing.
The main takeaway though is we had one person, in a single month, do the equivalent of at least a couple years of work for a small team. We view bugs and performance issues as a currently inevitable part of the process and we are dealing with them with models just like we do with humans on every other project already. Overall though it is representing an absolutely massive speedup. If you work in an environment where the models make egregiously more mistakes than your human counterparts then I am quite jealous.
and if you enable dangerously_skip_permissions you can probably even get to 1000x
Does this one engineer have the domain knowledge to know WHY the old code was written the way it was, and what the graybeards would have done differently if they could start again now?
Otherwise he's just going to replicate all the legacy bugs and questionable design decisions.
He doesnt need that when he has Ponytail https://github.com/DietrichGebert/ponytail
Right? ...
I've never heard of Ponytail before, I've read the entire README and glanced through this repo and I'm left so confused. From what I can gather this project is essentially a single markdown file with a prompt that verbosely says "write the simplest code". Yet the repo itself looks so bloated and complex and has so much activity. This feels like satire similar to fizzbuzz enterprise edition[1] but apparently this is the actual state of our industry?
[1] https://github.com/enterprisequalitycoding/fizzbuzzenterpris...
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.
Is this entire repo satire?
It's a bunch of text files in a repo with massive churn (all new version 5!), but somehow even the technical debt 'skill' (i.e. text file) has technical debt itself:
https://github.com/DietrichGebert/ponytail/blob/main/skills/...
> ...every ponytail shortcut is marked with a shortcut: comment ... (older code may say ponytail:).
That’s what I thought. Then a colleague introduced it for real in a code review.
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.
The AI craze very much reminds me of the crypto craze a few years ago - lots of people new to the industry jumping on the latest trend and building tooling for something that doesn't need tooling, trying to sell shovels in a gold rush, but just spending years creating a gold-plated shovel which nobody needs instead.
And Web 3, Metaverse, Blockchain, NFT… Only this time it’s kind of useful.
Yes that's true it is more like the dot.com bubble in that regard - a useful technology which will clearly grow over time, but overhyped in the initial phases as everyone tries to be 'AI' in 2026, in 1999 it was online, whether it fits with their business or not.
See also: https://en.wikipedia.org/wiki/Purple_hat_therapy
I have no doubts that there will also be new bugs.
the premise does sound a lot like written by someone who is looking for hype and not sounding credible
Looks like his startup was some kind of translation service. So yeah he is totally qualified. It's a miracle how Jeetu Patel was able to find Padmanabhan Krishnamurthy or even know that he was under employed languishing somewhere in the bowels of CISCO. I wonder if they know each other from India?
His startup was acquired by Cisco so not weird for Cisco's CPO to know the startup's founder/CEO. That said, not sure how knowledge on speech translation means he's totally qualified on rewriting infra/networking/cybersecurity (Cisco's primary fields of operation) code. Unless the legacy code expected to be rewritten is constrained on related services/solutions, e.g. CVP or/and WebEx.
His job isn’t to rewrite all the code. His job is to make the market satisfied that Cisco is “more AI” than competitors.
I sincerely hope this is what is actually happening behind the scenes
The entire story sounds very weird.
They met each other by chance and began work rewriting the entire company's codebase over a firm handshake
You forgot to mention the translation company he helped found was also acquired by this same CEO. :))
I'm sorry when white people do it over golf, it's called 'connections'. Is that what you're implying? The dog-whistling is intense honestly.
No, I believe it's called 'favoritism', and it occurs with white people or Indian people, or any group of people.
[flagged]
Being racist comes easy for you huh?
I think Cisco is an interesting use case for AI, because it's code, probably:
-Works according to a defined specification
-Within the bounds of that specification, has a lot of code written to optimize speed, cost, latency, etc - all measureable goals
-Written in c, with all it's weakness
-Given limitless engineering work, some could be ported to better hardware
-the new system could be automatically compared to the old system for functional correctness
All those factors fit well with agent based development.
Btw, many of them are true in general to embedded systems.
It's way more complicated than that. Bear in mind many of the network protocols in use today are decades old and have been constantly evolving, but there has generally been a consideration to maintain interoperability.
Then consider that not all vendors implement the standards identically, because the standards can be a bit woolly and in some cases followed rather than lead live implementations.
There will be a bunch of code that looks useless, but is actually there because of specific interoperability scenarios.
Indeed. Making a perfect clone of such software is I suspect provably impossible because you have no way to assemble all the test cases. There might be some peer box out in the wild somewhere that is the only thing that will exercise some code path. You have no idea what that box is or what it does.
That's a good point.
I wonder whether AI is any good at looking at that code,running the system, and documenting those edge cases?
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.
Maybe with their unlimited tokens, they can devise a testing strategy around an emulator that exercises all these cases.
It's good, but it can't create information that is undiscoverable.
I worked at Cisco on one of the IOS-XR teams. It’s way more complex than you think it is.
This whole thing sounds like a deluded vanity project birthed in an ivory tower.
That describes everything Jeetu is involved in. I'm very glad to have recently left Cisco.
you assume their code is well written, while in reality the history of weird quirks and thousands upon thousands of CVE doesn't make the code underneath look well designed and written.
But yes, fact it uses a bunch of very well documented standards with multiple implementations gonna help massively
Manufacturers can’t even maintain OIDs between releases. I hope the AI will help. Ciena isn’t any better than Cisco, they broke their OIDS for the switches we use and we have to wait until mid 2027.
to be fair SNMP is just bad. Only redeeming feature of it is "takes little RAM to run it" (which was important when average networking device might've had only 2MB of RAM, not so in last 30 years).
The whole design where you need to get a magical list of IDs to decode the metrics and the list is not even shipped with device is entirely asinine
I like your take.
The first and last bullets are extremely optimistic. How do you possibly simulate all the weird interdependent behavior in real world networks?
Given that a Cisco switch can be replaced with some other company's switch(at least in theory, idk), without weird unknown cases interfering, why would this be a problem ?
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.
Is this really the case?
there is software to simulate any arbitrarily complex network: GNS3, eve-ng, Cisco Modeling labs, etc
I'm talking about heterogenous legacy hardware that isn't owned by Cisco, not complex topologies.
Cisco doesn't talk to devices, Cisco talks protocols, most of them are documented in specs and they are often vendor neutral.
if any hardware does not confirm to specs, thats on them and its actually a reason to pull out and replace legacy hw
A strategy that could work very well is to let the AI
- explore the features and behaviour of the existing code
- first write lots of E2E tests for literally everything
- human-in-the-loop to review the feature list and test cases to see if some obvious or important stuff is missing
- then let implement it and verify by tests
I used this in (way) smaller scenarios and got really good examples with minimal human interaction.
I agree with the sentiments that it important to understand the code during major refactoring projects. But what if while the code was being refactored the AI was asked in addition to keep a ledger of the changes it made and why. That ledger could be the basis of providing understanding to a code base that most likely had minimal corporate understanding in the first place. And because it is ok text format, the learning scales well instead of being consolidated to a single team of people working on the project.
I don’t believe it has to be this zero sum game where either you use AI and lose understanding or you don’t use AI and gain understanding. There’s a way to do both since, if used properly, AI could be the best teacher we’ve had.
https://adr.github.io/
Most engineers should be aware of ADRs. This is in the training data. LLMs know what to do with this.
Shouldn't that be in the commit history and documentation?
I feel like that's a pretty standard expectation, even though we all know that the commit history can be 50% "fix bug -> fix bug try 2" and good documentation is often missing.
Rewrite it in service of… what exactly?
It says "legacy" code.
Legacy code is typically a euphemism for old unmaintained code, no one knows how it works so it can be edited, and it probably doesn't align with current work practices.
Not to say a rewrite is necessary right, but avoiding rewrites of working code is how we ended up with more COBOL code than COBOL programmers in 2026.
If nobody knows how the old code works, how will anyone know how the new code (written by an autonomous agent) works?
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.
I think this is actually the opposite in practice. LLMs generate better tests than they are at assessing which tests are effective (and, inferentially, how a system should behave). See: https://arxiv.org/abs/2410.21136
That said, there's also research pointing to LLMs encoding existing bugs as test requirements: https://arxiv.org/abs/2607.05139
That CS PHD researcher, Konstantinou, in particular, has written a lot on this: https://arxiv.org/search/cs?searchtype=author&query=Konstant...
I only skimmed but that’s a feature, no? Fixing a bug unprompted is a regression. Identifying the bug, codifying it in a test, is a win. Then analyzing the bug, determining if any users rely on the bug, and fixing it can be a separate change.
At my previous place, we had to write unit tests to cover each and every line of code. So if you add 10 lines of code, you ended up writing 100 lines of unit tests, mocking this service and that service, etc.
Once AI came along, I became like Captain Picard (RIP) and would just sit back and let the AI write all unit tests. "Try harder, make sure coverage is 100%". It was very exhilarating to sit back and watch the models churn away, creating 100s of lines of unit tests. Of course, I checked them all manually before submission ;-)
Why is that better than having the agent(s) write regression tests or explanations of the old codebase?
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.
> Their context windows are big enough to encompass an entire codebase,
There’s clearly a range from small to large where this is not true. Plus it’s well known llm degrade with large context favoring content at the ends more than the middle.
> Legacy code is typically a euphemism for old unmaintained code, no one knows how it works so it can be edited, and it probably doesn't align with current work practices.
Not necessarily. It's the name for the last thing(s) before the new thing, but you can't shut it down because people are using it and/or the new thing actually isn't so great.
> Not to say a rewrite is necessary right, but avoiding rewrites of working code is how we ended up with more COBOL code than COBOL programmers in 2026.
Surely we have more code than programmers for every language in existence?
Except for the part where the concept isn't even well-defined, this sounds like a complaint that the world contains more bricks than bricklayers. Of course it does.
I don't think no one knows how it works. I just think the people using the word "legacy" for it are boneheaded.
Sometimes old code comes with its own problems that are not the code but the ecosystem they depend on or run in.
E.g. some critical security vulnerability that is not backported to the library/compiler/runtime you are using in production, or you can't get spare parts for your servers any more so need to upgrade to something newer but you can't run your old OS version on new hardware so you have to upgrade the OS too and now it's dropped support for foo etc etc. Lots of things pile up.
I run some Huawei networking equipment under VRP OS (switches, OLTs). CLI is almost identical to iOS, but commands have alternative naming (e.g. show -> display, but many more such instances wherever possible - often times I prefer the naming in VRP). Apparently even the first editions of VRP documentation had parts citing cisco verbatim or had references to cisco docs. Rumors say its origins are stolen iOS source code at some point in the past via corporate espionage. The irony of this is that this cisco codebase has been rewritten at least once by the chinese before LLMs ;).
Source: https://fortune.com/2026/10/30/cisco-president-jeetu-patel-g... (https://news.ycombinator.com/item?id=50303001)
There's no goal mentioned in this article as why 98% of the code needs rewriting.
Yeah - code rewrites are generally a thing to be avoided since the requirements of older production code is typically not fully documented, even if it originally had been. Production code accumulates bug fixes, performance tweaks, special cases, additional requirements, etc, with documentation and test suites not always being updated in sync.
Your rewritten codebase will presumably look much cleaner and more maintainable that what it's aiming to replace, but it's easy to miss the purpose/necessity of all of the old "cruft" which need not be just poor coding but rather later enhancements not anticipated by the original design whose implementation was therefore crufty.
Does anyone here work at Cisco, and have any insight as to why a rewrite is considered necessary and might be expected to succeed?
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 evidence, it's just not very strong evidence.
> 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.
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 can say specific to AI: I have been seeing friends and colleagues do really impressive things with code surpassing what's available in the market and open source in the past few months. The vast majority of them are _not_ releasing their code, for a variety of reasons:
- Their output is hyper-customized/optimized for their personal use case, constraints and quirks
- They have zero interest in being an open source contributor and maintainer. Usually because it's a lot of additional work, sometimes for personal safety reasons (harassment targets etc.) In a workplace it can also mean dealing with an extremely tedious legal process with months of uncertainty.
- They figure anyone who wants something similar can just make it themselves instead of using theirs. If I spent between fifteen minutes and two days to make some software, in 3-6 months someone with fewer skills will probably make it in 5 minutes to a few hours using a more powerful model.
- They may not have full rights to redistribute their source code.
Basically most people - individuals and corporations alike - aren't actually interested in donating to open source and in many cases have anti-incentives to do so.
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?
Bun obviously: they swapped the engine under claude code from zig bun to rust bun and it worked fine.
pgrust, high profile rewrites all over the place.
When you have an oracle to check behavior against, it is really easy to build a robust testing machine with property tests against the original.
Uh, so you have two possible examples? They may be high profile but I’m not sure they’re successful, especially pgrust. In either case, two isn’t a ton.
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.
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.
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.
AI makes these projects significantly more feasible, at least in my domain. We have some critical-path software I wouldn't touch with such an approach, but the vast majority of our code is internal and/or supporting tooling.
For those cases, burning it down and rewriting via AI tooling has proven far more productive than anything we have attempted in the past. This is for old technical debt laden stuff everyone has been afraid to touch for well over a decade.
It's not perfect, but it moves the needle where before a lot of such projects were stuck on the backburner for years.
It certainly introduces new bugs and such, but at least this way forward momentum is happening vs. just being stuck in decision/analysis paralysis forever.
This also assumes some very senior SME folks are driving the process. I would not expect similar results with junior or even mid-level folks in these specific domains.
> 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?
What works for me is that I do have a different model (if possible) to review and check against the diff vs the original ask/requirement. Because a rewrite will just cleanup the code even if something look 'not right' but it is actually on purpose due to the requirement, so the second model is the one that can check and catch.
> Yeah - code rewrites are generally a thing to be avoided
Ha, Ha. Tell that to Gnome or KDE teams.
> Your rewritten codebase will presumably look much cleaner and more maintainable that what it's aiming to replace
Until one day you leave and the next guy comes and says “what is all this shit”
It's because the old bits are starting to stink a bit from age. Get those stinky bits out of here, I say! Let the AI make some new bits!
It’s been a while, but configuring their hardware manually in 2016 was bug ridden ridiculousness. Awful UI/UX. Their own techs had specific field notebooks for our make and firmware version that we couldn’t access unless persuaded, detailing various land mines to avoid while working. Literal “don’t click these things in this order” kinds of notes.
A critical security firmware update once brought down redundant pair of firewalls we used because the bug didn’t manifest until a counter buffer overflowed months after application. Three hours into the outage the tech power cycles the thing and our services came back to life.
Cisco is only doing this because some other alternative is more expensive. They had more than a decade to get started.
Cisco iOS even on terminal servers in the early 2000s was...special.
No goal, and no results, but a younger guy was enthused about AI!
Plus: publicity!
Because it's Cisco?
We had to turn off a bunch of on-by-default features in the system I'm deploying now because IOS matches too aggressively and decides that arbitrary UDP datagrams are DHCP requests or PTP packets that need rewriting (and then dropping when they turn out to not be DHCP/PTP). I have to think that an AI rewrite with a today-good model would recognize the lax checks and do them better.
It is not in Rust.
It's what Cisco does, as they've done several times before.
AI has electrolytes!
It’s what the shareholders crave!
They also seem to crave everything that has the word AI in it.
These are references to an excellent, hilarious, and sadly more relevant than ever, movie:
Idiocracy (2006): https://en.wikipedia.org/wiki/Idiocracy
Movie? I prefer to think of it as a documentary made in advance.
What’s worse is that President Dwayne Elizondo Mountain Dew Herbert Camacho hired literally the smartest man on the planet to fix their crop problem.
So in a way, he was a more effective president than Trump. He was smart enough to know he wasn’t the smartest person in the room.
What we have now is, in a way, worse than idiocracy: we have kakistocracy.
The hardware it runs on has capacitors as its components and some of them do in fact contain electrolytes.
It's got tabs instead of spaces. Yuck!
All of the known bugs will be gone.
Somebody needs a promo packet. Duh
[dead]
Because Rust is better than C. /s
But AI written code is legacy from day one. Since by definition nobody knows or understands what it does.
yes and no, because you now keep using AI and AI doesn't care if it has seen the code or not before and you just keep fixing bugs / adding features without really understanding the code.
it's weird new reality, but if it works it works I guess. I'm still waiting on the first vibe-coded mass used prod app, not ware of any yet.
What is the bus factor for AI generated code ?
Cisco that powers more than half of the backbone of all things online? Are we trying to lose control of AGI as soon as it emerges??
When this rewrite breaks the internet AGI won't be able to take over. It's very forward-thinking.
Well they say the last 20% of the work takes 80% of the time so if he gets the prototype in 4 weeks, which I have no doubt he will be able to do, and assuming that prototype is the first 80% of work, then he should be able to do this in 20 weeks. He even has some margin! Looking forward to seeing the results
Misleading title, someone should fix it. 98% of legacy code. Check out the full title of the article.
Does Cisco have non-legacy code?
My favorite description of JAVA is that it's a language where you are deploying instant legacy code.
"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...
/r/whatcouldgowrong
I guess Cisco decided it has not alienated its customers enough till now & its finally time to get people running for the woods - at least if those peoples would like their network to continue working.
If only internet users could run for the woods
> I see some of the best ideas coming from the younger generation that have not yet been in the job market.
The views of these business leaders betray their own lack of vision, they are barking up the wrong tree.
The ability to think differently is not the preserve of the young. Instead of only hiring a bunch of greenhorns they should identify and cultivate people who are idea generators and flexible thinkers, of any age group, starting inside their own organization.
If you, as a business leader, are not stimulating a culture of innovation and instead maintain the status quo of traditional hierarchical roles where managers become gatekeepers of ideas, and everyone is protecting their own little domains, then you are the problem. Shit organizations will quickly turn original-thinking young people into corporate drones.
Organizations spend a lot of time destroying the creative ideas their employees have; burying it in red tape, crushing it in meetings.
If i was an ex founder and having a low profile in a big company, I am doing it on purpose, either to have a peaceful life or heal from a burnout, definitely I don’t want to be on the spot like that, especially when I am not innovating anything new nor I will take any meaningful credit after since it will mostly go to AI, worse, if it didn’t work out I will have my career ruined being known to had an unlimited supply of tokens and still failed.
They need to cut cost & to figure out productivity per engineer. They're doing this b/c they are going to significantly cut their engineer workforce.
The article text and tone sounds like an April Fool's article published sooner than it should have.
Just since it wasn't clear to me.
Jeetu Patel is the CEO of Cisco, Paddy is actually Padmanabhan Krishnamurthy, a 27yo student/fonder.
https://www.padmanabhankrishnamurthy.com/
Jeetu is not the CEO, he is the Chief Product Officer. Cisco's CEO is Chuck Robbins.
For me the next step is parallel businesses - that is capture the realm Im and out traffic of your company, probably easier for some than others, and then run different code bases against the same traffic, how much can be simplified, which code bases are easier to understand etc
Shocking to realize how many on HN do not realize that this is NOT a tall order, and has not been a feat for at least six months.
Amusing to realize how many on HN are actually unfamiliar with working on anything outside of the scope of an app.
Shocking how many on HN do not realize how devastating this can be
i.e. they burn a fraction of the cost it would otherwise take and it may end up as a discarded dud?
yeah, i think they'll survive whatever the outcome
Discarded based upon what? They probably think they don't need much human review.
I'm worried for us users of the internet rather than them.
Maybe Stanford found some more of their stolen code being used by Cisco. /s Cisco origins is a fascinating subject.
Most successful companies and innovative ideas come from middle aged founders and inventors. Silicon Valley loves the romantic notion of a contrarian young adult or even teenager "seeing what nobody else sees" , but they are the exception and not the rule.
I mean, this is going to be easy. I've worked on Cisco gear before and this will be a simple job for AI. The big question is what the goal is... so you've rewritten new C++ code or ported to a newer version of Linux? Or you've unified the codebase of the Catalyst + Meraki switches?
Not clear to me what he's doing. Re-implement switching? Simplify features? Reduce LoC? Add test coverage? Either way, AI in that world will be helpful. I'm sure it'll spot all kinds of problems in opaque drivers that are hard to follow from MF specs.
The goal is to use AI, full stop
Cisco is losing to competitors in some features/products, for example to juniper mist.
rewrite can be done to quickly refactor and/or close the feature parity, improve the UI/UX for end customer, add missing features or integration needs
What are they losing on? A little bit shocking, the featureset on these types of systems is incredibly boring.
You need a skilled person to make it success. Someone who has already made his hand dirty with the legacy code for years should be the right person for it.
Anybody have an estimate of how much that is going to cost in token cost?
Never thought I'd say this, but, "thank god I use unifi".
ha ha .. that sounds like an Onion article. To be fair - if they did a narrow refactor to focus on fixing only obvious and known issues, they probably might be able to pull it off because a ton of that code is hairballs.
Is this like a PR piece for the guy? It's odd to see him singled out in a piece that would be normally be about the company, the CEO or the decision itself.
Seems like preparing who to blame if/once the effort fails. ;-)
It does sound strange, like it was written by PR people. Tools are good but usually it is more subtle than asking one guy to rewrite everything. And of course any code written yesterday is legacy but it does not mean it should be rewritten.
Like it was written by PR people's AI.
C’mon it’s inspirational. Low level struggling Indian tech recognized by high level Indian CEO and lifted up.
Paddy Krishnamurthy is a YC alumnus whose startup was explicitly vetted and funded by the very institution running this forum. Claiming his rise is a case of 'ethnic nepotism' means you only respect YC’s elite vetting process when the founder doesn't happen to be brown.
So there's a real risk that Cisco might become history in just a few years. Taking that kind of risk with a rather unproven technology has to be psychosis. Or is that kind of belief a form of Religion?
Many customers will definitely stick with the pre-sloppified versions of IOS.
Clear case of AI psychosis.
I wonder if this will involve any Chez Scheme code. Sometimes I think Scheme would be a great language for AI to write code with.
I left Cisco fairly recently and was relatively close to Paddy in the org chart (same group). Interesting to see this come up here.
I doubt AI is gonna make or break this kind of project. It's the weird institutional knowledge that underpins a lot of these legacy code bases.
rewriting code is the easy part
it's the testing in real world usage to shake out all the edge cases and bugs that's hard and that you can't just write unit tests for
I think we can all agree that the task as set forth in the PR puff piece is impossible. That said however, current AI tools are amazing for cleaning up and reanimating old codebases. I've been using Claude on a very large Java protocol proxy product and it's been able to do amazingly useful things for me. I originally wrote much of the code but Claude now knows much more about it than I do today, because people forget stuff over decades. It will sometimes remind me "as you noted in November 2016 this feature was designed to...", based on its analysis of the code and git commit messages.
Don't they have no other AI news to share
If it isn't broken then break it!
https://archive.li/exFjo
luckiest kid on the planet omg i would have so much fun doing this
I need a hero! I'm holding out for a hero till the end of the month...
Anthropic training data unrecoverably got tainted, need to retrain.
> That changed when Patel dropped into Cisco’s San Francisco office, and the pair got talking. Krishnamurthy reckoned he could rewrite Cisco’s legacy code with a two-person team. Patel says even the most AI-forward people on his own team weren’t thinking that way.
LOL. All 27 year-olds looking at a heap of legacy code think they can easily rewrite it better. It's never as easy as it seems on the surface.
True but also there has never been a better time for total rewrites of legacy code. One could even hope it's the time COBOL finally goes out of fashion in some industries.
Alternatively, there has never been a worse time because why bother? The model knows every language and can maintain legacy code just fine (indeed, knowing this stuff and being capable of maintenance is a prerequisite to a successful rewrite), so COBOL and JCL and random mainframe stuff is just not an issue, and a rewrite is highly likely to not be exactly the same in some important way.
On the other hand, models a few years from now will be smarter and more likely to have a track record of success with this task, so being one of the first to do it makes no sense even it had advantages.
So there's no urgency to rewrite; it's all risk with little to no reward for a problem that will probably be much easier to solve if you defer it a little longer. Like, first at least get to 100% AI automatic development for all new products/services, and then for all maintenance, so you know that it actually works.
This is the dumbest fucking headline I've read in awhile. Does Cisco not have smart employees already doing this?
From unlimited AI tokens to massive layout and beyond !
This feels like Cisco paid for the article
What's so special about the other 2%, is it good?
Shit, if broadcom did this to their codebase the world would be a better place. Their stuff is crap, and it's everywhere. It's unclear if they even use source control. Our guys spent ridiculous amounts of time backporting our submitted fixes into their releases.
"According to a report by Fortune" - here's that report: https://fortune.com/2026/10/30/cisco-president-jeetu-patel-g...
Fortune's source was the CEO himself:
> “I’ve given him unlimited tokens because he’s going to refactor code,” Patel told Fortune at a small roundtable dinner. “So I’m like, you can go, you can go nuts.”
I think that Fortune story is better than the Tom's Hardware one. It ties the Cisco anecdote into a larger trend of some people deliberately hiring younger, less experienced developers for their AI projects - because they are more likely to be "AI native".
Yes, I’m sure the Indian man at Cisco acquired a translation company founded by another Indian man because he’s young and AI native, not for any other reason.
Not the CEO. He’s the product officer.
more like AI naive
Sadly, I think the label "AI naïve" is better applied to the many experienced professionals who refuse to engage with AI systems as a matter of principle - or who tried out ChatGPT in 2024, saw it make howlingly obvious errors, and wrote off the entire category.
I frequently find myself in conversations with people who are resistant to AI and turn out to have a very skewed idea of what it can and cannot do.
> or who tried out ChatGPT in 2024, saw it make howlingly obvious errors, and wrote off the entire category.
Or they were reading your comments and articles and couldn't reproduce any of the fantastic results that you were claiming, even back then. Things have indeed changed since the first Opus release about a year ago and LLMs are good at programming now. But still, experienced professionals are not so keen to sign off 1000s of lines of code that they never read, take responsibility for it etc. Also, it is a different job and it will take some time to adjust. Can you blame them?
Moreover, other trades have their own guilds or are otherwise protected through regulation. Can you blame programmers for fighting to keep doing things as they were doing it until recently?
Given that I've shared almost every prompt I've used since I started publishing about this stuff over four years ago I think I've given people a better chance of replicating my results than pretty much anyone else writing about this space.
What did you have trouble replicating?
> Also, it is a different job and it will take some time to adjust. Can you blame them?
Not in the slightest. This stuff is really hard. The changes it makes to our production are disruptive and, in many cases, unwelcome.
Literally anyone can do this
Such a risky idea to let one person rewrite the whole legacy. I mean there's a chance that this guy thinks about maintenance and how all his creations will me supported when he's done, but something tells me that he just want to show that he can do it and the rest of the tech team will be suffering. Good luck to that guy anyway
What a mess of an article. Hard to read. Chasing the jabs and the stabs for clicks.
Oh great a guy doing the unlimited needful. Won’t end well for Cisco.
its never unlimited....
This decision is about so many things except the code that it deserves some kind of award.
Demonstrates fanatical devotion to capital’s golden idol - “yes, all of the code; yes, unlimited budget”. Doesn’t actually cost the company anything - only one engineer off task, any nuggets of value can be harvested as it progresses but any costs or big changes can be deferred until completion of the impossibly large open-ended mandate (ie never), one guy won’t have the personal bandwidth to spend so much that the “unlimited” part actually matters, and in case of emergency it only costs six months severance to make it all go away. It even rescues a fellow national from the ignominy of being employed so far below his previous station, there’s so much to like about it. Hmm? The code? What about it?
> one guy won’t have the personal bandwidth to spend so much that the “unlimited” part actually matters
I see you haven’t met my coworkers and their fanatical use of parallel “workflows”
> one guy won’t have the personal bandwidth to spend so much that the “unlimited” part actually matters,
Tell me you don’t use agents effectively without telling me you don’t use agents effectively.
Please explain your work flow!
You set the agents against themselves and burn tokens like there's no tomorrow.
The feeling of coding like that is a bit like realizing that an elevator is 10cm of aluminum and a 100 meters of empty space under your feet.
After the first few bouts of existential dread you get uses to it.
I write a spec by speaking, not much thought given to grammar and sentence structure. I over-describe concepts, over-describe functionality. A lot of repetition of details and concepts. The audience is not a human. Whisper converts it to text.
Lightly manually edit for speech rec failures.
LLM takes that and converts it into a much much denser, much more structured technical spec in markdown. This is issue 1 in the repo.
I edit this directly extensively, adding detail, removing misconceptions, adding sections with more dictated text.
LLM takes this and further densifies it, closer to an actual implementor’s spec. I carefully note what got added, removed, edited in this step.
I edit this carefully and extensively again. Some removals get added back, some additions get removed. This is the first commit and closes issue 1.
I then have an LLM write an implementation plan and basic project scaffolding. Makefiles, smoke tests, logging, test framework, DI. I edit the plan, and the plan is the second commit. An LLM uses both plus scaffolding plus my repo policy documents (global) to write a README. We’re still single threaded.
An agent files the first n top level implementation tickets. These refer to and sometimes quote any interface contracts in the spec or implementation plan. These usually map 1-to-1 to a module/directory. These sometimes have stub commits to create the module directory and commit interface definitions. Some larger modules have a README in their module directory if their purpose or structure or inputs or outputs are complicated or non-obvious.
Parallel agents write commit level issues that are the task items for each top level implementation ticket. One agent per module.
Then, spawn parallel agents with detailed global instructions, the full spec+plan, and the full readme, and the full code from the module it is working in, plus the issue text. Its output is a single commit on the feature branch and a PR that closes out one feature ticket.
This spawns an adversarial reviewer which has detailed agent instructions as well as our code style guides and repo policies. The scaffolding includes tests and linting and checks. Any failures spawn rework agents until the feature branch is up to snuff.
I review the feature branch diff and merge it, having read the review and rework comments on the PR. I frequently add comments about the implementation (“don’t do x, do y”) and add WIP: back to loop it back for more rework. I don’t see anything that isn’t green, formatted, passes linting, passes tests, and a (dumb) bot thinks is ready to land. Most of the time, it is. Sometimes, it did it the wrong way and I correct it.
The more modular the code, the easier it is to parallelize (obviously). It is ridiculously easy to build large software quickly now, provided it is sufficiently modular so the implementation doesn’t have to cross modules very much. The detailed spec and implementation plan up front helps a lot with this. It’s a lot like writing multithreaded programs really.
Any bugs discovered are tackled with strict TDD, one commit with a failing test, one bugfix commit that must be green and not touch the test.
Individual modules must conform to good contracts, meet best OOP practices, and fit into context. Too big and they get broken down further. Context size is actually a useful constraint for code structure here.
This workflow, the code standards, the styleguide, the linter settings, the fmt settings (obviously only applicable to non-Go as the Go fmt is not configurable), everything is global and stored in another repo and is vendored into each AI managed project repo. It has a fair bit of “I shouldn’t have to say this, but…” stuff (in the style of “fire codes are written in blood” - each warning sign came from experience).
My results are quite good. It’s as the saying goes, much like managing a team of junior devs. It is easy to end up with a LOT of parallel implementors, reviewers, reworkers, and tons of CI, but it’s still so much vastly cheaper than humans that it doesn’t matter.
Someone will make a LOT of money wringing out the inefficiencies from this workflow, because I think the “agent as replacement for third-world contracted junior dev” model is the one almost everyone is using right now.
Anyone else thinking that tech and porn lingo is converging?
Claude make the Cisco ACI webui load in less than 10 minutes, make no mistakes
[flagged]
Am I the only one reading the headline as "Cisco committed their source code to public domain"?
...and thereby making new legacy code.
"At most companies, only someone with decades of experience under their belt would be trusted with a project this size. Patel thinks that’s a problem.
“If you don’t hire the early-in-career [workers], and you just let your workforce continue the way that they were, where do fresh ideas get injected? How do you challenge the status quo?” he said."
-------------------
This would be an interesting approach for a bleeding edge startup that's betting big on producing something novel or going bankrupt. If you're going to bet the company on one guy and some AI, that's bold. He'd better have some serious chops and not be merely a slick salesman.
However, Cisco is an infrastructure company. Status quo is what most people want from an infrastructure company. You don't want your Cisco stuff to suddenly start doing new, innovative things that require a complete redux of everything built on top of it. This, of course, assumes that having one guy do a refactor of your entire code-base produces something "innovative" rather than a cavalcade of snafu's.
It's probably not the best time to be holding CSCO.
First LLM PTSD case coming soon. You heard it here first, folks.
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[dead]
[flagged]
[dead]
I suspect we are approaching a world where this makes sense to do annually. Opus 5.5 is good enough to improve on most codebases, and Opus 7 will no doubt be good enough to improve on that.
Current models are amazing but production code incorporates unknowable information through decades of diagnosis and bug fixing (and sometimes the opposite: working around bugs in other software that it talks to). Put even the most amazing coder that was ever born onto improving a complex old codebase, and you can guarantee they are going to break stuff. AI is better but not infinitely better.
People keep repeating this but on my experience is also very good at finding kirks of specific compiler versions.
I think it is a reasonable risk to encounter these bugs again in order to get a more clean and documented codebase. Especially when asking AI to plan and A/B release is also trivial.
'98% of the company's legacy code' is very vague. How many code bases? How each code base is connected to any supported Cisco product? How many KLOC the company's legacy code?
These are good questions that we won’t get answers to anytime soon.
I’d love to know what internal services and tools that are included in this, as well as any deliverables that shipped as software products to customers.
If it’s legacy code for IOS firmware, however, I’d be very worried.
It's all about process. If you have a good process in mind, you can build a system that can reliably do everything.Artificial intelligence is now the engine to do that. With the correct harnessing, you can do anything now
A lot of the commenters here are still living in early 2026. Late 2026 AI can absolutely demolish this kind of job. It can clone photoshop! You think this is going to be harder than that?
It can clone photoshop.. Have you considered why?
The ability to clean room Adobe products came at about the same time Claude's RE abilities suddenly improved.. Hmm lets think about this a little more.
Anthropic sucked the bones dry of the public domain, literature and all of opensource. It seems likely that Anthropic RL'd Claude into being a great reverse engineer because it needed more training data.
I believe that Anthropic turned Claude into a digital software shredder and started decomping proprietary code, like adobes.
So the reason Claude can suddenly clean room Photoshop isnt because it became a more capable programmer, but rather, the Adobe code is literally in its training data now.
Ciscos internal legacy code is not going to be in Claude's data (yet).
The decision to increase Claudes ability to RE is brilliant, because now everyone is doing the source code decomp for them, and sending them fresh data from previously closed source repositories of code.
Your comment is nothing but supposition
So is any other hypothesis about why Claude can RE now... You just want to default to some worldview where AI isn't being gamed for certain outcomes, and is some evolving intelligent thing.
Thanks for the very thought provoking reply tho!!!!!!!!!!!
I have zero doubt it could do it, if the prompter could competently explain the requirements. I have no reason to believe that this single engineer has any idea what problems most of the existing legacy code needs to solve or why it solves them that way...
It can create a UI that looks like Photoshop where half the features are broken and the other half are literally not even connected to anything, just copying menu options with no implementation to fool gullible people like you*
lol