Development Lifecycle

The 5-Phase Workflow

Agentic development follows a five-phase workflow: Explore, Plan, Implement, Verify, Commit. This is not a suggestion. Each phase maps directly to enforcement mechanisms that prevent the agent from skipping steps, cutting corners, or shipping unverified changes. Teams that collapse these phases --- letting agents jump from reading code straight to committing --- produce the same class of errors that undisciplined human developers produce, except faster and at larger scale.

The phases are sequential by design. An agent that implements before exploring will miss context. An agent that commits before verifying will ship broken code. The enforcement mechanisms at each phase exist to make it structurally difficult to violate this ordering.

graph LR
    A["Explore"] --> B["Plan"] --> C["Implement"] --> D["Verify"] --> E["Commit"]
    A -.- A1["Read-only mode"]
    B -.- B1["Human review"]
    C -.- C1["PostToolUse hooks"]
    D -.- D1["PreCommit hooks"]
    E -.- E1["Conventional commits"]

Phase Details

PhaseWhat HappensEnforcement Mechanism
ExploreRead-only investigation. The agent reads files, searches code, inspects dependencies, and builds a mental model of the relevant codebase. No writes occur.Plan mode (Claude Code), Read-Only mode (Codex). The agent is structurally prevented from making changes during this phase.
PlanThe agent proposes changes in natural language. It describes what it intends to modify, why, and what the expected outcome is. The human reviews and approves or redirects.Human review gate. In Claude Code, Ctrl+G toggles between plan and act modes. The agent cannot proceed to implementation without explicit approval.
ImplementThe agent executes the approved changes: edits files, runs commands, creates tests.PostToolUse hooks fire after every tool invocation. These hooks can run linters, formatters, or lightweight test suites automatically after each edit. Violations surface immediately, not at commit time.
VerifyThe full test suite runs. Linting, type checking, and integration tests execute against the complete changeset.PreCommit hooks block the commit if any check fails. CI pipelines provide a second layer of verification that cannot be bypassed locally.
CommitThe agent creates a commit with a structured message and opens a pull request with full context.Conventional commit format enforced via hooks. PR templates ensure the description includes what changed, why, and how to test it.

Enforcement Mapping

Every development practice can be mapped to one of three enforcement tiers: guidelines (soft, in instruction files), rules (hard, in hooks or configuration), and gates (blocking, cannot be bypassed by the agent). Production teams should push critical practices as far right in this table as possible.

PracticeGuidelineRuleGate
Write tests firstDocumented in CLAUDE.md as a convention
Conventional commitsStated in CLAUDE.md commit format sectionPreCommit hook validates message format
No push to mainStated in CLAUDE.md git workflow sectionPreToolUse hook intercepts git push to protected branchesBranch protection rules on the remote
Lint before PRStated in CLAUDE.md pre-commit checklistPostToolUse hook runs linter after every file editCI required status checks block merge
Secret detectionStated in CLAUDE.md security sectionPreCommit hook scans diff for secrets.gitignore excludes sensitive files; CI secret scanner blocks merge

The pattern is consistent: a practice starts as a guideline. When the guideline proves insufficient --- because the agent or a human occasionally forgets --- it escalates to a rule. When the rule proves insufficient --- because rules can be overridden --- it escalates to a gate. Gates are the only tier that provides deterministic enforcement.

Guidelines shape behavior in 90% of cases through cooperative compliance. Rules catch the remaining 9% through active enforcement. Gates catch the final 1% through structural prevention.

A common mistake is to put everything at the guideline tier and assume the agent will always comply. It will not. Instruction files are probabilistic. Hooks are deterministic. For anything where a violation would cause a production incident, the enforcement must be deterministic.


Getting Started Flow

Setting up an agentic development workflow requires six steps. Each step is independent: you can stop at any point and have a functional setup. Later steps add capability but are not prerequisites for earlier ones.

Step 1: Install the Agent

npm i -g @anthropic-ai/claude-code

This provides the claude command. Other agents follow similar patterns: npm i -g @anthropic-ai/claude-code for Claude Code, Codex CLI via npm i -g @openai/codex, Gemini CLI via npm i -g @anthropic-ai/gemini-cli or platform-specific installation.

Step 2: Open Your Project

cd your-project && claude

The agent starts in the project root. It automatically discovers configuration files, git history, and project structure. No additional setup is required to begin exploring.

Step 3: Create an Instruction File

Create CLAUDE.md (or AGENTS.md or GEMINI.md) in the project root. Start minimal. Cover the seven essentials documented in the Instruction Files page: project conventions, tech stack, testing, git workflow, security rules, file structure, and pre-commit checklist.

# Minimal starting point
cat > CLAUDE.md << 'EOF'
# CLAUDE.md

## Project
Brief description of what this project does and its tech stack.

## Testing
- Run tests: `npm test`
- All changes require tests.

## Git
- Branch from `main`. Conventional Commits format.
- Run `npm run lint` before committing.
EOF

Step 4: Add Slash Commands

Create .claude/commands/ in your project root. Each markdown file in this directory becomes a slash command the agent can execute.

mkdir -p .claude/commands

cat > .claude/commands/review.md << 'EOF'
Review the current git diff for:
1. Correctness: logic errors, edge cases, null checks.
2. Style: adherence to project conventions in CLAUDE.md.
3. Tests: coverage of new code paths.
4. Security: hardcoded secrets, injection vectors, auth gaps.
Report findings as a numbered list with file:line references.
EOF

The agent can now execute /review as a reusable workflow.

Step 5: Configure Tool Connections

Create .mcp.json in the project root to connect the agent to external tools via the Model Context Protocol.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "env:GITHUB_TOKEN"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "env:DATABASE_URL"
      }
    }
  }
}

The agent now has read access to GitHub issues, PRs, and your database schema without leaving the conversation.

Step 6: Add Skills as Workflows Grow

As your team identifies repeatable multi-step workflows, encode them as skills. Skills combine instruction context, tool configuration, and execution logic into reusable units. They go beyond slash commands by supporting parameterization, composition, and delegation to subagents.

Add skills incrementally. A skill is warranted when you find your team issuing the same sequence of commands across multiple sessions.


Progressive Adoption Strategy

Teams that succeed with agentic development follow a consistent adoption curve. Teams that try to deploy the full stack on day one fail. The pattern is the same across every organization that has adopted these tools at scale.

Week 1: Instruction File Only

Week 2: Add Hooks

Week 3: Add MCP Servers

Week 4: Add Skills

Month 2 and Beyond: Add Subagents and Plugins

The key principle is that each week adds one category of capability. If any week’s addition causes instability or confusion, stay at that level until the team is comfortable before proceeding.


Checkpoints and Recovery

Every action the agent takes creates a checkpoint. This is the safety net that makes aggressive experimentation viable. You do not need to be cautious about what you ask the agent to try, because every state is recoverable.

How Checkpoints Work

When the agent modifies a file, creates a file, deletes a file, or runs a command that changes state, the system records a snapshot of the affected state. These snapshots are ordered chronologically and can be navigated in both directions.

Recovery Mechanisms

ActionMechanismScope
Undo the last actionDouble-tap EscReverts the most recent agent action. Equivalent to a single-step undo.
Targeted rollback/rewind commandPresents a list of recent checkpoints. Select a specific point to restore. All actions after that point are discarded.
Full session resetStart a new sessionThe filesystem state persists, but the agent context is fresh. Combine with git checkout to reset file state.

Checkpoints change the interaction model from “supervise every action” to “review the outcome and rewind if needed.” The downside cost of a bad attempt approaches zero, making aggressive exploration the optimal strategy.


Start with Phase 1 (Explore) and Week 1 (instruction file only). Build from there. Every layer is independently valuable.