Before AI Coding: Write a One-Rule Brief and Test the Boundary

A coding agent can implement a rule you never agreed on. The result may compile beautifully and still do the wrong thing. Before asking for another feature, write down one decision the software must make, the words it uses and the examples that prove you mean the same thing.

Why this is worth doing now

In an August 20, 2026 essay surfaced by GeekNews this week, Miłosz Smółka argues that domain understanding and shared language remain important when AI writes code. He also cautions against applying advanced domain-driven design patterns to simple projects. That is an argument from a practitioner, not a benchmark proving that one architecture wins. Read the original Three Dots Labs essay.

The practical response here is deliberately smaller than an architecture migration: a one-rule brief. Use it when people disagree about what a status means, when an agent invents an exception, or when a passing test seems to validate the wrong behavior. It complements a coding handoff record: the handoff says where work stopped; this brief says what one piece of behavior is supposed to mean.

Choose one decision, not an entire product

Start with a sentence that has an actor, an action and a limit. “Build booking management” is too broad. “A booking owner may cancel a confirmed room booking before its start time” is small enough to interrogate. The example below is fictional product policy, not a recommendation for a real venue.

For the first slice, explicitly exclude refunds, recurring bookings, staff overrides and notification delivery. Those may matter later. Naming them now prevents an agent from quietly designing all four while you are trying to settle one boundary.

Give the important words a local meaning

These definitions belong to this example. Do not automatically rename a “customer” in billing to match a “member” in booking. First ask whether the two words refer to the same concept and who owns the translation. A glossary should clarify a boundary, not erase one.

Write examples that could disagree with the implementation

Cucumber's original Example Mapping article distinguishes a story, rules, concrete examples and unanswered questions. It describes a collaborative discovery technique rather than a requirement to write formal test syntax in the meeting. Use that distinction here: if you cannot name the expected result, record a question instead of pretending you have a test. See Matt Wynne's December 8, 2015 explanation.

For this fictional rule, let the booking start at 10:00:00 UTC. Fix the clock in the test rather than relying on the time at which the test happens to run. All examples use the same date and a confirmed booking unless stated otherwise.

The table intentionally leaves one case open. Decide whether the second request should return the existing outcome or a specific error, and what an audit entry should do. A model choosing the friendliest message is not the same as the team choosing a policy. Also settle where the trusted clock is evaluated and how simultaneous requests affect stored state; a client-side disabled button alone does not enforce this rule.

Keep unknowns visible and assign an owner

Put each unresolved question beside the decision it blocks. “What about time zones?” is vague. “Which instant does the server compare, and how is a user's local start time converted?” gives someone a concrete investigation. Write an owner and the evidence needed to close it. Do not include real customer records or credentials in a prompt when a made-up example will do.

• Policy question: What should a repeated cancellation return? Owner: the person responsible for booking behavior.
• Implementation question: Can two requests both create a cancellation side effect? Owner: the engineer responsible for the write path.
• Review question: Do the tests verify the stored result as well as the response? Owner: the reviewer.

An agent can propose options and enumerate edge cases. Ask it to mark assumptions, not promote them into requirements. If a question changes the permitted action or the data kept, resolve that question before shipping the affected behavior.

Copy this one-rule brief

Feature / rule:
Decision owner:
Terms and their local meanings:
Allowed actor and action:
Required starting state:
Exact time / quantity / status boundary:
Expected resulting state:
Forbidden changes or side effects:
Success example:
Boundary example:
Rejected example:
Repeated or simultaneous request behavior:
Unanswered questions and owners:
Explicitly excluded work:
Evidence required before merge:

Then give the agent a bounded instruction: “Restate this rule and list contradictions or missing outcomes first. Do not implement unresolved policy. Once the brief is agreed, propose the smallest change and tests that cover each decided example. Preserve unrelated behavior. Report which checks actually ran and which remain untested.” This is a suggested prompt, not a guarantee that an agent will follow it.

Review the rule, the change and the proof separately

1. Words: Do the brief, function names and test names describe the same concept?
2. Examples: Does each decided row have an assertion about the resulting state, not only a success message?
3. Boundary: Is the equality case tested explicitly? Are units and time references consistent?
4. Owner: Did a responsible person settle policy questions rather than leave generated assumptions in place?
5. Evidence: Which test command ran, against which revision, and what was skipped?

For the booking example, a green ordinary-success test is not enough if the exact-start test is missing. Equally, a complete brief does not prove that storage failures, authorization or concurrency are safe. Review those implementation concerns in the actual system and keep untested areas visible.

The useful stopping point is modest: one small decision is understood, its important examples have agreed outcomes, and the code can be checked against them. You do not need a cathedral of diagrams to stop a robot from enthusiastically building the wrong cupboard.