Building with AI

Coding agents reduce the cost of turning instructions into software. That advantage shifts the bottleneck. The problem is no longer only whether a capability can be built, but whether it deserves to exist, whether it solves the right problem and whether it preserves the user's understanding.

AI must absorb complexity, not produce it.

An agent can implement a weak specification at great speed, reproduce conventional patterns that do not fit the context and add plausible options that nobody asked for. This is why AI-assisted development needs an explicit layer of intent, limits and verification.

Six directives for teams and agents

Directive	Requirement	Limit
D01 Foundation before implementation	Understand the product definition, its authority, its scope and the evidence behind it before proposing components or code. Where Job Stories exist, preserve their circumstance, motivation and outcome.	Do not start building if a material ambiguity may alter the solution, the scope or a rule.
D02 Sufficient specification before generation	Define states, decisions, constraints and acceptance criteria at the level the risk requires.	Do not turn a vague prompt into an extensive implementation and then use the code to discover the problem.
D03 Deliberate simplicity	Prefer the solution that demands fewer concepts, decisions and memory from the user where both achieve the same result.	Less code is not the measure; less unnecessary burden is.
D04 Determinism where it matters	Implement critical rules, permissions, calculations, states and validations as verifiable logic.	Do not delegate certainty, compliance or security to a model's variable behavior.
D05 Verification before acceptance	Evaluate the flow, the edge states, accessibility, performance and the real outcome.	Generated code and passing unit tests do not amount to a finished product.
D06 AI subordinate to the user	Use AI to propose, explain and execute within clear limits, keeping review and reversibility proportionate to the impact.	The fluency of a response never substitutes for evidence or authorization.

The second governing question

Now that we can build almost anything more easily, what deserves to be built and what should we deliberately leave out?

This question introduces an obligation that could previously remain hidden by technical cost. It must be raised during the product definition and when evaluating alternatives, not used during implementation to unilaterally trim an approved scope. Every capability must justify its existence against a simpler alternative, including the alternative of not building it; once authorized, any exclusion requires a traceable product decision.

Determinism and generation

The choice is not between a deterministic product and a product with AI. A dependable system combines both according to the nature of each decision.

Type of behavior	Preferred treatment	Examples
Must always produce the same result under the same conditions	Deterministic rule and automated test	Permissions, prices, limits, calculations, state transitions
Can yield several useful answers and requires interpretation	AI with context, limits and evaluation	Explaining, summarizing, proposing alternatives, classifying text
May affect money, reputation, security or rights	AI proposes; a rule or a person authorizes	Publishing, purchasing, deleting, sending, changing access
Uncertainty is part of the output	AI declares assumptions and confidence level	Recommendations, estimates, incomplete information

The flow prevents code generation from becoming the first act of design. It does not seek to create a documentation-heavy phase or to impose a structure on the PRD. It aims to understand the foundation received, produce the clarity needed to plan and maintain coverage through to acceptance.

Step	Decision	Work	Minimum evidence
F01	Understand the foundation	Recognize the sources, the authority, the scope, the structure used and the expected results.	A faithful map of the product definition, without reformulating it for technical convenience.
F02	Establish coverage	Inventory the applicable stories, capabilities, rules, states, journeys, criteria and relationships.	Complete coverage, with gaps or contradictions made visible.
F03	Plan the implementation	Resolve dependencies, blockers, order, parallelism, integration and testing without modifying the scope.	A coherent plan that accounts for the whole approved definition.
F04	Make progress concrete	Use the existing Job Stories, or formulate a derived view where it adds clarity and is identified as such.	Circumstances, motivations and outcomes preserved where applicable.
F05	Establish the experience contract	Describe what the person must understand, decide and feel at the critical moments.	Main route, states and interaction promise.
F06	Model rules and risks	Separate deterministic logic, generative behavior, permissions and irreversible actions.	A map of decisions and limits.
F07	Explore and prototype	Compare alternatives and test understanding, hierarchy and recovery before optimizing code.	The reason for the chosen alternative and evidence from the journey.
F08	Build, integrate and verify	Implement the plan, maintain traceability and reconcile results against the full scope.	Code, tests and evidence of coverage; outstanding items and exceptions made explicit.

Each artifact exists to answer a question, not to satisfy a template. It may be a section of the PRD, a derived view, a table, a test or a separate document. If the information already exists, it must be referenced and not duplicated. Depth depends on length, complexity, uncertainty and risk; if an artifact neither changes a decision nor helps verify one, it must be simplified or removed.

Artifact	Question	Minimum content
A01 Map of the foundation	What must be built, why and with what authority?	Sources; scope; results; rules; limits; evidence; non-goals
A02 Coverage map	How will the full scope be accounted for?	Mandatory elements; relationships; dependencies; implementation; tests; status; exceptions
A03 Job Story sheet where applicable	When does the need arise and what change is the person after?	Circumstance; motivation; outcome; current behavior; anxiety; evidence; assumptions
A04 Experience contract	What must the person understand and be able to do?	Main route; language; decisions; feedback; control; recovery
A05 State model	What can happen and which transitions are valid?	States; events; rules; errors; permissions; persistence
A06 Complexity budget	What burden are we adding?	New concepts; decisions; steps; exceptions; visible options
A07 Acceptance plan	What evidence authorizes declaring the development complete?	Results; rules; Job Stories where they apply; accessibility; performance; edge states; metrics
A08 Decision record	Why did we choose this alternative?	Alternatives; trade-offs; assumptions; decision; date; outstanding evidence

The agent should not begin an implementation if it cannot answer the following questions precisely, at the level required by the risk and the complexity:

• What is the authorized product definition and what scope does it establish?

• Which elements of the foundation justify the development and what evidence supports them?

• Does the plan account for all mandatory stories, capabilities, rules, states and criteria?

• Where Job Stories exist, are the circumstance, the motivation and the outcome separated from the solution?

• What is the main route and which alternative states matter?

• Which decisions must the user make and which can the system resolve?

• Which behavior requires deterministic certainty?

• What falls outside the scope and who established that exclusion?

• What evidence will demonstrate that the development is complete?

If an answer is missing that could materially change the solution, the scope, a rule or a right, the agent must stop and ask for it. If the uncertainty is minor, reversible and within its authority, it may declare an assumption and proceed without silently reducing the coverage it has committed to.

The following contract can be incorporated into a repository's instructions, into a PRD or into a coding agent's prompt. It must be accompanied by the product's specific context and does not replace the definition of the problem.

CR01 Purpose. Build the simplest solution that lets the user achieve the defined outcome, preserving clarity, control and the ability to recover.

CR02 Before programming. Identify the authorized sources, explain the product foundation and confirm the full scope. Recognize the structure the definition uses; where it contains Job Stories, preserve their circumstance, motivation and outcome. Separate evidence from assumptions and identify any ambiguity that could materially change the solution.

CR03 When planning. Account for every mandatory element and establish their dependencies, blockers, order, integration and tests. Do not select, omit or defer parts of the scope on your own initiative. If constraints prevent covering it, request a decision from the product authority.

CR04 When proposing. Present the recommended alternative, a simpler alternative and the option of not building, where the decision still belongs to product. Explain how each one responds to the foundation, what burden it introduces and what trade-offs it demands.

CR05 When designing. Do not expose internal structures. Use the user's language, known conventions, a clear hierarchy, progressive depth, editable defaults and immediate feedback.

CR06 When using AI. Reserve critical rules for verifiable logic. Declare uncertainty. Do not carry out high-impact actions without proportionate authorization. Maintain traceability, review and reversibility.

CR07 When implementing. Respect the agreed scope and preserve traceability to its foundation. Do not add features, modes, configurations or abstractions that were not requested. Cover empty, loading, error, success and recovery states, and integrate the related parts.

CR08 Before declaring the work complete. Reconcile the implementation against the complete product definition. Verify results, rules, criteria and, where they apply, the Job Stories in their circumstances. Also check accessibility, perceived performance, errors, persistence of work and user control. Deliver evidence, outstanding items and approved exceptions.

Expected delivery format from the agent

1. O01 Authorized sources and product foundation that justify the development.

2. O02 Inventory of scope and coverage of the applicable stories, capabilities, rules, states and criteria.

3. O03 Jobs to Be Done and Job Stories where they form part of the definition or contribute a useful derived view.

4. O04 Available evidence, assumptions and outcome criteria.

5. O05 Chosen alternative and the reason for discarding more complex options.

6. O06 Files or components modified and the limits of the change.

7. O07 States and edge cases covered.

8. O08 Tests run and evidence of results.

9. O09 Risks, uncertainties, outstanding items, exceptions and decisions that still require human judgment.

Short prompt for starting a task

Before writing code, identify the authorized product definition, explain its foundation and confirm the full scope. Recognize all applicable stories, capabilities, rules and criteria; where Job Stories exist, preserve their circumstance, motivation and outcome. Distinguish evidence from assumptions. Plan dependencies and coverage without omitting or deferring scope on your own initiative. Implement the simplest solution that meets what was approved, and verify results, integration, errors and recovery.