The AI software factory operating model. Audio conversation transcript.
Two AI-generated voices discussing the post by Jon Shanks.
https://getwayfinder.io/blog/the-ai-operating-model

Host: Today we're talking about the operating model for an AI software factory. Last time we covered what the factory is. So what do we mean by its operating model?

Guest: It's how people, agents and shared platform capabilities work together to deliver and run software. It sets who owns outcomes, how work flows, which standards apply, what agents may do on their own, and how you assess quality, cost and performance. Small, accountable product teams direct the work, and a shared factory supplies the capabilities, standards and controls that let agents do more of it.

Host: Is there a standard model to copy?

Guest: There isn't one settled model yet. But most organisations already have a cloud operating model, with responsibilities for security, delivery and running services assigned. Microsoft's Cloud Adoption Framework describes three arrangements: centralised, shared management and decentralised. I'd start from shared management. Product teams own customer outcomes and their services, a platform team provides capabilities they can reuse, and security, architecture and other specialists set standards with the teams.

Host: And that assumes some foundations are already there?

Guest: Yes. Cloud accounts, identity, networking, delivery pipelines and operational responsibilities all need owners. AWS's cloud operating model already covers architecture, observability, security operations, reporting and financial management. Those are capabilities to assess and build on, not to start again.

Host: So what changes when you hand work to agents?

Guest: Where people spend their time. Before delegating, they need to make the requirements, domain knowledge and engineering standards clear enough for an agent to use. While the agent works, the factory controls which systems it can reach and which actions it can take. Afterwards, the team needs evidence that the work meets the requirements and produces the intended outcome. An agent finishing its task doesn't show that the design, architecture, security or customer experience standards have been met. Each of those needs an owner, an agreed standard and a way to assess the result.

Host: What needs to be in place before you start?

Guest: I'd check five areas for the particular work you're delegating. Ownership and context: a named service owner, a clear customer problem and maintained information about the domain. Security and environments: scoped identities, secrets handling and access policies that the platform enforces, so an instruction can't grant extra access. Engineering and design: approved patterns, conventions and components. Delivery and operation: reliable tests, release policies, monitoring and a tested recovery path. And measurement: a baseline for business outcomes, delivery, quality and cost.

Host: Having those written down isn't enough, though?

Guest: No. A security policy needs enforcement, a design standard needs usable components and a quality requirement needs a check that can detect failure. If your test suite misses important defects, giving it more generated changes leaves you with the same gap. You can start with assisted work, where an agent prepares a change for an engineer to inspect, and increase autonomy for a task only when its owners, controls and validation are working.

Host: You describe the model as lean. What does that mean here?

Guest: Fewer handoffs, small batches, limited work in progress, fast customer feedback and continuous improvement. Agents can generate work faster than people can assess or release it. A team with hundreds of unfinished agent changes is just accumulating work. DORA's research describes AI as amplifying an organisation's existing strengths and weaknesses, and it points to small batches as a way to counter delivery instability.

Host: So what are the rules for the team?

Guest: Five. Own a bounded product or customer problem from discovery through operation. Start only as much work as the team can validate. Ship small changes and watch their effects. Turn recurring corrections into better tests, standards or skills. And give explicit time to improving the factory. If review work keeps growing, start less and improve the checks. Adding more agents to the same queue just leaves people with more unfinished work.

Host: Who's actually in the product team?

Guest: I'd start with three capabilities. A product lead who understands customers, chooses the problems and defines success. A designer who owns the journeys, usability and accessibility, and validates the experience with users. And a technical lead who owns the architecture, correctness and reliability. Agents can draft specifications, prototypes and implementations, but each of those people needs the judgement to assess work they didn't produce.

Host: Does that mean three people can run a product?

Guest: For a bounded product with strong platform support, three people could cover it. SVPG has proposed a product manager, a designer and an engineer as a future team shape, but that's a forecast over three to ten years, not evidence that every product can run that way. For a production service, I'd often add an engineer for review capacity, operational cover and continuity. Treat three as a hypothesis to test, not a staffing rule.

Host: What about junior engineers, if agents take the introductory tasks?

Guest: They need another route to build judgement. Pairing, owning a small improvement from specification through release, explaining the implementation and evidence to a colleague, and learning from incidents. They need to learn the system, not only how to use agents.

Host: How does the wider organisation support the team?

Guest: A shared platform team runs the factory as an internal product: environments, identities, agent execution, reusable workflows, evaluation and cost visibility. Specialists in security, reliability, data and accessibility embed where needed and turn repeatable expertise into reusable checks. That follows Team Topologies, and its point about cognitive load matters: a smaller team needs a scope it can understand and operate. Every shared agent or skill also needs a named owner responsible for evaluating, maintaining and retiring it.

Host: And who owns the standards the agents follow?

Guest: "Agents follow our standards" is only useful when someone creates those standards, makes them available in the work and checks they're followed. The product lead owns requirements, the designer and design-system owner own the experience, the technical lead owns architecture, security owners own access policies, and the service owner owns operational readiness. Use instructions to guide judgement and automated controls to enforce requirements wherever you can. AutoScout24 is a good example: plugin owners maintain their plugins, platform engineering admits new ones, and a required linter checks structure and ownership.

Host: Can you walk through how a piece of work actually moves?

Guest: Take a new customer onboarding flow. First, the product lead chooses the outcome, say helping customers finish setup without assistance, and records today's completion rate as a baseline. The team writes acceptance scenarios, including interrupted setup and invalid input. The designer validates a prototype with users, and the technical lead decides how onboarding connects to the account service. Agents build in small changes using the agreed components. If engineering finds the account service can't safely resume partial setup, that goes back to product and design. Then agents return test evidence and previews, each owner checks their part, and a limited rollout lets the team watch completion before expanding it.

Host: How do you know the delegated work is good?

Guest: I'd measure four things. Business outcomes, owned by the product lead, against the baseline. Engineering delivery: lead time, unfinished work, review effort and rework. Quality and reliability: acceptance results, escaped defects, failed changes and recovery. And economics: cost per accepted outcome, including people's time, model spend and shared infrastructure, with failed attempts recorded. Uber's software factory account tracks cost per outcome alongside quality in this way.

Host: And then you act on it?

Guest: Yes. Unresolved acceptance failures stop a release. Repeated review corrections become improvements to the skill or standard. More escaped defects can mean less autonomy. And a technically sound feature that doesn't improve the customer outcome goes back to discovery.

Host: How much autonomy should agents have?

Guest: Start with human-reviewed delivery and expand it when there's evidence that validation works. Stripe's unattended agents work in isolated environments and produce changes that people review. StrongDM describes a three-person team that avoids human code review altogether, but with substantial investment in automated validation. I think of four levels: assisted, delegated, policy-controlled automation and exception-led supervision. Permissions should be specific to the task. Reliable dependency updates don't show an agent can redesign payment authorisation.

Host: Finally, how would you adopt it?

Guest: Test it in one bounded product area over ninety days. In the first thirty, assess ownership, standards and measurement, assign missing owners and set baselines. From day thirty-one to sixty, delegate selected work types and measure review effort, failures and customer results. From sixty-one to ninety, expand what works and automate low-risk changes. Let evidence from the work, not a date, decide when to give agents more autonomy.

Host: Where should someone start tomorrow?

Guest: Pick one customer problem and look at how you deliver it today. Name the owners, find the standards agents will need to follow and check whether you can measure the result. Then choose the first piece of work to delegate.