The Thin-Slice AI Workflow: Ship Small, Verify, Then Expand

If you’ve ever used an assistant on a real codebase, you’ve probably seen the pattern:

1. You ask for a change.
2. It proposes a big rewrite.
3. You paste it in.
4. Something subtle breaks (tests, edge-cases, formatting, or simply “this doesn’t match our style”).

The failure mode isn’t the assistant being “wrong”. It’s that the slice of work you attempted was too large for the amount of context you provided.

A practical fix is to work in thin slices: make the smallest useful change, verify it, and only then expand.

This post shows a repeatable, low-drama workflow you can use for coding, docs, and prompt iteration.

---

What “thin slice” means

A thin slice is the smallest version of the task that produces a real signal.

Not “refactor the module”.

Instead:

• “Rename this one function and update its callers.”
• “Add one integration test that reproduces the bug.”
• “Improve one paragraph in the README and verify it still matches the API.”

Thin slices keep you close to the ground truth (your repo, your tests, your product constraints), and they reduce the chance that an assistant invents structure you didn’t ask for.

---

The Thin-Slice AI Workflow (5 steps)

1) Write a 6-line intent header

Before you ask for anything, write a tiny “contract” at the top of the chat or ticket.

Example:

Intent: Fix crash when CSV has empty trailing column
Scope: Only parser.ts and parser.test.ts
Constraints: No new deps. Node 20. Keep perf same or better.
Definition of done: New test fails on main, passes after fix.
Out of scope: Refactors, renames, style changes
Output format: Provide a minimal diff + explain why it works

This header is doing more work than it looks like. It answers the two questions that cause most output drift:

• “How big am I allowed to go?”
• “How will we verify?”

2) Ask for a plan that produces a diff

A plan is only useful if it ends in something you can run.

Prompt:

Propose a thin-slice plan (3–6 steps). For each step, say:
- what file(s) change
- how we verify (test/command)
Stop after the plan.

You’re explicitly preventing the “and here’s the full rewrite” impulse.

3) Execute the smallest change first

Pick the first step that creates real signal and do only that.

Typical thin-slice starters:

• Add or adjust a failing test.
• Add a log line or assert to locate the fault.
• Change one function, not the architecture.

Prompt:

Implement step 1 only. Return a unified diff.
Don’t touch formatting or unrelated code.

If you can’t apply a unified diff cleanly, ask for a “before/after” snippet for the exact lines.

4) Verify with a harness (not vibes)

Thin slices are worthless if you don’t verify them immediately.

A “harness” can be:

• npm test parser (targeted test)
• node repro.js input.csv (repro script)
• curl request + snapshot assertion
• pytest -k failing_case

If your project doesn’t have a harness, make one as the first slice.

A good verification prompt looks like:

Given this diff, list 3 concrete ways it could still be wrong.
Then propose 2 quick verification checks (commands or assertions).

This turns the assistant into a risk generator, not a solution generator.

5) Expand one slice at a time

Only after verification passes do you expand scope.

Prompt:

Now implement step 2. Keep the change minimal.
If you think step 2 requires refactoring, explain why and propose a smaller alternative.

You’re keeping the assistant in a loop:

change → verify → expand

---

Concrete example: a “big refactor” becomes 3 safe slices

Let’s say you want to “improve error handling” in an API client.

A typical big output is: new error classes, new retry logic, new middleware, changes everywhere.

Thin-slice version:

1. Slice A (signal): add one test that asserts the current (bad) behavior.
2. Slice B (fix): change the one function that maps HTTP 429 into a generic error.
3. Slice C (improve): add one optional retry helper behind a flag.

Notice what’s missing: no sweeping refactor, no reformatting, no drive-by renames.

The assistant can still help a lot, but it’s helping in a constrained space.

---

Thin slices for documentation (yes, it works there too)

Docs fail in a similar way: assistants love to rewrite everything in one “consistent voice”, but they can easily drift from reality.

Try this:

Slice 1: “Update only the installation section to match the current CLI flags. Do not touch examples.”

Harness: run the commands in a scratch shell.

Slice 2: “Add one troubleshooting entry for the most common error message.”

Harness: link it to a real stack trace or log line.

Docs get better and stay true.

---

Copy/paste prompt templates

Template: Thin-slice request

Intent: <one sentence>
Scope: <files/areas>
Constraints: <deps, versions, performance, style>
Definition of done: <what passes / what output exists>
Out of scope: <what NOT to change>

Task: Propose a thin-slice plan (3–6 steps). Stop after the plan.

Template: “diff only” implementation

Implement step <n> only.
Return a unified diff.
Do not modify unrelated files.
If you must assume something, list assumptions first.

Template: verification / paranoia pass

Act as a reviewer. Given the diff, list:
- 3 failure modes
- 2 edge cases we should test
- 1 thing to watch in production logs
Keep it specific.

---

Why this works (the short version)

Thin slices win because they:

• reduce context requirements
• create quick feedback loops
• make it easy to rollback
• turn “unknown unknowns” into test cases

Most importantly, they keep you in control. The assistant becomes a high-leverage teammate, not a runaway code generator.

If you adopt only one habit from this post, make it this:

Never ask for a big change without first asking for the smallest verifiable slice.