AI can accelerate implementation. It cannot resolve business rules we have not defined.
Coding agents are now good enough that the bottleneck has moved. Writing the code is rarely the slow part anymore. Knowing exactly what the code should do, and being able to show that it does it, is.
A simple request: “Implement license validation”
Consider a short task given to a coding agent: implement license validation. It sounds complete. Before any code is written, though, several decisions need to be clear:
| Open question | Why it's a policy, not a detail | Options someone has to choose between |
|---|---|---|
| What happens when a license expires? | It decides whether a customer's running system stops. | Stop immediately, allow a grace period, or degrade to read-only. |
| Can the runtime keep operating offline? | It trades availability against enforcement. | Block without a check, or trust a cached validation for a limited time. |
| Can one license authorize multiple instances? | It defines what the customer actually bought. | One instance per license, a seat count, or per-environment rules. |
| When does a renewal take effect? | It decides when a paying customer is unblocked. | On payment, on the next check-in, or after manual confirmation. |
These are business policies with architectural consequences. An offline grace period, for example, means the runtime needs a signed, cached validation result and a clock it can trust. That's not a detail to leave for the agent to infer.
Correct code, wrong policy
When a requirement leaves gaps, an agent fills them with plausible defaults. The tests it writes usually come from the same assumptions. The result can compile, pass every test, and still enforce the wrong policy.
- 01
Gap in the requirement
“Validate the license”, with no rule for expiry or offline use.
- 02
Agent infers a default
A reasonable-looking choice, made silently.
- 03
Tests share the assumption
Code and tests agree, because they come from the same guess.
- 04
Green build, wrong behavior
The policy is discovered by a customer, not a reviewer.
In AI-assisted engineering, I see three practices becoming increasingly important.
1 · Define intent before implementation
Specify expected behavior, constraints, system boundaries and acceptance criteria before delegating.
A specification doesn't have to be long. Acceptance criteria written as observable behavior are often enough:
# Illustrative acceptance criteria for one decided policy Given a license that expired less than 72 hours ago When the runtime validates it at startup Then it keeps running and reports "grace period" to the operator Given the licensing service is unreachable And the last signed validation is older than 24 hours When the runtime starts Then it refuses to start and logs the reason
The numbers in that example are placeholders. What matters is that they were decided by someone accountable for the business, written down, and made testable.
2 · Establish a shared domain language
An “active subscription”, a “valid license” and an “authorized runtime” are not necessarily the same thing.
DDD's Ubiquitous Language helps engineers and domain experts make those distinctions explicit within each bounded context. That clarity supports both human collaboration and agent execution: an agent given precise terms and their rules is far less likely to merge two concepts that the business keeps separate.
Precise terminology matters. So do the rules behind it. A glossary without the rules is just vocabulary.
3 · Build verification into the workflow
Harness engineering is not just better prompting. It is designing the environment around the agent: relevant context, scoped tools and permissions, progress tracking, and actionable feedback. I explore that idea further in AI Agents Can Write Production Code. Can They Prove It Works?
Before delegating a coding task, I ask:
- Which domain rules must remain true?
- What is the agent allowed to change?
- Which failure scenarios must be covered?
- What evidence is required to accept the result?
If I can't answer those four questions, the task isn't ready for an agent. Usually it isn't ready for a person either.
Verification starts before implementation
In my workflow with OpenAI Codex, verification starts before implementation, with domain clarification and architectural boundaries, and continues through TDD, code review and regression checks.
- 01
Clarify the domain
Rules, terms and open policy questions answered.
- 02
Set boundaries
What the change may touch, and what it may not.
- 03
TDD
Acceptance and failure cases first, where TDD fits.
- 04
Review
Does the code enforce the rule we meant?
- 05
Regression
Existing behavior still holds.
A failed check goes back to the step that owns it: sometimes the code, sometimes the requirement.
Passing tests are evidence, not proof
Passing tests provide evidence. They do not, by themselves, prove that we understood the requirement.
The opportunity is not simply to produce more code. It is to shorten the path from a well-understood business problem to a verified implementation, without outsourcing engineering judgment.
What is one requirement you now make explicit before delegating work to a coding agent? Join the discussion on LinkedIn, or see how I approach agent-based systems.
Quick answers
Can an AI coding agent decide business rules?
It will often fill gaps with plausible defaults, but those are guesses. Rules such as expiry behavior, offline use or renewal timing are business policies. Someone accountable for the domain has to decide them and make them explicit.
What should a specification for a coding agent include?
Expected behavior, constraints, system boundaries and acceptance criteria, including failure scenarios. A task description says what to work on; a specification says what a correct result must do.
Why does DDD's Ubiquitous Language matter for AI-assisted development?
Terms like active subscription, valid license and authorized runtime can mean different things in different bounded contexts. Making those distinctions explicit helps people and agents implement the same rule.
Is passing tests enough to accept code written by an agent?
Passing tests are evidence, not proof. If the tests were written from the same misunderstanding as the code, both will agree and still be wrong. Domain clarification, review and regression checks close that gap.