In 2023, the most valuable artifact at a lot of AI companies was a text file. Not the model — that was rented from OpenAI or Anthropic. Not the codebase — that was a thin wrapper around an HTTP client. The actual product, the thing the founders guarded and the engineers iterated on for hours every day, was the system prompt.
This is easy to forget now that it sounds absurd. But for roughly eighteen months, “prompt engineer” was a real job title with real salaries, and entire startups treated a 4,000-word block of instructions as their core IP. There were prompt marketplaces. There were leaked system prompts that produced news cycles. The phrase “$200k for typing” floated around as a joke, but the joke landed because it wasn’t entirely wrong.
What was actually happening was that the prompt had collapsed into the role normally played by application code. In a traditional system you have a database, business logic, an API surface, validation, error handling, and a UI. In a prompt-era AI product you had: a model, and one giant string. Everything else — the persona, the rules, the format constraints, the safety guards, the few-shot examples, the routing logic — was crammed into that string. The prompt was the architecture.
The prompt was the architecture.
Why it briefly made sense
You can see why it felt that way. Models had just become capable enough that natural language could substitute for code in a lot of places. “Don’t answer questions about competitors” worked surprisingly well. “Format your response as JSON” worked, sort of. “If the user seems frustrated, escalate” worked when it felt like it.
Each of these would normally be a few hundred lines of dispatch logic in a regular product. Instead, it was a bullet point. The economics looked incredible.
The pattern was also legible to non-engineers, which mattered. A product manager could read the prompt, suggest a change, and ship it before lunch. There was no compile step, no migration, no PR review of a state machine. Founders loved this because it meant they could prototype faster than their engineering team could plan. The prompt was a kind of universal solvent — anything you wanted the product to do, you could try to express in instructions.
One global namespace, no module boundaries
But the architecture had a fatal property: it was monolithic. Every behavior lived in the same string. Adding a new rule meant editing a document where every other rule was also written. Rules collided silently. The “be concise” line at the top fought with the “explain your reasoning” line in the middle. The few-shot examples implicitly taught patterns the explicit instructions tried to forbid.
And because there were no module boundaries, you couldn’t reason about parts of the prompt in isolation. The whole thing was one big global namespace.
The other problem was that the prompt was load-bearing in places nobody had documented. Teams would discover, after a model upgrade or an A/B test, that some apparently innocuous phrase (“You are a helpful assistant”) was actually doing structural work — keeping the model from veering off into other personas, or anchoring response length, or suppressing a failure mode nobody had a name for. Remove it and things broke in ways that took weeks to diagnose. This is not how software is supposed to behave.
Folk magic in place of a discipline
What people called “prompt engineering” was really a form of folk magic that worked because the underlying system was opaque. Move this line up. Add the word “carefully.” Use ALL CAPS for the constraint that matters. Wrap the instructions in XML tags. Some of these worked because of real tokenization and attention dynamics; many worked because of superstition that happened to correlate with a model update. The discipline never quite stabilized because it didn’t have ground to stand on.
It also didn’t scale across products. A prompt that worked beautifully for a customer support bot would behave bizarrely when applied to a legal research assistant. You couldn’t compose prompts the way you compose libraries — paste two together and you got something neither author would have written. The lack of composability meant every product rebuilt the same primitives from scratch, badly, and shipped them inside their monolithic string.
The era ended when the tasks got harder
The era ended not because anyone declared it over, but because the tasks got harder. As soon as you wanted an AI to do something across multiple steps — browse a site, modify a codebase, place an order — the prompt couldn’t hold the state. You needed memory between turns, tools that returned structured results, control flow that branched on actual data. The prompt as application architecture started looking like CGI scripts as application architecture had looked twenty-five years earlier: a useful artifact for its moment, but not a foundation you’d want to build a real system on.
What replaced it wasn’t a better prompt. It was a different idea about where intelligence should live. The prompt era ended when people stopped trying to put the whole product into the model’s mouth and started building the world the model would operate inside. That shift is the rest of this series.