The Methodology

How IFD Works

Intent-First Development inverts the traditional sequence. Design sessions come first, producing structured artifacts that AI tools can consume. Code is the final step — not the starting point.

Step I

Collaborative Design Sessions

Every significant piece of work begins with a design conversation. A developer or architect works with an AI partner to explore the problem space, surface options, and make deliberate choices — typically 30 to 90 minutes, producing structured artifacts rather than meeting notes.

The session operates at defined altitudes — from high-level vision through architecture to component design. A gate check between altitudes asks concrete questions: at 30,000 ft, is the capability map complete? At 10,000 ft, are component boundaries and integration points agreed? Teams do not descend until the answer is yes — which prevents premature implementation and surfaces misalignment before it compounds.

50,000 ftVision
gate check
30,000 ftCapabilities
gate check
10,000 ftArchitecture
gate check
5,000 ftComponents
gate check
1,000 ftImplementation

Step II

Documentation Artifacts

The design session produces concrete artifacts: explanations that capture architectural reasoning, Design Decision Documents that record each significant choice with options considered and the driver behind the decision, and reference materials defining the specifications implementation must conform to.

Structured with the Diataxis framework, these artifacts give AI tools clean, predictable input — not ad-hoc notes. Diataxis is more than folders named docs/: it treats each content type as a distinct cognitive mode with its own structure, and the framework prevents the common drift where reference becomes tutorial, or explanation becomes how-to.

DecisionsChoices made, with the options considered and the driver recorded

AssumptionsBeliefs taken as true, tracked so we know when they break

QuestionsWhat we don't know yet, surfaced so it cannot hide

RisksThreats to intent — architectural drift, constraint violations, scope pressure

Cross-cutting @ any altitude

Step III

Executable Intent

Documented decisions become active constraints that shape every AI output. The methodology distills prose — naming conventions, architectural rules, cross-cutting concerns — into forms AI assistants load at generation time, not read by humans later.

What changes is not the mechanism; it is the default. Conventions that previously lived in tribal memory — enforced only when a reviewer happened to catch a violation — become enforced at the moment code is written. Architectural boundaries become unbreakable. Decisions recorded in DDDs become inspectable against the generated code. Intent stops decaying with each passing quarter.

From prose“API paths use kebab-case, resource-first.”

To constraintEvery generated endpoint conforms — drift is caught at the moment of creation.

From prose“Services emit OpenTelemetry traces with the standard attribute set.”

To constraintGenerated scaffolding includes trace setup with the right attributes, every time.

From prose“Public API handlers validate input against the shared schema before any business logic.”

To constraintGenerated handlers have validation as the first statement. Unvalidated paths do not exist to begin with.

Step IV

Partnered Implementation

Implementation is not a handoff. It is a working partnership between three parties: the practitioner who directs and reviews, the AI that generates at speed, and the intent corpus both operate from. Each contributes what the others cannot.

The corpus is not a folder of files — it is the DDDs on the current design path, the Skills active for this task, and the CLAUDE.md index that orients the AI to the rest. The practitioner brings judgment the corpus cannot encode: when a constraint should flex, when a new pattern is warranted, when generated code fits the rules but misses the point. The resulting code respects architectural boundaries, follows project conventions, and aligns with documented decisions — because all three partners are contributing.

Intent CorpusDecisions made and assumptions declared — the architectural context the work depends on.

PractitionerJudgment, review, and direction — the human who steers and catches what doesn't fit.

AI AssistantGeneration at speed, operating with the corpus and the practitioner's direction in context.

Together, they produceCode that fits

The Inversion

Understanding → Documentation → Code. Documentation is not a tax on development — it is the medium through which design happens.

Traditional development produces code first and documentation maybe. Intent-First Development reverses that order deliberately. The upfront investment in captured intent compounds: every subsequent modification, extension, and onboarding event benefits from the reasoning that was recorded at the start. The inversion costs time once; it saves time every time after that.

Ready to introduce IFD to your team?

Talk to XTIVIA →

Explore key concepts →

Without IFD

Code First, Questions Later

AI generates code from a one-line prompt
Result uses generic patterns, not team conventions
Architectural misalignments compound silently
Next developer has no context for the choices made
Refactoring reveals decisions no one can explain

With IFD

Intent Before Implementation

Design session surfaces options and records the decision
Documentation explains why, not just what
Skills encode conventions the AI applies at generation time
Generated code traces back to documented intent
Future modifications have a clear target, not a mystery