The Economics of Intent-Driven Engineering: Who Does What, Where, and Why It Works
- Mark Kendall
- 21 hours ago
- 4 min read
The Economics of Intent-Driven Engineering: Who Does What, Where, and Why It Works
Intro
Most AI conversations today focus on one thing: developers writing code faster.
That’s not the transformation.
The real shift—the one that organizations are struggling to understand—is this:
Intent-Driven Engineering changes how the entire organization participates in software delivery.
It doesn’t replace roles.
It redefines how each role contributes, using the right tool at the right level.
This article explains the full model:
Who does what
Where they work
What they produce
What outcomes improve
And how to operate this in a real enterprise
What Is Intent-Driven Engineering?
Intent-Driven Engineering is a model where:
Business intent → Structured intent → Executable systems
Instead of:
Developers guessing requirements
Endless back-and-forth clarification
Inconsistent implementations
You get:
Clear intent
Structured translation
Deterministic execution
The Big Idea Behind the Chart
The chart you saw is not just a diagram.
It’s an operating model:
Every role has a lane.
Every lane has a tool.
Every tool produces a specific output.
And most importantly:
Intent is the contract that connects them all.
🔷 The Roles, Tools, and Responsibilities
1. Delivery Lead — The Outcome Owner
Where they work
Browser (Claude / Chat UI)
Jira / planning tools
What they do
Define:
Business goals
Desired outcomes
Constraints
Success criteria
What they produce
High-level intent
Clear direction for the team
Expected outcomes
Alignment across stakeholders
Prioritized, meaningful work
Clear definition of “done”
Best practices
Focus on what, not how
Be explicit about constraints
Avoid technical implementation details
Use Claude to refine clarity, not generate code
2. Scrum Master — The Flow Orchestrator
Where they work
Jira / Agile boards
Browser (optional Claude support)
What they do
Break intent into:
Stories
Tasks
Manage:
Flow
Dependencies
Blockers
What they produce
Structured, executable work items
Expected outcomes
Predictable delivery
Clear task boundaries
Smooth team flow
Best practices
Keep stories small and testable
Ensure each story maps to intent
Avoid over-specifying technical solutions
Use Claude to clarify ambiguity—not to design systems
3. TPM / Architect — The Intent Translator (Critical Role)
Where they work
Browser (Claude)
Optional CLI (advanced users)
Architecture/design tools
What they do
Convert business intent → technical intent
Define:
Architecture patterns
Constraints & guardrails
Integration points
Data contracts
What they produce
✅ Intent File (THE CONTRACT)
Expected outcomes
Consistent system design
Reduced ambiguity for developers
Reusable architecture patterns
Best practices
Treat the intent file as code (version it, refine it)
Be explicit:
Inputs
Outputs
Constraints
Standardize patterns (your TMF, adapters, etc.)
Use Claude to interrogate the design (AI asking questions = best results)
4. Developer — The Intent Executor
Where they work
CLI (primary for power)
IDE (IntelliJ / VS Code)
What they do
Take the intent file and:
Generate code
Generate tests
Implement features
Refine and validate locally
What they produce
Working code
Feature branches
Pull requests
Expected outcomes
Faster delivery
Higher consistency
Reduced manual effort
Best practices
Let AI generate—but always review
Stay in feature branches
Follow standard Git flow (commit → push → PR)
Use CLI for:
Repo-wide changes
Scaffolding
Use IDE for:
Debugging
Precision edits
5. QA / Quality Engineer — The Quality Guardian
Where they work
Browser (Claude)
Test management tools
CI/CD dashboards
What they do
Validate:
Test coverage
Edge cases
Functional correctness
Perform exploratory testing
What they produce
Validated releases
Quality reports
Expected outcomes
Fewer defects
Higher confidence releases
Better user experience
Best practices
Use AI to:
Generate test scenarios
Identify edge cases
Focus on what could go wrong
Align testing directly to intent
6. DevOps / SRE — The Release Enabler
Where they work
CLI
CI/CD platforms
Observability tools
What they do
Manage:
Pipelines
Deployments
Monitoring
Ensure:
Reliability
Scalability
What they produce
Automated pipelines
Stable environments
Observability
Expected outcomes
Faster releases
Lower downtime
Reliable systems
Best practices
Automate everything possible
Integrate quality gates early
Ensure visibility (logs, metrics, tracing)
Align pipelines with intent outputs
🔁 End-to-End Flow (How It All Connects)
Delivery Lead
→ Defines what needs to happen
Scrum Master
→ Structures the work
Architect / TPM
→ Creates the intent file (contract)
Developer
→ Executes using CLI + IDE
QA + DevOps
→ Validate, deploy, and monitor
💰 The Economics (Why This Works)
This model doesn’t remove roles.
It does something more powerful:
It increases the return on every role.
What improves:
Throughput
More features with same team
Time-to-market
Faster delivery cycles
Quality
Fewer defects, less rework
Cost efficiency
Lower cost per feature
Optionality
More innovation capacity
⚠️ Common Misconception
“Everyone needs to learn coding tools.”
Wrong.
Delivery Leads → do NOT need CLI
Scrum Masters → do NOT need Python
Architects → may optionally use CLI
Developers → DO need CLI/IDE
👉 The power comes from role alignment, not tool overload
🔥 Final Takeaway
If you’re going all-in on Claude Code (or any AI-driven development model), this is the structure:
Intent is the contract
Roles are the engine
Systems enforce the outcome
And the one line to remember:
We’re not making developers faster.
We’re making the entire organization aligned.
Comments