Develop AI Coding Agents & Code Generation
Direct coding agents that plan and execute multi-step tasks, generate and refactor code, and hand you reviewable diffs. The job shifts from typing every line to scoping, steering, and reviewing.
What is the Develop Phase?
The Develop phase is where AI does the most visible work - and it has changed the most. AI has moved past autocomplete and inline suggestions to coding agents that take a scoped task, plan it, and execute it across multiple files before handing you a diff to review. Those agents also run in the background now - in a cloud sandbox or a separate worktree - so several can work in parallel while you review what comes back.
That changes the developer's role rather than removing it. You spend less time typing every line and more time writing clear specs, giving the agent the right context (a repo instruction file such as AGENTS.md or CLAUDE.md, plus MCP-connected tools), steering it when it drifts, and owning the review of everything it produces. The agent is fast and tireless; the judgment, architecture, and accountability stay with you.
In the Develop phase, AI helps you:
- Execute scoped, multi-step tasks as a coding agent
- Generate code that follows your project's patterns and style
- Refactor existing code for better performance or readability
- Debug issues by analyzing error messages and code flow
- Explain unfamiliar code or complex algorithms
The discipline that makes this work - clear context and rigorous review - is its own skill. See Context & Spec-Driven Development and the AI Agents & Tools guide.
Quick Reference
Coding Agent
Working, tested code
Claude Code, Cursor, Copilot, Codex
The engineer who owns the ticket; a human reviewer approves the merge
Reviewed pull request merged by a human
Inputs and Outputs
Develop is where the spec becomes working code. It is also where the volume of change is highest, so the artifacts it hands over are chosen to keep human review tractable.
What it receives
- The approved Spec and the API and data contract from Ideate.
- The repo instruction file, which tells the agent how to build, test, and follow conventions, and where the risk tiers sit.
- The ADRs that constrain the design, so an agent does not quietly reopen a settled decision.
- An agent with its own identity, scoped permissions, and a sandbox or worktree to work in.
What it hands off
- A Ticket Contract for each slice of the spec: acceptance criteria, data touched, risk tier, flag, and rollback.
- An approved Plan for each ticket, written by the agent and approved by a human before any code is written.
- A reviewed, risk-tiered Pull Request with tests, a stated model and task source, and what a human verified.
- Merged, working code that the Launch phase can test, release, and roll back.
Slice, plan, then diff
The order matters. The ticket contract fixes what done means. The plan, covered under plan first, lets a senior engineer catch architecture mistakes in minutes instead of in a long diff. Only then does the agent implement, in the small batches described under small batches.
Key Activities
Agentic Task Execution
Hand a coding agent a scoped task and it plans the steps, edits across multiple files, runs commands, and returns a diff - following your project's patterns and style.
Real-Time Review
AI reviews your code as you write, catching bugs, security issues, and suggesting improvements before you commit.
Refactoring
AI helps refactor legacy code, extract reusable functions, and improve code structure while maintaining functionality.
Debugging
AI analyzes error messages, stack traces, and code flow to identify root causes and suggest fixes.
Example Workflow
Slice the Spec into Tickets
Break the spec into thin, independently shippable slices. Write each as a ticket contract with Given/When/Then criteria, a risk tier, a feature flag, and a rollback plan.
Pick the Agent and the Lane
Match the agent to the work. Choose by fit, not by ranking; see Choosing a Coding Agent. Keep unattended work on the safe class; see Agents in the Pipeline.
Plan First, Then Approve
The agent reads the repo and proposes a plan: files, interfaces, migrations, test surface, blast radius, and rollback. A senior engineer approves or revises it.
Tests From the Criteria
Generate the tests from the acceptance criteria before the implementation exists, then implement until they pass.
Implement in a Small Batch
The agent works in a sandbox or separate worktree and returns a diff under the size cap, with its model version and task source stated.
Review at the Tier
AI pre-review clears the mechanical comments. A human then reviews to the standard of the ticket's risk tier, using the reviewer checklist.
Merge and Move to Launch
A human merges the approved pull request, usually through a merge queue. The merged work becomes the input to the Launch phase.
Risk-Tiered Review
Uniform review collapses when agents raise the volume of pull requests. Instead, each change is classified against the approved plan and the code-ownership map, and review effort follows the risk. The full model is on Engineering Practices and AI Code Review at Scale.
Low risk
Scope: Docs, copy, tests, flag-off scaffolding, and safe-class dependency bumps.
Review: Can merge on green checks, with a human sampling the merges on a regular cadence.
Agent-authored: Yes.
Standard
Scope: Ordinary feature work behind a flag.
Review: One human reviewer, after AI pre-review has cleared the mechanical comments.
Agent-authored: Yes, and labeled as such.
High risk
Scope: Authentication, money and eligibility logic, personal data paths, migrations, rule engines, external adapters, and infrastructure.
Review: Two humans plus an architect. No AI auto-approval.
Agent-authored: No.
Who Owns It
The engineer who owns the ticket is accountable for the result, whoever or whatever typed the code. A reviewer approves the merge. For the highest risk tier, an architect joins. Accountability does not transfer to the agent.
What the AI drafts
- The plan, the tests, the implementation, and the pull request description.
- The first review pass: mechanical issues, style, and obvious bugs.
- Refactors, debugging hypotheses, and explanations of unfamiliar code.
- Repair attempts when a check fails, within a fixed number of tries.
What humans decide
- Whether the plan is the right plan, before a line is written.
- Whether the diff does what the ticket asked and nothing else.
- Anything that touches the highest risk tier.
- The merge. Agents never approve, merge, or re-request review on their own pull request.
Entry and Exit Criteria
Entry criteria
Start the phase when all of these are true.
- A human has approved the spec and the contract.
- The repo instruction file is current and the risk tiers are mapped to paths.
- The ticket exists as a contract: criteria, data touched, tier, flag, and rollback.
Exit criteria
A ticket leaves the phase only when all of these are true.
- The plan was approved by a human before implementation.
- The pull request is within the size cap and links its plan and ticket.
- Tests cover the acceptance criteria and pass in CI.
- Review was done to the standard of the risk tier, and the reviewer checklist is complete.
- A human merged the change.
Best Practices
Give Context
Always provide AI with relevant context - your project structure, coding standards, and the specific problem you're solving.
Review Every Agent Diff
An agent can change many files at once. Read, test, and understand the full diff before committing it - you are accountable for code you did not type.
Iterate on Prompts
If the first result isn't right, refine your prompt. Be more specific, provide examples, or break the task into smaller pieces.
Approve the plan, not just the diff
A plan is quick to read and catches design mistakes while they are cheap. A large diff mostly catches typos.
Don't Skip Security
AI may generate code with security vulnerabilities. Always run security scans and review for common issues like injection attacks.
Anti-Patterns
These patterns are catalogued on Twelve Ways AI Adoption Fails. Four of them live inside the Develop pipeline itself.
Era 3 Tooling on Era 2 Process
Agents open pull requests into a review process built for one human reading another human's diff. The queue backs up, or reviewers skim and the reviews go shallow.
Coverage as the Test Gate
Generated tests assert almost nothing but still count as coverage. A green build proves little until a mutation score checks that the tests notice a change.
Personal Tokens in CI
An agent workflow authenticates as whichever developer set it up. Its actions are unattributable, and the pipeline breaks when that person leaves.
What to Measure
Develop is where output is easiest to inflate, so measure delivery and quality together. The set below comes from Measuring Impact.
PR review turnaround
Review time is the constraint that agents shift rather than remove. Read it relative to PR size, not alone.
Cycle time, ticket to production
The honest measure of whether faster typing became faster delivery. Track the median and the 85th percentile.
Change failure rate
If it rises while output rises, speed was bought by lowering the bar.
Bug escape rate
Defects reaching production, counted the same way before and after adoption.
Go Deeper
PR template
Fields that make AI involvement, plan approval, and mutation coverage visible.
Read moreReviewer checklist
A checklist for agent-authored diffs, aimed at the failure modes generic review misses.
Read moreChoosing a Coding Agent
A rubric for picking an agent by fit, run as a fair trial on your own code.
Read moreA worked example
One feature carried through all five phases, with real tickets and plans.
Read moreFrequently Asked Questions
Agentic coding means delegating a scoped task to an AI agent that plans the work, edits across multiple files, runs commands, and returns a diff for you to review. Unlike autocomplete it executes multi-step work; unlike vibe coding, the developer reviews and owns every change.
No. Agents can produce a lot of code quickly, but developers stay in control. You define the task and context, review every diff, and own architecture, security, and complex logic. The shift is from writing every line to directing and verifying the work.
Small enough that a reviewer can hold the whole change in mind and judge it against the approved plan. Agents make large diffs cheap to produce and expensive to review, so many teams cap pull request size in the pipeline and ask for a split when a change passes the cap. Working in small batches is the practice that keeps review from becoming the bottleneck.