2.4 The 80/20 rule: get to runnable, then get to correct

What the 80/20 rule means in vibe coding

The 80/20 rule here is not “ship broken code.” It’s a strategy for reducing time-to-feedback.

• 80% = get to something that runs end-to-end (even if rough).
• 20% = turn that runnable slice into something correct, reliable, and maintainable.

When you start with “perfect correctness,” you often get stuck in design debates and prompt loops. When you start with “runnable,” you get reality feedback immediately—and reality feedback is what makes you fast.

Phase 1: get to runnable

“Runnable” means you can execute an end-to-end path without manual heroics. It does not mean it’s correct in every case.

Why runnable first is so powerful

• It reveals missing requirements: you discover what matters when you try to use it.
• It reveals integration issues: wiring problems show up early (imports, configs, env vars).
• It anchors architecture: you can see the shape of the system and adjust boundaries early.
• It prevents endless prompting: you stop speculating and start observing.

What “runnable” includes

• A single working path: one happy-path flow from input → output.
• Minimal configuration: the smallest set of env vars or settings required.
• Clear run instructions: “do X then Y” works on a clean machine.
• Basic error surfacing: failures are visible (logs/messages), not silent.

Phase 2: get to correct

“Correct” means behavior matches your spec across typical and edge cases—and stays correct as you iterate.

What correctness includes (practically)

• Acceptance criteria: specific behaviors that must hold.
• Edge cases: invalid input, empty input, timeouts, partial failures.
• Regression protection: tests or checks that prevent backsliding.
• Clear failure behavior: what happens when it can’t complete the task.

Why correctness comes second

Correctness is expensive without a runnable baseline. You can’t test what you can’t run. You can’t measure what you can’t execute. The fastest route to correctness is often:

• Get a thin version running.
• Lock the core behavior with a few tests.
• Iterate to cover edge cases.

A practical sequencing framework

Use this sequencing to decide what to do first:

1. Architecture skeleton: entrypoint, modules, boundaries, basic data flow.
2. Happy path: one end-to-end scenario that demonstrates usefulness.
3. Observability: logs and clear errors so failures are diagnosable.
4. Safety net: one smoke test or minimal unit tests for core logic.
5. Edge cases: invalid inputs, timeouts, retries, fallbacks.
6. Hardening: refactors, cleanup, performance, security checks.

This is the “adult” version of 80/20: run first, then protect and refine.

The “walking skeleton” checklist

A walking skeleton is the thinnest implementation that proves your architecture and enables real iteration.

• Entrypoint exists: there is a clear starting place to run the app.
• One user flow works: input → processing → output.
• Key boundaries exist: separate core logic from I/O and from “model calls” (if applicable).
• Minimal configuration: no complex setup; defaults where possible.
• Failure is visible: errors are surfaced in logs/messages.
• Documentation stub: a short README or run section exists.

Hardening checklist (turn runnable into reliable)

Once it runs, harden it. This is where you avoid the “prototype in prod” disaster.

Correctness

• Add unit tests for core logic.
• Add a regression test for the last bug you fixed.
• Add schema validation for structured outputs.
• Define error contracts (what users see on failure).

Reliability

• Timeouts and retries (with backoff) for external calls.
• Idempotency where needed (avoid double side effects).
• Graceful degradation (fallback modes, partial results).
• Circuit breaker behavior for repeated failures (later).

Observability

• Structured logs for key events and errors.
• Request IDs / correlation IDs (for web systems).
• Metrics for success rate and latency (later).

Security

• No secrets in prompts or logs.
• Input validation and allowlists.
• Least-privilege tool design (if using tool calling).
• Threat model the feature if it touches auth/data.

Maintainability

• Refactor for clarity (names, modules, dead code removal).
• Consistent formatting and lint rules.
• Documentation updated to match reality.

When NOT to use this rule

Sometimes “get to runnable fast” is the wrong move. Don’t apply 80/20 blindly when:

• The first run is already high-risk: actions that delete data, move money, or change permissions.
• You can’t verify safely: you lack a staging environment or a safe test dataset.
• Correctness is the product: safety-critical or regulated features where failure is unacceptable.

In these cases, you still want fast feedback—but your “runnable” phase must be a safe sandbox: mocks, simulations, dry runs, feature flags, and explicit approvals.

Common anti-patterns (and fixes)

Anti-pattern: never returning to “correct”

• Symptom: the project “works” but is fragile; every change breaks something.
• Fix: schedule checkpoints; add tests; refactor intentionally.

Anti-pattern: “walking skeleton” becomes a full app

• Symptom: you keep adding features before the first end-to-end path is stable.
• Fix: freeze scope: one flow, then harden, then expand.

Anti-pattern: perfection first

• Symptom: lots of planning and prompting, little running code.
• Fix: demand a runnable skeleton; iterate with tests.

Anti-pattern: relying on “manual testing only”

• Symptom: regressions creep in; you lose confidence and slow down.
• Fix: add a smoke test, then grow tests over time.

Copy-paste templates

Template: ask for a walking skeleton

Build a walking skeleton for [project].
Constraints:
- Minimal end-to-end path (one happy flow)
- Clear module boundaries
- No extra features
Deliver:
1) File structure
2) Minimal implementation
3) One command to run
4) What to do next to harden it

Template: harden a runnable baseline

We have a runnable baseline. Now harden it.
Constraints:
- Keep diffs small
- Add tests for core logic and one regression
- Improve error handling (no stack traces to users)
Deliver:
1) Plan
2) Minimal diffs
3) Verification commands

Template: enforce 80/20 scope

Stop adding features.
We are in "correctness phase" now.
Focus on:
- tests/checks
- error handling
- refactors for clarity
- docs/run instructions

Where to go next

• 2.5 The “spec first” habit that prevents spaghetti
• 2.3 “You drive, the model types” (posture)