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.
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.
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.
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.
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?
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.
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
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.
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.
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?
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.
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.
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.
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.
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 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.
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’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".
'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?
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.
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 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.
Otherwise he's just going to replicate all the legacy bugs and questionable design decisions.
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 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.
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?
-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.
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.
I wonder whether AI is any good at looking at that code,running the system, and documenting those edge cases?
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.
This whole thing sounds like a deluded vanity project birthed in an ivory tower.
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.
What have been achieved using this port?
And how did you make sure the port is correct?
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".
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.
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