Part of Mechanisms of Vibe Coding

Mechanism: Split & Conquer

One-sentence definition

Split & conquer is planning work so each agent session has a single shippable job — with its own goal, fence, and verify step — instead of one mega-prompt for a whole feature.

The problem

You describe the entire feature in one message: API, UI, emails, admin panel, analytics. The agent starts everywhere. Half the files change. Tests fail in three modules. You cannot tell which slice broke or which session to retry.

Big prompts feel efficient. They are integration traps — all coupling, no checkpoints. AI sessions work best at human-reviewable size, not roadmap size.

Symptoms:

• One chat spans days with no merge
• Partial features everywhere, nothing end-to-end works
• You restart from scratch because the thread is unsalvageable
• PRs that reviewers refuse to open because the diff is “the feature”

How it works

Before the first agent message, decompose into ordered slices. Each slice must have:

1. A name (“health JSON shape”, not “backend”)
2. A goal + verify
3. A scope fence
4. Dependencies on prior slices (explicit)

  Feature vision
       │
       ▼
  List slices (ordered)
       │
       ▼
  Session 1 ──► verify ──► merge
       │
       ▼
  Session 2 (builds on 1) ──► verify ──► merge
       │
       ▼
  … until feature complete

Slices can be horizontal (layer by layer) or vertical (thin end-to-end). Prefer vertical when you need early proof the feature works; use horizontal when one layer is genuinely blocked.

When to use it

• Any feature larger than one file and one test
• Before multi-day agent work
• When teaching a team how to parallelize AI sessions
• After a failed “build it all” session — replan as slices

When not to use it

• Truly atomic bugfix — already one session; use goal + constraints only
• Spike to learn feasibility — one exploratory session, then split for implementation
• Over-splitting (“change line 42”) — slices should be reviewable units, not edits

Failure modes

Slice soup — Twelve micro-sessions with no order. Fix: Number slices; note dependencies.

Hidden coupling — Slice 3 assumes slice 1 landed but it did not. Fix: Verify and merge each slice before starting the next.

Split without goals — Slices are topic labels. Fix: Each slice gets symptom + verify.

Parallel slices on same files — Two agents edit the same module. Fix: Branch-per-experiment or sequential merges.

Never integrating — Perfect slices that never compose. Fix: Include integration verify in the last slice or a dedicated glue session.

Minimal example

Context: Add optional details field to GET /health when ?verbose=1.

Split:

• Session 1 — Response shape: verbose=1 returns { ok, details: { uptime } }; test passes
• Session 2 — Bootstrap data: details.uptime reflects real uptime; test passes
• Session 3 — Docs + negative space: README documents query param; no other routes changed

Three chats, three merges — not one chat for the whole feature.

Done when: Each row was a separate session with its own verify before the next started.

Tool instances (optional deep-dive)

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

Cursor

• Plan mode first: Ask for a numbered slice list; approve before Agent runs.
• One Composer tab per slice — tab title = slice name.
• Todo lists in agent — align agent todos to your slice list; reject extra todos.
• Paste slice goal at top of each new chat; link prior PR in handoff if needed.

Other tools

GitHub issues per slice, Linear sub-tasks — decomposition is project management, tool-agnostic.

Related mechanisms

• Scope fence — enforces one job per session
• Vertical slice — alternative slice shape
• Goal — each slice needs one

Try it yourself

Exercise: Take one feature from your backlog. Write 3–5 numbered slices with goal + verify per slice. No agent until the list is complete.

You need: One feature idea; ten minutes

Done when: Each slice could be explained to a colleague without referencing the whole feature.