Most developers using AI coding tools have exactly one mode: type a prompt, hope for the best. A new practitioner framework from developer Jason Robert lays out four distinct patterns for AI-assisted coding, each calibrated to task complexity, and the argument is convincing enough to be worth adopting.
The core idea is simple: stop using the same approach for a variable rename and a full feature build. Robert breaks AI-assisted development into four escalating patterns, each with a time estimate and clear triggers for when to level up.
One-Shot Edits and Plan Mode
One-shot editing (~1 minute) is what most people already do. You know exactly what you want, you tell the assistant, it does it. Variable renaming, null checks, import cleanup. The key insight here isn't the pattern itself but knowing when to leave it: if you're writing multi-paragraph explanations of what you want, you've outgrown one-shot.
Plan mode (~2-3 minutes) adds a collaboration step. The AI presents its understanding of the problem and its intended approach before writing any code. You redirect before it commits. This is where tools like Claude Code and Cursor already shine with sub-agents that can explore different parts of a codebase in parallel. Robert gives a practical example: creating an API endpoint where the assistant surveys the codebase, proposes schema updates, routes, controllers, and tests, and you catch what it missed (like authorization middleware) before it writes a line.
Spec-Driven Development
This is where the framework gets interesting. For medium-to-large tasks (~5-10 minutes), Robert argues you should have the AI produce a markdown spec file before generating any code. The spec describes what's being built, why, and how.
The benefits are real: the spec becomes a reviewable artifact you check into your repo, reviewers can evaluate design decisions before implementation, and when you hand a well-written spec to a coding assistant, the output quality jumps noticeably. Robert mentions tools like SpecKit and GSD (Get Shit Done) for this workflow, and suggests teams review specs before implementation, the same way they review code.
Multi-Agent Workflows for Large Features
The heaviest pattern (~10-30 minutes) uses multiple specialized agents with deterministic routing defined in YAML, not managed by an LLM. An architect agent generates a solution design, a content reviewer scores it on accuracy, completeness, consistency, and feasibility (0-100 scale), plans scoring below 90 go back for revision, and a readability reviewer does a final pass.
Robert reports that two or three iteration cycles usually produce a strong spec, though complex designs sometimes need five or six rounds. The tradeoff is token cost: multi-agent workflows burn through tokens fast, and managing context modes (accumulate, last-only, explicit) is still experimental.
The Real Takeaway
The most useful observation in the piece isn't any single pattern but the calibration problem. Robert notes that "the most common mistake I see is engineers either defaulting to one-shot for everything or overinvesting in elaborate workflows for simple changes." Both waste time, just in opposite directions.
The framework is deliberately tool-agnostic. It applies whether you're using GitHub Copilot, Claude Code, Cursor, or OpenCode. That's the right call since the tools keep changing every few months, but the patterns for working with them effectively are more durable.