We're open-sourcing DevBox, our autonomous engineering harness

DevBox is an open source engineering harness you hand a task to the way you would a teammate. It works out which repositories need to change, makes the change, tests it, reviews its own diff, and opens a draft pull request. It's MIT-licensed, runs on your own infrastructure, and talks to your own model endpoint. The code is at github.com/rudderlabs/devbox.

We've been running DevBox across our own engineering organization since April. And since then:

• 1500+ pull requests
• 80% merge rate
• 66 repositories touched

The backlog that never moves

Every engineering organization carries work that's clearly worth doing and never worth prioritizing. An API client that needs one more field mapped. A test with a timeout too tight for CI. A dependency pinned three minor versions back. Documentation that drifted from the code six weeks ago.

None of it competes with roadmap work, so none of it gets scheduled. It accumulates, and the cost shows up somewhere else: the flaky test everyone reruns, the integration gap that becomes a support ticket, the upgrade that turns into a week of work because it never got the hour it needed.

The work is understood. Most of these tickets could be written precisely in about two minutes. They sit because no engineer has a free afternoon.

We built DevBox for that work, and we're releasing it under the MIT license.

What DevBox does about it

DevBox works from Linear. Assign it an issue, or mention it on one. What comes back is a draft pull request that DevBox has already tested and reviewed itself. You review that pull request on GitHub and leave your comments there, or you reply in the Linear session instead. Either way it pushes new commits to the same branch.

The scope is deliberately narrow. DevBox handles short to medium tasks that are already well understood. It doesn't replace an engineer designing a complex feature, and we don't run it that way. Human review and steering are part of the design. Follow-up rounds handle corrections: a missed edge case, a test to add, a naming convention to respect. They aren't for redesigning the approach.

Each agent writes down what it's doing, in the Linear session as it goes: the decision it took and the alternative it passed over, the correction a reviewer gave it, the mistake it made and what the right answer turned out to be. The decisions explain why the pull request looks the way it does, which is usually a reviewer's first question. A mistake that keeps coming back points to a gap in your documentation, or to code worth restructuring so the mistake can't happen.

After implementation, a distillation stage decides which of those observations are worth keeping and files them by domain into the repository's knowledge files: architecture, conventions, patterns, entry points, the stack. Those files are committed in the same pull request as the code change, so new knowledge arrives for review next to the work that produced it.

When DevBox learns something wrong, you see it in the diff and correct it, the same way you'd correct a misleading comment or a stale README.

It follows your conventions

The objection we hear most about coding agents is that they write code the way an outsider would, ignoring conventions a team spent years settling.

DevBox reads its instructions from the repositories it works on. Build commands, test commands, naming rules, the patterns you want and the ones you've banned live in files like AGENTS.md at the repository root, next to the code, reviewed like everything else. DevBox can only follow conventions you've written down.

Most of those conventions live in skills, self-contained packages of instructions and expected workflows that sit in the repository alongside the code. A skill describes how one kind of work is done here, such as how a migration is written, or which checks run before a change counts as finished.

DevBox runs each stage as a separate agent and hands each one the skills it needs before the work starts.

How it works

Assigning a Linear issue to DevBox calls a webhook on its control plane. The control plane asks OpenSandbox for an isolated environment for that one task, starts it, and watches it.

From there DevBox is on its own. The harness runs inside the sandbox, carries out the task, and reports progress back to the control plane, which posts it to the Linear issue as it goes. At the end it opens a pull request. Nobody has to intervene before that point, and in practice people rarely do.

Leaving DevBox alone like that is only reasonable because the sandbox is sealed. Everything it sends out goes through iron-proxy, which adds the real credentials the sandbox never holds, and refuses any host that isn't on the allowlist.

Once the pull request exists, the control plane watches for your response: a review or comment on the pull request, a failed CI run, or a message in the Linear session. Any of those starts another round of work on the same branch.

The control plane is a Bun service with Postgres, sandboxes come from OpenSandbox (containers on a laptop, pods on a cluster), the agents are built on DeepAgents, and iron-proxy handles egress. The whole thing installs from a Helm chart.

Inside the sandbox the work moves through fixed stages, and each stage is its own agent. The first reads the repositories and your conventions. The next decides which repositories to change and writes a plan, and another agent argues with that plan before a line of code is written. Implementation runs one agent per repository. Then up to six reviewers go over the diff at the same time, each looking for a different class of problem, and a fix pass either resolves what they found or records why it disagreed.

Each agent can run on its own model and reasoning effort. Review can run on a stronger model at high effort while the early reading stages run cheaply, so cost and quality are set per stage instead of once for the whole pipeline.

Why it's safe to point at your private repositories

Most teams hesitate before giving an autonomous process a token with write access to their source code. Five properties of the design address that.

• Your credentials never enter the sandbox. It receives dummy values for the GitHub token and the model key, and iron-proxy substitutes the real ones as requests leave.
• The sandbox can only reach hosts you allow. iron-proxy is its only route out and its only name resolver, and anything not on the allowlist is refused, so nothing in the sandbox can send your source code to a host that isn't on the list.
• Writes are limited to the repositories you list. Anything outside that list is refused at the proxy rather than discouraged in a prompt.
• DevBox only takes instruction from people you designate, because anyone who can comment on a pull request could otherwise try to steer it. You name the trusted organizations and users, and if you name nobody it reads no pull request discussion at all.
• Each task gets its own environment. Tasks don't share a workspace, so one can't corrupt another's branch or state.

For production, run DevBox on Kubernetes, where each task is its own pod and the egress rules are enforced by network policy. You can go further and give sandboxes a runtime class, so each one is a Kata Containers virtual machine instead of a container sharing the host kernel. The chart ships a production example that does that, on dedicated nodes. The Docker Compose path exists so you can try DevBox on a laptop in an afternoon. It isn't the shape to run a team on.

What it has done for us

We run DevBox across our own engineering organization. Over the last three months it has merged 734 pull requests across 60 repositories, and 80% of the pull requests it took to a decision in that period were merged. The rest were closed after a person read the change and judged it not worth taking.

The rate rose every month: 72% in August, 79% in September, 91% in October. Our read is that two things changed. DevBox got more capable, and we got better at briefing it.

A third of it is small features. They're small in a specific way: one more field in a mapping, an audit for an API version change, a configuration flag behind a safe default. Work that can be specified precisely and is never urgent enough to schedule.

One recent example: a new customer hit a bug in one of our integrations in their first weeks with us. DevBox had a pull request open 21 minutes after an engineer approved the work, and the fix was live for every customer that afternoon.

The pull request that relicensed DevBox under MIT, ahead of this release, was opened by DevBox.

Where it doesn't work well

DevBox fails in predictable ways, and the failures cluster into three kinds.

• Vague tickets produce vague changes. A one-line issue with no detail gets a change that misses the point. What works is a spec. An engineer refines the requirements into the issue description before delegating, and that moves the outcome more than any configuration we've tried.
• Tribal knowledge is invisible to it. When a workflow lives in people's heads instead of in the code, DevBox can't follow it and will confidently do something else. Write it down in the repository, or teach it through follow-up comments on the pull request, which the distillation stage then records for later tasks.
• The harness needs an image built for your stack: the toolchain, the versions, and the dependency trees that are slow to resolve from scratch. Build that image before you judge the results.

These are the problems a new engineer hits in their first week, and they respond to the same fixes.

If your team requires a review before merge, someone still reviews every pull request DevBox opens. Those pull requests are easier to review. Each covers one task, follows the conventions you wrote down, and comes out of the same plan-and-review process every time. Short, predictable pull requests are cheaper to read than long, surprising ones.

Run it yourself

DevBox is MIT-licensed and self-hosted. You bring your own model endpoint and key, so your code and your prompts go to a provider you already have a relationship with. It works with OpenAI-compatible endpoints and with Anthropic's API.

Getting started takes one configuration file listing the repositories DevBox may touch and your model endpoint, then a single command to bring the stack up. The first build takes about ten minutes. Connect it to Linear and GitHub, delegate an issue in Linear, and watch the draft pull request arrive.

The source code, quickstart, and Kubernetes guide are at github.com/rudderlabs/devbox. Pick one ticket from the backlog that never moves and hand it to DevBox.