Vibing coding: which way do you prefer?

What “vibing coding” can mean

Common vibing styles (and how they differ)

1) Prompt-to-app (Chat-first)

• Describe the feature → LLM generates code → you paste/run → repeat.

• Prototypes, throwaway demos, quick UI scaffolds.

• Fastest time-to-first-working-version

• Great for exploration and unfamiliar APIs

• Architecture drifts quickly

• Subtle bugs + inconsistent patterns

• Harder to test and refactor later

• Keep prompts small and iterative

• Ask for tests before adding new features

• Force conventions: lint, format, folder structure

2) “Driver–Navigator” (You code, LLM reviews)

• You write the code; LLM acts like a reviewer: suggests improvements, edge cases, refactors.

• Production code where you still want speed but need control.

• You keep architectural ownership

• Higher code quality than chat-first generation

• Slower than prompt-to-app

• If you under-specify intent, feedback can be generic

• Ask for: “What did I miss?” “Worst-case inputs?” “Concurrency/latency/security issues?”

3) Spec-first vibing (LLM helps plan, then you implement)

• Co-write a short spec (requirements, constraints, acceptance tests) → implement.

• Anything that will live longer than a week.

• Prevents scope creep

• Easier to test, easier to hand off

• Feels less “vibey” at first

• Requires discipline to keep spec lightweight

• Keep the spec to 1 page:
• “Must/Should/Won’t”
• API contract
• Data model
• 5–10 acceptance checks

4) Test-first vibing (LLM writes tests, you fill implementation)

• Describe behavior → LLM generates unit/integration tests → you implement until green.

• Logic-heavy code, bug fixes, regressions.

• Higher confidence

• Great for refactoring without fear

• LLM can write unrealistic tests if your environment isn’t specified

• Setup/fixtures can become overhead

• Provide real constraints (runtime, libraries, DB, HTTP clients)

• Prefer a few high-value integration tests over many brittle unit tests

5) Repo-aware vibing (LLM inside IDE with context)

• Use an IDE assistant that reads your project, symbols, and files; you work in-place.

• Medium/large codebases.

• Better consistency with existing patterns

• Faster navigation (find relevant files, suggest edits)

• Context still incomplete (generated changes can be wrong)

• Over-trust can introduce silent breakage

• Always run tests/linters

• Ask it to point to the exact files/functions it relied on

• Use small diffs and review carefully

6) “Ops vibing” (LLM for DevOps + debugging)

• Feed logs, metrics, error traces → LLM proposes hypotheses and experiments.

• Incident response, performance tuning, environment issues.

• Faster triage and idea generation

• Helps translate between layers (app ↔ infra)

• Can hallucinate root causes

• Needs accurate, complete signals

• Ask for ranked hypotheses + evidence needed for each

• Log the experiments you try and outcomes

Comparison cheat sheet

Picking a style (simple rules)

• If it’s a weekend project: Prompt-to-app.

• If it must be maintainable: Driver–Navigator or Spec-first.

• If correctness matters: Test-first.

• If the codebase is big: Repo-aware IDE + small diffs.

• If you’re firefighting: Ops vibing with hypothesis-driven checks.