[{"data":1,"prerenderedAt":25},["ShallowReactive",2],{"blog-article-coding-assistants-are-not-an-architecture":3},{"id":4,"slug":5,"body":6,"html":7,"title":8,"description":9,"category":10,"tags":11,"author":16,"date":17,"year":18,"month":19,"quarter":20,"status":21,"featured":22,"series":23,"seriesOrder":24},"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.","factory-and-architecture",[12,13,14,15],"architecture","application-factory","api-first","production","fazezero-editorial","2026-06-23T00:00:00.000Z",2026,6,2,"published",false,"the-application-factory",3,1790080511789]