What you will learn What "you produce intent, not code" actually means, and the two things a developer owns.
Until now a developer's output was code. Under IntentOps:
| Output | What is reviewed | |
|---|---|---|
| Before | code | code review |
| IntentOps | intent + tests | is the intent right, are the tests sufficient |
AI handles implementation. The developer defines what to build and how we know it is done.
Write it in plain language, but leave no room for interpretation.
Room for interpretation is a bug. In the example above, omit "no stacking" and AI decides for itself — and that decision may differ from what was intended.
This is the four parts of a good instruction applied to code work.
The specification turned into something judgeable.
Tests are the only definition of "done." Five pass, it is finished; they do not, it is not. There is no "almost there."
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.
HyperTeamsgraph 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 -.-> TIntent 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.
Honestly, some things get harder.
| Before | IntentOps | |
|---|---|---|
| Starting vaguely | possible (figure it out while building) | impossible |
| Understanding by building | a common approach | you must understand up front |
| Partial completion | "we're 80% there" | pass or not pass |
"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.
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.
Similar but different.
| TDD | IntentOps | |
|---|---|---|
| Tests first | yes | yes |
| A person writes the code | yes | no |
| Status of code | an asset | derived |
| Purpose | better design | automating the judgement of done |
If you have TDD habits, moving to IntentOps is easy.
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.
1. What two things does a developer own under IntentOps?
The specification (unambiguous) and the tests (an executable pass criterion). AI handles implementation.
2. What has to be true for "code is ephemeral" to hold?
The tests must be dense enough. Tests are the only thing guaranteeing that regenerated code preserves the old behaviour, so with weak tests regeneration is a gamble rather than an improvement.
3. What gets harder under IntentOps?
Starting vaguely becomes impossible. "Build it and understand the requirements as you go" stops working. Splitting work small mitigates it.
When code becomes derived, the definition of legacy changes too → Fluid software
✗ "Let people apply coupons in the cart"✓ "Enter a coupon code in the cart to apply a discount. - Only one coupon applies (no stacking) - Expired coupons show 'This coupon has expired' - Below the minimum order value, show 'Valid on orders over $30' - The total updates immediately after applying"Tests: 1. Apply a valid coupon → discounted price shown 2. Try to apply a second coupon → rejected + message 3. Expired coupon → 'This coupon has expired' 4. $30 coupon on a $20 order → 'Valid on orders over $30' 5. After applying, total = original − discount1. Pick one task (a small one)2. Write the tests before writing any code3. Check whether those tests can judge "done"4. If not, the specification is incomplete → rewrite it