How to Break a Feature into Tasks an AI Agent Can Finish

You cannot split a feature well until you know what the feature is. Spec-driven development is the name for writing that down first. Microsoft's developer blog describes it as defining "common guardrails, requirements, constraints, acceptance criteria, and edge cases up front," then using AI to generate code and tests against that shared context (Microsoft Developer). The same post sums up the lesson its teams learned: "Spec quality = output quality."

GitHub's open-source Spec Kit, described in the same Microsoft post, breaks the lifecycle into seven steps: constitution, specify, clarify, plan, tasks, implement and validate. You do not need the tool to use the idea. A three-file version works in any repository, and JetBrains documents it step by step (JetBrains):

The important detail is that each step stops before the next. JetBrains' plan prompt ends with "Do not write or modify any code yet." Writing the plan to a file creates "a checkpoint," a place to review the strategy before code changes. The task list then becomes "your control panel," a record of progress that lives outside the agent's memory.

Microsoft's post adds a caution worth keeping: "Not every change needs the full lifecycle." A one-line fix needs a clear prompt, not three documents. Use the full sequence when a feature touches several components or will take more than a few tasks.

The most common mistake when splitting a feature is to split it by technical layer: one task for the database, one for the API, one for the user interface. Visual Paradigm's guide to story splitting explains why that fails. Horizontal slices "can't deliver the value to the end customer without interaction or integration with other layers" (Visual Paradigm). Its analogy is a cake: people do not eat the top layer before the second, they cut a slice through all of them.

Humanizing Work defines a vertical slice as "a work item that delivers a valuable change in system behavior such that you'll probably have to touch multiple architectural layers to implement the change" (Humanizing Work). Splitting by layer "may satisfy small, but it fails at independent and valuable."

Vertical slices matter even more with agents, for three reasons:

• Each slice can be tested end to end. The agent can prove the slice works, not just that it compiles.
• Integration problems show up early. A layer-by-layer plan hides mismatches until the last task, when the agent has the least context about the first.
• Every task leaves the system working. If you stop after any task, you have something real.

There is one practical exception. A small enabling task, such as adding a database table and migration that later slices depend on, is often fine as its own task when it is short and has its own check. Keep these rare, and keep them small.

The INVEST criteria from agile practice make a good checklist for each slice: independent, negotiable, valuable, estimable, small and testable. Humanizing Work notes that close to implementation, small, estimable and testable matter most. For an agent, testable matters most of all.

Humanizing Work lists splitting patterns that teams have used for years. Several map directly onto agent tasks (Humanizing Work). Here they are applied to one example feature, letting account owners invite teammates by email.

Humanizing Work's advice on the simple-then-complex pattern applies directly: find the core of the story, keep it simple, and "move every variation into its own story." For an agent, each variation becomes one task with one test.

A resulting tasks.md might begin like this:

## Phase 1: Core invite
- [ ] 1. Add `invitations` table and migration. Check: migration runs up and down.
- [ ] 2. POST /invitations creates an invite for a valid email. Check: API test passes.
- [ ] 3. Invite email is sent with a one-time link. Check: test asserts email queued.
- [ ] 4. GET /invitations/:token accepts the invite and adds the member. Check: API test.

## Phase 2: Rules
- [ ] 5. Invites expire after the configured period. Check: expired token returns 410.
- [ ] 6. Owners can revoke a pending invite. Check: revoked token returns 404.

Each line has a single goal and its own check, and the system works after every one.

The task list holds one line per task. When you hand a task to an agent, expand that line into a short contract. Microsoft's teams found that "good specs capture intent, constraints, and acceptance criteria, not just structure" (Microsoft Developer). The same holds at task level.

Task 5 of tasks.md: invitations expire.

Goal: an invitation older than INVITE_TTL_HOURS cannot be accepted.
Context: src/invitations/accept.ts, src/invitations/model.ts,
         tests/invitations/accept.test.ts. Requirements in requirements.md.
Constraints: no schema change; use the existing created_at column.
             Do not change behavior for unexpired invites.
Done when: a test for an expired invite returns 410, all invitation
           tests pass, and `pnpm lint` passes.
Out of scope: reminder emails, admin UI.
Stop if: the change needs a migration or touches billing code.
When done: tick task 5 in tasks.md and summarize files changed.

Each field prevents a specific failure. The context list stops the agent from wandering the codebase. The constraints stop it from redesigning. The "done when" line gives it a finish it can verify. "Out of scope" stops it from building the next task early. "Stop if" gives it permission to halt instead of improvising, which is often the most valuable line in the contract.

A good list can still fail if you hand all of it to the agent at once. JetBrains' execution advice is direct: do not ask the agent to "do everything in tasks.md" in one go. Start with a subset, such as tasks one and two, require the agent to mark progress in the file, and "review after each phase" by checking the changes and running the tests before moving on (JetBrains). If a task uncovers unexpected complexity, update the task list with new subtasks before continuing.

A simple loop:

1. Give the agent one task contract.
2. The agent implements, runs the check and ticks the task.
3. You review the diff and run the check yourself.
4. Commit. The commit is the checkpoint.
5. Start the next task, in a fresh session if the last one grew long.

The fresh session is deliberate. Zylos Research's survey describes two habits from long-horizon agent work that apply here: "checkpoint-and-re-read," where the agent saves its state and goal to a file and reads it back fresh, and "hard session length limits with explicit handoffs" (Zylos Research). The task list and the requirements file are that handoff. A new session that reads them starts clean, with the goal in front of it.

The same discipline lets you run tasks in parallel safely. Augment's guide to spec-driven work notes that each task "should be implementable and testable in isolation" (Augment Code). Tasks that meet that bar, and touch different files, can go to separate agents at the same time.

Split a task again when you see any of these:

• The goal needs "and". "Add expiry and revoke" is two tasks.
• You cannot name the files. If you do not know where the change goes, the first task is investigation, with a written finding as its output.
• The check is vague. "Works correctly" is not a check. Write the test or command first.
• The diff would be large. If you expect a change you could not review in one sitting, split by pattern.
• The agent asks to summarize and continue. That means the task outgrew the session.
• The agent's plan for the task has phases. Phases are tasks.

Splitting has a cost too. Humanizing Work notes the tension: as stories get smaller, "it becomes harder to make them independent and valuable." A task that takes the agent two minutes and needs ten minutes of review is too small. Aim for tasks that each produce a meaningful, testable change, and for a list a person can read in a few minutes.

Done this way, the feature becomes a sequence of small, reviewable commits. Each one is easy to check, easy to revert, and easy to hand to the next session or the next agent.