The Vocabulary
Key Concepts of Intent-First Development
Intent-First Development introduces specific concepts that may be new to teams accustomed to traditional or AI-assisted workflows. Each addresses a failure mode in how AI tools are currently used.
Design Decision Documents
A DDD records a significant architectural choice with its scenario, options evaluated, recommendation, and final decision. The separation between recommendation and decision preserves the analytical process — including cases where a business constraint overrode the technically preferred option.
When a future team member asks why you chose X, the DDD answers not only "because of these trade-offs" but also "we actually recommended Y, but chose X because of Z."
Skills
Skills encode conventions, constraints, and patterns in a structured form that AI tools consume directly. They are not documentation summaries — they are actionable constraints: "Use this component structure," "Follow this naming convention," "Apply this error-handling pattern."
Practice-level Skills travel with the methodology. Project-level Skills are developed as part of the project's own design work.
CLAUDE.md
Every IFD project includes a CLAUDE.md at the repository root — the AI entry point. It is not documentation; it is an index. It points AI tools to the documentation they need, in the order they need it. Without it, AI tools navigate by heuristics. With it, they navigate by intent.
CLAUDE.md contains what the project is, where to find key documentation, active Skills, and constraints that apply across the codebase.
Deterministic vs. Non-Deterministic Work
IFD explicitly categorizes work by predictability. Deterministic work follows known patterns and can be delegated to AI with confidence — CRUD from a data model, tests from component interfaces, scaffolding from templates. Non-deterministic work requires human judgment: architectural choices, API boundary design, build-vs-buy decisions.
This categorization directly informs how teams delegate. AI assists non-deterministic work; it should not decide it.
Intent Fidelity
Intent fidelity measures whether a codebase's implementation reflects its documented design intent. High fidelity means the code does what the documentation says it should. Low fidelity means the codebase has drifted — through undocumented changes, expedient shortcuts, or AI-generated code that ignored architectural context.
Intent fidelity gives engineering leaders a concept for what they have always sensed intuitively: some codebases feel coherent, others feel accidental.
Altitude
Altitude is the IFD metaphor for design abstraction level. From 50,000 ft (vision and problem definition) through capability mapping, architecture, and component design, down to 1,000 ft (implementation). Each level has a gate check — conditions that must be satisfied before descending.
Ascending — returning to a higher altitude when implementation reveals a design gap — is expected and healthy. It is not failure; it is the process working.
A System, Not a Checklist
These concepts are not independent tools. They form a system — each one closing a failure mode that the others leave open.
DDDs capture decisions before they become mysteries. Skills make those decisions machine-actionable. CLAUDE.md gives AI tools the map they need to navigate with intent. Altitude keeps design sessions from collapsing into implementation before the architecture is understood. Intent fidelity gives you a way to measure whether it worked. Use one without the others and you have a useful practice. Use all of them and you have a methodology.
Bring the full methodology to your team.
Talk to XTIVIA →