What is an AI software factory? Audio conversation transcript.
Two AI-generated voices discussing the post by Jon Shanks.
https://getwayfinder.io/blog/what-is-an-ai-software-factory

Host: Today we're talking about AI software factories. Writing code has got easier, but it's only one part of delivering software. So what is an AI software factory?

Guest: In its ideal form, it's taking an idea and having agents and skills support the business case, the prototype, the design, the build, the deployment and the improvement afterwards, with people approving and assessing the work throughout. It follows your standards automatically, so each review needs less input from you.

Host: How is that different from a team where everyone has a coding agent?

Guest: The agents do discrete tasks. One plans, one builds, one tests, one reviews, one assesses the security and one deploys. Each does its part, works with the others and reports back to the team, like stages on a production line. What you measure is the quality of what ships, the design, the user experience, the architecture and the resilience, not the lines of code.

Host: What are companies actually seeing from this?

Guest: Uber says more than 70% of its pull requests are attributed to agents. Its usage grew seven times since February while total AI spend stayed roughly flat, and cost per session fell 52%. Its engineers have also described more than 250 automated migrations covering nine million lines of code. Stripe merges over 1,300 agent-written pull requests a week. HubSpot's review agent gives first feedback 90% faster. These are individual company results, not a forecast for every team.

Host: Doesn't more code just mean more to review?

Guest: It can. Faros found that with higher AI adoption, median review time was five times longer and bugs per pull request rose by 28%. When every developer uses different instructions and review rules, reviewers pick up the differences. A shared review agent can check for bugs, security issues and your standards before a person looks at it. You still need to test that those checks find the problems you expect.

Host: So how do you know if it's working?

Guest: Counting requests, tokens or pull requests only tells you how much activity there is. Ask whether it solved the problem, whether changes reach production faster, whether quality and reliability improved, what each accepted piece of work cost, and whether security issues are being fixed. DORA's five delivery measures are a good base: lead time, deployment frequency, change fail rate, failed deployment recovery time and rework rate.

Host: And the cost? How do you work out the bill?

Guest: Uber breaks model spend into six factors: users, sessions per user, turns per session, requests per turn, tokens per request and the average price per token. As an illustration, 100 people running 20 sessions a month, with five turns per session, two requests per turn and 1,000 tokens per request, use 20 million tokens. At an illustrative £5 per million, that's £100. Then add infrastructure and people's time, and divide by the outcomes you accepted, such as a verified fix or a completed review.

Host: Let's talk about what it's made of. How does work move through it?

Guest: There are nine stages. A person states the intent. An agent drafts the spec and a person approves it. Agents draft the design and a person signs it off. An agent proposes a plan, and a person checks it before anything is built. The agent builds in an isolated environment and tests against the requirements. Then there are two gates, review and release, where work stops until the checks pass or someone approves it. After release, agents investigate alerts and keep dependencies up to date.

Host: Does every team build its own agents and skills?

Guest: If they do, you pay for the same work many times and end up with different standards. A skill packages the instructions, examples and tools an agent needs for one job, like a review. Share it, and teams start from something already tested and contribute improvements back. Environments, identities, security standards and the approval workflows go central. Product requirements, domain knowledge, architecture decisions and acceptance tests stay with the team.

Host: You mention a context graph. What is that?

Guest: It records what an agent needs to know and how it connects. A service has an owner, a repository, environments and dependencies. Take an alert on a checkout service. With the graph, the agent goes straight from the alert to the service, the code, the owning team and somewhere to test a fix. Without it, the agent searches dashboards, runbooks and deployment records, which costs time and tokens. In a separate dataset lookup, Uber's agent found the right table in 38 seconds with its graph, against 20 minutes without it, and the second time it got the wrong answer. That's one experiment, not a speed-up to assume for every task.

Host: And the LLM proxy?

Guest: It sits between the agents and the models. It controls access, records usage and links cost to a team and a task, so you can follow an expensive run back to the work it was doing and see whether it finished.

Host: How do people work with all of this?

Guest: The team still decides what to build, assesses the result and takes responsibility for what reaches users. People set the rules for merging and releasing. A documentation update might go through automatically, while a payments change needs a named reviewer. The agent should show what it did and how it checked it, so the reviewer doesn't repeat every test.

Host: How do you build trust in an agent?

Guest: One task type at a time. Start with work that's easy to describe and check, like a dependency upgrade with good tests. Watch whether it meets the requirements and stops when it can't verify something. As the results hold up, reduce the supervision for that task.

Host: Does this mean smaller teams?

Guest: Gartner predicts 60% of organisations will adopt smaller engineering teams by 2029, up from 15% in 2026. The bigger effect is opportunity. If large teams can scale down, you can create more product teams from the same people, and put the pressure on finding more products to build and new markets.

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

Guest: Mature foundations. An agent needs to create an environment, run tests, get permission to use a tool and deploy safely. If people raise tickets and wait for those things, the agent waits too. You need environments on demand, clear identities and permissions for agents, automated policy checks, shared templates, and records of what each agent did and what it cost. Stripe, for example, sends a branch back to a person after two CI runs, so an agent doesn't keep spending on a problem it can't fix.

Host: So where should someone begin?

Guest: The bug backlog. A defect with logs and a reproduction is the clearest brief an agent can get, and the team feels the backlog going down. Put the proxy in place and measure first, get the telemetry right, build a context graph, run evals on your agents, and share skills centrally. Then set the guardrails, test your own security, decide what you'll report on, and keep everyone learning with you.

Host: And where does Wayfinder fit?

Guest: Wayfinder gives you the platform for an AI software factory out of the box: the environments, identity, policies and workflows agents need to work in your cloud accounts. You can try it now at getwayfinder.io, or speak to us for a demo.