Developer Workers

A Developer worker is a Virtual Worker that does hands-on code work in a real container: bug fixes, test-writing, dependency bumps, doc sync, and low-risk refactors, the delegable toil that pulls senior engineers off higher-value work. It runs on a coding-agent account you link, so your own model quality and quota carry over, and it prepares a change for a person to review. Push code is locked to Always supervised: no setting lets a worker push on its own. After this page you will be able to put a Developer worker to work, understand its container and provider account, and use the no-push floor well.

Developer workers use the Developer permission role and run in a container, on a linked coding-agent account. Container time is metered on usage credits for as long as the worker's container is up. See AI Connection and Budgets for linking an account and keeping it inside its provider limits.

What to Delegate, and What Not To

After this section you will be able to scope a Developer worker to work it does well. A Developer worker is a force multiplier on well-defined tasks, not a replacement for engineering judgment. Give it work that is bounded and checkable:

  • Bug fixes with a clear repro and expected behavior.
  • Writing tests for existing code paths.
  • Dependency bumps and routine maintenance.
  • Documentation sync when code and docs drift.
  • Low-risk refactors with a defined scope.

What it should not do is decide architecture, or ship anything unreviewed. A coding agent can produce a confident but broken change, often enough that letting it merge on its own is a mistake. Backbuild is built around that risk, which is why the next section keeps every push with a person.

The No-Push Floor

After this section you will be able to tell a tech lead exactly where the line is. Push code is one of the two capabilities locked to Always supervised: the server keeps it supervised whatever a request asks for, so no autonomy setting lets a worker push on its own. A Developer worker edits files, runs tests, and prepares a complete change inside its container, and you review it there: open its VS Code editor or its terminal for that slot, read the change, run it, and decide. The worker's job is to get a reviewable change to your door, not to walk through it.

Like every autonomy setting, the floor records your rule rather than blocking a command at the moment it runs (see Autonomy and Approvals), and this release has no screen that gives a worker write access to your repositories. Your organization's read-only repository access, when it is set up, lets a worker fetch a read-only copy of a repository, never push. Keep it that way: never put a credential that can push into a Developer worker's container, and its changes wait there for a person.

Does pushing code require approval, or can it merge to main unattended? Push code is locked to Always supervised and cannot be set to autonomous, and this release has no screen that gives a worker write access to your repositories. Keep any credential that can push out of a worker's container, and its change waits there for you to review.

How well does it actually do the work? Scope it to well-defined, checkable tasks, bug fixes, tests, dependency bumps, doc sync, and treat it as a force multiplier whose output you review. The transcript records exactly what it did, and you review the change before anything lands.

How a worker's change reaches you 1. A task is assigned a bug fix, a test, or a dependency bump 2. It works in its container edits files and runs the tests 3. It prepares a change with a written description 4. A person reviews the change in the slot's VS Code or terminal Push code: Always supervised no setting lets a worker push alone
A Developer worker works in its container and prepares a change for a person to review; Push code is locked to Always supervised.

The Container and What the Worker Can Reach

After this section you will understand where a Developer worker runs and what it can reach. A Developer worker operates a real, isolated container, the same on-demand cloud computer you can launch yourself, with a terminal and a full editor for each of its slots. You choose its size, from the sizes your organization's container policy allows, and lay out its slots, how many run at once, which tool each runs, and how much memory each gets, when you configure the worker (see Configure step 2). The container can run in Backbuild's cloud or on one of your organization's own Docker hosts, added under Settings, then Administration, then Remote Hosts (see Remote Hosts). Its reach is bounded by its Developer role: the tools a run may use come from that role, a skill can narrow them but never widen them, and nothing in a ticket or a message can add one. Push code stays locked to Always supervised.

You can watch a Developer worker at work from its page: one terminal and one VS Code editor per slot, so you open exactly the slot whose files you want to read. Turn on Connect in read-only mode by default and its terminals open read-only until you choose Take control, so looking over a worker's shoulder never means typing into its session. See The Worker Page.

Bring Your Own Provider Account

After this section you will be able to run a worker on your own coding-agent subscription. A Developer worker's coding agents run on a coding-agent account you link, so the exact model and quota your team already pays for carry over to the worker. In this release they do not run on platform credits. You link the worker's own provider-native account in Configure step 5, by signing in to it in a temporary Backbuild container terminal or with an API key. Linking the account and keeping it inside the provider's 5-hour and weekly limits with the usage throttle are covered in AI Connection and Budgets.

Whose provider account and quota does a Developer worker use? Whichever you link. Point the worker at its own coding-agent account and it uses that subscription's model and quota, and link several accounts per tool to share the work or fail over between them. You choose the source explicitly.

Where a Worker's Secrets Are

After this section you will be able to answer the secret-leakage question. The credentials a worker uses, its linked provider sign-ins, live in your organization's zero-knowledge, post-quantum secrets vault; an API key linked instead is encrypted by Backbuild before it is stored. When the worker's container starts, each account is restored into the container for the coding tool in its slot: only that slot can read it, it is not saved in the home folder, and it is left out of the session logs the container uploads. No Backbuild tool reads a stored value out of the vault. The coding tool and the work it does run as the same slot, so that slot's work can reach its linked account and anything else in the container, including the repository it works on. Link accounts dedicated to the worker, and keep other secrets out of the repository and the container. The full treatment is in Security and Governance.

Will a worker leak secrets into logs or read my environment file? A worker can read what its container holds, including an environment file committed to the repository it works on, so keep secrets out of the repository. Its linked accounts are not saved in its home folder or its uploaded session logs, and no tool returns a stored vault value. Review every change it prepares before it is pushed.

Where to Next