Adoption is the easy part
Most organisations can buy AI tooling, publish guidance and show a rising adoption curve. That proves that people can access the tool. It does not prove that software moves through the enterprise faster, more safely or with less rework.
The local effect is obvious: code, tests, documentation and analysis can be produced faster. The system effect is less convenient. More output can create more review, more inconsistent patterns and more uncertainty about what is safe to accept. A faster developer can still wait on the same architecture decision, test environment, security review or upstream team.
The bottleneck moves. The delivery system does not improve merely because typing became cheaper.
Start with workflows, not assistants
The useful unit of design is a workflow with an outcome and a verification path.
A team might redesign incident follow-up so an agent gathers evidence, links recent changes, drafts the first analysis and proposes regression tests. Another might turn acceptance criteria into test cases, then require automated checks before review. A platform team might expose approved APIs, architecture rules and working examples so assistants stop guessing at local conventions.
Each case combines the work, context, action and control. That is materially different from distributing a generic assistant and hoping useful practice emerges consistently across hundreds of teams.
Context is infrastructure
Enterprise software work depends on context that is usually fragmented: repositories, documentation, architecture decisions, service ownership, internal APIs, policies, tickets, runbooks, incidents and examples of what good looks like.
An assistant that cannot see the relevant context fills the gap with plausible output. An assistant that can see everything creates a different problem. The context layer therefore needs deliberate retrieval, identity, permissions, freshness, provenance and cost boundaries.
Treating this as infrastructure makes the capability reusable. Teams should not each rebuild the same brittle set of prompts and integrations in isolation.
Verification moves closer to creation
AI can increase the volume and variability of change. The answer is not to add a ceremonial review step at the end. Verification needs to move into the workflow: tests, policy checks, architecture fitness functions, dependency rules, security scanning, traceable sources and explicit approval for consequential actions.
The design goal is not autonomous code generation. It is faster movement from intent to a change the organisation has good reason to trust.
Measure the system
Seat count is procurement data. Prompt volume is activity data. Useful measurement follows the delivery system:
- lead time and review cycle time;
- rework after review;
- change failure and rollback frequency;
- escaped defects and security exceptions;
- developer flow, cognitive load and onboarding time;
- the cost and latency of the AI-enabled workflow itself.
Not every intervention needs an elaborate experiment. It does need a baseline and enough evidence to decide whether to scale, redesign or stop.
The executive choice
An AI software factory is not a product to procure once. It is a set of operating choices: which workflows matter, what context the enterprise will expose, what agents may do, which controls are automated, how teams change and what evidence leadership will accept.
The organisations that make those choices coherently will compound the benefit across teams. The rest will own an increasingly expensive collection of assistants.