Sometimes old code comes with its own problems that are not the code but the ecosystem they depend on or run in.
E.g. some critical security vulnerability that is not backported to the library/compiler/runtime you are using in production, or you can't get spare parts for your servers any more so need to upgrade to something newer but you can't run your old OS version on new hardware so you have to upgrade the OS too and now it's dropped support for foo etc etc. Lots of things pile up.
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.
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 ;-)
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
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.
> 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.
Surely we have more code than programmers for every language in existence?
Except for the part where the concept isn't even well-defined, this sounds like a complaint that the world contains more bricks than bricklayers. Of course it does.
Sometimes old code comes with its own problems that are not the code but the ecosystem they depend on or run in.
E.g. some critical security vulnerability that is not backported to the library/compiler/runtime you are using in production, or you can't get spare parts for your servers any more so need to upgrade to something newer but you can't run your old OS version on new hardware so you have to upgrade the OS too and now it's dropped support for foo etc etc. Lots of things pile up.
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.
If nobody knows how the old code works, how will anyone know how the new code (written by an autonomous agent) works?
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.
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 ;-)
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
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...
Why is that better than having the agent(s) write regression tests or explanations of the old codebase?
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.
> 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.
Surely we have more code than programmers for every language in existence?
Except for the part where the concept isn't even well-defined, this sounds like a complaint that the world contains more bricks than bricklayers. Of course it does.
I don't think no one knows how it works. I just think the people using the word "legacy" for it are boneheaded.