On this page#
- Before you install anything
- The steps
- A working configuration
- Objective
- Invariants
- Allowed scope
- Required workflow
- Completion report
- What to skip
- Your first real task
- FAQ
Before you install anything#
To start vibe coding in a real repository, first define what must remain true, how changes will be verified, and what the agent may touch. Then configure one agent, give it a small bounded task, inspect the diff, and run the repository’s existing checks. The order matters because settings cannot rescue an ambiguous task or an unverifiable result.
Vibe coding means using natural-language prompts to generate and modify software through AI. In a production repository, however, “the code runs” is not acceptance. The change must also preserve interfaces, tests, data assumptions, security boundaries, and conventions that may not be obvious from the requested feature.
The correct order is:
- Identify invariants.
- Find the repository’s verification commands.
- Establish scope and prohibited changes.
- Configure the agent.
- Assign one bounded task.
- Review the diff and verification evidence.
Starting with model settings, extensions, or an elaborate prompt library is backwards. A large language model generates likely continuations from context; it does not automatically know which undocumented behavior your team considers contractual. Give it those constraints before asking it to act.
That is the central rule: constrain first, delegate second, optimize later.
Photo by Boris K. on Pexels.
The steps#
Follow these steps in order. Each one removes a specific failure mode before the agent gains more freedom, so a mistake stays visible and inexpensive to correct. Skipping ahead creates the illusion of speed while moving ambiguity into the code, where it becomes harder to detect during review.
-
Write down the invariants — this prevents a locally correct change from breaking system behavior.
Record the behaviors that must not change: public interfaces, authorization rules, persisted data shapes, error semantics, and compatibility requirements. Do not write “avoid regressions.” Name the actual boundaries.
-
Locate the existing checks — this prevents the agent from inventing its own definition of done.
Find the repository’s real formatter, linter, type checker, test commands, and build process. The agent should use what the project already trusts. If a relevant behavior has no automated check, state the manual verification required.
-
Set the permitted scope — this prevents opportunistic refactoring.
Name the directories or components the agent may edit. Also state what it must not change, such as dependencies, schemas, public APIs, generated files, or unrelated formatting.
-
Create a repository instruction file — this prevents critical context from disappearing between sessions.
Put stable rules in
AGENTS.mdfor Codex or the corresponding repository instruction file used by your agent. Tool-specific setup belongs in the tool’s own documented mechanism; for example, consult the Claude Code documentation when configuring Claude Code rather than assuming every agent reads the same filenames. -
Ask for a plan before edits — this prevents the first plausible interpretation from becoming code.
Require the agent to identify affected files, relevant invariants, verification commands, and unresolved ambiguity. The plan should be short enough to review, not a ceremonial essay.
-
Approve one bounded implementation — this prevents a review from becoming repository archaeology.
A good first change has a narrow outcome and an obvious verification path. Do not begin with a migration, architectural rewrite, or cross-cutting cleanup.
-
Inspect the diff before accepting the explanation — this prevents confident prose from substituting for evidence.
Review changed behavior, not just changed lines. Then run the repository’s checks and verify any uncovered invariant manually.
For a reusable version of this operating model, the PairFoundry Agent Operating Kit turns these controls into working templates rather than a collection of disconnected prompting tricks.
A working configuration#
Use a small repository contract that tells the agent what to inspect, what it may change, and what evidence it must return. The configuration below is intentionally tool-light: replace the bracketed fields with repository facts, save it under the instruction filename your chosen agent supports, and keep task-specific requests out of it.
# Repository operating rules
*Photo by ThisIsEngineering on [Pexels](https://www.pexels.com/photo/female-software-engineer-coding-on-computer-3861951/).*
## Objective
Make the smallest change that satisfies the requested behavior.
## Invariants
- Preserve: [public interfaces or externally visible behavior].
- Preserve: [authorization, validation, or data integrity rule].
- Preserve: [compatibility or persistence requirement].
*Photo by Al Nahian on [Pexels](https://www.pexels.com/photo/computer-program-on-computer-screen-7325498/).*
## Allowed scope
- Edit only: [directories or files normally in scope].
- Do not change dependencies, schemas, generated files, or public APIs unless the task explicitly requires it.
- Do not refactor unrelated code.
## Required workflow
1. Read the relevant implementation and tests before editing.
2. State the proposed files, behavioral change, and verification plan.
3. Ask before proceeding if the request conflicts with an invariant.
4. Implement the smallest coherent patch.
5. Run: [format command].
6. Run: [lint or type-check command].
7. Run: [focused test command].
8. Run: [broader required test or build command].
## Completion report
- Summarize the behavior changed.
- List every modified file and why it changed.
- Report each verification command and its result.
- Disclose skipped checks, failures, assumptions, and remaining risks.Here is what each part does:
| Line or block | Why it exists |
|---|---|
| Objective | Biases the agent toward a minimal patch instead of unsolicited redesign. |
| Invariants | Converts hidden repository knowledge into explicit acceptance constraints. |
| Allowed scope | Establishes a change boundary and blocks unrelated cleanup. |
| Read before editing | Forces the task to be grounded in existing implementation and tests. |
| State the plan | Exposes a wrong interpretation before it produces a large diff. |
| Ask on conflict | Prevents the agent from silently choosing which requirement to violate. |
| Repository commands | Makes verification concrete and repeatable. |
| Completion report | Separates evidence, assumptions, and remaining risk. |
Do not paste generic commands into those placeholders. Incorrect verification instructions are worse than missing ones because they produce false confidence. If you need more repository-ready patterns, the PairFoundry packs overview shows the available operating materials without requiring you to build an oversized configuration first.
What to skip#
Skip anything that increases ceremony before it increases control. The common beginner setup sequence—install every extension, collect a giant prompt, enable maximum autonomy, and ask for a broad feature—is wrong for an established repository. It expands the agent’s action surface before you have defined acceptance or recovery boundaries.
Do not start with:
- A universal “perfect prompt.” Repository invariants matter more than motivational language or role-play.
- Every available integration. Add access only when a task needs it. More tools create more possible side effects.
- Maximum autonomous execution. Autonomy should follow reliable scope control and verification, not precede them.
- A new test framework. Use the repository’s current checks unless the task explicitly concerns test infrastructure.
- A full codebase index or documentation rewrite. Read the paths relevant to the task first.
- Model-setting comparisons. A different setting will not repair missing invariants or an undefined acceptance test.
- A toy greenfield app. It does not exercise the constraints that make your real repository difficult.
- A large refactor as calibration. Large diffs hide whether the agent understood the request.
- Blind acceptance of generated tests. A test can merely encode the agent’s mistaken interpretation.
Official tool documentation, including the Claude Code documentation, explains supported capabilities and configuration. It cannot tell you which behavior your repository must preserve. That contract is your responsibility.
If you are not ready to formalize a paid operating kit, use the free PairFoundry foundations track to establish the basic task, context, and verification loop first.
Your first real task#
Choose a small defect or maintenance change inside a component you understand, with an observable expected result and existing verification nearby. The best first task is not impressive; it is diagnostic. It should reveal whether the agent reads local conventions, respects scope, handles ambiguity, and reports evidence without putting critical repository behavior at risk.
A strong first task might be:
- Correcting one validation edge case covered by nearby tests.
- Improving an error path without changing the public interface.
- Adding a focused regression test, then making the smallest implementation change that passes it.
- Removing a narrow duplication while preserving current behavior and checks.
Give the agent four things:
- The exact observed behavior.
- The expected behavior.
- The relevant invariants and prohibited changes.
- The commands and manual checks required for acceptance.
Then require a plan before editing. Reject plans that contain unexplained refactors, dependency changes, or phrases such as “clean up related code.” After implementation, inspect the actual diff and verification output. The agent’s summary is navigation, not proof.
Only widen the task boundary after this loop is reliable. The PairFoundry agent setup hub is the natural next place to refine setup practices, but refinement comes after a controlled real task—not before it.
Related reading#
- MCP server tutorial — the setup that survives a real repo
- Npm install google Gemini CLI: a working configuration, explained line by line
FAQ#
Is it easy to learn vibe coding?#
Yes, the interaction pattern is easy to learn: describe a change, let an agent propose or produce code, and review the result. The difficult part is learning to specify invariants, constrain scope, and verify behavior. Experienced engineers usually need less prompting instruction than they need a disciplined operating loop.
Where do I learn vibe coding?#
Start in a real repository you understand, using one bounded task and the workflow above. Read your agent’s official documentation for supported controls, then use the PairFoundry foundations track for a structured progression. Avoid tutorials whose success condition is merely generating an application that appears to run.
How to enable vibe coding?#
There is no universal switch. Install or open an AI coding agent, give it access only to the repository and tools required for the task, add repository instructions, and provide a bounded request with verification commands. Enabling the software is trivial; enabling it safely means defining its operating boundary first.
Can anyone do vibe coding?#
Anyone can use natural language to request code, but not everyone can safely approve changes to a consequential repository. Approval requires understanding the expected behavior, recognizing protected boundaries, and evaluating verification evidence. An agent can help produce code; it cannot transfer accountability away from the person or team merging it.
Is 25 too old to start coding?#
No. Age is not the constraint here. The useful question is whether you are willing to learn how software behavior, tests, interfaces, and failures fit together. AI can accelerate code production, but sound judgment still comes from examining systems carefully and treating generated output as a proposal rather than an answer.