How Linear Breaks Execution at Planning Boundaries
TRIGGER
When using coding agents for complex tasks, one-shot execution frequently fails because the agent loses context partway through and diverges from the intended approach—the larger the task, the more likely the agent goes 'off the rails.'
APPROACH
Mercury's engineering team structures agent interactions as iterative planning sessions: they describe the feature goal, go back and forth with the agent until agreeing on a plan, then execute step-by-step (e.g., 'execute step one' which might be writing test cases first). Input: feature description + conversational refinement. Output: agreed plan followed by incremental implementation. They use this for in-editor agentic chat on larger tasks.
PATTERN
“Your agent will go off the rails on large tasks—not because it ran out of context, but because it lost track of intent. The trap is chunking by lines of code or files when the real failure mode is intent drift. Break execution at planning boundaries and validate before any code to keep the agent aligned with you.”
✓ WORKS WHEN
- Task requires multiple coordinated changes across the codebase (more than 2-3 files)
- The approach has meaningful decision points where the agent could reasonably go different directions
- Engineer is actively in-editor and can provide iterative feedback within a session
- Task is novel enough that there's no existing template or example to follow
✗ FAILS WHEN
- Task is highly repeatable with established patterns (use templates instead)
- Context switching cost of back-and-forth exceeds the risk of one-shot failure
- Time constraints require fire-and-forget execution (e.g., overnight batch processing)
- Task is simple enough that planning overhead exceeds implementation time