Most engineering teams now write code with an AI assistant. The next step is already here: agents that pick up a task on their own, work in the cloud while nobody watches, and come back with a pull request that has already been tested.
From a trend to common practice
Stripe’s Minions merge more than a thousand pull requests a week that contain no human-written code. Engineers start them from a Slack thread or a button on a flaky-test ticket, each runs in its own isolated dev machine, and a person reviews the result.
Stripe isn’t an outlier. In The state of the tech industry in 2026, The Pragmatic Engineer lists internal agent platforms at Ramp, Uber, Shopify, Spotify, Block, DoorDash, Dropbox and a dozen more, and notes that most mid-sized and larger companies have built their own. It also reports that agent-authored pull requests grew ninefold in eight months.
Unattended agents have stopped being an experiment. The open question is how a team that isn’t Stripe gets one working on its own codebase.
Why the assistant on your laptop isn’t enough
A local assistant like Claude Code or Cursor makes an engineer faster, but it still runs on that engineer’s attention. Someone has to start it, answer its questions and check its work, and most people can juggle only a handful of sessions before switching between them costs more than it saves.
An autonomous agent changes the model. You hand it a task and get back a reviewable result some time later, while you do something else. The engineer’s day starts to look like an event loop: start tasks, review what has come back, step in where judgement is needed. Work that used to be synchronous becomes asynchronous.
The economics of the long tail
Every engineering organisation has a backlog of work that matters but never wins a sprint: production errors, flaky tests, dependency and security updates, outdated docs, bugs that affect a few customers, small requests from ops. The code is rarely the expensive part. The cost is everything around it: triage, grooming, estimation, planning, context switching, review and release.
That overhead made the long tail uneconomical, so it stayed in the backlog and slowly made the product worse. Agents change the maths. In the system we built for an e-commerce client, a working run costs about $20 in model usage and under a dollar of compute. At that price, a lot of work that was never worth scheduling is suddenly worth trying.
The work doesn’t become free. The main remaining cost moves to human review, which is why trust, not code generation, becomes the thing to optimise.
Why many attempts stall
In our experience the model is rarely the bottleneck. Teams that struggle usually make one of these mistakes:
- The agent can’t run anything. If it can only read and edit code, it can’t reproduce a bug, run the tests or click through the app, and the quality shows.
- Feedback comes too late. Open a pull request, wait for CI, feed the failure back, repeat: slow, expensive, and noisy for reviewers.
- Humans sit in the middle of the loop. An agent that stops to ask in Slack and waits for an answer isn’t autonomous.
- Nobody plans for the output. Once it works, pull requests arrive faster than the team can review them, and the queue becomes the new bottleneck.
What it takes to build one
The setups that work, Stripe’s and ours included, share the same building blocks:
- A sandbox per task. A short-lived, isolated cloud environment with the code, dependencies, running services, test data, a browser and a terminal: everything an engineer has locally.
- A dispatcher. One entry point for work from wherever it starts: a schedule, a ticket, a monitoring alert, a chat message, a pull request comment.
- An orchestrator. Code handles the predictable steps such as provisioning, git, gates and delivery; the model handles investigation and implementation. That keeps runs cheaper, more consistent and easier to debug.
- A verification harness. Linters, types, the right subset of tests and a QA pass in the browser, all run before a person sees the change.
- Observability and memory. Logs and artifacts for every run, and lessons the agent saves and reuses, so it doesn’t repeat the same mistake on the next task.
- A trust layer. Preview environments, targeted end-to-end tests and automated review, so a person can verify a change in minutes.
“We’re accumulating code faster than we’re accumulating trust.” — Kent Beck
A capability, not a product
Factories are a useful comparison. Lights-out factories have been a goal since the 1980s, yet most plants run as hybrids, with machines doing the repetitive work and people designing, supervising and improving the lines. And no factory makes cars, chips and medicine on the same line: each is built for what it produces, from shared machinery.
Autonomous coding agents work the same way. Sandboxes, orchestration and harnesses are common concepts, but how a run provisions your services, which tests count as proof and who reviews what all depend on your stack, your infrastructure and your team. That’s why companies build their own, and why buying a generic platform in a market that changes every quarter is a risky bet.
What it looks like in practice
This year we built an autonomous agent for a multi-tenant e-commerce platform, on infrastructure the client already had. It started with one job, triaging production logs every day, and grew to take tickets and pull request comments. In three months it opened 88 pull requests and the team merged 57, 89% of them without a line of human code.
The biggest surprise was who used it. QA engineers find a bug in end-to-end tests and have the agent fix and ship it without a developer. Product managers pick suitable items off the roadmap and ship them themselves. The full story is in the case study.
Start small, start now
You don’t need to automate everything at once. Pick one line of work that is bounded, easy to verify and constantly deprioritised, such as production errors, security fixes or small bugs. Build the sandbox and the harness for it, measure what gets merged, then add the next line. Each one reuses the infrastructure the last one built.
Models keep getting better, so teams with the infrastructure in place will be able to hand agents bigger tasks without rebuilding anything. Teams without it will still be setting up sandboxes. That gap is where Aleph One helps: we design and build autonomous agents around your codebase and your process, and stay until your team runs them on its own.
FAQ
Does an autonomous agent replace engineers?
No. It takes on bounded, verifiable work that would otherwise wait in the backlog. Engineers decide what to delegate, review the results and spend more of their time on the work that needs them.
Which tasks are a good fit?
Tasks that are clear to reproduce, scoped to one application, easy to test and light on visual design: production errors, security fixes, small bugs, business-rule changes and maintenance.
Do we need new infrastructure?
Usually not much. We build on your existing cloud, CI and ticketing tools: the sandbox can run on a CI service you already pay for, and tasks start from the tools your team already uses.
