Part of Mechanisms of Vibe Coding

Mechanism: Vertical Slice

One-sentence definition

A vertical slice is a single session that ships one path through the stack — request to response, UI to DB, or trigger to effect — as a thin working thread instead of completing one horizontal layer for the whole feature.

The problem

You build the entire data layer first, then all routes, then UI. Nothing demoable for two weeks. Integration surprises appear late. Agent sessions on “just the repository layer” produce code that does not fit the API you eventually want.

Horizontal layers optimize for architecture comfort. Vertical slices optimize for early truth — something you can curl, click, or test end-to-end, even if ugly.

Symptoms:

• “Backend is done” but frontend cannot call it
• Integration bugs discovered after large merges
• Demos require faking half the stack
• Agent refactors the slice you built because upper layers needed different contracts

How it works

Pick the smallest user-visible or API-visible path:

  Slice 1 (thin):
    GET /health?verbose=1 → reads uptime from bootstrap → JSON response
    (one route, one field, one test, curl demo)

  Slice 2 (next thin path):
    Add details.memory next — same vertical pattern

  Not slice 1:
    "All of bootstrap refactoring" (horizontal)

Each slice is a scope fence session with goal + verify on the full path, not just one layer.

  User / client
       │
       ▼
  ┌─────────────────────────┐
  │  Vertical slice (thin)  │  ← one session targets full column
  │  route → logic → output │
  └─────────────────────────┘

Pair with split & conquer: multiple vertical slices beat one horizontal phase.

When to use it

• New features needing early feedback or demos
• Unknown integration risk between layers
• Agent work where you want a curl/browser check each session
• Replacing “build all models first” plans

When not to use it

• Deep infrastructure with no user path yet — horizontal spike may be necessary first
• Performance-only work deep in one layer — no vertical story
• When slice would touch too many systems — narrow the slice or split horizontally once

Failure modes

Fake vertical — “E2E” that mocks every layer. Fix: At least one real boundary (real HTTP, real file, real DB) per slice.

Slice too thick — Whole admin dashboard in one slice. Fix: One button, one API, one screen state.

Skipping verify on path — Unit tests only on the bottom layer. Fix: Verify the slice at the top (HTTP test, e2e).

Horizontal relapse — Slice 1 route only, slice 2 logic only — not vertical. Fix: Each slice completes the column.

No PR-sized outcome — Slice bigger than reviewable. Fix: Thinner slice.

Minimal example

Context: First verbose health slice — only uptime in details.

Vertical slice goal:

One curl proves the slice:
  curl "/health?verbose=1" → 200, ok true, details.uptime is number

Includes: route handler, bootstrap read, test via supertest/http
Excludes: memory, docs, other routes

One session, one merge, one demo command.

Done when: Curl passes without manual wiring or mocks hiding the stack.

Tool instances (optional deep-dive)

Portable idea above; this section is tool-specific. Date: June 2026.

Cursor

• Demo command in goal block (“done when curl …”).
• Agent: Implement route + minimal logic + test in one fenced session.
• Browser MCP / terminal — verify slice at the top of the stack when UI is involved.

Other tools

Walking skeleton, tracer bullet — same pattern in agile literature.

Related mechanisms

• Split & conquer — order multiple slices
• Scope fence — one slice per session
• PR-sized vibes — slice size vs reviewability

Try it yourself

Exercise: Define one vertical slice for a feature — name the single curl, click, or CLI command that proves it. List every layer touched in one line.

You need: One feature; five minutes

Done when: Your proof command exercises at least two layers (not “unit test on a private function only”).