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 | parent | next [-]

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 | parent | next [-]

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 \| parent \| next [-]
		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 \| parent \| prev \| next [-]
		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...
	▲	rafram 13 hours ago \| parent \| prev [-]
		Why is that better than having the agent(s) write regression tests or explanations of the old codebase?

▲

jiggawatts 3 hours ago | parent | prev | next [-]

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 | parent | prev [-]

[deleted]

▲

LoganDark 13 hours ago | parent | prev [-]

I don't think no one knows how it works. I just think the people using the word "legacy" for it are boneheaded.