Your roadmap from Class 43 shows the whole journey: phases, milestones, and risks in order. A task is the next piece of terrain — the small patch of ground you actually stand on and finish today. This lesson connects the two. The most common mistake builders make with AI is decomposing only by technical layer: "do all the frontend, then all the backend, then add AI later." Months pass, every layer looks busy, and no user can complete a single real action.

The layer trap

Decomposing by layer feels organized because each pile of work looks uniform. One agent builds screens. Another designs tables. A third "adds AI." The problem is that none of those piles can be tested as a user experience. The frontend has no real data. The database has no real reader. The AI summary has no approved inputs and no place to appear. Integration is postponed until the end, which is exactly when surprises are most expensive.

Worse, layer-based work gives AI maximum room to guess. "Build the frontend" leaves scope, files, inputs, and done-ness undefined, so the agent invents all four. You discover the invention weeks later when the backend expects something different.

A vertical slice fixes this by cutting across layers instead of along them. It touches whatever UI, data, and logic are needed — but only enough to deliver one recognizable user outcome with one finish line.

What a slice is

A vertical slice is the smallest end-to-end change that gives a user a recognizable piece of value. Three tests:

1. One user outcome. A specific person does something and sees a result. 2. One finish line. You can demonstrate it without narration or "imagine this part works." 3. Thin through the stack. It may touch interface, data, and logic, but each only as much as this outcome requires. Everything else is an explicit non-goal.

A slice is not a prototype of everything. It is a finished piece of something small.

Broad versus slice

Notice what each slice on the right does. It names the user, the action, and the observable result. It also implies its boundary: one ticker, not every market; one saved item, not sharing or alerts; a draft from existing records, not live research or auto-publishing; seeded availability, not payments or bookings. A reviewer can check it in a minute.

Why AI likes slices

AI agents do their best work when ambiguity is small. A good slice makes six things concrete:

• Scope: which screens, records, and functions are in play — and which are not.
• Files: the handful of files the agent may read and change.
• Inputs: where the data comes from (seeded, mocked, or an already-approved record).
• Outputs: exactly what the user sees, including empty and error states.
• Tests: how you will check it — a click path, a query, a labeled draft.
• Handoffs: what the next slice receives, such as a field name or a record shape.

Slices also reveal missing interfaces early. The moment you write "show the approved source card," you must decide what a source record contains: title, publisher, date, URL, approval flag. That decision — the interface contract — surfaces in slice two instead of ambushing you in slice ten. Class 42's specifications and Class 43's roadmap feed directly into this: the slice is where the contract gets its first real test.

The dashboard slice sequence

Take the research-dashboard v1 from earlier classes. Instead of "frontend, then database, then AI, then watchlists, then refresh," order it as five slices, each valuable and each exposing the next real dependency:

1. Seeded company view. A visitor enters one ticker and sees a company page built from seeded data, with a clear empty state when no research exists yet. Dependency: none. Exposes: what a company record needs. 2. Approved source card. A visitor on a company page sees source cards drawn from approved records only, each showing title, publisher, and date. Dependency: slice 1. Exposes: the source record shape. 3. Source-linked draft. A user requests a draft summary built only from those approved records; the result is labeled draft, lists its sources, and is never published automatically. Dependency: slice 2. Exposes: the draft's input contract and labeling rule. 4. Private watchlist item. A signed-in user saves one company to a private list and sees only their own item on return. Dependency: slices 1–2 plus identity. Exposes: ownership and authorization. 5. Scheduled refresh with status. A user sees when a company's data was last refreshed and whether the refresh run succeeded, is running, or failed. Dependency: slices 1–3. Exposes: background-run observability from Class 26-style thinking.

Each slice ships something a user can touch. Each also hands the next slice a concrete contract instead of a vague promise.

A slicing habit

When a slice feels big, narrow it with one of these moves: fewer users (one role, not all), fewer items (one ticker, one record), seeded inputs instead of live ones, read before write, manual trigger before automatic schedule. If it still cannot be explained in one sentence, split it again.

Practical exercise: write five slices

Take one ambitious idea of yours — a dashboard, a marketplace, a study tool.

1. Write five vertical slices in order. 2. Each slice must state a user, an action, an observable result, and an explicit non-goal. Example format: "A [user] can [action] and sees [result]. Non-goal: [what this slice deliberately excludes]." 3. Order them so each slice's dependency on earlier slices is visible.

Finish line: a SLICES.md file with five ordered slices, each small enough to explain in one sentence, each with a user, action, result, and non-goal.

Verify: read any slice aloud. Can a friend describe how they would check it in under a minute without asking you a clarifying question? If not, narrow the user, the item count, or the inputs.

Common failure mode: writing features instead of slices ("user accounts," "search backend"). If no user action produces an observable result, it is a layer, not a slice. Rewrite it starting with "A user can…"

Check your understanding

1. What is a vertical slice, and how does it differ from a technical layer? 2. Why does layer-first decomposition hide integration problems until late? 3. Name two things a slice makes concrete that help an AI agent guess less. 4. In the dashboard sequence, what dependency does the draft slice have, and what interface does it expose? 5. Rewrite "build the database" as a one-sentence vertical slice with a non-goal.