Patterns as code,
not as prose.

01

The same instruction, three different services

Every team has a page like this somewhere in its wiki:

“Each command gets its own handler. Validation happens before the handler runs. Handlers never touch the database directly — they go through the repository. Every command publishes its events through the outbox.”

Hand that page to an AI coding assistant and ask for three new commands. You will probably get three services that each follow the rule — in three different ways. One validates inside the handler. One names the repository differently. One “publishes through the outbox” in a way your platform team has never seen. Each one passes its tests. None of them is quite your pattern.

That isn’t a bad model. It’s what language models do: they interpret text, and interpretation varies with the prompt, the files in context, the model version and a little randomness. For business logic, that flexibility is the point. For the structure of your system, it’s the problem.

Architecture should not depend on how a model happens to read a paragraph today.

02

Express the pattern as a generator

An Nx generator is a small program that creates code from templates and options. It is how many teams already scaffold libraries and applications in Nx workspaces. It turns out to be a very convenient way for an architect to express a design pattern: the folders, the files, the naming, the wiring — written once, in code, with a schema for its options.

{
  "$id": "command",
  "properties": {
    "name":    { "type": "string", "description": "Command name, e.g. AddCartItem" },
    "service": { "type": "string", "description": "The service that owns it" },
    "events":  { "type": "array",  "description": "Events the command records" }
  },
  "required": ["name", "service"]
}

nx g @acme/nx-cqrs:command --name=AddCartItem --service=cart --events=CartItemAdded

The handler, the validator, the repository call and the outbox wiring come out the same every time. What is left for the AI is the part that is genuinely new: what adding an item to a cart means for this business.

03

How M1Spec uses your patterns

1. Register your pattern repository. In M1Spec’s Enterprise Pattern Language, add the repository that holds your patterns. Each pattern keeps its description and diagrams, and the technologies it uses are linked to your technology catalog.
2. Patterns become part of the plan. When M1Spec plans a change, each task says which of your patterns it applies, and through which generator.
3. The agent runs your generators. The M1Spec agent fetches your Nx plugin, runs the generator with the right options in your repository, and has your coding assistant fill in the business logic.
4. The result is reported back. The agent reports what changed in the architecture — new projects, containers and components — with evidence, for you to review before it becomes part of the model.

04

Why this matters beyond one team

• Your architecture scales without you in every review. The pattern is enforced by how code is created, not by how carefully someone reads the pull request.
• Patterns become an asset. Versioned, tested and shared like any package — across teams, across projects, and for consultancies, across clients.
• AI cost goes where it creates value. Model reasoning is spent on domain logic, not on rewriting boilerplate a generator produces in milliseconds.

Natural language for intent. Generators for structure. AI for what’s new.