One evening in August I went out for dinner while agents built a feature for my own app, Thura, a receipt app for online sellers in Myanmar. The feature let a shop work in kyat or in Thai baht.

I didn't hand it over as one big prompt. It was a plan of five small tasks. Each task went to a fresh agent, and each one was reviewed before the next one started. All five passed review on the first try.

Then one last review looked at the whole branch. It found a bug that none of the five reviews could see: the home screen showed "0 Ks" for receipts priced in baht. Every task was right on its own. The bug lived between them.

That evening is this whole post in small form. Small, checked tasks work. But they need one more check at the end.

"But the new models can handle big tasks"

They can, and that's the biggest change since I started using agents.

METR measures how long a task (in human time) an AI agent can finish with 50% success. In their 2025 paper, that length had been doubling roughly every seven months since 2019. Their January 2026 update puts the doubling since 2024 at about three months. The newest models I use every day (Fable 5, Opus 5.5, GPT-5.6 Sol) work for hours on their own. Anthropic says Fable 5 can work autonomously longer than any previous Claude model, and cites a customer who migrated a 50-million-line codebase in a day. That's the vendor's claim, but it matches what I see.

So I'm not saying agents can only handle small things. The limit is on my side: how much I can actually check.

Why big tasks still go wrong

1. "Sometimes" and "reliably" are far apart

That 50% number is the headline, but I don't ship code that works half the time. In METR's 2025 paper, the task length a model could finish 80% of the time was about five times shorter than its 50% length. One model's 50% horizon was about an hour. Its 80% horizon was about 15 minutes.

Those were older models, and today's numbers are much longer. But the gap between "can sometimes" and "can reliably" is built into how success drops with length. It doesn't go away just because the whole curve moves up.

%%{init: {"themeVariables": {"xyChart": {"plotColorPalette": "#534AB7"}}}}%% xychart-beta title "Success vs task length (half-life model)" x-axis "Task length, in multiples of the 50% horizon" ["0", "0.25", "0.5", "0.75", "1", "1.5", "2", "3", "4"] y-axis "Success %" 0 --> 100 line [100, 84, 71, 59, 50, 35, 25, 13, 6]

80% success sits at about ⅓ of the 50% length. Illustrative model (Ord, 2025).

2. Doubling the task squares the risk

Toby Ord looked at the same data and found that success falls off roughly like a half-life: a constant chance of going wrong for every minute of work. If that's true, doubling a task's length squares its success rate.

  • 80% on a task → about 64% on one twice as long
  • 50% → 25%

Ord is clear that this is an approximate model fitted to one task suite, not a law. Still, it matches what I see. The bigger the prompt, the more places a small mistake can slip through.

3. Longer runs, more shortcuts

In Part 1 I wrote about reward hacking: agents making the check pass instead of doing the work. METR found a 2025 frontier model reward-hacking in every run (21 of 21) of one optimisation task, for example by tampering with the scoring. Adding "please do not cheat" to the prompt barely helped: it still did it in 80% of runs.

A long, vague task leaves more room for shortcuts. A small task with one clear check leaves less.

4. Long context still costs something

Chroma tested 18 models in 2025 and found performance dropped as inputs got longer, even on simple tasks, and got worse when the context held similar-but-wrong information. Newer models handle long context much better, and vendors say so. I don't bother arguing about it. Clearing the session between tasks costs nothing, so I just do it.

Splitting alone doesn't help

I only noticed this when I did the math.

Say each small slice succeeds 80% of the time. Chain five slices together, run them all, and check only at the end: the chance that all five are right is 0.8⁵, about 33%. That's no better than one big task five times as long.

Splitting only pays off if you check between slices.

When I check each slice before starting the next, I catch a failure right away and redo one slice, not the whole feature. The next slice then builds on code I've already checked, not on a mistake I haven't seen yet.

flowchart TD subgraph big ["One big task: checked once, at the end"] direction LR B1["One prompt: build the whole feature"] --> B2["Review: hours"] end subgraph small ["Small slices: checked after each one, then as a whole"] direction LR S1[Repository] --> C1{✓} --> S2[State] --> C2{✓} --> S3[Search bar] --> C3{✓} --> S4[Filter sheet] --> C4{✓} --> S5[Wire up] --> C5{✓} --> F["Final review of the whole branch"] end big ~~~ small

This is how it has gone on my own app. On a feature I built in seven tasks, the task that wrote the end-to-end tests caught a real race: close the welcome screen and reload fast, and it came back. On a guest checkout flow I built in five pieces, the reviews after two of those pieces caught security holes before the next piece was built on top of them. Both would have been much harder to find in one big diff.

But remember the dinner story. Checking each slice doesn't catch a bug that only appears when slices meet. So after the last slice, I run one review over the whole branch. It's the only check that sees how the pieces fit together.

So this is really Part 1 again. Small tasks give small diffs, and small diffs are ones I can actually check.

What "agent-sized" means to me

I don't size a task by what the agent can do. I size it by what I can check. Four questions:

  1. One sentence. I can describe the diff in one sentence. If I need "and" three times, it's three tasks.
  2. One proof. "Done" can be shown by a test, a build or a screenshot. Not by me reading and hoping.
  3. Fifteen minutes. I can review it properly in about 15 minutes.
  4. One revert. If it's wrong, I can throw it away with a single revert, without untangling it from other work.

Any box unticked? Split the task.

An example: search and filter

Here's how I'd now split "build the search and filter screen" in a Flutter app:

  1. Repository: add searchProducts(query, filters) and its unit tests. No UI.
  2. State: a notifier that holds the query and filters, with debounce. Unit tests.
  3. Search bar: the input widget wired to the notifier. Widget test.
  4. Filter sheet: the bottom sheet UI. Widget test.
  5. Wire it up: connect everything on the screen, plus empty and error states. One integration test.

Each slice gets its own short PASS/FAIL checklist (the one from Part 1), a fresh reviewer, and a clean session before the next slice starts. Then one final review of the whole branch. Six small reviews instead of one I'd never really do.

The agent is still fast; each slice takes a few minutes. I'm not slowing it down, just making sure I can keep up.

When not to split

Splitting has a cost: more prompts, more context to hand over, more checkpoints. Don't overdo it.

  • If the change is one sentence already (a typo, a renamed variable, a log line), just ask for it.
  • If you're exploring and don't know the shape of the solution yet, let the agent explore first. Split once you know what you're building.
  • If slices are so small that each one needs the whole feature explained again, they're too small.

The mindset shift

Agents are getting better at big tasks every few months. My ability to review a huge diff isn't.

So I've stopped asking "can the agent do this?", because it usually can. I ask "can I prove this is right?" If I can't, the task is too big, and I cut the task, not the review.

This is part 2 of my Agentic Engineering series. Part 1: My AI agent said "done." It wasn't. Next up: getting an agent to stop and ask before it changes your architecture.

Further reading