Skip to main content

​
Overview

Vibe coding is a development approach in which you describe what you want in natural language, let a generative-AI coding agent produce the code, and steer, verify, and refine the result through continuous dialogue. The term is sometimes used for a throwaway-prototype style in which generated code is accepted without being read. This page covers something else: the practice as applied to a production codebase maintained by a team, where a human stays responsible for verifying the output. This page explains the groundwork a coding agent needs before it can perform, the verification responsibilities that stay with the human, and how to handle sessions, context, and custom instructions.

​
Prerequisites

A coding agent’s output quality is bounded by the codebase and process it works in. When AI adoption fails to deliver, the cause may be missing groundwork rather than the tool. The coding agent has nothing consistent to imitate and no guardrails to catch its mistakes. Conventions, tests, and design knowledge are not made obsolete by the coding agent — they are what the coding agent runs on, and what lets you judge its output. Prepare the foundation before expecting results.

Unified coding conventions

A coding agent imitates the code it sees. A codebase that follows one consistent style — for example, a published style guide — steers generation toward uniform output, while mixed styles produce mixed results.

Test code

Tests serve two roles: they are a primary source the coding agent reads to understand the spec, and a guardrail that mechanically catches wrong output before a human does.

Documentation and custom instructions

READMEs, design docs, and coding agent instruction files (such as AGENTS.md or tool-specific configuration) are standing context the coding agent receives every session without being pasted into the prompt.

Pull requests and review culture

A habit of small, focused pull requests keeps coding agent output reviewable. Generation speed is worthless if the change arrives too large to verify.
Dead or unused code works against all of the above: the coding agent cannot tell that it is obsolete and will imitate it. Removing it is part of preparing the codebase.

​
Verification and the human’s responsibility

Vibe coding changes who writes the code, not who is responsible for it. The author of a generated change is the human who requested it: before sending it to review, be able to explain every line. Generation speed that produces unexplained changes does not raise productivity — it moves the cost from writing to reviewing, where it grows. Do not rely on eyeballing alone. Hand the coding agent a check that returns pass or fail — the test code, the build, a linter — and instruct it to iterate until the check passes. Then have the coding agent show evidence (the test output, the command it ran and its result) rather than assert success.

​
Manage sessions deliberately

Treat a session as a unit of context. Keep related changes in the same session so the coding agent retains shared context. Horizontal expansion is the clearest example: get a single instance working and verified, then expand to the remaining places in the same session, where the verified implementation is still visible to the coding agent. The proven example serves as the spec for the repetitive work.
Example instruction for the expansion
Start a new session for an unrelated task so stale history does not bleed in. A session’s history has the same limitation as human short-term memory: the more irrelevant material it holds, the less reliably the relevant part is used. A working rule: after correcting the coding agent twice on the same issue, stop correcting. The context now holds the failed attempts, and they keep steering the output. Start a new session with a prompt that incorporates what the failures taught you — a clean session with a sharper prompt outperforms a long session with accumulated corrections.

​
Keep course corrections cheap

A coding agent generates code fast, which means it generates the wrong code fast too. To keep the cost of a wrong direction low, structure the work so any single step is cheap to discard, and commit at a fine grain. Commit in small, coherent steps — finer than you would open a pull request — so you always have a safe point to roll back to. Take a data-model change as an example: proceed in sequence — define the model → verify it → generate the migration.
Example sequence: adding a table
With this order, a wrong field name caught at step 2 costs a one-file fix. Catch it after generating the migration in one shot, and the correction requires a rollback and changes across multiple files.

​
Hand over just enough context

The largest factor in output quality is the size and focus of the context handed to the coding agent. A sprawling, multi-part request spreads the coding agent’s attention thin and accuracy drops; a narrow task with the right references produces clean, on-target code. The goal: give the coding agent the smallest context that is still complete enough to do the job.
Bad: too much
Bad: not enough
Good: just enough
The first has enough information, but most of it is noise that dilutes attention, and the “refactor along the way” mixes in an unrelated concern. The second is minimal, but with no location and no detail about the symptom it invites an unbounded search. The third hands over only what acting on the task requires: the symptom, the actual error log, and how to proceed. It states no theory about the cause: the log carries the failing request and the failing location as facts, and tracing them to the cause — a keyword containing a full-width space — is the coding agent’s job. Structure also matters. A hierarchically organized instruction — goal, then constraints, then concrete references — is parsed more reliably than one long undifferentiated paragraph.
A poor instruction
Example of a structured instruction
When the task needs data the coding agent cannot see — issues, library documentation, design data — provide it through a Model Context Protocol (MCP) server rather than pasting large blobs into the chat.

​
Use custom instructions

Custom instructions are an instruction file the coding agent reads at the start of every session: build and test commands, style rules that differ from defaults, repository conventions, and known gotchas. They are the concrete form of the “documentation and custom instructions” item in the foundation above.
AGENTS.md
Check the file into git so the team shares it, and keep it short — in an overlong file, individual rules get lost and adherence drops. Knowledge that is only sometimes relevant belongs in a skill, which loads on demand instead of occupying every session.

Agentic Workflow

Where vibe coding builds in dialogue, agentic workflows delegate implementation to coding agents and scale it in parallel.

Skills

Encode a recurring workflow once as a skill and invoke it whenever needed.