BH3D Logo
Glossary of Intent-Based Development

A Unified Vocabulary for Intent-Based Development

By Ben Houston, 2025-05-02

Intent-based development represents a shift in how we build software: rather than focusing on code as the source of truth, developers define structured intent — describing what they want the system to do.

To support consistent understanding and collaboration, this guide introduces a standardized vocabulary for the core components of intent-based development.

Core Concepts

Intent-Based Development

A programming model where software is generated from structured declarations of desired outcomes. Developers express what they want through intent files, and implementation is treated as an output rather than a source of truth.

Intent File

A structured YAML file that describes a single software feature, component, or behavior.

Content may include:

  • Natural language requirements (e.g., “a login form with email and password”)
  • Structured props, types, or routes
  • Builder reference indicating how to interpret the file

Format: .intent.yaml Example filename: LoginForm.intent.yaml

Intent files are version-controlled and serve as the primary design artifact in an intent-based system.

Builder

A module that transforms an intent file into one or more artifacts. Builders:

  • Define the expected schema of the intent file
  • Encapsulate domain expertise and implementation conventions
  • Produce output files (e.g., components, tests, endpoints)

Builders may also output new intent files — enabling recursive, compositional generation. This nesting supports the structured creation of large systems through a tree of progressively lower-level intents.

Examples:

  • react/component
  • sql/report-query
  • nextjs/page

Artifact

The result of applying a builder to an intent file. Artifacts may include:

  • Code (e.g., .tsx, .sql, .ts)
  • Tests
  • Configuration files
  • Documentation

Artifacts are derivable and often ephemeral. They can be regenerated at any time and are typically reviewed before being committed. They are not considered authoritative sources of system design — the intent is.

Concern

A modular file defining reusable logic or behavior that applies across multiple intent files. Concerns are used to express cross-cutting functionality such as:

  • Authentication
  • Theming
  • Analytics
  • Accessibility

Format: .concern.yaml

Intent files reference concerns to inherit behavior declaratively without duplicating implementation logic.

Agent

An interface that assists the developer in interacting with the system. Agents can:

  • Help author or refine intent files
  • Select builders
  • Orchestrate multi-step workflows
  • Execute generation commands

Agents may be implemented as:

  • CLI tools
  • IDE plugins
  • Conversational UIs

Agents are facilitators — they do not generate code themselves but coordinate the use of builders based on developer input.

Project

A cohesive collection of intent files, concerns, and generated artifacts organized around a shared software purpose.

Projects may:

  • Contain both generated and hand-written code
  • Use different builders for different subsystems
  • Employ recursive generation patterns for hierarchical structure
  • Define organization-specific conventions through builder composition

Diffing and Regeneration

Because artifacts are not the source of truth, the system enables:

  • Diffing: Previewing generated changes before applying them
  • Regeneration: Reapplying builders after edits to intent files
  • Override policies: Manually edited files can be protected, merged, or liberated from further generation

These mechanics ensure developer control and traceability without undermining the declarative model.

Conclusion

Intent-based development allows developers to move up the abstraction ladder — focusing on what they want rather than how to implement it. But to scale, this approach requires precise and consistent terminology.

This vocabulary provides the foundation for communicating about, building with, and extending Declary. As the toolkit evolves, these core concepts will remain central to how intent and implementation interact in future software systems.