When LLM conversation memory accidentally becomes static analysis

I read this post about accidentally turning LLM memory into program analysis and it is the kind of accidental discovery that makes you rethink tooling. The author was not trying to build a linter. They fed a small codebase into an LLM’s context window so it could answer questions about the code. Standard workflow. Then they asked a vague question about a function and the model pointed out a logic error the author had missed. Not a syntax error. A subtle branch condition that could fail under specific input. The interesting bit is this was not prompt engineering. No chain-of-thought. No “analyse this code for bugs”. The model simply had enough code in memory that when asked to explain behaviour, it spotted the inconsistency while constructing its answer. This is closer to how I actually debug than how static analysis tools work. I load the code into working memory, trace execution mentally, and catch mistakes when explaining the logic to someone else. Rubber duck debugging, except the duck talks back and sometimes notices the off-by-one before you do. The practical limits are obvious. Context windows are finite. The model hallucinates confident nonsense about edge cases it did not actually trace. It misses entire classes of errors that formal verification would catch. But for the narrow band of bugs that show up when you describe code behaviour to another human, this accidental method works surprisingly well. I have been treating LLM context as a scratchpad for temporary facts. This flips it: load the whole system, ask clarifying questions, let the model’s internal reasoning surface bugs as a side effect of explanation. Not a replacement for tests or type checkers. A different debugging modality that happens to overlap with how I think through code already.

---

Source: I accidentally turned LLM memory into program analysis