From Intent-Based Engineering to Intent-Driven Engineering: What Changed in One Year
- Mark Kendall
- 3 days ago
- 3 min read
From Intent-Based Engineering to Intent-Driven Engineering: What Changed in One Year
Intro
In early 2025, a new idea started gaining traction: Intent-Based Engineering (IBE).
The promise was compelling—developers could define what they wanted, and platforms would handle the rest. Less configuration. Less infrastructure overhead. More focus on building features.
At the time, it felt like a breakthrough.
But over the past year, something important happened.
Teams tried it.
And in doing so, they discovered a critical gap.
What emerged from that gap is something more complete, more practical, and far more powerful:
👉 Intent-Driven Engineering
What Is Intent-Based Engineering (IBE)?
Intent-Based Engineering (IBE) is an approach where developers specify desired outcomes—such as deploying a microservice with a database—without needing to manage the underlying infrastructure.
Instead of writing infrastructure code or configuring environments manually, developers interact with a platform (often via UI or CLI) that provisions everything automatically.
Typical flow:
Developer defines service requirements
Platform provisions infrastructure
CI/CD pipelines are generated
Monitoring and security defaults are applied
The goal is simple:
👉 Reduce friction and keep developers focused on building features
And to be clear—this was (and still is) a meaningful step forward.
Where IBE Fell Short
Once teams began implementing IBE in real enterprise environments, several challenges became clear.
1. It Solved Setup… But Not Execution
IBE made it easier to create services.
But what happens after deployment?
How do systems evolve?
How are failures handled?
How is behavior governed across environments?
👉 IBE focused on creation, not lifecycle
2. It Relied Too Heavily on UI Abstractions
Many implementations leaned on:
Guided portals
Wizards
“Click to create service” flows
This works for simple use cases.
But at scale?
👉 UI-driven systems don’t hold up in automated, multi-environment enterprise pipelines
3. It Lacked a Clear Operating Model
IBE didn’t fully answer:
Who owns the “intent”?
How is it versioned?
How do teams collaborate across domains?
How is governance enforced?
Without these answers, platforms became inconsistent across teams.
4. It Didn’t Bridge to Production Reality
The biggest issue:
👉 What works in a sandbox doesn’t automatically work in production
Teams could generate services quickly—but struggled with:
Observability integration
Security enforcement
Runtime consistency
Multi-system orchestration
The Shift: Intent-Driven Engineering
Intent-Driven Engineering builds on the idea of intent—but takes it much further.
It’s not just about defining outcomes.
It’s about making those outcomes:
👉 Executable, governed, and production-ready
What Is Intent-Driven Engineering?
Intent-Driven Engineering is a structured approach where intent is defined as a versioned, executable contract that drives the full system lifecycle:
Architecture
Code generation
Deployment
Runtime behavior
Observability
Evolution over time
Instead of stopping at provisioning, the system continues to operate on that intent across environments.
The New Model: From Idea to Production
Intent-Driven Engineering introduces a complete flow:
1. Intent Definition
Teams define intent in a structured format (e.g., YAML, JSON, or API-driven).
Example:
Service type
Dependencies
Performance requirements
Compliance constraints
2. Intent Compilation
The intent is interpreted and validated.
Missing dependencies identified
Security policies applied
Architecture decisions enforced
3. System Generation
The platform generates:
Infrastructure
Application scaffolding
CI/CD pipelines
Observability integrations
4. Deployment to Runtime
The system is deployed into real environments:
Kubernetes
Cloud platforms (AWS, etc.)
Enterprise integrations
5. Continuous Evolution
This is where Intent-Driven Engineering separates itself.
The system doesn’t stop after deployment.
Changes to intent trigger updates
Monitoring feeds back into decisions
Scaling and resilience are adjusted automatically
👉 The system evolves with the intent
Why This Matters
The shift from IBE to Intent-Driven Engineering is not incremental.
It’s foundational.
Faster Time to Market
Teams move from idea to production systems in days—not months.
Reduced Operational Overhead
Infrastructure, pipelines, and integrations are handled systematically.
Consistency at Scale
Every system follows the same governed patterns.
Real Production Readiness
Not just “it runs”—but:
Observable
Secure
Scalable
Integrated
True Engineering Leverage
Small teams can deliver what previously required large organizations.
The Real Insight
Intent-Based Engineering was never wrong.
It was just incomplete.
It introduced the idea that developers shouldn’t have to think about infrastructure.
But it didn’t go far enough.
👉 It didn’t turn intent into a system
Key Takeaways
IBE focused on simplifying setup
It struggled with lifecycle, governance, and production realities
Intent-Driven Engineering extends intent into full system execution
The result is faster delivery, stronger consistency, and real scalability
Final Thought
The industry is still catching up.
Many teams are still experimenting with abstraction layers, internal developer platforms, and prompt-driven workflows.
But the next step is already clear:
👉 Time to move beyond prompts.
👉 Time to move beyond provisioning.
👉 Time to move toward Intent-Driven Engineering.
Learn More
If you want to go deeper into how this works in real enterprise environments—including architecture, execution models, and production patterns:
👉 Read the full breakdown here:
👉 Get the full guide:
Comments