What is Autobuild?
Published May 8, 2026 · Last updated May 12, 2026 · 4 min read
Autobuild is Obvious's system for running software development work with AI agents. You give it a spec — a document describing what to build — and it decomposes the work, assigns tasks to agents, opens pull requests, and tracks everything through to merge.
This article explains what Autobuild is and how it's organized, so you can decide whether it fits your workflow before you spend time setting it up.
What Autobuild does
When you point Autobuild at a spec, it creates an initiative — a container for the work described in that spec. From there it breaks the initiative into features (logical chunks of work) and executables (the individual tasks an agent will complete, one at a time).
Most executables produce a pull request. The agent reads the task, writes the code, opens a PR, and hands it back to you for review. Some executables produce other outputs — documents, configuration changes, or research — depending on the task. You stay in the loop on every decision point; Autobuild handles the work in between.
If something goes wrong mid-task, you can ask an agent to babysit a stalled PR — dispatching it back to the agent for another pass without starting over.
How work is organized
Autobuild uses a three-level hierarchy:
Initiative
├── Feature
│ └── Executable
└── Executable (direct child)
Initiative — the top-level goal. Corresponds to a feature, a sprint's worth of work, or any bounded deliverable you'd write a spec for. You set the priority and assign an owner.
Feature — a logical sub-group within an initiative. Not every initiative needs features; simple work can attach executables directly to the initiative.
Executable — the atomic unit. One task, one agent, one PR. An executable has a status that tells you exactly where it is:
| Status | What it means |
|---|---|
| planned | Queued, not yet started |
| queued | Handed to an agent, waiting to start |
| in progress | Agent is actively working |
| in review | PR is open and waiting for your review |
| paused | Work paused, will resume when unpaused |
| blocked | Waiting on a dependency |
| failed | Something went wrong — needs attention |
| completed | Work done |
| cancelled | Closed without completing |
What you see in the dashboard
Autobuild has its own section in the sidebar, labeled Autobuild. It lists the projects connected to active initiatives.
The Autobuild home has six tabs:
| Tab | What it shows |
|---|---|
| Overview | A stats bar (counts of active work by status), an activity grid showing executable activity across your initiatives, and analytics widgets (PR activity, leaderboard, delivery time, recent initiatives, recent bugs) |
| Pull Requests | All PRs Autobuild has opened, with CI and review status |
| Board | Executables organized by status |
| Initiatives | Cards for each initiative with progress and health chips |
| Settings | GitHub connection, Triage Project, repo sandboxes |
| Issues | Bug reports and improvement requests linked to Autobuild work |
At the top right of the home, a Mine / All toggle filters the view to work you're directly involved in or the full workspace.
If you've never used Autobuild before, you'll see the empty state instead of tabs. It shows three setup steps:
-
Connect GitHub so Autobuild can open and track PRs
-
Open a project that has a spec (a document describing what to build)
-
Ask the agent to build your spec — it will create an initiative, decompose it into features and tasks, and start working
How GitHub connects
Autobuild needs a GitHub App installed on your organization to open and track PRs. You install it from the Settings tab (or from the empty state). Once connected, you'll see your repositories listed and can import them into Autobuild.
For each imported repository, Autobuild can provision a repo sandbox — a pre-built checkout of the repo that agents use to run code safely. Sandboxes have their own status:
| Status | What it means |
|---|---|
| Available | Ready to provision a sandbox |
| Pending | Sandbox is being set up |
| Building… | Building the snapshot image |
| Ready | Sandbox is ready for agents to use |
| Failed | Sandbox build failed |
Before you set it up
To use Autobuild you need:
-
A GitHub organization where you can install a GitHub App
-
At least one Obvious project with a spec document
-
Workspace admin access to configure the GitHub connection and Triage Project
Next steps
-
Connect GitHub — go to Autobuild → Settings → install the GitHub App and import a repository
-
Configure a repo sandbox — once a repo is imported, provision a sandbox from Settings → Repo sandboxes → Add another sandbox
-
Start your first initiative — open a project with a spec and ask the agent to build it