agree with @infabo - It's not needed.
And there is CoreBit – Network topology & monitoring tool inspired by “The Dude”, that I'd have to guess was built with some assistance of AI, and seem to have good reviews from forum. Whatever anyone think of AI, it very good at generating web pages and SQL, or reverse-engineering stuff too. So don't let the fact /interface/bridge is also a mystery to LLMs fool you in what they can do ;). CoreBit opted to "standard" monitoring things, thus the "inspired" by
Well, at least my AI (with instructions, prompting, access GPL code, previous code I wrote, etc) has a good handle /console/inspect, /app, and CHR upside-and-down, see my tikoci.github.io which I cleaned up with CoPilot/Claude with some effort on my part for sure, but trust me the robots worked hard (e.g. hours on QEMU "guest tools" on X86, /app editor, OpenAPI3, and cleaning up webpages, etc.). Now I have a background in software engineering, so I know what I want pretty specifically and fill in gaps in RouterOS like is someone in "Beginner Basics" here, so that helps.
But we have not had the clunkers take a look at the Dude yet. It's on the list. I want to unwind the Dude SQLite database, since I've long wanted to extract information, and likely from getting to bottom of the SQLite schema used by The Dude, it have a good sense of the protocol.
Now, AFAIK, The Dude uses same winbox protocol, just with different "TLV IDs"... This would be a bit more work and more effort. Especially to get right, since it likely figure out the basic protocol (and likely already in training for NSA/other leaks/security reports/etc long ago). The problem is it's a packed binary protocols using IDs for everything, which is very efficient, but the mapping of those IDs packed in structures to path/commands/attributes, likely be much more work. And The Dude fits in the "winbox" protocol, some how. See Open-Source Python Reimplementation of WinBox Terminal Access who has implementation of "terminal-over-winbox" so I suspect The Dude is just different set if some TLV ID in winbox that have to be map (for dude likely a bunch more than opening the terminal which does not attribute mapping)
And that is the key question here... If by "retired", they mean the Win32 dude.exe app only... then I'd imagine that some AI could re-create the Dude (without the source, only screenshots, and direction if you really wanted a Win64 version of it, or something web-based...) - over the course of many hours, many tokens, and good prompting.
But if "retired" means the dude.npk you install... that's a different story since there really be no dude. Nothing to reverse engineer then. Since I think it's Dude data model and architecture are excellent, and give works by only package install, not local hardware needed...it fills an important need (e.g. I have a lot of LTE devices, so some local dude that just collects the signal other data from a set of LTE devices at a site, is just so simple - no container, no X86, one package install). And the dude.npk and efficiency of winbox protocol that still has legs...it's packed binary so less on wire than SNMP or even native API.
The Win32 client can go away IMO... but the core architecture embodied in the how The Dude works is hard to replicate. In fact, it more sophisticated in some way than many people think since it even has some notion of hierarchical dude server, that the Win32 API did not really help with, and I still not sure how to use... but allow rolling up data in UI without a central database.
The Dude abides. Maybe?