Governing the plan, not just the code

Part 4 of 5 in a series on autonomous software delivery. Part 2 and Part 3 covered how our agent Ralph delivers and tests a feature. This part covers the design decisions that need human agreement before implementation.

The delivery loop described so far assumes the request fits in one autonomous run: implement, test, merge, deploy, then let a human judge the result. That works for a bug fix or a small feature. But a request like “turn the app into a multi-tenant platform with organisations, roles and billing” contains decisions that will shape much of what comes afterward. How are organisations isolated? Can someone belong to several? Who owns the subscription? Passing tests cannot establish whether the agent chose the arrangement the organisation wanted.

For work like this, we added a design phase. Ralph researches the existing application, weighs the options and proposes a plan for human approval before writing implementation code. The purpose is to settle consequential choices while they are still proposals, before they become assumptions embedded across the application.

A design people can review

The design brings the goal, alternatives, recommended architecture, relevant data model and screen concepts together in one document. It also proposes stories with acceptance criteria. The document gives both the human and later implementation runs a complete version to work from.

And we store it in the repository, with revision history. We review the proposal through a design board in Ralph, which displays the document, the open decisions with options and a recommendation, and the proposed stories. The human can approve, request a revision or reject the proposal.

The design stays in the repository as history. A revision updates the same design, and subsequent implementation runs read the approved design before building.

Deciding when design is needed

Adding a design phase to every request would slow down ordinary work, so Ralph applies a selection rule during refinement and checks again before implementation when no design exists. One signal is sufficient on its own: a new product concept that needs stored data, an API and a user interface. Otherwise, the rule looks for a combination of signals, such as multiple user flows, unresolved architectural choices or changes to shared concerns like authorization and tenancy. Routine changes have explicit exclusions; touching several internal classes does not by itself make a feature large.

When the rule identifies a candidate, Ralph explains its reasons and asks whether to start a design. The human can decide that ordinary refinement is enough. This keeps the rule useful as a way to surface complexity while leaving the decision with someone who understands the context.

Make the first story useful

An approved architecture still needs a workable delivery sequence. A tempting split is one story for storage, one for the API and one for the screens. Each looks manageable, but the human may have nothing useful to evaluate until all three are finished. That delays the feedback our delivery loop depends on.

Our design instructions therefore ask for the smallest usable version first, followed by one or two additions that each improve it. For the multi-tenant example, a first slice might let an administrator create an organisation and a member use it with basic access control and data isolation. More detailed roles and billing could follow, if the agreed scope allows it. The first slice crosses the necessary technical layers and gives a human a working flow to judge. A design can also produce a single story when no further split is needed.

The design phase gives larger work an additional human decision before the delivery loop begins. Ralph prepares the alternatives and the proposed sequence; the human settles the choices that affect scope, policy and acceptable risk. Each resulting story then follows the same testing, delivery and acceptance process as smaller work. Part 5 covers how organisations can adopt these practices gradually, including before they are ready to let an agent merge its own changes.

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

Ralph is built at Rubicon, part of BBTG. AATB and ARBT are our working answers, not industry standards. Yet.