From laptop loop to governed platform

Part 5 of 5 in a series on autonomous software delivery. The previous parts introduced Ralph, our autonomous development agent, and the delivery, testing and design practices around it. This part covers how other organisations can adopt those practices gradually.

A recurring response to Ralph is understandable: “We are not ready to let an agent merge its own code.” Our setup moves human acceptance after integration, and that depends on testing, evidence and a reliable way to remove rejected changes. A team still establishing those practices has work to do before the same arrangement makes sense. But much of that work improves delivery immediately, even while humans continue to approve every pull request.

Ralph started with a simple loop: give a coding agent a task, let it work, and repeat until it finishes. Turning that into something our organization could use meant engineering the process around it. The practices in this series provide a path from that experiment to a delivery flow a team can operate and review.

Build the foundations in steps

1. Make work items usable. A request needs enough context and testable acceptance criteria for someone to build it without reconstructing a conversation from last week’s standup. Decisions should be recorded where the team can find them. This helps an agent, a new colleague and the person returning to a feature months later. For larger requests, the design phase from Part 4 settles the open choices and produces stories that each deliver something useful.

2. Make integration controlled and recovery practical. Require pull requests and passing CI checks, protect the integration branch from direct or destructive changes, and establish how rejected work is removed. In our AATB flow, merge commits support reverting a feature through another PR. The useful preparation is to practise that recovery path and understand its limits, including changes that depend on one another. Human PR approval can remain in place while a team develops confidence in these controls.

3. Make testing decisions visible. ARBT uses eight named testing steps, but another team may choose a different set. The essential agreement is which checks always run, when additional testing is needed, and how skips or blockers are reported. Evidence should connect each acceptance criterion to what ran and what was observed, with a supporting run or artifact the reviewer can open. This gives human reviewers a better basis for judging the result, regardless of who wrote the code.

4. Write down the operating procedure. Keep short instructions in the repository for starting the application, testing changes, deciding when design is needed, and reporting completion. These instructions make the team’s expectations accessible to both people and agents. They also give the team something concrete to revise when a run goes wrong, instead of relying on someone to remember an exception next time.

5. Introduce autonomy within that process. Begin with small, well-understood changes and evaluate the running results. Let the agent produce evidence while the team retains its existing approvals, then use those runs to decide where less supervision is justified. Self-merge to an integration environment and permission to release to production are separate decisions. In our case, production release remains a human responsibility.

These steps give a team useful stopping points. An agent that prepares a tested change for human review can already be valuable. Moving further should follow experience with the team’s own repositories, environments and failure modes.

What the failures taught us

The frameworks grew from runs that went wrong. Ralph once skipped starting the application for a visual change and delivered a broken screen. That led to the explicit screenshot check before opening a PR, described in Part 3. An early version tried to rework a rejected feature unattended, which taught us to make rejection end the work and return the item to the backlog. A monitoring timeout once stopped the host and interrupted active runs, so we changed failure handling to keep that peripheral check from taking down the service.

These incidents are also why success needs a broader definition than “the agent finished.” A useful run delivers behavior the human accepts, with evidence that supports that judgement. A failed run needs to leave a clear account of what happened and what remains. Recovery still takes time: someone may need to diagnose the failure, resolve dependencies or repeat verification. The purpose of the framework is to make that work visible and manageable.

Engineering the loop is the job

The opportunity is to spend less human time driving routine implementation and more on deciding what should be built and evaluating whether it works. That requires a delivery process whose requests, checks, decisions and outcomes can be inspected. More capable models may complete more work within that process; the need to establish what was requested, what changed and whether it was accepted remains.

A team can begin with the part of its delivery process that causes the most friction today: unclear requests, unreliable checks, missing evidence or difficult recovery. Improving it helps the people doing the work now and creates a better foundation for whatever autonomy comes next. That is what building Ralph has taught us, and why the work around the agent has become the central subject of this series.

The agents write the code. Engineering the loop is the job now.

Ralph is built at Rubicon, part of BBTG, where we help organisations improve their software delivery. If any of this maps to where your team is stuck, my inbox is open.