What a mess of an article. Hard to read. Chasing the jabs and the stabs for clicks.
paxy 3 hours ago [-]
Having to rewrite decades worth of legacy Cisco code is going to make Claude retire and start a goose farm.
Fuzzwah 55 minutes ago [-]
> 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 :-)
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.
pdimitar 55 minutes ago [-]
First LLM PTSD case coming soon. You heard it here first, folks.
williadc 13 hours ago [-]
There's no goal mentioned in this article as why 98% of the code needs rewriting.
schainks 12 minutes ago [-]
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.
jmspring 10 minutes ago [-]
Cisco iOS even on terminal servers in the early 2000s was...special.
HarHarVeryFunny 13 hours ago [-]
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?
jimmaswell 3 hours ago [-]
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.
amelius 2 hours ago [-]
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.
solyin 1 hours ago [-]
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.
Bayart 48 minutes ago [-]
What would be the Python megacorps of choice ? Trading firms ? Not a regular pythoner (pythonist ? pythonian ?) myself.
heylook 19 minutes ago [-]
I hope everyone that reads this can understand why it's a ridiculous argument.
80fj0348i 2 hours ago [-]
In my experience it's been much simpler to rewrite programs from Python to <insert lower level language of choice here>
InsidiousWombat 1 hours ago [-]
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.
stavros 2 hours ago [-]
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.
habitue 2 hours ago [-]
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
what 21 minutes ago [-]
> we have a ton of high profile examples
Such as?
literalAardvark 2 hours ago [-]
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.
beardbandit 31 minutes ago [-]
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.
ravishi 1 hours ago [-]
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.
phil21 3 hours ago [-]
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.
anyonecancode 2 hours ago [-]
> 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.
curt15 2 hours ago [-]
Does the coding assistant demonstrate any tricks to improve the likelihood of success for such rewrites?
InsideOutSanta 4 hours ago [-]
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!
nitwit005 4 hours ago [-]
No goal, and no results, but a younger guy was enthused about AI!
dboreham 44 minutes ago [-]
Plus: publicity!
entrope 4 hours ago [-]
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.
oceansky 4 hours ago [-]
It is not in Rust.
add-sub-mul-div 13 hours ago [-]
AI has electrolytes!
analognoise 12 hours ago [-]
It’s what the shareholders crave!
yako21000 12 hours ago [-]
They also seem to crave everything that has the word AI in it.
daveguy 4 hours ago [-]
These are references to an excellent, hilarious, and sadly more relevant than ever, movie:
Movie? I prefer to think of it as a documentary made in advance.
classified 13 hours ago [-]
The hardware it runs on has capacitors as its components and some of them do in fact contain electrolytes.
Hikikomori 4 hours ago [-]
It's what Cisco does, as they've done several times before.
DonHopkins 4 hours ago [-]
It's got tabs instead of spaces. Yuck!
vonneumannstan 12 hours ago [-]
Somebody needs a promo packet. Duh
aaron695 4 hours ago [-]
[dead]
piker 13 hours ago [-]
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.
m4rtink 12 hours ago [-]
Seems like preparing who to blame if/once the effort fails. ;-)
WindyTree 19 minutes ago [-]
C’mon it’s inspirational. Low level struggling Indian tech recognized by high level Indian CEO and lifted up.
koskokos 12 hours ago [-]
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.
dboreham 44 minutes ago [-]
Like it was written by PR people's AI.
balderdash 12 hours ago [-]
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.
cheney_2004 10 minutes ago [-]
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?
petra 12 hours ago [-]
That's really interesting.
What have been achieved using this port?
And how did you make sure the port is correct?
bill10 38 minutes ago [-]
Don't they have no other AI news to share
Taikonerd 12 hours ago [-]
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."
InsidiousWombat 1 hours ago [-]
I chose to interpret it as "our codebase is that bad we need a hero"
g-b-r 6 hours ago [-]
Both Indians, and Indians on average seem to have gone more heavily on careless AI than the worst American psychotics
eudamoniac 3 hours ago [-]
Indians have always been stereotyped for sycophancy and slavish adherance to spec over common sense, so it makes sense that that would go with being AI pilled.
g-b-r 3 hours ago [-]
I don't want to sound racist (which I'm not), but in my experience Indian software developers have often been less careful and concerned about quality than the average developer; it probably comes from many only becoming so for the job prospects, and not having much computer experience before college.
So it's not surprising if they embrace AI.
There's also that Indian cheaper outsourcing companies risk being displaced by AI, if they don't adopt it extensively to further reduce their pricing.
yako21000 3 hours ago [-]
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.
solyin 49 minutes ago [-]
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".
brcmthrowaway 1 hours ago [-]
They are stastically more likely to post the most slop projects per hour.
DonHopkins 4 hours ago [-]
Maybe his blood boy's high on gourmet cannabis and Oreos.
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.
tw04 4 hours ago [-]
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.
literalAardvark 1 hours ago [-]
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.
Aperocky 12 hours ago [-]
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.
icedchai 12 hours ago [-]
It's sad to hear how Cisco has fallen. I remember working on some early ISP networks in the 90's. Cisco was everywhere!
hnlmorg 4 hours ago [-]
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.
bluGill 3 hours ago [-]
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.
bigfatkitten 2 hours ago [-]
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.
benjojo12 12 hours ago [-]
Just because something is/was widely deployed does not mean it was good
runjake 10 hours ago [-]
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.
ThePinion 4 hours ago [-]
I was curious but wasn't going to ask, so thank you for adding it!
icedchai 12 hours ago [-]
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.
bombcar 2 hours ago [-]
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.
icedchai 42 seconds ago [-]
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.
smackeyacky 27 minutes ago [-]
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
kotaKat 10 hours ago [-]
They didn't even need the AI to make thousands of hot bricks nationwide. Here's just one of the latest hits...
"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 :)
gonight 1 hours ago [-]
Never thought I'd say this, but, "thank god I use unifi".
pianopatrick 1 hours ago [-]
Anybody have an estimate of how much that is going to cost in token cost?
Aperocky 12 hours ago [-]
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.
bombcar 1 hours ago [-]
Better than 750k tests is millions of customers! They’ll test it for you!
Taikonerd 13 hours ago [-]
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?
I have no doubts that there will also be new bugs.
koskokos 12 hours ago [-]
the premise does sound a lot like written by someone who is looking for hype and not sounding credible
sleepyguy 12 hours ago [-]
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?
forgotpwd16 4 hours ago [-]
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.
bombcar 1 hours ago [-]
His job isn’t to rewrite all the code. His job is to make the market satisfied that Cisco is “more AI” than competitors.
oblio 12 hours ago [-]
The entire story sounds very weird.
greenavocado 5 hours ago [-]
They met each other by chance and began work rewriting the entire company's codebase over a firm handshake
sleepyguy 3 hours ago [-]
You forgot to mention the translation company he helped found was also acquired by this same CEO. :))
alwa 13 hours ago [-]
Rewrite it in service of… what exactly?
rustyhancock 13 hours ago [-]
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.
rafram 13 hours ago [-]
If nobody knows how the old code works, how will anyone know how the new code (written by an autonomous agent) works?
rustyhancock 13 hours ago [-]
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.
mlmonkey 6 hours ago [-]
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 ;-)
paimapi 11 hours ago [-]
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
Why is that better than having the agent(s) write regression tests or explanations of the old codebase?
jiggawatts 3 hours ago [-]
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.
13 hours ago [-]
LoganDark 12 hours ago [-]
I don't think no one knows how it works. I just think the people using the word "legacy" for it are boneheaded.
emoII 12 hours ago [-]
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
dmortin 13 hours ago [-]
Misleading title, someone should fix it. 98% of legacy code. Check out the full title of the article.
loloquwowndueo 12 hours ago [-]
Does Cisco have non-legacy code?
hangrybear666 12 hours ago [-]
My favorite description of JAVA is that it's a language where you are deploying instant legacy code.
DonHopkins 4 hours ago [-]
"Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back
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.
m4rtink 12 hours ago [-]
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.
g-b-r 6 hours ago [-]
If only internet users could run for the woods
petra 12 hours ago [-]
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.
mkjs 12 hours ago [-]
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.
dboreham 40 minutes ago [-]
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.
petra 12 hours ago [-]
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?
mkjs 11 hours ago [-]
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.
dboreham 38 minutes ago [-]
It's good, but it can't create information that is undiscoverable.
InsidiousWombat 1 hours ago [-]
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
Cyph0n 12 hours ago [-]
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.
eudamoniac 3 hours ago [-]
That describes everything Jeetu is involved in. I'm very glad to have recently left Cisco.
wil421 12 hours ago [-]
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.
InsidiousWombat 1 hours ago [-]
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
pphysch 12 hours ago [-]
The first and last bullets are extremely optimistic. How do you possibly simulate all the weird interdependent behavior in real world networks?
petra 12 hours ago [-]
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 ?
Cyph0n 12 hours ago [-]
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.
bijowo1676 4 hours ago [-]
there is software to simulate any arbitrarily complex network: GNS3, eve-ng, Cisco Modeling labs, etc
pphysch 3 hours ago [-]
I'm talking about heterogenous legacy hardware that isn't owned by Cisco, not complex topologies.
bijowo1676 49 minutes ago [-]
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
dfedbeef 2 hours ago [-]
Literally anyone can do this
cheevly 11 hours ago [-]
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.
g-b-r 6 hours ago [-]
Shocking how many on HN do not realize how devastating this can be
1970-01-01 12 hours ago [-]
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??
masfuerte 12 hours ago [-]
When this rewrite breaks the internet AGI won't be able to take over. It's very forward-thinking.
mr_roboto 12 hours ago [-]
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.
Ancalagon 11 hours ago [-]
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.
mr_roboto 10 hours ago [-]
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.
greenchair 4 hours ago [-]
and if you enable dangerously_skip_permissions you can probably even get to 1000x
snov 4 hours ago [-]
What's so special about the other 2%, is it good?
bluegatty 12 hours ago [-]
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.
measurablefunc 3 hours ago [-]
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.
> “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".
blazarquasar 1 hours ago [-]
Not the CEO. He’s the product officer.
rasz 12 hours ago [-]
more like AI naive
simonw 11 hours ago [-]
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.
tamimio 2 hours ago [-]
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.
jeffybefffy519 4 hours ago [-]
its never unlimited....
blobbers 12 hours ago [-]
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.
bijowo1676 4 hours ago [-]
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
g-b-r 6 hours ago [-]
The goal is to use AI, full stop
3 hours ago [-]
rasz 12 hours ago [-]
Maybe Stanford found some more of their stolen code being used by Cisco. /s Cisco origins is a fascinating subject.
classified 13 hours ago [-]
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?
wmf 5 hours ago [-]
Many customers will definitely stick with the pre-sloppified versions of IOS.
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
dboreham 32 minutes ago [-]
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.
spkm 2 hours ago [-]
[dead]
pupppet 12 hours ago [-]
[dead]
causal 12 hours ago [-]
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.
dboreham 29 minutes ago [-]
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.
raincom 12 hours ago [-]
'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?
orthogonal_cube 3 hours ago [-]
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.
Rendered at 03:43:53 GMT+0000 (Coordinated Universal Time) with Vercel.
https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fv...
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.
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 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.
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.
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.
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
Such as?
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.
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.
And AI is really good at all the stages here.
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.
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.
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.
Idiocracy (2006): https://en.wikipedia.org/wiki/Idiocracy
What have been achieved using this port?
And how did you make sure the port is correct?
So it's not surprising if they embrace AI.
There's also that Indian cheaper outsourcing companies risk being displaced by AI, if they don't adopt it extensively to further reduce their pricing.
https://www.youtube.com/watch?v=hBA0AH-LSbo
Being a mess isn't a problem when you have more than 6 items context.
If history has taught us anything. It’s that the measure of a successful product is usually more to do with its sales people.
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.
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.
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
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 :)
Otherwise he's just going to replicate all the legacy bugs and questionable design decisions.
Right? ...
[1] https://github.com/enterprisequalitycoding/fizzbuzzenterpris...
Anyone who has used the built in date picker knows why everyone rolls their own.
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.
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 ;-)
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...
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.
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...
-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.
But yes, fact it uses a bunch of very well documented standards with multiple implementations gonna help massively
This whole thing sounds like a deluded vanity project birthed in an ivory tower.
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
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.
if any hardware does not confirm to specs, thats on them and its actually a reason to pull out and replace legacy hw
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.
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".
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.
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.
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
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’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.