# Why LLM debugging fails on fragmented repository context > Source: > Published: 2026-05-25 15:54:21+00:00 After spending a lot of time debugging large repositories with ChatGPT/Claude, I kept noticing the same failure pattern: the model was not necessarily "bad at coding" — it was operating on a broken map of the repository. Typical workflow looks something like: At that point the model starts interpolating architecture that may not actually exist. A lot of “hallucinated code” is really just missing repository state. That was the motivation behind building `grab` . `grab` is a small terminal-native workflow tool for iterative repository context extraction. The workflow becomes: ``` search → extract → accumulate → recurse ``` Instead of repeatedly starting over with disconnected snippets, repository context is accumulated incrementally across extraction passes. Example: ``` grab --tree grab auth grab --functions server.py grab 500 635 auth.cs ``` Function indexing ended up being especially useful because it exposes exact extraction coordinates: ``` file:start-end ``` That allows the model to recursively request additional implementation context explicitly instead of guessing hidden code paths. The accumulated context is continuously copied into the active clipboard/tmux buffer, which makes iterative debugging surprisingly fast in practice. The tool is intentionally simple right now: But I think the underlying problem is larger than simple snippet retrieval. Once repository context becomes fragmented, the model loses architectural continuity and starts constructing plausible-but-invented relationships between components. I’ve started thinking about this more as: rather than “prompt engineering.” There’s a short demo in the README showing the workflow in practice.