I don't think there's a name for it yet, you'll have to coin one. There's a related thing they do like this:
- The user tells the agent to add feature X
- The agent adds the feature
- User: "Yeah that's good but I don't think we need Y that you added, get rid of it"
- The agent removes Y, adds comments that Y was removed, adds backwards-compatibility for saves which used Y (obviously there aren't any, since Y only existed for 5 minutes and was never deployed - the project itself might never have been deployed either), adds a test for Y's non-existence, adds text to the UI saying "Note: Y has been removed. There are no traces of Y in the project"
You missed the part where context compacts, it realizes Y is missing and reimplements it from scratch and proudly boasts that it did the exact opposite of what you had asked
I'm with you in not wanting to see these types of comments in my code. I aim for each revision of the code to stand on its own, and not reference its past or future. There are exceptions and nuances, of course, such as TODO comments or comments related to ongoing migrations. I try to keep these short and reference tasks in the issue tracker, which are going to be more useful to anyone who happens to be reading the code.
I've heard the argument that leaving these comments in, helps support future AI code generation. In this example, it was important to you at the time you made the change that create_* functions have defaults, so having this in the code captures that knowledge for later agents. It's similar to a more general argument that you should leave (correct) AI-generated code alone because it will be easier for the AI to "understand" code it generated that your modified version of it.
I see the validity in these arguments, but I don't think we should be so deferential to these models. The first part of this comment ("Now create_background params have default values") is completely redundant with the function signature and as no place in the code. The second part ("the same as create_screen") is genuine knowledge that is worth capturing for the agent, but it should be captured at a higher level doc about the codebase, rather than tacked onto some arbitrary function as a comment.
Ironically I used AI for this question, and what came out is 'Echo prompt' apparently it's a thing: repeating LLM instructions twice increases accuracy.
Another idea was Chain of Thought leakage. It's like as if a chef saying "Now I am adding salt because the customer requested so"
I'm not sure if you're worried that the comment leaks what you prompted, or that the comment is redundant and evident, and makes it obvious that it wasn't written by a human, and for both these issues the solution is just to proof-read your damn code
The context is if you ask for something like “X that looks awesome” it’ll then describe itself as looking awesome throughout your product in customer facing fashion ways.
Instead of “title” it’ll become “the awesome title”
I don't think there's a name for it yet, you'll have to coin one. There's a related thing they do like this:
- The user tells the agent to add feature X
- The agent adds the feature
- User: "Yeah that's good but I don't think we need Y that you added, get rid of it"
- The agent removes Y, adds comments that Y was removed, adds backwards-compatibility for saves which used Y (obviously there aren't any, since Y only existed for 5 minutes and was never deployed - the project itself might never have been deployed either), adds a test for Y's non-existence, adds text to the UI saying "Note: Y has been removed. There are no traces of Y in the project"
I think that GPT-5.5 does it the most.
You missed the part where context compacts, it realizes Y is missing and reimplements it from scratch and proudly boasts that it did the exact opposite of what you had asked
I'm with you in not wanting to see these types of comments in my code. I aim for each revision of the code to stand on its own, and not reference its past or future. There are exceptions and nuances, of course, such as TODO comments or comments related to ongoing migrations. I try to keep these short and reference tasks in the issue tracker, which are going to be more useful to anyone who happens to be reading the code.
I've heard the argument that leaving these comments in, helps support future AI code generation. In this example, it was important to you at the time you made the change that create_* functions have defaults, so having this in the code captures that knowledge for later agents. It's similar to a more general argument that you should leave (correct) AI-generated code alone because it will be easier for the AI to "understand" code it generated that your modified version of it.
I see the validity in these arguments, but I don't think we should be so deferential to these models. The first part of this comment ("Now create_background params have default values") is completely redundant with the function signature and as no place in the code. The second part ("the same as create_screen") is genuine knowledge that is worth capturing for the agent, but it should be captured at a higher level doc about the codebase, rather than tacked onto some arbitrary function as a comment.
Ironically I used AI for this question, and what came out is 'Echo prompt' apparently it's a thing: repeating LLM instructions twice increases accuracy.
Another idea was Chain of Thought leakage. It's like as if a chef saying "Now I am adding salt because the customer requested so"
I would call those reasoning comments or reasoning artifacts. They’re supposed to be internal comments and they ended up in the code.
I'm not sure if you're worried that the comment leaks what you prompted, or that the comment is redundant and evident, and makes it obvious that it wasn't written by a human, and for both these issues the solution is just to proof-read your damn code
The context is if you ask for something like “X that looks awesome” it’ll then describe itself as looking awesome throughout your product in customer facing fashion ways.
Instead of “title” it’ll become “the awesome title”
Crude but cromulent example.
Internal messaging/thinking?