The Software Factory

Rick Whalley

AWS Consumer Summit 2026, Exec and Leadership track

#2041 Add payee endpoint

POST /payees

All checks passed

#2042 Transaction history

GET /api/v2/getTxns

14/14 passing

#2043 Update account address

POST /address.update

Build green

#2044 Payment retry

log.info("retry", id)

All checks passed

#2045 Balance enquiry

console.log(customer)

Tests pass

#2046 Statement export

logger.debug(req.body)

31/31 passing

#2047 Standing order setup

throw new LimitError()

Build green

#2048 FX quote

return { ok: false, err }

All checks passed

#2049 Card freeze

catch (e) { return null }

Tests pass

#2050 Account closure

DELETE /accounts/{id}

9/9 passing

#2051 Limit override

print(f"by {user.email}")

Build green

#2052 Dispute submission

res.json({ error })

All checks passed

Individually impressive.
Collectively ungoverned.

0:10–2:00. Click 1: the tiles land, on the demo moment. Click 2: headline, as I say the line.

Every engineering organisation in this room has AI coding tools in the hands of its developers by now. And I'd guess most of you have seen the same two things.

The first is the demo moment. A developer shows you a function written in seconds, a test suite generated from a description, a refactor that would have taken an afternoon done before the coffee's cold. It is impressive. It's real.

The second thing is quieter and takes longer to show up. A new endpoint that's patterned differently from the rest of the service. A pull request that passes every test and quietly violates three architecture decisions your teams spent months agreeing. Logs that leak customer data because nobody told the tool that was a rule. The tool didn't know. Left alone, it can't know. Every session starts from zero, with no memory of your standards, your security posture, your architecture, or what the last ten services look like.

So at the level of an individual developer, you get speed. At the level of an organisation, every piece is impressive on its own and the whole doesn't hold together. It's inconsistent. It's hard to audit. It's disconnected from the standards you actually care about. Individually impressive. Collectively ungoverned.

And that's the gap I want to talk about. Not whether these tools are fast. They are. Whether you can govern that speed across a whole organisation.

The standard travels with the tooling.

2:00–3:25. Click 1: the agentic line, on "that is exactly the move we've made". Clicks 2–4: ADRs, security constraints, testing strategy, as I name them.

The question we started with a little over a year ago was: what would it take to turn that into a factory?

Not factory in the sense of rigid or bureaucratic. Factory in the engineering sense. Opinionated tooling. An ordered process. Quality standards built into the machines themselves rather than held in the operator's memory.

You already run one of these. Think about a CI pipeline. Nobody asks engineers to remember to run the linter. Nobody puts it on a checklist. It's wired in, it runs every time, for everyone, and it enforces the same standard. The standard travels with the tooling.

That is exactly the move we've made for AI-assisted delivery. Your architecture decisions, your security constraints, your testing strategy: instead of documents that a developer might read and a tool will never see, they become behaviour the agent actually exhibits. Contract-first ordering isn't a wiki page — it's the order the build step follows. No customer data in logs isn't a code review comment — it's a constraint injected into every single build.

That's the insight. Everything else I'm going to show you is built on it.

Where Kiro stops, and where the factory starts

3:25–5:50. Click 1: the Kiro band, on "maps onto the middle of our production line". Click 2: the harness band, on "but look at the two ends of the line".

We've built this on Kiro. When I say the harness, I mean the layer we've built around the agent: the skills, the checks and the gates that turn a coding tool into a production line. Six stations: foundations, analyse, design, build, verify, operate. Engineers drive it from the Kiro CLI or the Kiro IDE. The choice is theirs, and the harness is the same either way. I want to separate what Kiro gives you out of the box from what we've had to add.

Kiro's core idea is spec-driven development: requirements, design, tasks, in that order, before any code. It's the right idea, and it maps onto the middle of our production line. Specs cover design. The agent covers build. Steering files carry your standing context. Hooks let you automate behaviour at specific moments. It's a good substrate, and it's why we chose it.

But look at the two ends of the line.

On the left, before the spec, is where the business lives. Somebody has a policy document, a product requirement, a Jira ticket that represents a whole initiative. Getting from there to a specification precise enough to delegate a build from is real work: decomposing into epics and features, generating acceptance criteria at every level, checking the spec for coverage and coherence before anyone designs anything. Kiro works one feature spec at a time. It doesn't take an initiative and carry it across a system of services. The harness does. A skill that elaborates business requirements into acceptance criteria. A scorecard that checks whether a spec is ready to build from. A stage gate where the team agrees the scope before design begins.

Testing moves left with it too. The functional and non-functional test scenarios are derived from those acceptance criteria before a line of code exists. Not written after the build to see what it does. Written before, to say what it must do.

One quality specification, running in both directions.

5:50–7:05. No builds.

The acceptance criteria written in Analyse are the same artefact that drives the build, and the same artefact the test suites verify against. One quality specification, running in both directions: governing what gets built, and verifying what was produced. Precision at that stage is what makes confident delegation possible later. Vagueness there propagates forward as defects.

On the right, after the build, Kiro hands you code. The harness runs the full test suites against it, functional and non-functional. It remediates defects inside a governed loop. Then it runs a formal verification pass across correctness, alignment, trust and risk before anything is cleared to deploy.

So the short version for this room: Kiro gets you from a spec to working code. The factory gets you from a business requirement to a verified, deployable increment. And there's one more piece that makes that hold across a whole system rather than one service at a time. I want to spend longest on that one.

The inversion

7:05–8:25. Click 1: the meta-repo column, on "we inverted it".

Most engineering organisations treat the microservice as the primary unit. Each service is independent: owned by a team, with its own repository and its own pipeline. The macro tends to be informal — how those services compose into a system, what the contracts between them are, what the whole thing is supposed to do. It lives in Confluence, in people's heads, in the design document that was accurate six months ago. Services are independent. Their coordination is emergent.

That was always a weakness. With autonomous build agents, it becomes the weakness. Because an agent building one service has no idea what the other four are doing unless somebody tells it, every time.

We inverted it. The meta-repo is the primary unit. Services are composable components of it. The meta-repo holds the harness itself. It holds the organisation's context: the ADRs, the non-functional requirements, the service templates, the cross-cutting concerns. And for each increment it holds the factory plan — the macro-level implementation plan for the whole system.

I want to give you three concrete benefits of that inversion.

The agent's scarce resource is context.

8:25–9:55. Click 1: the fan-out, on "from that one plan, a per-service plan is derived".

The scarce resource for an AI agent is not intelligence. It's context. What does it know about your world at the moment it starts work? Left to individual developers, the answer is: whatever they remembered to paste in. Which varies by developer, by day, by how much of a hurry they were in.

In the meta-repo model, the whole picture lives in one place. The system-level acceptance criteria. The contracts between services. The shared event schemas. The dependency graph. The deployment order. From that one plan, a per-service plan is derived and pushed to each service's branch. When an agent builds a service, it receives a complete brief derived from the same source of truth as every other service in the increment. It knows what to build, what contracts to honour, and what its place in the system is.

That's the difference between an agent that is fast and an agent that is fast and right. The context problem isn't solved by a bigger model. It's solved by having a place where the whole system is described, and a mechanism that delivers the right fragment of it to every build.

Change once. Propagate everywhere.

9:55–10:55. Click 1: the meta-repo half and the deployment sequence, on "in the meta-repo model, that change happens once".

The second benefit is control.

Take the most common source of pain in a distributed system: a shared contract changes. A new field on an event that four services consume. In the usual model, that change is negotiated across four teams and lands in four repositories at four different times. You reconcile the drift afterwards. Usually in production.

In the meta-repo model, that change happens once, at the factory level. The factory plan reflects it. The per-service plans propagate it. Each service's implementation is derived from the same updated source. You changed one thing and the system followed.

The same holds for deployment. The factory plan carries the deployment order and the cross-service dependencies. A feature that spans five services ships as one coordinated thing in a known sequence with a stage gate before it.

Every merged change is a breadcrumb.

Add purpose code to payment confirmation #2187

Merged factory-bot merged 6 commits into main from increment-14/accounts

Adds purposeCode to the PaymentInitiated consumer and the confirmation view.

Factory plan: FP-014, increment 14

Acceptance criteria: AC-31, AC-32

48 checks passed

Pull request#2187

Factory planFP-014

Stage gateDesign, signed off

Acceptance criteriaAC-31

Business requirementBR-7

ADR-019 changed once in the meta-repo the next build on every service follows it

10:55–11:55. Clicks 1–4: the chain, link by link, as I say "to the plan… to the stage gate… to the acceptance criteria… to the business requirement".

The third benefit is the one your risk and audit functions will care about.

Every pull request the factory raises carries a reference back to the factory plan that drove it. Which means every change in production can be walked back: to the plan that coordinated it across services, to the stage gate that passed it, to the acceptance criteria that specified it, to the business requirement it came from. That isn't a report you compile after the fact. It's a property of how the work was produced.

And the standards themselves are governed the same way. The ADRs and the non-functional requirements live in the meta-repo: versioned, reviewed and applied uniformly. Change one, and the next build on every service follows it. Enforced, rather than published.

The system is the unit.
Services are instances of a pattern.

Bounded autonomy

12:35–15:15. Click 1: the gates, on "stage gates". Click 2: the loop, on "a defined envelope". Click 3: the two failure modes, on "that number matters". Click 4: the four human ticks light, on "a person signs off four times".

Everything so far rests on delegating work to a machine. So let me be clear about what makes delegation safe, because I know that's the question underneath all of this.

Two things.

Stage gates. There are four, and a person signs off each one: the scope, the design, the verified build, and readiness for production. Human-led, machine-assisted. Before the design is signed off, the machine checks the package for consistency: requirements against acceptance criteria, acceptance criteria against design, design against the implementation plans. Drift gets corrected upstream, so you've verified the inputs are coherent before you hand over. Before production, it assembles the evidence, and a person reads the full summary of what was built. The gates aren't overhead. They're what lets you delegate in between them.

A defined envelope. Between the gates, no agent reviews its own work; independent reviewers check it against the spec and against the engineering standards. When something fails, at any station on the line, the machine gets three attempts to remediate. If the third fails, it stops. It reports exactly what failed. It does not push. It escalates to a human rather than trying harder.

That number matters because of what it rules out at either end. "Always ask" sounds safe, and it isn't. An engineer approving every step of an autonomous build stops reading by the twentieth prompt. Approval becomes a reflex — yes ops — and the quality of the decision degrades precisely because a human is nominally making it. "Run until it works" fails the other way: an agent that never gives up will spin for hours, burning time and tokens on a problem it has already shown it can't solve. Three attempts, then escalate. The engineer isn't babysitting the build, and the build isn't running unsupervised into the ground.

So a person signs off four times. Not before every task, which would make autonomy meaningless. At the four points where accountability actually sits.

That's the machine. Autonomous where autonomy is safe. Gated where judgement is required. And the standard holds even when nobody is watching.

Operational today.

3 monthsClient's own estimate

4 weeksActual

Financial services proof of value, one slice of the system.

Programme extended to build the whole system.

Policy document
Product requirements
Acceptance criteria
Factory plan
Per-service builds
Verified system

One unbroken line of traceability

Also running in UK healthcare

15:15–16:35. Click 1: "3 months". Click 2: "4 weeks". Click 3: the extension line, on "has since been extended". No client names.

This is operational on live engagements today. The one I can say most about is a financial services client. They scoped the proof of value at around three months of work. We delivered it in four weeks. It was a slice of the system, chosen to prove that it could be done, that the proposed architecture was sound, and that the quality met the standard a heavily regulated environment demands. Policy document and product requirements in; a working, verified slice out, with full traceability from the business requirement to the running service. That programme has since been extended to build the whole system. The same shape is running in UK healthcare.

The core loop is solid. The shift-left testing, the verification layer, the multi-service coordination through the meta-repo: working. What we're building now is everything around it. Making it easier to use. Making it easier to start, with package management for the harness itself. And reporting: where the build is up to, what's missing, who needs to act, and what it's costing in tokens.

Do your standards exist in a form an agent can act on?

Documents a developer might read

Home › Engineering › Standards and policies

Contract-first orderingWiki page, last edited 14 months ago
Logging and customer dataConfluence space, 37 child pages
Architecture principles v3 FINAL.pdfPDF, 2.4 MB
Security policy overview.pptxSlide deck, 48 slides

Behaviour an agent exhibits

Steering fileContract-first ordering
Injected constraintNo customer data in logs
HookArchitecture principles
Test scenarioSecurity policy

16:35–17:30. Click 1: the two columns, on "or do they exist in documents".

So here's the question I'd ask of your own organisation.

You've bought the tools. Your developers are using them. The speed is real. The question is whether you can govern it. And that comes down to one thing: do your engineering standards, your architecture decisions, your security constraints, exist in a form an agent can act on? Or do they exist in documents that a developer might read and a tool will never see?

If it's the second, you have what most organisations have today. Moving to a factory means putting your standards into the machinery. It means making the system the unit of work rather than the service. It means delegating inside gates you've already verified.

Write rules that say yes.

17:30–18:55. Click 1: the calendars become rules and the outer loop shrinks, on "what you need are rules that let you say yes".

Which brings us to the part that gets missed. Everything I've described speeds up the inner loop: build, test, verify, repeat. It does nothing for the outer loop, which is what it takes to get that increment approved for production. The factory can sequence a deployment. It can't approve one. If a verified increment then sits waiting for the next change advisory board, or an architecture review, or a threat modelling session before it can deploy, you've burnt a lot of the gain you just made. Those gates exist for good reasons. The problem is how they're written. Most of them today are meetings that tell you what you haven't done. What you need are rules that let you say yes: if the threat model is attached and the ADRs are honoured and the non-functional tests pass, this can deploy. Written down and checked by the machine, the same as everything else. The stage gates I described earlier already work this way: the machine checks the conditions, and a person signs off. It's the standard travelling with the tooling one more time — applied to governance rather than code.

Two things to do when you get back.

Pick your three most important engineering standards and ask where they live.
Pick your slowest gate to production and ask what it would take to write it as a rule that says yes.

Individually impressive. Collectively ungoverned.

The Software Factory

Individually impressive.Collectively ungoverned.

The standard travels with the tooling.

Where Kiro stops, and where the factory starts

One quality specification, running in both directions.

The inversion

The agent's scarce resource is context.

Change once. Propagate everywhere.

Every merged change is a breadcrumb.

The system is the unit.Services are instances of a pattern.

Bounded autonomy

Operational today.

Do your standards exist in a form an agent can act on?

Write rules that say yes.

Two things to do when you get back.

Individually impressive.
Collectively ungoverned.

The system is the unit.
Services are instances of a pattern.