Context Engineering vs Vibe Coding: What Changes in Practice

Vibe coding means prompting an AI, accepting what it writes without reading it, and judging only whether the result seems to work. Context engineering means deciding what the model sees at each step: the instructions, the files, the tools, the history. They answer different questions. Vibe coding is about how much of the output you check; context engineering is about how carefully you shape the input. In practice, moving a project from the first to the second changes six habits: where your instructions live, how a task is worded, how errors are reported, how work is checked, how long a session runs, and where decisions are written down.

Vibe coding, as it was coined

Andrej Karpathy named it in a post on X↗ (opens in a new tab) on 2 February 2025: “a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He described accepting every change without reading the diffs, pasting error messages back with no comment, and letting the code grow beyond his usual comprehension. He was also clear about the scope: not too bad for throwaway weekend projects.

A year on, he drew the line himself. In his summary of a Sequoia Ascent 2026 talk↗ (opens in a new tab) he writes that vibe coding raises the floor, letting almost anyone create software by describing it, while what he calls agentic engineering raises the ceiling: coordinating fallible agents while preserving correctness, security, taste and maintainability. Vibe coding, in his words, is fine for prototypes and personal tools. How the term spread and drifted is covered in what is vibe coding.

Context engineering, as defined

Anthropic’s engineering team defines context engineering as the set of strategies for curating and maintaining the optimal set of tokens↗ (opens in a new tab) during inference, including everything that lands in the window besides the prompt: system instructions, tools, external data and message history. Their guiding principle is to find the smallest possible set of high-signal tokens that makes the outcome you want likely, because models get worse as the window fills, which they call context rot.

That is a discipline about input. The techniques themselves, retrieval on demand, compaction, notes, subagents, are in context engineering for AI agents, and how it differs from writing a good prompt is in context engineering vs prompt engineering. This post is about the change in how you work.

Two axes, not two ends of one

Because one term is about output and the other about input, they combine rather than compete:

• No context, no review: pure vibe coding. Fast, and fine for something you will throw away.
• Good context, light review: a prototype built in a repository with a short rules file and a test command. Still quick, and far fewer surprises.
• No context, heavy review: you read every diff and correct the same mistake every session, because nothing you taught the agent survives the chat.
• Good context, real review: what Karpathy calls agentic engineering. The agent gets what it needs, and you check what it did.

The third corner is the one people fall into when they stop vibe coding: they start reviewing but never write anything down, so the review never gets shorter. Context engineering is what makes the review shrink over time.

What changes in practice

1. Instructions move from the chat to a file. Anything you have typed twice goes into CLAUDE.md, AGENTS.md or your tool’s rules file, kept short. Anthropic’s Claude Code best practices↗ (opens in a new tab) give a test for each line: would removing it cause mistakes? If not, cut it.
2. Tasks name the place and the check. “Add tests for the parser” becomes “write a test for the date parser covering an empty string and a leap day; run the tests after”. The agent can infer intent; it cannot guess your constraints.
3. Errors come with a symptom and a target. Pasting a stack trace with no comment is the vibe coding move. Say what you saw, where you think the cause is, and what fixed looks like, and ask for the root cause rather than a suppressed error.
4. The agent gets a check it can run. Tests, a build, a screenshot to compare. Without one, the agent stops when the work looks done, and you are the only test.
5. Sessions end on purpose. One long chat carries every failed attempt into the next request. Clear the context between unrelated tasks, and after two failed corrections on the same problem, start a fresh session with a better first message.
6. Decisions are written where the next session will find them. A choice made in chat is gone when the chat is. A file, a task or a decision record is not.

# Vibe coding
the export is broken, fix it

# With context
CSV export drops rows with a comma in the name (see issue #212).
The writer is in src/export/csv.ts; follow the quoting in src/export/tsv.ts.
Write a failing test with the name "Smith, Jo" first, then fix it.
Run pnpm test export. Do not change the column order.

The second version takes a minute longer to write. It names the file, points at a pattern to copy, sets the check and says what must not change. None of it is clever prompting; it is context the agent could not have found on its own.

When vibe coding is still the right call

Not every project deserves the setup. A one-off script, a prototype to show users on Thursday, a personal tool nobody else will run: the cost of context engineering is higher than the cost of throwing the result away. The mistake is not vibe coding; it is vibe coding something and then treating it as if someone had checked it. Product managers who prototype this way will find a routine for keeping the plan separate from the prototype in vibe coding for product managers.

Moving a vibe-coded project across

When a prototype turns into something people depend on, you do not need to start again. You need to capture what the chat knew.

1. Write the rules file from experience: the commands that run it, the mistakes the AI kept making, the files it must not touch.
2. Add tests for what already works, so the agent has a check before it changes anything.
3. List what you know is broken or missing as separate tasks, each with its own check.
4. Work one task per session from then on, and write down each decision as you make it.

The third step is the one that gets skipped. A prototype’s known gaps usually live in the head of whoever built it. Written as tasks, they become context the next session, or the next person, can read.

Context that belongs to the work, not the tool

A rules file belongs to one repository, and chat history to one tool. Some context belongs to the work: what the task is, what was tried, what was decided. On fenbs, that lives on the board. Each task has a note for the problem and a plan for how it will be done, and the board keeps AI context, short notes about how you work that any connected assistant reads with fenbs_get_context before it starts. An assistant that works something out can leave a note with fenbs_add_context_note, signed with its name, so the next session starts from it instead of rediscovering it. Choices that outlast a task go on the Decisions page. That is context engineering applied to the work itself.