How Autobuild Works
Published June 3, 2026 · Last updated September 23, 2026 · 4 min read
Autobuild turns a software request into organized, reviewable work. It prepares code changes in an isolated repository sandbox and links the resulting pull requests so you can review them before anything reaches your main branch. You follow every build from one home and step in when Autobuild needs your decision. If you are new to Autobuild, start with What is Autobuild?.
How work is organized
Autobuild organizes a software request into an initiative, one or more features, and the executables needed to complete them.
An initiative is the overall body of work for your request. A feature is a coherent part of that request. An executable is a specific unit of work that Autobuild can complete and track. For example, an initiative to improve sign-in might include a feature for session handling and another for error messages. Each feature can contain executable work such as a code change or a check of the resulting behavior.
Dependencies connect work that must happen in order. An executable that needs another result waits for its prerequisite. Independent executables can move forward at the same time. This lets you see why some work is active while other work is waiting.
What each executable status means
Every executable has a status that tells you 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 and needs attention |
| completed | Work done |
| cancelled | Closed without completing |
Where to follow progress
Open Autobuild in the sidebar. The Autobuild home opens on a page that asks "What do you want to build?". Describe the work in the composer, and Autobuild starts a build from your description. Builds appear under Your builds on the same page, and you can view them as cards or as a list. Select View all to open all builds, where you can search and filter by status and decision.
Select a build to open the build drawer. The drawer shows the build's name, project, status, owner, and age at the top. While the build works, you can follow its plan and see each task in it. When Autobuild needs you, the drawer shows the decision waiting on your input, with the options you can choose between. When the build completes, the drawer shows a summary with links to the work.
Review pull requests on the PRs page. Each PR is linked to the work that produced it.
Bug reports live in Atlas. Improvement requests live on the Improvements page. Neither appears on the Autobuild home.
For a walkthrough of your first build, see Your First Initiative.
How code changes are prepared
Code work happens in a sandbox: an isolated environment prepared from your connected repository. Autobuild can make and check changes there without changing your main branch.
When a proposed code change is ready for review, Autobuild links it as a pull request. A pull request lets you inspect the change before it is merged. Continuous integration (CI) means automated checks that run against a pull request before the change is ready to merge. These checks help surface problems while the change is still reviewable.
Where approval is required
Autobuild prepares work for review; it does not replace your judgment. Before a change reaches your main branch, review the pull request and confirm that it matches your request and your team’s standards. If the checks surface a problem or the change is not what you expected, keep it out of the main branch until it is corrected.