From Vibe to Context: Do We Still Need the Spec?

As of: October 2026. Anyone working today with Claude Code, Copilot, Cursor, or similar tools knows the tension: On one hand, the models have become so powerful that a rough task assignment often carries surprisingly far. On the other hand, you quickly notice in real projects that good results rarely come from just a good one-liner. This is exactly where the line runs from Vibe Coding to Context Engineering. The pointed thesis of this article is therefore: Yes, strict prompt specifications are becoming less important in some situations. But the effort does not disappear – it shifts from formulating individual prompts to designing the project context.

Vibe Coding: Concept, Promise, Early Practice

The term “vibe coding” goes back to Andrej Karpathy. In his much-cited X post from February 2, 2025, he described a style where you “almost forget the code,” request changes in everyday language, simply throw errors back into the model, and often even hit “Accept All” without thoroughly reading diffs. This was not a precise methodology, but rather a deliberately pointed description of a new practice: type less, say more, iterate quickly, trust the model.

The appeal is obvious. For greenfield ideas, throwaway prototypes, UI sketches, or small helper tools, this approach can be very productive. Anyone building a form, a small script, or a simple service on a common stack benefits from the fact that models already know many common patterns from training. In such situations, Vibe Coding is not just laziness, but a form of leverage: less friction between idea and first working result.

But even in Karpathy’s original text, the warning is included. He explicitly writes about “throwaway weekend projects” and about how the code can grow beyond its usual depth of understanding. That is exactly where the risks begin: vague requirements, blind acceptance of changes, hard-to-detect security issues, and technical debt that only becomes visible later. Independent studies from 2025 and 2026 support exactly this skepticism: LLM-generated code can appear functional and still contain security or quality issues that easily slip through without additional review.

The Shift: Why the Loose Prompt Became a Context Craft

That the term Context Engineering subsequently established itself is no coincidence. Anthropic describes Context Engineering as the evolution of Prompt Engineering: Not only the words in the prompt count, but the entire set of tokens and signals the model sees in a situation – system instructions, tools, external data, message history, MCP context, and other states. The focus thus shifts from “How do I formulate the request?” to “What information should the model see at which moment at all?”

The reason for this lies in the way today’s coding and agent tools work. Modern agents no longer operate in a single turn, but in loops with tools, intermediate states, and follow-up decisions. The potentially relevant context grows constantly. It is then not enough to overwhelm a model with as much text as possible. You have to select, structure, and reload at the right time.

That is precisely why project files like CLAUDE.md or AGENTS.md, stored memory entries, skills, and subagents have become so important. Anthropic openly documents that CLAUDE.md files load permanent project rules, architecture notes, and working conventions into every session, while Auto Memory makes corrections and patterns available across sessions. Subagents, in turn, are explicitly used to process subtasks in their own context window so that the main conversation does not get clogged with trivialities. This is exactly the opposite of “one big prompt solves everything.”

Context Engineering therefore does not primarily mean longer prompts. It means better context architecture. Which project rules always apply? Which information does only a specialist agent need? What is stored permanently, what is loaded just in time? And what must the human explicitly specify because the model cannot possibly know it from training?

The Thesis Put to the Test

Now to the actual thesis: “Today’s models are so good that tight context specifications are often no longer necessary. Often a few sentences describing the project are enough.”

The fair finding is: That is sometimes true. And that is exactly what makes the thesis so attractive.

It holds especially where tasks are close to common patterns. In a fresh project with a standard stack, well-known libraries, and a manageable target, models can supplement surprisingly much. A rough assignment like “build a small FastAPI service with JWT login, PostgreSQL, and tests” often already delivers a surprisingly usable starting point today. For small features, prototypes, or internal tools, the gap between a brief instruction and a working draft has become significantly smaller. This is not because context is unimportant, but because part of the context is already embedded in the model: framework conventions, standard project structures, common test patterns, familiar API forms.

But the thesis breaks down where the decisive factor is not in general training knowledge. Large, evolved codebases contain local truths: internal shortcuts, historical architecture decisions, team conventions, special cases in deployment, implicit security assumptions, legacy interfaces, and maintainability rules. This knowledge is precisely not guessable for the model. Anyone starting here with only two sentences gets not “less specification,” but more often hallucinations with a professional tone.

Added to this is a second breaking point: Quality and security are not automatically derivable from high model capability. A quantitative analysis from 2025 concludes that functional correctness is not a reliable indicator of code quality and security; precisely for this reason, static analyses and additional verification are necessary. Another study on agentic program repair on SWE-bench shows that agentic workflows can also create new vulnerabilities – especially when more autonomy is allowed and context about the issue and codebase is incomplete. In short: Better models reduce some friction, but they do not eliminate the costs of missing context information.

A Small Experiment for Everyday Use

Anyone who wants to test the thesis themselves does not need a large research environment. A small team experiment is enough. Take an identical task in a real but non-critical codebase – for example: “Add a new filter option in the search dialog, including tests and documentation.” Have the model work once with only a brief short description. In the second run, give it structured context: relevant files, architecture note, acceptance criteria, project rules, test command, and two typical pitfalls.

Compare not only “works” or “doesn’t work,” but also: number of follow-up questions, number of subsequent corrections, quality of tests, adherence to conventions, readability of changes, and review effort. My expectation would be: For small, generic tasks, the difference is smaller than in 2024. But as soon as project knowledge, constraints, and non-obvious standards become important, the structured context should perform more robustly.

Where the Boundary Lies

The boundary thus runs less between “old” and “new” models than between task types. Vibe-like approaches work well where the model can plausibly fill in missing details from known patterns. They become risky where missing details are domain-specific, architectural, or security-relevant.

It becomes particularly critical in four situations. First, in large legacy projects: Here, local knowledge is more important than general framework knowledge. Second, with implicit team rules: If naming, error handling, or release practices are not made explicit, the model optimizes for plausibility, not for your reality. Third, with security and maintainability requirements: Studies show that AI-generated code can still exhibit systematic weaknesses. Fourth, in longer agentic chains: The more loops, tools, and intermediate steps involved, the more important good context management becomes instead of mere hope in model intelligence.

Conclusion and Recommendation

So does the specification effort disappear? No. It shifts. Some prompt tricks from the early phase become less important: artificially inflated role prose, rigid formulation recipes, and over-optimized one-shot prompts. What becomes more important, on the other hand, are the things the model cannot derive from world knowledge: acceptance criteria, project rules, architecture boundaries, decision logs, relevant files, test and security requirements.

My concrete recommendation is therefore: Use short prompts where the problem is generic. But invest deliberately in reusable project context as soon as the same rules apply multiple times. Write CLAUDE.md or AGENTS.md, keep acceptance criteria brief and explicit, use memory for recurring corrections, and separate research, implementation, and review more strongly via specialized agents or subagents. The future lies not in the choice between Vibe Coding and specification. It lies in knowing when a few sentences are enough – and when missing context will later cost more than any clean specification at the start.

Sources

🌐 Machine-translated from the German original, editorially reviewed. 🤖 Written with AI assistance.