Vibe Coding vs Agentic Coding: When to Use Which

You should use vibe coding for exploration and low-stakes prototypes. You should switch to agentic coding when the cost of a hallucination exceeds the cost of setting up guardrails. The line sits where you can no longer read every line the model writes before it ships.

I hit this wall last quarter. A founder came to me with a FastAPI service generated entirely in Cursor Composer. It worked locally. It passed the happy path. Then a malformed payload hit an endpoint the model had “handled” with a try/except that swallowed the exception and returned 200 OK. The downstream worker processed garbage for six hours before anyone noticed. That is the vibe coding trap in production: code that looks right until it isn’t.

What is the difference between vibe coding and agentic coding?

Vibe coding is conversational. You prompt, the model generates, you accept or tweak. You are the pilot. Agentic coding delegates a goal to an autonomous loop: plan, act, observe, repeat. The model drives. Vibe coding vs agentic coding: when to use which comes down to who owns the context window and who verifies the output.

In vibe coding you hold the context in your head. You read the diff. You run the tests. In agentic coding the system holds context across steps, often via a graph like LangGraph or a tool-calling loop like Claude Code. The agent writes code, runs linters, executes tests, and iterates until a pass condition is met. You review the final PR.

Decision matrix: project complexity vs. autonomy requirements

If you are building a weekend MVP to validate demand, vibe code it. Ship fast. Delete later. If you are adding a payment webhook handler that touches Stripe idempotency keys and your audit log, do not vibe code it. The blast radius is too high.

I use a simple rule: if I would not approve the PR without running the full test suite and checking the logs, I do not let an agent merge it without the same gates.

Toolchain comparison: Cursor Composer vs. Claude Code vs. LangGraph

Cursor Composer excels at multi-file edits inside the editor. You highlight a module, ask for a refactor, get a diff. It stays in your flow. It is still vibe coding because you accept each step.

Claude Code (the CLI agent) runs in your terminal. You give it a task: “add retry logic with exponential backoff to all external HTTP calls.” It greps, edits, runs pytest, sees failures, patches, repeats. That is agentic. It can burn tokens fast. I cap it with a max-turns flag and a strict allowlist of directories.

LangGraph is not an IDE tool. It is a framework for building your own agents. I use it when the workflow is deterministic: ingest PDF, extract tables, validate schema, write to Postgres. The graph nodes are Python functions. The edges are explicit. Hallucinations drop because the model only decides which node runs next, not what the node does. For a deeper look at wiring LLMs to tools, see MCP Server vs API: When to Use Each for LLM Tooling.

Risk profiles: hallucination rates, context limits, and debugging overhead

Hallucinations in vibe coding look like plausible wrong answers: a datetime.utcnow() without timezone, a missing await on an async client, a SQL query that works in SQLite but deadlocks in Postgres. You catch these by reading.

Hallucinations in agentic coding look like infinite loops: the agent “fixes” a test by deleting the assertion, or it creates a migration that drops a column the API still reads. You catch these by replaying the trace.

Context limits bite both. Vibe coding hits the chat window ceiling. Agentic coding hits the tool-call history ceiling. I truncate aggressively. For agents I summarize tool outputs to one line. For vibe coding I start a fresh chat per logical change.

Debugging overhead is the hidden tax. Vibe coding debug time is linear: you read, you spot, you fix. Agentic coding debug time is branching: you read the trace, you find the bad decision node, you adjust the prompt or the graph, you rerun. Budget 30 percent extra time for the first agentic task. It drops to 10 percent once the evals are solid.

Hybrid workflow: starting with vibe, hardening with agents

This is how I actually work.

1. Vibe the scaffold. Open Cursor. Prompt: “FastAPI project with SQLModel, Alembic, pytest, structlog, Dockerfile.” Commit.
2. Vibe the domain models. Paste the PRD. Get Pydantic models, enums, database tables. Review every field. Commit.
3. Agent the boilerplate. Hand off to Claude Code: “Generate CRUD routers for all models in app/models/__init__.py. Follow the pattern in app/api/v1/users.py. Run pytest -x until green.” Review the PR.
4. Vibe the business logic. Complex rules, state machines, money math. I write these. The model assists with syntax.
5. Agent the tests. “Property-based tests for the pricing engine using Hypothesis. Target 90% branch coverage.” The agent finds edge cases I missed.
6. Hardening. Add evals for any LLM calls. Add CI gates: ruff, mypy, pytest, bandit. Add observability: structured logs, traces, metrics.

The switch from step 3 to 4 is the pivot. Before the pivot I optimize for speed. After the pivot I optimize for correctness.

Production guardrails: evals, CI gates, and observability for AI-authored code

Code written by an agent is not special. It is just code you did not type. Treat it like code from a junior engineer who works fast and sometimes lies.

Evals for LLM steps. If your pipeline calls an LLM (summarization, extraction, classification), you need a golden dataset. Run it on every PR. Fail the build if F1 drops below threshold. I store eval cases as JSONL in evals/ and run them in a dedicated GitHub Actions job.

CI gates. Standard Python stack:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/ruff-action@v3
      - run: mypy --strict app
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pytest --cov=app --cov-fail-under=80
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bandit -r app -ll

Observability. Structured JSON logs. Correlation IDs passed through every request. Traces for async workflows. I use structlog + OpenTelemetry. When the agent writes a background task, it must emit a span. See FastAPI background tasks poll APIs, create PDFs, send email for the pattern I enforce.

Canary deploys. Never let agent-authored code go straight to 100 percent. Route 5 percent of traffic. Watch error rates, latency, business metrics. Roll back on anomaly.

When not to use agentic coding

Do not use agents for:

• Database migrations that cannot be rolled back in seconds
• Cryptographic code (key rotation, token signing)
• Security-critical authz logic (RBAC, ABAC)
• Anything requiring deep tribal knowledge not in the repo

Do not use vibe coding for:

• Production hotfixes under pressure
• Refactors that touch more than three files
• Code you do not understand well enough to explain to a peer

FAQ

Can I use agentic coding for a solo project? Yes. The guardrails are cheaper than the debugging time. Set up evals and CI once. Reuse them.

How do I stop the agent from deleting my tests? Add a pre-commit hook that fails if test file line count drops. Or run the agent in a branch with a protected tests/ directory via .gitignore rules in the agent config.

Is Cursor Composer agentic? No. It is multi-file vibe coding. You approve each diff. It does not run a loop of act-observe-repeat on its own.

What is the fastest way to add evals to an existing LLM feature? Export 50 real inputs and your manually corrected outputs to JSONL. Write a pytest test that calls your pipeline and compares against the goldens. Run it in CI.

Key Takeaways

• Vibe coding keeps you in the loop. Agentic coding moves the loop into the machine.
• Match the mode to the blast radius: prototype with vibe, harden with agents.
• Guardrails are not optional for agentic code. Evals, CI gates, and observability are the price of autonomy.
• Hybrid workflows win. Scaffold with vibe, generate boilerplate with agents, own the core logic yourself.
• If you cannot explain the diff, you do not own the code. That rule applies to both modes.