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