Recursive Intent

Recursive generation in intent-based programming enables a toolkit to become self-amplifying -- capable of ingesting its own outputs to build deeper layers of application intent, structure, and behavior from minimal user input.

Intent as Compiler, Not IDE

Intent-based programming shifts our role from coders to specifiers. Instead of composing code line by line, we articulate what we want, and the system figures out how. But this realization leads to a deeper insight: an intent-based toolkit is less like an IDE and more like a compiler for structured thought.

What happens when we feed its output back into itself? The answer is recursive intent: a process where a small seed of intent expands outward into a fully realized application through successive, self-guided generations. It turns the toolkit into a recursive compiler -- capable of building an app from a prompt.

"What if your toolkit could take a single-page spec and recursively expand it into an entire application, database schema, API layer, and UI -- without ever asking you to manually fill in the blanks?"

Recursive Generation Defined

In traditional compilers, code is transformed across multiple passes -- syntax parsing, semantic analysis, optimization, and code generation. Recursive intent-based programming follows a similar pattern, but it does so across layers of abstraction:

1. Parse high-level intent
2. Infer mid-level specs (entities, flows, UI components)
3. Emit sub-intent files (e.g. Lead.intent.yml)
4. Re-ingest and generate corresponding implementations
5. Repeat as needed until the app is fully formed

Each stage produces more structure and detail than the last -- all driven by inference, not imperative logic.

One Prompt to Full App

Imagine a user creates a file called app.intent.yml with a single description:

application:
  name: CRM
  description: A simple CRM for tracking leads and deals.

The toolkit might infer:

• Entities: Lead, Contact, Opportunity
• Pages: LeadList, LeadDetail, OpportunityPipeline
• APIs: POST /leads, GET /contacts, etc.

It generates sub-intents for each, such as Lead.intent.yml, and uses those to generate implementation code: data models, forms, routes, pages, and tests. With another pass, it can build a dashboard, notifications, or admin tools based on existing output.

From one prompt, you get a working scaffold of the entire system.

Benefits of Recursive Intent

Massive Leverage from Minimal Input

You declare intent once; the system amplifies it across dozens of files.

Emergent Architecture

Instead of front-loading all decisions, architecture emerges naturally from successive inference steps.

Inference Visibility

Each pass produces new intent files, making the system's reasoning explicit, editable, and reviewable.

Incremental Refinement

Developers can lock in parts of the intent, freeze generated files, or manually adjust before triggering the next recursive expansion.

Challenges

Inference Drift

Just like in recursive image generation, small errors can amplify. Without stability mechanisms, later outputs might contradict or overwrite earlier ones.

Overgeneration

The system might eagerly create too many files, features, or subcomponents. There must be depth limits and scoping options (--depth=2, --only=api).

Spec Explosion

Recursive generation can overwhelm with YAML. A healthy UX includes ways to collapse, summarize, and annotate specs.

Recursive Intent as Compiler Pipeline

We can model recursive generation as a compiler pipeline:

1. Lex/Parse: High-level natural language is interpreted
2. Infer: The system deduces structure, entities, flows
3. Emit: New intent files are written
4. Re-ingest: These become input to the next pass
5. Optimize: Deduplicate, refactor, collapse repeated patterns

Each cycle brings more clarity. Over time, the application takes form like a sculpture being revealed through recursive chiseling.

Mitigating Drift: Persistent Inference Caching

Recursive generation benefits enormously from a concept introduced earlier: inference caching.

Every time the toolkit makes a choice (e.g. "use JWT for auth"), it should log that decision. These logs can be frozen, reviewed, and edited. As the recursive process continues, the system consults the cache to ensure consistency.

This also enables user override: you can lock in one inference while allowing others to evolve. Drift becomes optional, not inevitable.

Tooling Implications

A recursive intent-based toolkit needs the following capabilities:

• declary bootstrap app.intent.yml → recursively generate hierarchy
• declary inspect → visualize intent tree
• declary freeze Lead.intent.yml → prevent regen
• declary refine Opportunity.intent.yml → rerun generation based on edits
• declary diff → preview output changes before applying

This isn't just code generation. It's intent propagation, refinement, and stabilization.

Cultivating Software, Not Writing It

Recursive intent reframes software development as cultivation:

"In recursive intent programming, the developer doesn't write code -- they cultivate it."

You plant a seed of intent. The system expands it into a tree of interrelated components. You prune, shape, and refine. The result is emergent software, aligned with purpose from root to leaf.

Conclusion: Toward Generative Systems

Recursive generation is the next evolution of intent-based programming. It allows systems to build themselves from a seed of purpose, growing complexity in structured layers.

With persistent inference, modular specs, and recursive propagation, we can build apps from a single sentence -- not in a magical way, but through disciplined generative design.

The future of development is recursive. One prompt at a time.