{"slug": "the-codebase-is-the-prompt", "title": "The Codebase Is the Prompt", "summary": "A developer using Fable 5 found that the quality of AI-generated code depends heavily on the codebase it works with, not just the prompt. In personal projects with clean code, Fable 5 solved complex problems effectively, but at work with a messy codebase, results were inconsistent. The developer concludes that the codebase itself acts as the prompt, conditioning the model's output.", "body_md": "The database analogy is usually wrong when people use it to explain AI.\n\nA language model is not a database full of facts, documents, or answers. When you ask it a question, it is not looking up a record and returning the matching row. There is no table called “JavaScript bugs” or “how to design an API” hidden inside the model.\n\nBut the analogy is not useless. It is just usually applied at the wrong level.\n\nThe prompt is not a key that retrieves a stored answer. It is more like a fuzzy query into a compressed space of learned patterns. The model does not fetch the answer. It reconstructs a plausible continuation from the patterns that the prompt makes relevant.\n\nThis matters because **people often mentally separate the prompt from the data**.\n\n“My instruction is the prompt. The codebase is the material the model works on.”\n\nBut the model has no such separation.\n\nIn a codebase task, the codebase is the prompt.\n\nThe surrounding code conditions the output just as much as the typed request does. The naming, the architecture, the hidden assumptions, the tests, the missing tests, the file layout, the comments, the abstractions, and the inconsistencies all become part of the query.\n\nThis became obvious to me after using Fable 5.\n\nI was blown away. I blasted through two Claude Code subscriptions, one personal and one from work, and upgraded to the Max plan almost entirely because of Fable. I had personal projects lying dormant for years, not because I did not care about them, but because I could not find the time and energy to get back into the complexity they required. I had tried earlier models every now and then, asking them to add features or move these projects forward, and every time they failed hard.\n\nWith Fable 5, that changed.\n\nIt solved multiple problems that I had personally sat with for hours without success. More importantly, it solved them in a way I could understand. It did not just dump code on me. It helped me see the shape of the solution. For a while, it felt almost godlike. I was in heaven. The only thing keeping me from going completely crazy from lack of sleep were the token limits.\n\nSo I expanded the experiment. I used it on more personal projects, including multi-year-old projects I had not touched because of time constraints, life, and having small kids. Again, the same thing happened. Old projects started moving. Problems that had felt too expensive to re-enter suddenly became solvable.\n\nBut at work, I could not get the same fable boost.\n\nAt first, the obvious explanation was process. Maybe I was not committing to the tool in the same way. Maybe strict acceptance criteria, guardrails, review requirements, and company constraints prevented the same flow.\n\nThen came the ban.\n\nThat pause gave me time to review what had actually happened. I looked back at code Fable had written for me. I also reviewed code from other developers that had been generated with Fable. The picture became more complicated.\n\nSometimes Fable had produced excellent code. Sometimes it had solved genuinely difficult problems. But sometimes it had produced bad code with obvious issues.\n\nEventually, something clicked.\n\nThe quality of the output was closely linked to the quality of the codebase it was working with.\n\nThat sounds obvious. But the solution is not obvious.\n\nThe simple reflex is to say: if the model performs worse in a bad codebase, give it more good code. Give it best practices. Give it clean examples. Give it architecture guidelines. Add counterweights to the prompt so the messy codebase does not dominate the answer.\n\nBut this does not help as much as one would hope.\n\nThe reason is that good code is local.\n\nIn a good codebase, encapsulation and clear interfaces let you understand a function from its signature and a small neighborhood around it. You do not need to read the entire system to safely change one piece. The relevant information is close by. The code compresses well because the same patterns repeat. The model can see the local shape and infer the missing parts.\n\nBad code is non-local.\n\nA function depends on hidden global state. Behavior changes because of something in a distant file. A method only works if someone remembered to call `init()`\n\nfirst. A harmless-looking change breaks an unrelated feature because the real dependency is implicit. The important information is not near the code being changed.\n\nThis is where LLMs struggle.\n\nThe information the model needs to be correct may simply not be in its context window. Worse, neither the user nor the model necessarily knows which distant code is the relevant context to supply. So the model reasons from what it can see, fills the gaps with priors, and produces something confident and wrong.\n\nThis is why “just add best practices” often fails.\n\nBest practices are not neutral. They also become part of the query. If you give the model a messy codebase and then add a clean example, you may think you are saying: “Fix this bad code using this good principle.”\n\nBut the prompt is saying: “Continue with this pattern.”\n\nThose are different tasks.\n\nThe model can get pulled away from the actual problem. It may produce code that looks better in isolation but does not fit the hidden constraints of the system. It may follow the best practice while missing the reason the code became ugly in the first place.\n\nA bad codebase is therefore not merely a hard query against a good prompt.\n\nIt is a bad prompt.\n\nYou are handing the model a worse input and asking for a better output than the input supports.\n\nThis closes the loop back to compression. The very property that makes code bad for humans — irregularity, inconsistency, special cases, high entropy — is the same property that makes it hard for a predictive model to work with. Good code compresses well because it is regular. A language model is, at bottom, a compressor of regularities. So regular code is its home turf, and irregular code is where it is weakest.\n\nThe thing that frustrates the human and the thing that defeats the model are one thing.\n\nThat is also why in-context learning is often misunderstood. The model is not learning your codebase in the way a developer does. It is not building a durable mental model. It is being temporarily conditioned by whatever fits into the prompt. If the relevant invariants are missing, implicit, or spread across the system, the model cannot reliably infer them just because you gave it more text.\n\nAnd this also explains context rot.\n\nContext rot is not merely what happens when the context window gets long. It is what happens when the query decays. Old assumptions, abandoned solutions, stale files, half-correct explanations, and irrelevant examples remain in the conversation. The model keeps trying to satisfy all of them because, from its perspective, they are still part of the prompt.\n\nThe practical conclusion is not that LLMs are useless on bad codebases.\n\nIt is that **the fix is usually not a cleverer prompt.**\n\nThe fix is to supply the non-local context the model cannot see, and to shrink the task until locality holds again. Instead of asking the model to fix the system, ask it to inspect one boundary. Instead of asking it to refactor a tangled module, first ask it to identify the hidden invariants. Instead of giving it generic best practices, give it the specific constraints that make this codebase weird.\n\nThe people who get real value from LLMs on bad codebases are often the people who already understand the code well enough to compress the chaos for the model.\n\nThe model rewards whoever can make the **query** sharp.", "url": "https://wpnews.pro/news/the-codebase-is-the-prompt", "canonical_source": "https://dev.to/timon_krebs_c89f82a68ba4c/the-codebase-is-the-prompt-2llh", "published_at": "2026-06-27 23:52:13+00:00", "updated_at": "2026-06-28 00:03:25.945211+00:00", "lang": "en", "topics": ["large-language-models", "generative-ai", "developer-tools"], "entities": ["Fable 5", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/the-codebase-is-the-prompt", "markdown": "https://wpnews.pro/news/the-codebase-is-the-prompt.md", "text": "https://wpnews.pro/news/the-codebase-is-the-prompt.txt", "jsonld": "https://wpnews.pro/news/the-codebase-is-the-prompt.jsonld"}}