One idea ran through the whole program under different names: the agent needs a contract for the task; it needs an executable standard — rules it applies on every PR; it needs a shared language so the person and the AI understand the task the same way. Until now we deliberately did not name a concrete methodology — because the principle matters more than the brand. This article closes the loop: here is what such a principle is made of, here are the ways to hold it, and here is the one this site is built on.

Why a methodology at all, if you have AI

The temptation is understandable: the executor is so strong, just hand it the task in words — it'll figure it out. On a small piece, that's true. But a product engineer leads the whole path alone, and over distance unnamed rules drift apart: the agent decides the same question differently across PRs, the seams between pieces don't line up, review starts from scratch every time.

A methodology is a way to make the rules explicit and checkable once, so the agent holds them itself while you think about the product. Not bureaucracy for its own sake, but leverage: the stronger the executor, the more each rule that lives only in your head costs you.

What makes a methodology fit for AI

Not every methodology sits equally well on work with an agent. The ones that work have four properties:

  • An explicit contract for the task. Not "do it well," but a checkable description: what goes in, what comes out, which rules, how you know it's done.
  • Executable rules, not a PDF. A standard the agent applies on every PR — not a guide a human is "supposed to remember."
  • A shared vocabulary. The same names for concepts in the spec, in the code, and in conversation — so the person and the AI don't have to translate each other.
  • Slicing into slices. A unit of work you can specify, build, and verify whole — not "a layer of all features at once."

These four properties are not about a particular brand. Choose a methodology by them.

Ways to hold it

There are several approaches, and they don't exclude each other:

  • Spec-driven development — start from an executable spec, derive code and tests from it.
  • DDD plus explicit standards — a shared domain language and codified rules for style and architecture.
  • ADRs — architecture decision records: fix "why this way" so the choice isn't re-litigated.
  • Use Case Pattern — a methodology that ties all of the above into one frame: a use-case spec, a domain layer, paired executable rules. This site is built on it.

Use Case Pattern — the one this site teaches

Use Case Pattern (UCP) is the methodology taught here and the one the standards and agent skills are organized around. Briefly, what it gives a product engineer:

  • A use-case contract. Every command or query is described by a card: actor, input, invariant, acceptance criteria. That is the contract you hand the agent.
  • An executable standard. Rules with R-* codes and a paired skill the agent applies on every PR. The standard lives in a rule, not in a reviewer's memory.
  • One body of knowledge in two forms. Every piece exists twice: an article for you — to understand; a rule for the agent — to apply.

An overview of the methodology is on the Use Case Pattern page. The whole product-engineer program is this methodology applied by one person with AI: from the problem to shipping and metrics.

Not the only way

UCP is not dogma and not the only right answer. If a spec-driven flow or your own set of standards already works for you, the four properties from the section above matter more than any particular brand. Choose by context: language, team, domain maturity.

This site teaches Use Case Pattern for two reasons: it gathers all four properties into one coherent frame, and it comes with ready executable rules the agent applies out of the box. But the value is in the discipline of explicit contracts and checkable rules — not in the name.

Next