AutoCode

AutoCode runs your coding agent through planning, approval, implementation and independent validation. It saves progress and checks evidence before reporting completion. Start with a request in a committed Git project; approve the plan before implementation begins.

Documentation

Read the documentation site. Start with these five guides: install AutoCode, run your first task, understand a pause, read completion evidence, and review a pull request. The site has search, deeper guides and a version selector; latest follows master.

Install and start

Requires Python 3.11+, Git, and macOS or Linux (Windows through WSL). Install from this checkout into a virtual environment:

python3 -m venv .venv
.venv/bin/pip install --editable .
source .venv/bin/activate
autocode --version
autocode doctor --workspace /path/to/project
autocode "Build a greeting CLI" --workspace /path/to/project

On WSL, run these commands in the Linux terminal with Linux Python. An existing Windows-created .venv cannot be reused there; see the WSL checkout and environment notes.

Try the workflow without an account or model spend: autocode demo creates an offline sample, shows rejected evidence and a completion refusal, then completes with independently reproduced checks and demo acceptance. It prints the retained run and evidence paths. See the offline demo.

OpenCode 1.x is the default engine. To use a logged-in Codex CLI instead, add --engine codex, or --engine claude for a logged-in Claude Code. See installation, provider setup and model selection. If your account serves only one model, start with --single-model MODEL to run every role on it (per-role reasoning flags still apply).

To check a change made by another coding tool, supply its comparison base and your acceptance criteria to autocode verify. It checks the existing change and retains a canonical evidence report. See Standalone verification.

Reliability

AutoCode does not report completion without evidence. Live sweeps on the three-case portfolio (small new application, feature in an existing project, bug fix) are recorded in docs/reliability-table.md and RELIABILITY.md. Fake-provider rows are kept separate and never mixed with these. The table is generated, never edited by hand:

python tools/reliability_table.py docs/reliability-sweeps.json

When a run stops for input, continue it from the project or its task worktree:

autocode --status    # what the run needs
autocode resume      # continue it, acknowledging a pause (no --resume-paused needed)

AutoCode acts on the only unfinished run there. With several, it lists them and changes nothing; name one with --run-dir, which works from any directory:

autocode --run-dir /path/to/run --status
autocode --run-dir /path/to/run --chat

The workflow guide explains questions, plan approval and review. The CLI reference covers answers, approvals and recovery.

For browser, Figma or strict test prerequisites, add --task-preflight qualification/preflight.json. The preflight guide covers worker permissions, design inputs, named collection and proof setup. Failed prerequisites pause before model dispatch; readiness never replaces verification.

Build from a Figma design

This path requires native Codex, ChatGPT login and the connected Figma plugin available to Codex CLI sessions.

# Design first, or implement an existing file:
autocode ui "Design a responsive team dashboard"
autocode "Build the supplied design" --workspace /path/to/project --engine codex \
  --figma-file "https://www.figma.com/design/FILEKEY/Project"

# Implement a completed, accepted AutoCode UI run:
autocode --workspace /path/to/project --engine codex \
  --ui-run /path/to/project/.autocode-ui/runs/ACCEPTED-RUN

See Figma design and implementation for design review, accepted handoffs and visual verification. Implementation reviews use current browser capture bundles: autocode visual-capture --config capture.json records the rendered implementation and its inputs before an independent reviewer judges the images.

Give one component its own design

For an architecture with components.json, dependency_trace.json and contracts/*.schema.json, add one of these fields to the relevant component:

Choose one field per component. Only that component receives the design; components without either field use their text brief.

autocode components architecture --workspace /path/to/project \
  --options '--engine codex'

Design-bearing builds require native Codex. Plan approval and independent implementation review still apply. Repeating the command resumes saved work; a changed accepted handoff is rejected instead of silently changing the design for that build. See the complete component example for the architecture format, approvals and integration.

More guides

• Parallel task lanes and components
• Large projects and workstreams
• Execution and completion checks
• Named test proof for Python, Go, Node and Vitest
• Exact output, raw fallback and usage measurement
• Dashboard and macOS app
• Testing and scenario harness
• Check a coding tool/model's conformance
• Task-run interface for integrations
• VS Code extension
• AutoCode inside Claude Code and other agents: skill and MCP server
• Experimental OSS Arena and controlled improvement gates

Role names

The terminal and dashboard use the same job names: Requirements, Planner, Plan Reviewer, Builder, Tester, Completion Reviewer and Resolver. A configured model can perform different jobs; the current step names the job being done. See roles and reviewer-routing modes.