[{"data":1,"prerenderedAt":48},["ShallowReactive",2],{"blog-tag-architecture":3},[4,24,37],{"id":5,"slug":6,"body":7,"html":8,"title":9,"description":10,"category":11,"tags":12,"author":17,"date":18,"year":19,"month":20,"quarter":21,"status":22,"featured":23},"2026\u002F07\u002Ffactory-and-architecture\u002Fidentity-tenancy-and-authorization-from-the-first-commit","identity-tenancy-and-authorization-from-the-first-commit","\nAsk what usually delays an AI application's go-live and the answer is rarely the AI. It's the security review. Specifically, the discovery that identity was bolted on, authorization checks are scattered through the code, and tenant isolation depends on every developer remembering a `where` clause.\n\nIn our factory, these three concerns are part of the architecture from the first commit. They're generated into the core of every application foundation.\n\n## Identity\n\nEvery foundation authenticates against an **enterprise identity provider** from day one: OpenID Connect or SAML to Entra ID, Okta, Ping, government SSO or a national identity platform. Local development uses the same flows with a local provider. There's no “temporary” username and password table waiting to be removed.\n\nService-to-service calls use their own identities, and AI agents act either as a service identity or on behalf of the invoking user, never with ambient superuser rights.\n\n## Authorization\n\nAuthorization is **explicit and central**:\n\n- Roles map to permissions in one place.\n- Permissions are checked in the application services layer, not in route handlers or UI code. Every entry point gets the same checks: the API, background jobs, agents and imports.\n- Consequential actions can require a second approver (maker\u002Fchecker) as a declared policy, not ad-hoc code.\n- Principals are re-evaluated per request, so a disabled user or a changed role takes effect immediately.\n\nThis is what makes a security review short. Reviewers read one policy map instead of hunting through handlers.\n\n## Multi-tenancy\n\nMany applications serve several tenants: business units, subsidiaries, government entities, partners, or customers of an SI. The foundations treat the **tenant as a first-class part of the data model**:\n\n- Tenant-owned records are stored and queried within the tenant's partition.\n- The tenant is taken from the authenticated principal, never from request data. A forged tenant ID in a payload is ignored.\n- Cross-tenant requests return “not found” rather than “forbidden”, so they don't leak existence.\n- Cross-tenant views, where legitimately needed, are separate and permissioned paths.\n\nIsolation is tested automatically: cross-tenant reads and writes are part of every foundation's test suite.\n\n## Why generate it instead of documenting it\n\nA guideline that says “always check the tenant” is followed until the deadline. A generated core that makes the unsafe path hard is followed every time. Because the same patterns run across the whole inventory, a weakness found in one place gets fixed in the factory and flows into every foundation that follows.\n\n## What still happens per customer\n\nThe integration with the customer's identity provider and directory, their role model and approval policies, their tenancy boundaries, and their security review. The rails are fixed, and the configuration is the customer's.\n\nMore on the rails: [Architecture](\u002Ffactory\u002Farchitecture) · [AI accelerates, architecture governs](\u002Fblog\u002Fai-accelerates-architecture-governs)\n","\u003Cp>Ask what usually delays an AI application's go-live and the answer is rarely the AI. It's the security review. Specifically, the discovery that identity was bolted on, authorization checks are scattered through the code, and tenant isolation depends on every developer remembering a \u003Ccode>where\u003C\u002Fcode> clause.\u003C\u002Fp>\n\u003Cp>In our factory, these three concerns are part of the architecture from the first commit. They're generated into the core of every application foundation.\u003C\u002Fp>\n\u003Ch2>Identity\u003C\u002Fh2>\n\u003Cp>Every foundation authenticates against an \u003Cstrong>enterprise identity provider\u003C\u002Fstrong> from day one: OpenID Connect or SAML to Entra ID, Okta, Ping, government SSO or a national identity platform. Local development uses the same flows with a local provider. There's no “temporary” username and password table waiting to be removed.\u003C\u002Fp>\n\u003Cp>Service-to-service calls use their own identities, and AI agents act either as a service identity or on behalf of the invoking user, never with ambient superuser rights.\u003C\u002Fp>\n\u003Ch2>Authorization\u003C\u002Fh2>\n\u003Cp>Authorization is \u003Cstrong>explicit and central\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Roles map to permissions in one place.\u003C\u002Fli>\n\u003Cli>Permissions are checked in the application services layer, not in route handlers or UI code. Every entry point gets the same checks: the API, background jobs, agents and imports.\u003C\u002Fli>\n\u003Cli>Consequential actions can require a second approver (maker\u002Fchecker) as a declared policy, not ad-hoc code.\u003C\u002Fli>\n\u003Cli>Principals are re-evaluated per request, so a disabled user or a changed role takes effect immediately.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This is what makes a security review short. Reviewers read one policy map instead of hunting through handlers.\u003C\u002Fp>\n\u003Ch2>Multi-tenancy\u003C\u002Fh2>\n\u003Cp>Many applications serve several tenants: business units, subsidiaries, government entities, partners, or customers of an SI. The foundations treat the \u003Cstrong>tenant as a first-class part of the data model\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Tenant-owned records are stored and queried within the tenant's partition.\u003C\u002Fli>\n\u003Cli>The tenant is taken from the authenticated principal, never from request data. A forged tenant ID in a payload is ignored.\u003C\u002Fli>\n\u003Cli>Cross-tenant requests return “not found” rather than “forbidden”, so they don't leak existence.\u003C\u002Fli>\n\u003Cli>Cross-tenant views, where legitimately needed, are separate and permissioned paths.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Isolation is tested automatically: cross-tenant reads and writes are part of every foundation's test suite.\u003C\u002Fp>\n\u003Ch2>Why generate it instead of documenting it\u003C\u002Fh2>\n\u003Cp>A guideline that says “always check the tenant” is followed until the deadline. A generated core that makes the unsafe path hard is followed every time. Because the same patterns run across the whole inventory, a weakness found in one place gets fixed in the factory and flows into every foundation that follows.\u003C\u002Fp>\n\u003Ch2>What still happens per customer\u003C\u002Fh2>\n\u003Cp>The integration with the customer's identity provider and directory, their role model and approval policies, their tenancy boundaries, and their security review. The rails are fixed, and the configuration is the customer's.\u003C\u002Fp>\n\u003Cp>More on the rails: \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa> · \u003Ca href=\"\u002Fblog\u002Fai-accelerates-architecture-governs\">AI accelerates, architecture governs\u003C\u002Fa>\u003C\u002Fp>\n","Identity, tenancy and authorization from the first commit","Why identity, multi-tenancy and authorization are generated into the core of every fazeZERO application foundation instead of added before go-live.","factory-and-architecture",[13,14,15,16],"identity","architecture","application-factory","api-first","fazezero-editorial","2026-07-29T00:00:00.000Z",2026,7,3,"published",false,{"id":25,"slug":26,"body":27,"html":28,"title":29,"description":30,"category":11,"tags":31,"author":17,"date":33,"year":19,"month":34,"quarter":35,"status":22,"featured":23,"series":36,"seriesOrder":21},"2026\u002F06\u002Ffactory-and-architecture\u002Fcoding-assistants-are-not-an-architecture","coding-assistants-are-not-an-architecture","\nIt is the most common objection we hear from enterprises and systems integrators, and it's a fair one:\n\n> “Our developers already use Cursor, Claude Code and Copilot. Why do we need you?”\n\nThe honest answer is **not** that we have better AI. We use the same class of tools. The difference is what those tools are pointed at.\n\n## Implementation engines\n\nAI coding assistants are extraordinary at implementation. Given a clear intent and a clear structure, they write correct code quickly, refactor fluently and generate tests on request. They make good engineers much faster.\n\nWhat they don't provide is the structure itself. A general-purpose assistant has no opinion about your bounded contexts, your API versioning policy, your tenancy model or how your adapters should isolate a core banking system. It will happily produce *an* answer every time. It will not reliably produce the *same* answer every time.\n\n## Where the risk accumulates\n\nThe risks of architecture-free AI development are predictable:\n\n- **Inconsistent domain boundaries.** The same business concept lives in three services, modelled three ways.\n- **Weak API design.** Endpoints shaped by screens rather than contracts, and no versioning discipline.\n- **Late identity and authorization.** Role checks scattered through handlers, added after the demo.\n- **Inconsistent multi-tenancy.** Tenant isolation handled by convention, differently in each module.\n- **Thin testing.** Tests written to pass rather than to specify.\n- **Drift.** Regenerating a module quietly changes behaviour elsewhere.\n- **Production rework.** The prototype gets rewritten the moment it meets security review, integration or scale.\n\nNone of this is the tool's fault. It's what happens when the architecture is left to emerge.\n\n## An architectural system\n\nfazeZERO provides the part the assistants lack: a reusable application architecture refined over roughly two years and exercised across hundreds of application foundations. Concretely:\n\n- **Domain-Driven Design** with bounded contexts as the unit of structure\n- **OpenAPI-first contracts** validated before implementation\n- **Identity, authorization and multi-tenancy** generated into the core\n- **Adapters** that keep integrations out of the domain\n- **Testing and AI evaluation** as a delivery gate\n- **Observability, audit and evidence** patterns shared by every application\n- **Controlled regeneration**, so generated code can be refreshed without losing customer logic\n\nThe assistants then do what they are good at, inside those rails. We call it simply: **AI accelerates the implementation. fazeZERO governs the architecture.**\n\n## What this means for a systems integrator\n\nFor an SI, the question is not “fazeZERO or our developers.” It's whether every engagement should start with a blank repository and a fresh architecture debate. A reusable application layer means:\n\n- proposals start from an existing foundation and a defined delta\n- less pre-sales engineering on every opportunity\n- the SI's developers use their AI tools on customer-specific work, not on reinventing the plumbing\n\nWe describe the partner model in [how systems integrators can industrialize AI delivery](\u002Fblog\u002Fhow-systems-integrators-industrialize-ai-delivery).\n\n## A simple test\n\nAsk your team to build the same small application twice, a week apart, with the same assistant and the same requirements. Then compare the two architectures. If they differ in ways that would matter in production, you have found the gap an architectural system fills.\n\nSee the rails in detail on the [Architecture](\u002Ffactory\u002Farchitecture) page, or [bring us a use case](\u002Fcontact) and we'll show you the delta against the closest foundation.\n","\u003Cp>It is the most common objection we hear from enterprises and systems integrators, and it's a fair one:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>“Our developers already use Cursor, Claude Code and Copilot. Why do we need you?”\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>The honest answer is \u003Cstrong>not\u003C\u002Fstrong> that we have better AI. We use the same class of tools. The difference is what those tools are pointed at.\u003C\u002Fp>\n\u003Ch2>Implementation engines\u003C\u002Fh2>\n\u003Cp>AI coding assistants are extraordinary at implementation. Given a clear intent and a clear structure, they write correct code quickly, refactor fluently and generate tests on request. They make good engineers much faster.\u003C\u002Fp>\n\u003Cp>What they don't provide is the structure itself. A general-purpose assistant has no opinion about your bounded contexts, your API versioning policy, your tenancy model or how your adapters should isolate a core banking system. It will happily produce \u003Cem>an\u003C\u002Fem> answer every time. It will not reliably produce the \u003Cem>same\u003C\u002Fem> answer every time.\u003C\u002Fp>\n\u003Ch2>Where the risk accumulates\u003C\u002Fh2>\n\u003Cp>The risks of architecture-free AI development are predictable:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Inconsistent domain boundaries.\u003C\u002Fstrong> The same business concept lives in three services, modelled three ways.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Weak API design.\u003C\u002Fstrong> Endpoints shaped by screens rather than contracts, and no versioning discipline.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Late identity and authorization.\u003C\u002Fstrong> Role checks scattered through handlers, added after the demo.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Inconsistent multi-tenancy.\u003C\u002Fstrong> Tenant isolation handled by convention, differently in each module.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Thin testing.\u003C\u002Fstrong> Tests written to pass rather than to specify.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Drift.\u003C\u002Fstrong> Regenerating a module quietly changes behaviour elsewhere.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Production rework.\u003C\u002Fstrong> The prototype gets rewritten the moment it meets security review, integration or scale.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of this is the tool's fault. It's what happens when the architecture is left to emerge.\u003C\u002Fp>\n\u003Ch2>An architectural system\u003C\u002Fh2>\n\u003Cp>fazeZERO provides the part the assistants lack: a reusable application architecture refined over roughly two years and exercised across hundreds of application foundations. Concretely:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Domain-Driven Design\u003C\u002Fstrong> with bounded contexts as the unit of structure\u003C\u002Fli>\n\u003Cli>\u003Cstrong>OpenAPI-first contracts\u003C\u002Fstrong> validated before implementation\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Identity, authorization and multi-tenancy\u003C\u002Fstrong> generated into the core\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Adapters\u003C\u002Fstrong> that keep integrations out of the domain\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testing and AI evaluation\u003C\u002Fstrong> as a delivery gate\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Observability, audit and evidence\u003C\u002Fstrong> patterns shared by every application\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Controlled regeneration\u003C\u002Fstrong>, so generated code can be refreshed without losing customer logic\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The assistants then do what they are good at, inside those rails. We call it simply: \u003Cstrong>AI accelerates the implementation. fazeZERO governs the architecture.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>What this means for a systems integrator\u003C\u002Fh2>\n\u003Cp>For an SI, the question is not “fazeZERO or our developers.” It's whether every engagement should start with a blank repository and a fresh architecture debate. A reusable application layer means:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>proposals start from an existing foundation and a defined delta\u003C\u002Fli>\n\u003Cli>less pre-sales engineering on every opportunity\u003C\u002Fli>\n\u003Cli>the SI's developers use their AI tools on customer-specific work, not on reinventing the plumbing\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>We describe the partner model in \u003Ca href=\"\u002Fblog\u002Fhow-systems-integrators-industrialize-ai-delivery\">how systems integrators can industrialize AI delivery\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>A simple test\u003C\u002Fh2>\n\u003Cp>Ask your team to build the same small application twice, a week apart, with the same assistant and the same requirements. Then compare the two architectures. If they differ in ways that would matter in production, you have found the gap an architectural system fills.\u003C\u002Fp>\n\u003Cp>See the rails in detail on the \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa> page, or \u003Ca href=\"\u002Fcontact\">bring us a use case\u003C\u002Fa> and we'll show you the delta against the closest foundation.\u003C\u002Fp>\n","Cursor, Claude Code and Copilot are implementation engines, not architectures","Our developers already have AI coding tools, so why use fazeZERO? The answer is not better AI. It is the architectural system the AI works inside.",[14,15,16,32],"production","2026-06-23T00:00:00.000Z",6,2,"the-application-factory",{"id":38,"slug":39,"body":40,"html":41,"title":42,"description":43,"category":11,"tags":44,"author":17,"date":46,"year":19,"month":34,"quarter":35,"status":22,"featured":47,"series":36,"seriesOrder":35},"2026\u002F06\u002Ffactory-and-architecture\u002Fai-accelerates-architecture-governs","ai-accelerates-architecture-governs","\nEvery 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**.\n\nOur answer is a fixed, proven architecture. AI accelerates the implementation inside it. It does not get to reinvent the structure for each customer.\n\n## The problem with improvised architecture\n\nGive 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.\n\nRun that process ten times for ten applications and you get ten architectures:\n\n- domain boundaries drawn differently every time\n- APIs designed after the screens, not before them\n- identity and authorization added once someone asks about security\n- multi-tenancy handled three different ways\n- tests written after the fact, if at all\n- code that drifts every time it is regenerated\n\nNone of this shows in the demo. All of it shows in production, as rework.\n\n## What we do instead\n\nOur pipeline runs in a fixed order:\n\n1. **Requirements**: the business problem, users, workflows and user stories.\n2. **Domain model**: bounded contexts and the vocabulary of the business.\n3. **Governed architecture**: the same layering, service boundaries and adapters every time.\n4. **API contracts**: OpenAPI definitions for every boundary, before implementation.\n5. **Generated core**: services, adapters, identity, authorization and tenancy from the factory.\n6. **Customer-specific logic and AI**: the part that is genuinely unique to this customer.\n7. **Testing and controls**: automated tests, AI evaluations, audit and evidence.\n8. **Web application and deployment**: a working UI and a baseline for the customer's cloud.\n\nAI 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.\n\n## Why this is faster, not slower\n\nIt 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.\n\nWhen 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.\n\nThis 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.\n\n## What changes and what doesn't\n\nBetween customers, **these change**: domain vocabulary, workflows, integrations, data, AI capabilities, cloud and policies.\n\n**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.\n\nCustomer-specific functionality changes. The architectural discipline does not.\n\n## Where this leaves AI coding tools\n\nWe 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](\u002Fblog\u002Fcoding-assistants-are-not-an-architecture).\n\n## Where to go next\n\n- How the pipeline works end to end: [the Application Factory](\u002Ffactory)\n- The patterns every application starts with: [Architecture](\u002Ffactory\u002Farchitecture)\n- Your own use case mapped onto it: [Solution Definition Sprint](\u002Fservices\u002Fsolution-definition-sprint)\n","\u003Cp>Every enterprise now has access to AI that writes code. The interesting question is no longer \u003Cem>whether\u003C\u002Fem> AI writes the application. It is \u003Cstrong>what the AI is allowed to write into\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Our answer is a fixed, proven architecture. AI accelerates the implementation inside it. It does not get to reinvent the structure for each customer.\u003C\u002Fp>\n\u003Ch2>The problem with improvised architecture\u003C\u002Fh2>\n\u003Cp>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 \u003Cem>emerged\u003C\u002Fem>: shaped by the order in which prompts arrived, the examples the model happened to favour, and whatever the developer accepted at 11pm.\u003C\u002Fp>\n\u003Cp>Run that process ten times for ten applications and you get ten architectures:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>domain boundaries drawn differently every time\u003C\u002Fli>\n\u003Cli>APIs designed after the screens, not before them\u003C\u002Fli>\n\u003Cli>identity and authorization added once someone asks about security\u003C\u002Fli>\n\u003Cli>multi-tenancy handled three different ways\u003C\u002Fli>\n\u003Cli>tests written after the fact, if at all\u003C\u002Fli>\n\u003Cli>code that drifts every time it is regenerated\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of this shows in the demo. All of it shows in production, as rework.\u003C\u002Fp>\n\u003Ch2>What we do instead\u003C\u002Fh2>\n\u003Cp>Our pipeline runs in a fixed order:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Requirements\u003C\u002Fstrong>: the business problem, users, workflows and user stories.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Domain model\u003C\u002Fstrong>: bounded contexts and the vocabulary of the business.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Governed architecture\u003C\u002Fstrong>: the same layering, service boundaries and adapters every time.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>API contracts\u003C\u002Fstrong>: OpenAPI definitions for every boundary, before implementation.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Generated core\u003C\u002Fstrong>: services, adapters, identity, authorization and tenancy from the factory.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Customer-specific logic and AI\u003C\u002Fstrong>: the part that is genuinely unique to this customer.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testing and controls\u003C\u002Fstrong>: automated tests, AI evaluations, audit and evidence.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Web application and deployment\u003C\u002Fstrong>: a working UI and a baseline for the customer's cloud.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>AI is involved at almost every step. It drafts user stories, proposes domain models, writes implementation and generates tests. But it works \u003Cem>inside\u003C\u002Fem> rails that were set before it arrived.\u003C\u002Fp>\n\u003Ch2>Why this is faster, not slower\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>This is also why we can start customer work from an \u003Cstrong>existing application foundation\u003C\u002Fstrong> rather than a blank repository. Hundreds of foundations share one architectural grammar, so the closest one is usually a meaningful head start.\u003C\u002Fp>\n\u003Ch2>What changes and what doesn't\u003C\u002Fh2>\n\u003Cp>Between customers, \u003Cstrong>these change\u003C\u002Fstrong>: domain vocabulary, workflows, integrations, data, AI capabilities, cloud and policies.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>These don't\u003C\u002Fstrong>: bounded contexts as the unit of design, contract-first APIs, identity and tenancy in the core, tests as a gate, observability, and controlled regeneration.\u003C\u002Fp>\n\u003Cp>Customer-specific functionality changes. The architectural discipline does not.\u003C\u002Fp>\n\u003Ch2>Where this leaves AI coding tools\u003C\u002Fh2>\n\u003Cp>We use them, and so should your developers. They are excellent implementation engines. The mistake is treating them as an \u003Cem>architecture\u003C\u002Fem>. We have written more about that in \u003Ca href=\"\u002Fblog\u002Fcoding-assistants-are-not-an-architecture\">coding assistants are not an architecture\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Where to go next\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>How the pipeline works end to end: \u003Ca href=\"\u002Ffactory\">the Application Factory\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>The patterns every application starts with: \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>Your own use case mapped onto it: \u003Ca href=\"\u002Fservices\u002Fsolution-definition-sprint\">Solution Definition Sprint\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n","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.",[15,14,32,45],"enterprise","2026-06-18T00:00:00.000Z",true,1790080513446]