x2

X2

An agentic software engineering method: AI agents do the building, the build enforces the rules that must always hold, a person decides only at the gates, and the method measures its own cost in human turns.

The code is no longer the treasure

Something strange happened to software in the last few years, and almost nobody outside the industry noticed.

For half a century, the most valuable thing a software company owned was its code, the written instructions its programs run on. Code was slow and expensive to produce. Companies guarded it like gold, because rewriting it could take years and cost millions.

Then AI learned to write it.

Today, an AI assistant can write, and rewrite, working code in minutes. An entire section of a program can be regenerated faster than a person could read it. Overnight, code went from the most expensive thing a company owns to the cheapest. And anything that can be remade on demand is no longer a treasure.

So what is the treasure now?

The decisions. The things no AI can invent for you:

• how a product should be split into parts
• what information it must keep, and what must always stay true about it
• what it should look like and how it should feel to use
• which rules must never, ever break

A banking app can be rebuilt in an afternoon. The decision that no customer's balance may ever silently change cannot be rebuilt by anyone but the people responsible for it.

X2 takes this reversal seriously. It was created for teams who let AI do the building, and it answers one uncomfortable question: how do you stay in control of a builder that works faster than you can watch?

The trouble with a brilliant, forgetful builder

Imagine hiring a builder who works a hundred times faster than anyone alive, but who forgets everything between jobs and has no personal stake in whether the work is any good.

You could hand that builder your rules on paper. It would read them, then forget or ignore them on the very next task. This is not a hypothetical; it is how AI coding assistants actually behave. A rule that nobody actively checks is only a suggestion.

What X2 does about it

X2 sorts everything into three piles and puts each one where it cannot go wrong.

The unbreakable rules go into the machinery. Instead of living on paper, they are built into the automated checks that every piece of work must pass before it ships. Break a rule and the work simply fails, no matter what the AI claims. A machine enforces them, so they cannot be forgotten.

The decisions stay with people. They live in a handful of short documents that humans own and humans change. This is the treasure, and it is kept deliberately small.

The code becomes disposable. It is regenerated from the decisions whenever needed, like printing a fresh copy from a master document. Nobody mourns it.

The result: nothing important depends on the AI remembering anything.

In the method's own vocabulary the three piles are the invariants, the decisions and the consequences. X2.md walks through all three, and the reasoning behind them.

People keep the wheel

The AI does the building, but a person decides at three checkpoints:

1. Approve the plan. What is going to be built.
2. Approve the design. What it will look like, confirmed as the target to build toward.
3. Accept the finished work. Only after an independent check confirms it truly runs.

Between checkpoints, the AI must stop and ask whenever it hits a question no document answers.

And "finished" is never taken on the builder's word. Work counts as done only when a report, verified by someone who did not build it, shows it was genuinely tested and genuinely works. Nobody grades their own homework. The failure this guards against even has a name inside the method: green-but-wrong, a build where every light is green while the product is quietly not what was decided.

What it has built

Vemos is a real-time whiteboard for running facilitated sessions. Editors set a board up and hold its scaffold still; participants join from a personal link and contribute freely, and everything they touch is governed by rules the product enforces rather than merely records. X2 built it end to end, and the whole record ships with it in teklabsdigital/x2-examples: the stories, the locked design, every decision, and the numbered ledger of every human turn it took.

One canvas with ten people on it, live: cards dragged and rewritten, lines drawn between them, text, highlights and shapes landing, every cursor named, every note signed by the person who wrote it.

learn.reqwiseconsulting.com is a free seven-lesson prompt course with an AI trainer that marks your work. X2 built it in 2 days, six slices, idea to production. Every moment a person had to step in was logged as it happened and published in record/metrics.md, which is the part most methods cannot show you.

Get started

You need Claude Code, because the skills are written for it, plus the toolchain of whichever edition you build on. Two editions ship, measured against the same claims catalog, each publishing its own conformance record:

edition	the stack	you need
kernel/node-react/	Fastify 5 on Node 24, TypeScript end to end, React 19 client, node:sqlite as the store	Node 24
kernel/dotnet-react/	ASP.NET Core on .NET 9, EF Core, React 19 client, SQL Server as the store	.NET 9 SDK, Node 24, Docker

The React client is the same in both, composed from kernel/shared/, which is the home for everything that is not specific to a stack. The Node edition needs nothing beyond the runtime, because its database engine ships inside Node itself and there is no container to start. The .NET edition runs its engine in Docker and its client on Node.

They are not equally measured, and the records say so rather than averaging it away. The .NET edition is the older one and has been through more verification rounds; the Node edition is the second witness, built later to test whether the claims are portable at all, and more of its rows are still owed. Each edition's conformance table states its own status row by row, and neither is reconciled against the other.

Install the plugin once, from inside Claude Code:

/plugin marketplace add teklabsdigital/x2-method
/plugin install x2@x2

The first command registers this repo as a plugin marketplace; the second installs the skills, namespaced under x2:, so they are available in every project, including the new repo the method creates for you. Type /x2: in Claude Code to see them listed.

Invoke a skill:

• By name. Type the slash command, such as /x2:stories.
• By intent. Say what you want ("I have a product idea", "the app misbehaves at runtime"). Each skill declares when it applies, and Claude selects the right one.

Ask for /x2:help at any time to see what to run next. Migrating an existing project? Read "Greenfield first, and why" further down, then use /x2:adopt instead of the flow below.

To work on the method itself, clone the repo and symlink skills/* into Claude Code's personal skills folder instead; installed that way the skills appear unscoped (/stories, /seed, and so on) rather than under x2:.

From a user story to a running app

X2 works in slices: thin pieces of the product that each work end to end. Start Claude Code and describe your product idea. Then follow the flow. You approve at 3 gates and answer the odd question; the agent does the rest.

1. x2:stories turns your idea into epic-level stories, one line each. You approve them (gate 1).
2. x2:seed creates your project repo from an edition and arms the CI gate. Name the edition you want when you run it; it instantiates that edition's manifest.
3. x2:decompose records how the system divides up, the schema and the first slice.
4. x2:design produces the whole-product design prototype. You approve it (gate 2a).
5. x2:lock copies the prototype into your repo as the contract to build to. You approve the lock (gate 2b).
6. x2:derive-tests derives the acceptance tests from the locked design.
7. x2:implement builds the slice until every check passes. It asks you only when it hits a decision no record answers.
8. x2:slice-exit produces the audited report that declares the slice done. You accept it (gate 3).

Then run it: each edition's README has a "Running it" section that starts the app locally, for Node and for .NET. Deployment is per project: the CI loop gates every merge, and you attach your own release step to it.

Repeat steps 5 to 8 for each next slice. At project close, x2:extract runs the extraction loop described in the next section, so what the ledger recorded feeds the method.

The method keeps score of itself

Every time a person steps in, the moment is logged and classified: a decision only a person could take, or a defect in the method or its tooling. The count of those turns per shipped slice is the method's price tag, and the goal is to bring it down.

At project close, x2:extract mines that log with two lenses. The defect lens catches what bit. The churn lens catches what quietly resisted: decisions that never failed a test yet kept costing attention, the failure no retrospective surfaces because nothing ever went red. Findings change the method only through a human ruling; the sanitized results are published in record/, and the next project starts by reading them. Each project is meant to make the next one cheaper, and the record shows whether it did.

Where the evidence stands

The invariants come from 2 production systems. The method itself has now run on three projects, every human turn logged, classified and audited. The second is public and running at learn.reqwiseconsulting.com; the third, Vemos, is published whole, ledger included, in teklabsdigital/x2-examples.

Its first headline figure (25 human turns for the pilot's first slice) is retired, by the method's own extraction ruling: it mixed counting rules and scopes. The metric history lives in record/metrics.md under one counting rule. What travels across projects:

• Defect share of counted turns fell from about a third on the pilot to about a tenth on the second project, and held at about a tenth on the third.
• The marginal slice is where the method pays out. After its first slice, the second project's slices cost 1 to 7 counted turns mid-build, one of them zero. The third project's seven slices ran 1 to 18: once fidelity checking against the locked design became deterministic mid-project, the next three slices cost 1 to 2 turns each, and the cost that remained sat where no automated tier can drive a pointer on a direct-manipulation canvas.
• The pilot's watch classes (bootstrap loss, green-but-not-running, completeness interrogations) went to near zero in the second project.

Treat those numbers the way the method itself demands:

• A sample of three, with no baseline. Nobody has yet built the same product without the method and counted.
• The third project's extraction is a milestone pass, not a close: workstreams are still open,