AI accelerates the implementation. Architecture governs it.
Why fazeZERO uses AI inside a proven production architecture instead of letting it improvise a new architecture for every enterprise application.
Part of The Application Factory(2)
Every enterprise now has access to AI that writes code. The interesting question is no longer whether AI writes the application. It is what the AI is allowed to write into.
Our answer is a fixed, proven architecture. AI accelerates the implementation inside it. It does not get to reinvent the structure for each customer.
The problem with improvised architecture
Give a capable coding assistant a requirements document and a blank repository and you will get a working prototype quickly. You will also get an architecture that emerged: shaped by the order in which prompts arrived, the examples the model happened to favour, and whatever the developer accepted at 11pm.
Run that process ten times for ten applications and you get ten architectures:
- domain boundaries drawn differently every time
- APIs designed after the screens, not before them
- identity and authorization added once someone asks about security
- multi-tenancy handled three different ways
- tests written after the fact, if at all
- code that drifts every time it is regenerated
None of this shows in the demo. All of it shows in production, as rework.
What we do instead
Our pipeline runs in a fixed order:
- Requirements: the business problem, users, workflows and user stories.
- Domain model: bounded contexts and the vocabulary of the business.
- Governed architecture: the same layering, service boundaries and adapters every time.
- API contracts: OpenAPI definitions for every boundary, before implementation.
- Generated core: services, adapters, identity, authorization and tenancy from the factory.
- Customer-specific logic and AI: the part that is genuinely unique to this customer.
- Testing and controls: automated tests, AI evaluations, audit and evidence.
- Web application and deployment: a working UI and a baseline for the customer's cloud.
AI is involved at almost every step. It drafts user stories, proposes domain models, writes implementation and generates tests. But it works inside rails that were set before it arrived.
Why this is faster, not slower
It sounds like governance should slow things down. In practice, it does the opposite. It removes the decisions that don't need to be made again.
When the architecture is fixed, a new application doesn't debate how to structure identity, how to version APIs, where business rules live or how to test adapters. Those answers already exist, and they have been exercised across a large inventory of applications in very different domains. The engineering effort goes where it should: into the customer's workflow, data and integrations.
This is also why we can start customer work from an existing application foundation rather than a blank repository. Hundreds of foundations share one architectural grammar, so the closest one is usually a meaningful head start.
What changes and what doesn't
Between customers, these change: domain vocabulary, workflows, integrations, data, AI capabilities, cloud and policies.
These don't: bounded contexts as the unit of design, contract-first APIs, identity and tenancy in the core, tests as a gate, observability, and controlled regeneration.
Customer-specific functionality changes. The architectural discipline does not.
Where this leaves AI coding tools
We use them, and so should your developers. They are excellent implementation engines. The mistake is treating them as an architecture. We have written more about that in coding assistants are not an architecture.
Where to go next
- How the pipeline works end to end: the Application Factory
- The patterns every application starts with: Architecture
- Your own use case mapped onto it: Solution Definition Sprint