A Toolkit, Not a Framework: How to Adopt Intent-Based Development Gradually

Most teams can’t afford month-long rewrites, so intent tools have to fit into existing repos line-by-line.

That’s why we built intent-based development to work as a toolkit -- not a framework.

Frameworks demand you replace your architecture. Toolkits offer sharp, narrow tools you can apply where they make sense. Intent-based programming (IBP) belongs in the second camp. It works best when introduced gradually, in the places where it provides immediate value.

To reduce terminology friction, here’s a quick glossary:

• An intent file is a structured YAML file describing what a component or feature should do (e.g., Button.intent.yaml).
• A builder interprets that intent and produces working code (e.g., React component, SQL query).
• “Liberating” a file means decoupling it from generation so you can modify it freely.

Let’s walk through how the toolkit model works, where it fits in the AI-assisted dev landscape, and how it avoids the pitfalls of monolithic codegen frameworks.

The Problem with All-or-Nothing Paradigms

We’ve seen this before. Frameworks like Rails or Angular promised acceleration -- if you agreed to their way of thinking. But for teams maintaining legacy systems or working in constrained environments, those rewrites never materialized. The same thing happens when an AI codegen tool shows up and says: “Just give me a spec, and I’ll write your whole app.”

For most teams, that’s not a path. It’s a wall.

Intent-based tooling works better when it doesn’t require starting over.

The Spectrum of AI Coding Approaches

Here’s how different AI coding strategies compare in practice:

Approach	Example	Strengths	Limitations
Agentic Coding	Copilot Chat, Claude	Fast prototyping from natural language	Inconsistent outputs, lacks traceability
Codegen-as-a-Framework	Locofy, Codeium, or internal codegen tools at large orgs	Full-system scaffolding from spec	Hard to adopt incrementally; lock-in
Hybrid Intent Toolkit	Declary	Works alongside existing codebases	Requires managing codegen boundaries

Declary targets the last category. It provides structured intent files that you can place next to components, routes, or services in any repo -- and start benefiting immediately.

What the Toolkit Approach Looks Like

Let’s say you want to standardize how buttons behave across your app. Instead of creating another bespoke component, you write an intent file like this:

↓ ButtonGroup.intent.yaml

builder: react-functional-component
instructions: |
  A group of buttons with equal spacing on desktop.
  On mobile, buttons should stack vertically.
  The props are just standard react children
concerns:
  - prefer-types

Run declary generate and you get:

↓ ButtonGroup.tsx (generated)

export function ButtonGroup({ children }) {
  return (
    <div className="flex flex-col md:flex-row gap-2">
      {children?.map((btn, i) => <Button key={i} {...btn} />)}
    </div>
  );
}

Need to adjust layout? Change the intent file and regenerate. If you later need to customize deeply, you can “liberate” the file -- removing it from future codegen.

No boilerplate. No full-stack rebuild. Just one component, optimized.

Why This Model Works

The toolkit model unlocks several benefits:

• Incremental adoption: You can start with one intent file in one feature.
• No vendor lock-in: Files are local, versioned, editable. Code is yours.
• Easy rollback: You can diff generated changes, review them, and discard them.
• Team compatibility: Works with your existing stack, folder structure, CI/CD flow.
• Low risk experimentation: Try a new builder on one endpoint without affecting others.

In short: you don’t need permission to start. You just need one place where a clean declaration would help.

Where to Start: Intent-Friendly Targets

Based on usage patterns, here are places where IBP toolkits provide fast ROI:

• Reusable UI components: buttons, cards, loaders
• Standard REST endpoints: e.g., create/delete/update resources
• Structured forms with validation
• Reporting queries or dashboard visualizations
• Test scaffolding (to help combat test theater)

Most of these are high-duplication, medium-complexity features where existing implementation is boilerplate-heavy.

How Declary Supports Hybrid Workflows

Declary treats generation as just one tool in your dev process. It’s designed to coexist with hand-written code.

• Intent files live in the same repo, next to source code.
• Generated files can be diffed, reviewed, and optionally edited.
• Developers can override parts via extension points or props passthrough.
• You can mark a file as “liberated” if you need to take full control.
• Local builders allow you to encode your own conventions and scaffolds.

And because intent is declarative, it stays readable -- by developers, code reviewers, and AI agents alike.

Conclusion: Toolkits Win Because They Fit

The biggest barrier to adopting better developer workflows is the false belief that change must be massive to be meaningful.

But most of the things that transformed how we write software -- TypeScript, Git, CI, TDD -- started as small tools. They crept in file by file, test by test, check-in by check-in.

Intent-based programming doesn’t have to be a system rewrite. It can start with one file, one builder, one feature. Add it where it helps. Ignore it where it doesn’t.

Toolkits don’t ask for faith. They offer leverage.