[CSDN Editor's Note] As generative AI gradually integrates into the software development process, more and more AI-generated code is appearing in practical engineering - but have you ever thought that this code written by AI might be considered "legacy code" from the very beginning? Based on engineering experience and combined with AI's generation mechanism, the author of this article proposes a thought-provoking viewpoint: AI-generated code lacks contextual memory and maintenance continuity, thus it is in a state of "other people's old work" from the moment it is born. This is not only a calm observation of the current AI coding capabilities but also provides a new perspective for us to understand the future form of software development.
Original Link: https://text-incubation.com/AI+code+is+legacy+code+from+day+one
Translation | Zheng Liyuan
Produced by | CSDN (ID: CSDNnews)
In software development, the "improvability" of code often depends on the stage of its lifecycle. Generally, it can be divided into the following categories:
When a piece of code is something you just wrote: "Oh, yes, it can be changed that way, it shouldn't be difficult."
When a piece of code is something someone else just wrote: "Maybe they wrote it this way due to some recent temporary circumstances. If there's a real need, I can consider making adjustments."
When a piece of code is something you wrote before: "Hmm, I should have written it that way back then. If necessary, I'll prioritize it after I finish my current tasks."
When a piece of code is something someone else wrote before: "Why did they write it this way? But there's probably no need to touch it, let's wait until something goes wrong."
Overall, the speed of code evolution usually depends on how recently it was written and whether the maintainer is the original author.
In fact, this state is reasonable: for a stable and proven software system, rashly making "improvements" often brings additional risks, especially when you are not very familiar with the overall context of the system. The original author usually knows the potential logic and development background best.
AI Generated Code, What Stage Is It In?
So from another perspective, what stage is AI-generated code specifically in? In my opinion, it has several key characteristics:
(1) Even if AI has a context window, it is "stateless". This means that AI can infer why a piece of code is written in a certain way, but it cannot truly "know" the author's specific intention at the time, nor does it have the real-time memory that human maintainers have.
(2) Every time AI generates code, it is actually "written by someone else". AI is like a newcomer reading your code for the first time, building an understanding of the context from scratch. It won't really "remember" how the original input was transformed into a certain output through some "circuit".
(3) AI-generated code is already "old" from birth. It skips the "new code" stage and directly enters the "other people's old code" mode - it has no temporal "freshness" and no bonus from continuous maintenance by the original author. This kind of code can be considered "legacy code" from the start.
Of course, skilled AI developers are also trying to solve this problem. For example, by using carefully crafted prompts, designing reasonable context windows, detailed comments, and other means to compensate for AI's lack of state memory. But overall, these approaches are more like following inertia and slowly optimizing in one direction.
However, my personal guess is - perhaps this isn't a big problem at all, because code itself is a kind of "static state". As prompting engineering and context window capabilities improve, code will be increasingly "prompt-generated" rather than long-term maintained. In the future, the amount of code in "complex software" may be less, and more logic will rely on model reasoning and prompting rather than static structure.
In this context, AI-prompted generated code is more like a short-term/medium-term "transition bridge".
Some Highly Rated Comments Worth Savoring
After I organized the above points into an article and published it, it sparked a heated discussion on Hacker News. Here are a few highly-rated comments that I think are worth savoring:
(1) @dang: The beginning of the article can actually be traced back to Peter Naur's classic 1985 paper, "Programming as Theory Building". As a side note, Naur was one of the key figures in the ALGOL language and BNF syntax.
Naur's point is that complex software systems are essentially "theories" built in the collective minds of developers. Source code and documentation are just a lossy representation of this theory - because you can never fully recreate the entire thought process behind building the system using only code and comments.
In this sense, legacy code refers to: although you still keep the code and documentation as "artifacts", the "theory" supporting them has been lost with the departure of the original author. This means that you no longer have the authority to make "deep improvements" to the system, and can only do patching and maintenance.
So, what does this thinking mean for the era of Large Language Models (LLM)?
When LLMs generate code, do they inherently lack the "theory behind the program"? This is not a settled question, and there might be several possibilities:
When LLM generates code, it might already implicitly contain some kind of "theory", we just haven't understood it yet;
Maybe LLM can gradually build this theory from existing code, or will be able to in the future;
Perhaps LLM doesn't need the kind of "theory" that human engineering teams do;
If the code is generated by AI, then perhaps AI is the only entity that possesses the theory, and it's no longer human;
Or perhaps this "theory" is actually held by the person writing the prompt, rather than the person writing the code.
(2) @mrweasel: My boss and I often "defend" ourselves to new young colleagues by saying: "That's how we wrote it back then" - in most cases, this is just a way to cover up poorly written code interfaces, and "back then" might just mean two weeks ago.
But sometimes we are indeed correct. Some strange ways of writing code are for adapting to extreme boundary scenarios, or for integrating with some old systems - they were products of that era. Fortunately, we are still in the team, so we can judge which code can be deleted, or at least try to delete it.
I think that if LLM-assisted programming can record the Prompt and save it with the generated code, it might be better at managing technical debt than humans. For example:
If you know that a piece of code was generated by a Prompt like this - "Ensure boundary cases are handled when the client is running AIX 6", this can answer many questions. Although you still don't know who was using AIX back then, you at least know why this code exists and can judge whether it can still be deleted.
(3) @TZubiri: In the original text it was mentioned, "Even if AI has a context window, it is 'stateless'. That is to say, AI can infer why a piece of code is written in a certain way, but it cannot truly 'know' the author's specific intention at the time, nor does it have the real-time memory that human maintainers have."