Prompt engineering didn’t fail because of any single dramatic incident. It failed the way old codebases fail: slowly, then all at once, and mostly through accumulated weight nobody had budgeted for.
Walk into the prompt repository of any AI product that survived from 2023 into 2024 and you’ll find the same archeology. There’s a foundational block at the top defining the persona — the “you are a helpful X” — usually phrased with the kind of solemn formality you’d reserve for swearing in a witness. Below that, somewhere in the middle, are the rules. There are always rules. They were added in patches, each one in response to a specific incident, and each is phrased as if the model is a slightly slow child who needs to be told that no, you cannot recommend competitor products, no, not even if asked nicely. Toward the bottom, hidden among the few-shot examples, are the load-bearing pieces nobody documented because they got it working at 11pm and then everyone went home.
This artifact has all the failure modes of a long-lived monolith and none of the tools we’d normally use to refactor one.
Five ways the monolith breaks
The first failure mode is instruction collision. By the time a system prompt is 8,000 tokens long, it contains rules that contradict each other. “Be concise” sits in tension with “explain your reasoning step by step.” “Always cite sources” fights with “respond conversationally.” “Never speculate” loses every Tuesday to the few-shot example that demonstrates a polite hedge.
The model resolves these collisions opaquely, by some internal weighing nobody can audit. When the output looks wrong, you have no way to know which instruction “won” or why. You add a louder instruction on top, and now you have three rules in tension instead of two.
The second is hidden coupling. In normal software, when two parts of a system depend on each other, you can see it. The import statement, the function call, the schema reference — coupling has a citation. In a prompt, coupling is invisible. The phrasing in section 3 affects how the model interprets section 7. Changing the order of the few-shot examples changes the way the persona is read. Removing the word “carefully” from one place makes the format constraints in another place stop working. There’s no compiler that warns you. There’s no test that catches it. You discover it weeks later, in production, when something downstream notices.
The third is context bloat. Every rule you add is a token you spend on every request. Every example you include sits in the model’s context whether or not it’s relevant to this particular call. As products grew, prompts grew, and as prompts grew, you started spending real money to keep the model busy paying attention to instructions it would never need for the question it had just been asked. The model that could in principle answer your user’s question in 200 tokens was instead having to first wade through 9,000 tokens of unrelated policy. This is not free, in any sense.
It’s also worse than free, because of the fourth failure mode: lost-in-the-middle effects. Models don’t attend uniformly across long contexts. Instructions at the start and end get more weight than instructions in the middle. As your prompt grew, more and more of your rules got buried in the part of the context the model paid least attention to. You’d look at the prompt and see your rule clearly stated; the model would behave as if the rule didn’t exist. The natural response — moving important rules to the top — only worked once. After ten people had each moved their critical rule to the top, the top was just another middle.
The fifth failure mode is version brittleness. Every prompt was implicitly tuned to the quirks of a specific model version. A prompt that worked beautifully on GPT-4-0314 would behave differently on GPT-4-0613, sometimes subtly, sometimes catastrophically. Anthropic’s Claude family had its own evolution. Each model upgrade was a regression hunt. Teams developed elaborate eval suites just to figure out which of their carefully crafted phrases the new model had decided to interpret differently. The prompt was supposed to be a stable interface; it turned out to be a stack of micro-dependencies on model behavior, and the underlying ground was always moving.
The prompt was carrying the whole application
You can see, looking at all five together, that the problem isn’t really prompts. The problem is that the prompt was being asked to carry the entire weight of the application. We were treating instructions as if they were code, and they have none of the affordances that make code maintainable: no modules, no types, no isolation, no static analysis, no compiler errors, no useful tests. Just a long string and a hope.
The problem is that the prompt was being asked to carry the entire weight of the application.
The wall is the moment the marginal returns hit zero
What people called “the wall” was the moment when the marginal benefit of a longer, more carefully tuned prompt dropped to zero or below. You’d spend a week refining a constraint, ship it, watch three other things break, and realize you weren’t getting anywhere. The system had become path-dependent on its own history. The only honest move was to stop trying to fix it inside the prompt.
The fix is architectural, not editorial
The fix turned out to be architectural, not editorial. You don’t write a better prompt; you stop pretending the prompt is the application. You move the rules into a runtime, the behaviors into skills, the examples into retrievable artifacts, and the policy into a permission system. The prompt shrinks back to what it was originally good for: a small amount of framing, kept tight on purpose. The intelligence moves into the environment. That inversion is the subject of the next post, and it’s the moment the field stopped sweating over wording and started designing systems.