Explainer
In an AI software factory, people specify what a change should do. Coding agents implement it, tests check the result, and the team decides which changes need approval before release.
Follow a proposed change through the diagram. A failed check sends it back to the agent. After release, production signals go back to the operator, who can use them to specify the next change.
The loop
A person sets the outcome, agents do the work, and checks judge it. Work that fails a check returns to the last known-good state.
01 / Intent
The person who knows the workflow writes down what should happen, which constraints matter, and what an acceptable result looks like.
02 / Agents
A coding agent reads the specification and the codebase, then submits its change for testing.
03 / Validation
Acceptance tests check the result against the specification. A second model can look for mistakes, and a digital twin lets the team test failures that would be costly to trigger in production.
04 / Approvals
The team sets a risk threshold. Routine changes can proceed after the checks pass. For higher-risk changes, a reviewer examines the evidence and decides whether to release.
05 / Runtime
Permissions constrain the running software. Operators monitor its behavior and can restore a working version if a release fails.
06 / Operators
When a check fails or a customer reports a problem, operators trace it back to the specification, implementation, or test. They decide what to change before the next run.
Our paper Specification Oracles explores a related question. Can a language model learn how a system behaves and answer questions about it as a specification would?
A demo can work for one user and still fail in production. A test might cover only the successful case, or an agent might have broader permissions than a customer does. Select a step on the map to see where delivery can stall.
The route
One path reaches a trusted system. Five others dead-end. Drag the map, or hover a node to see why.
An agent that suggests an edit needs less oversight than one that can deploy it. Use the controls to see how the number of agents, their autonomy, and the consequences of a mistake affect the load on the team responsible for them.
5 agents · assisted · low blast radius
Clear ownership, low exception load.
At Diffusion Silicon Valley, we start with the people who run your workflow. For engagement details, see Work with Diffusion.
Four loops connect the codebase to the running application. They gather data from the running application, check the code, try user workflows, and turn findings into changes.
Watch production
Aware brings together product analytics, errors, session replays, and traces. Its Watch investigations collect evidence for each issue.
Keep promises
Housekeeper audits repositories for security, correctness, performance, and reliability issues. A model from a different family challenges each finding. Confirmed reports explain what goes wrong, how to reproduce it, and how to fix it.
See around corners
Explorer tries your application as different users, including admins and customers. Before taking an action, it records what it expects to happen. Reviewers can see where the application behaved differently.
Make the changes
Assembly turns findings, bug reports, and feature requests into pull requests. Each includes the checks and a captioned video showing the behavior before and after the change.
01 / Early lessons
In his Enterprise AI Summit talk, Diffusion founder and former StrongDM CTO Justin McCarthy recalls writing “No human-written code” on the board on day one. By day two, his team realized that nobody could read changes as fast as agents could write them. They had to change how they reviewed the work.
02 / Where it fits
An insurance claim passes through several hands before payout. A hospital discharge depends on decisions by several teams. The illustrative workflows on Work with Diffusion let you follow each handoff and see where work waits for approval.
03 / Where it fits
A running product gives a rewrite team a reference. Capture how the old system handles real workloads, then run the same checks on its replacement. The team can keep those tests through later rewrites.
04 / Where it starts
Build a small prototype of a decision an operator makes often. Give the operator a real case to try. Before a production test, agree on who owns that decision and how to tell whether the prototype handled it correctly.
A coding assistant helps a developer write or revise code. A factory also handles what happens after the agent proposes a change, from testing and approval to monitoring the release.
Validation. A passing test only tells you about the behavior it covers. In his Charlotte talk, Justin McCarthy estimated that validating a change could use 10 to 100 times as many tokens as writing the code.
Watch the Charlotte talk (estimate at 8:09)People decide which customer problem to solve, what good work looks like, and who can accept the risk of a release. As agents improve, teams can revisit which decisions still need a reviewer.
Pick one recurring workflow with a clear owner. Ask that person for a recent example, what they expected to happen, and how they knew the work was done. Those answers give you a first test.
You can start now by documenting the workflow and building acceptance tests. Those tests also give you a way to compare a new model with the one you use today.
Your team does. Your operators run the workflow, maintain its checks, and decide where to extend it.
Bring a workflow and someone who runs it. We'll identify a first change and agree on how to test it.
