this post was submitted on 30 Oct 2026
419 points (98.8% liked)
Technology
89286 readers
4666 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Just to get that straight: Legacy code is practically always large code with countless hidden requirements, and with insufficient or no tests and without documentation. But which works somehow. Any change needs to meet numerous unwritten requirements, and it can often only be tested in the real world. If you have N features, you have N*(N-1)/2 interactions between two features, so it is quadratic growth with N. This is why it is very hard and time-consuming to change.
It shouldn't be that way, but writing large software - especially in commercial environments - is often like climbing a high roof on a ladder, and then throwing away that ladder. Modifications are only incremental, and usually not documented. Incremental modifications are one of the only two working engineering approaches for software we know - and the only one used for commercial software.
The other way - which is used in aviation for example - is to specify, document, and test everything, right from the start.
Now the problem is you can rewrite legacy stuff as much as you like, but it is near impossible to make sure that large changes work. Because in order to do that, you would need to run the tests that do not exist, or create tests from specifications and requirements which do not exist either.
And GenAI tools are not going to change that. The agentic tools kinda work by filling in missing requirements with assumptions and average observed stuff. It can generate reams of code, fast. But while this kinda works for a small phone app, it doesn't for large complex stuff. If the code does not fit in the head of one person working for months on it, it will never fit in the context window of an LLM.
I've always thought that reverse engineering should have a counterpart. Reverse specification.
Or taking a working system and figuring out what it was designed to do and how. Then writing tests to that so that real world testing is not mandatory.
This is horrendously difficult, since I've never knew anyone achieving a successful codebase rewrite.
Another issue also is differentiating between hidden requirenments, undocumented features (positive), bugs (negative) and developer choice made during coding of the legacy software which does not affect the program positively or negatively.
A LLM (or alternatively a tem of developers) could do a reasonable well job of repuducing all these features and behaviors in a new program. But at that point you have effectively just cross-compiled your code (and maybe refactored it a bit).
The real issue is in identifying essential and wanted features from all the features, even if you could magically extract all of them. And in most cases that requires a deep understanding of the target audience/customer, which I would argue no person (including the customer), let alone a LLM, just has without years of requirenment refinement.
Forgot to add that is usually wrote in languages with little documentation and limited user cases online to learn or compare on.