Course outline
Agentic Engineering: the hands-on course · Module 3: Planning & task design
Sizing tasks for agents
Too small and you waste time briefing. Too big and the agent drifts. Learn to size work by how fast you can verify it, and find the sweet spot.
Lesson 9 / 24 · ⏱ 7 min
When a delegated task goes badly, I rarely blame the model first. Most of the time the task was the wrong size. Either I spent longer briefing than typing the fix, or I handed over something so big that the agent made twenty decisions I never saw.
Sizing is the first planning skill. Get it right and everything after it, briefs, plans, reviews, gets easier.
The sweet spot
The curve isn’t measured data, it’s the shape I see in practice. The left side is obvious: renaming a variable through an agent is slower than doing it. The right side is the trap, because big tasks feel like the best use of an agent.
Size by review cost, not writing cost
Agents make writing code cheap. They don’t make reading it cheap. So the real question is not “how long would this take me to write?” but “how long will it take me to trust the result?”
✕ Too big
- –“Add multi-tenant support to the app”
- –Done means “it works”, whatever that is
- –Touches schema, API, UI and auth at once
- –Diff you’d need an afternoon to review
✓ Agent-sized
- +“Add a tenant_id column and scope the orders query by it”
- +Done means these three tests pass
- +Touches one area of the codebase
- +Diff you can review with a coffee
My rough test has four questions. Can I state the outcome in one sentence? Can a command tell me it worked? Does it stay in one area of the code? Can I review the diff in one sitting? Four yeses: delegate. Any no: split it or shrink it.
Play: what would you do with this task?
🎮 Size the task
1 / 8 · Score: 0
Sort each task: do it yourself, hand it to an agent as is, or split it first.
Before you move on
✅ Key takeaways
0 / 4 completed