IntentOps

What you will learn What "you produce intent, not deliverables" actually means, and the two things you own (unambiguous intent and deterministic verification criteria). This applies equally across software and business workflows.

The output changes

Until now a practitioner's output was manual craftsmanship (hand-written code, drafting documents, stitching spreadsheets). Under IntentOps:

AI handles drafting and execution. The human defines what to achieve and how to objectively verify it is done.

graph TD
  subgraph "Traditional Work (Craft-Centric)"
    C1["Vague Requirements"] --> C2["Human Manually Crafts Output (Asset)"]
    C2 --> C3["Review Delays & Late Revisions"]
  end
  subgraph "IntentOps (Intent-Centric)"
    I1["Unambiguous Intent Spec"] --> I2["Deterministic Criteria Defined First"]
    I2 --> I3["AI Agents Generate Deliverables (Artifacts)"]
  end
  C3 -.->|"Shift in Primary Focus"| I1

The two things you own

1. The specification (Intent) — unambiguous

Write it in plain language, but leave no room for interpretation.

Intent Spec in Engineering

Intent Spec in Marketing & Planning

Room for interpretation is a defect. In the marketing example above, omitting the specific dates or CTA leaves AI guessing — and that guess may derail the campaign goals.

This is the four parts of a good instruction applied to knowledge work.

2. The tests — executable pass criteria (Criteria)

The specification turned into objective, judgeable gates.

Criteria are the only definition of "done." All conditions pass, it is finished; any condition fails, it is not. There is no "almost there."

Code is ephemeral

This is where the well-known phrase comes from — "code is ephemeral."

When you need to optimise or move to a different stack, you do not edit the code; you regenerate it from the same intent.

graph TD
  I["Intent + tests<br/>the original"] --> C1["Code v1"]
  I --> C2["Code v2<br/>performance pass"]
  I --> C3["Code v3<br/>different language"]
  C1 -.->|"all pass the same tests"| T["Pass criterion"]
  C2 -.-> T
  C3 -.-> T

Intent and tests are the original; code is derived. The old way inverted this — code was the original and documentation was derived, which is why the documentation was always behind.

What gets harder

Honestly, some things get harder.

"Build it and understand the requirements as you go" stops working. That was a genuinely common approach, so it takes adjustment.

But splitting small mitigates it. One micro-sprint is small enough to understand from the outset. The difficulty comes from trying to specify a large feature in one go.

How to start in practice

Before adopting it wholesale, practise like this:

Getting stuck at step 3 is the important experience. Most people first discover "these cannot judge completion." That shows how vaguely they had been starting all along.

Common misconceptions

"Isn't this just TDD?"

Similar but different.

If you have TDD habits, moving to IntentOps is easy.

"Doesn't writing specs that detailed take longer than writing the code?"

It might, once. But the specification gets reused — when regenerating, when building something similar, and when checking later why it was built this way.

Code, once written, is the end of that code. Intent stays alive.

Check yourself

1. What two things does a developer own under IntentOps?

2. What has to be true for "code is ephemeral" to hold?

3. What gets harder under IntentOps?

When code becomes derived, the definition of legacy changes too → Fluid software