On this page#
- What vibe coding memes get right—and what they miss
- What is shipped and what is roadmap
- How it changes your setup
- Repository boundaries
- Required validation
- Change policy
- Who this matters for
- The detail that matters in a team repo
- FAQ
What vibe coding memes get right—and what they miss#
Vibe coding is using a natural-language prompt to generate software while paying limited attention to the code itself. The joke is that you keep prompting until the result appears to work. The serious problem is that a team repository cannot accept “appears to work” as evidence that a change preserves its invariants.
The term is useful because it names a recognizable failure mode: the engineer delegates implementation and then evaluates only visible behavior. That definition is consistent with the broad description of vibe coding, but a meme compresses several different workflows into one punchline.
These are not equivalent:
- Asking an agent to write code, then reviewing and validating it.
- Asking an agent to explain unfamiliar code before changing it.
- Accepting generated code because the demo succeeds.
- Repeatedly pasting errors back into the agent until the errors stop.
The first two are ordinary engineering with a powerful interface. The last two are vibe coding in the dangerous sense.
A large language model is a model that generates likely sequences from learned patterns; it does not independently possess your repository’s unwritten constraints. That distinction matters more than whether the agent’s output looks confident. See the underlying concept in the large language model overview.
The right response to a vibe coding meme is therefore not “AI code is bad.” It is: which repository facts were available to the agent, and which checks proved that the patch respected them?
Photo by Daniil Komov on Pexels.
What is shipped and what is roadmap#
Shipped means code, configuration, and checks that exist in the repository now. Roadmap means intended behavior that has not yet become an enforceable constraint. Treating a plan, an agent suggestion, or a documentation promise as current behavior is a category error—and it produces patches against an imaginary version of the system.
Use three buckets:
| Status | What counts | How the agent should treat it | |---|---|---| | Shipped | Merged code, committed configuration, executable checks | Current system behavior | | Required next | An accepted task with explicit acceptance criteria | Scope for this change | | Roadmap | Proposed features, future migrations, possible conventions | Context only, never an assumed invariant |
An agent may generate a clean abstraction for the roadmap while breaking the shipped product. That is not foresight. It is the wrong implementation target.
Before accepting a patch, ask:
- Which behavior exists in code?
- Which behavior is required by this task?
- Which behavior is merely planned?
- Did the patch introduce infrastructure that only a future feature needs?
This distinction should also shape prompts. “Prepare the repository for a future permissions system” is dangerously open-ended. “Add the named interface without changing authorization behavior; do not add unused implementations” defines a reviewable boundary.
Official agent documentation can explain features and configuration, but it cannot decide which statements in your planning material are binding repository truth. Claude Code’s documentation describes the tool; your team must define the contract.
If you need a structured way to encode that contract rather than improvising it in every session, Full Foundry is the direct PairFoundry path. The point is not a longer prompt. It is a smaller gap between repository reality and agent context.
How it changes your setup#
Put stable repository instructions in the agent-facing file that is committed with the code, then keep executable truth in the build, test, lint, and schema configuration that already governs the project. For Claude Code, that means maintaining a repository-level CLAUDE.md; equivalent tools should receive the same rules through their committed instruction mechanism.
A useful instruction file should identify:
- The commands that validate a change.
- Architectural boundaries the agent must not cross.
- Files that are generated rather than hand-edited.
- Compatibility or migration requirements.
- Naming and module conventions that are not obvious from nearby code.
- The difference between current behavior and roadmap material.
- What the agent must report when it cannot complete a required check.
Do not turn the file into a wiki. An enormous instruction file hides the rules that actually affect a patch. Link to deeper material when necessary, but keep the operating constraints short enough to survive every task.
A practical structure is:
*Photo by Lukas Blazek on [Pexels](https://www.pexels.com/photo/person-encoding-in-laptop-574071/).*
## Repository boundaries
- Domain code must not import transport-layer modules.
- Do not edit generated files directly.
## Required validation
- Run the repository's existing test, lint, and type-check commands.
- Report any check that could not be completed.
*Photo by Digital Buggu on [Pexels](https://www.pexels.com/photo/monitor-displaying-computer-application-374559/).*
## Change policy
- Preserve public interfaces unless the task explicitly changes them.
- Do not implement roadmap items as part of adjacent work.This setup follows directly from the limitation of a large language model: it generates from the context it receives. If a crucial invariant exists only in one engineer’s memory, the agent does not have that invariant.
Instructions still do not replace enforcement. “Do not import this module” is guidance; an architecture test or lint rule is a gate. If violating a rule could merge a broken design, encode the rule in a check.
Teams still designing their first agent workflow can start with the free PairFoundry foundations track. Teams comparing narrower assets can use the PairFoundry pack overview.
Who this matters for#
This matters most to engineers working in repositories where correctness extends beyond the visible output: shared services, libraries, monorepos, migration-heavy applications, regulated systems, and products with compatibility commitments. A disposable prototype has fewer hidden consequences; a maintained team repository accumulates them.
The risk rises when a repository has:
- Multiple owners changing adjacent modules.
- Public APIs or consumers outside the repository.
- Database migrations with ordering or rollback constraints.
- Generated artifacts and source-of-truth files.
- Security boundaries that ordinary tests do not fully express.
- Expensive, partial, or environment-dependent validation.
- A roadmap that resembles the current architecture closely enough to be confused with it.
Solo engineers still benefit from explicit instructions, but they can often repair an undocumented assumption immediately. In a team, the person prompting the agent may not know that assumption exists.
The distinction is not junior versus senior. Experienced engineers can accept a plausible patch too quickly, especially when it is large and internally consistent. The code may look deliberate while solving the wrong problem.
That is why the useful lesson behind vibe coding memes is about verification, not embarrassment. The vibe coding definition describes reduced attention to generated code; the professional correction is to restore attention at the repository-contract level, not merely to read every line more slowly.
For continuing notes about specific tools and their operating boundaries, use PairFoundry’s tool notes.
The detail that matters in a team repo#
The decisive detail is whether agent instructions are committed, reviewable, and shared. A private prompt can make one engineer productive while creating a second, invisible version of the repository contract. Once multiple people use agents, uncommitted instructions become configuration drift.
Suppose one engineer tells an agent:
- Never change generated clients directly.
- Preserve an old serialization shape.
- Keep roadmap work out of current patches.
Another engineer’s agent receives none of that. Both can produce code that passes a narrow test, yet only one patch follows the team’s actual rules.
This is the failure that a typical vibe coding meme misses. The joke focuses on the person prompting badly. The repository problem is that correct prompting has not been converted into shared infrastructure.
Fix it with a simple loop:
- Put durable agent rules in the repository.
- Review changes to those rules like code.
- Convert critical prose rules into executable checks.
- Make task-specific assumptions visible in the pull request.
- Reject patches whose validation story is “the agent said it works.”
A committed instruction file also needs ownership. If anyone can quietly add personal preferences, it becomes a prompt battleground. Changes should explain which recurring failure or repository invariant each rule addresses.
Claude Code’s official documentation can tell engineers how the product consumes project context. It cannot supply your architectural boundaries or resolve disagreements about them. That responsibility stays with the team.
The boundary is crisp: using an agent is not vibe coding by default. Shipping code without understanding its contract, evidence, and blast radius is. In a real repository, the meme stops being funny exactly where shared assumptions begin.
Related reading#
- Claude Code MCP servers — the detail that matters in a team repo
- Ollama Claude Code — the practical version
FAQ#
How to tell if someone is vibe coding?#
Someone is vibe coding when they judge generated code mainly by whether the immediate output looks right, while skipping the code’s assumptions, validation, and repository constraints. Tool choice is not the test. The test is whether the engineer can explain what changed, why it is valid, and what evidence supports it.
What is vibe coding and why is it bad?#
Vibe coding means directing an AI through natural language while giving limited attention to the generated implementation. It is bad in maintained systems because visible success can conceal broken invariants, accidental scope, security errors, or compatibility changes. The vibe coding overview provides the broader definition.
What is an example of vibe coding?#
A developer asks an agent to add a field, runs the happy path, sees the field appear, and merges. They never inspect serialization compatibility, migration behavior, generated clients, or downstream consumers. The feature works in the demo, but the repository contract was never checked.
Is vibe coding still a thing?#
Yes, because the behavior does not depend on a particular model or product. Any workflow that substitutes repeated prompting and visible output for engineering verification fits the pattern. Better agents may reduce obvious errors, but they do not make private repository assumptions automatically available or enforceable.
Can you make money vibe coding?#
You can make money with software produced using AI agents, but revenue does not prove that the development process is sound. A prototype may earn money before hidden defects matter. A durable product still needs review, tests, security boundaries, operational checks, and a shared repository contract.