A fun anecdote, and I assume it's tongue in cheek, although you never know these days, but is the LLM guaranteed to give you back an uncorrupted version of the file? A lossy version control system seems to me to be only marginally better than having no VCS at all.
I frequently (basically every conversation) have issues with Claude getting confused about which version of the file it should be building on. Usually what causes it is asking it do something, then manually editing the file to remove or change something myself and giving it back, telling it it should build on top of what I just gave it. It usually takes three or four tries before it will actually use what I just gave it, and from then on it keeps randomly trying to reintroduce what I deleted.
Your changes aren’t being introduced to its context, that’s why.
The models definitely can get confused if they have multiple copies in their history though, regardless of whether your latest changes are in.
I'd say it's more likely guaranteed to give you back a corrupted version of the file.
I assume OP was lucky because the initial file seems like it was at the very start of the context window, but if it had been at the end it would have returned a completely hallucinated mess.
From experience, no. I’ve customized my agent instructions to explicitly forbid operations that involve one-shot rewriting code for exactly this reason. It will typically make subtle changes, some of which have had introduced logic errors or regressions.
I dont know where Gemini stores the context, but if I’m using a local LLM client app, that context is on my machine verbatim.
If you ask the LLM to give you back that context does it give back to you verbatim?
statistically, maybe.
Stochastically correct is the best sort of correct?
When I used toolcalls with uuids in the name, tiny models like quantized qwen3-0.6B would occasionally get some digits in the UUID wrong. Rarely, but often enough to notice even without automation. Larger models are much better, but give them enough text and they also make mistakes transcribing it
Well, it'll give you what the tokenizer generated. This is often close enough for working software, but not exact. I notice it when asking claude for the line number of the code with specific implementation. It'll often be off by a few because of the way it tokenizes white space.
Thanks. I noticed the same thing about line numbers but I didn’t know the reason. It has made me double check I’m in the right file more than once.