AI Development Needs an Operating Model. That Operating Model Is Intent-Driven Engineering.

AI Development Needs an Operating Model. That Operating Model Is Intent-Driven Engineering.

The first question I would ask when walking into an enterprise today is not:

Which AI model are you using?

It is not:

How many developers have access to an AI coding assistant?

And it is not:

How much faster are your teams producing code?

The first question is more fundamental:

Where is your AI operating model?

How are the teams organized?

Who owns the process?

What governs how AI is used across planning, development, testing, security, deployment, and production support?

Where are the shared services?

What happens at the repository level?

How is enterprise context delivered to the agent?

Who decides which work can be automated?

Who validates that the resulting software satisfies the original business intent?

Those questions expose the real maturity of an AI-enabled engineering organization.

Most companies are still focused on tool access. They are enabling coding assistants, purchasing model capacity, experimenting with agents, and encouraging developers to move faster.

That is a start.

It is not an operating model.

Agile Gave Us a Delivery Rhythm

Agile transformed software development because it gave organizations a more responsive way to plan and deliver work.

It challenged long, rigid development cycles.

It introduced shorter feedback loops.

It brought business stakeholders closer to engineering teams.

It encouraged incremental delivery, continuous learning, and adaptation.

But Agile was designed around human teams executing work through ceremonies, backlogs, stories, and iterative delivery.

AI changes the execution environment.

The team is no longer composed only of people.

Developers now work with coding agents, planning agents, test-generation agents, security agents, review agents, automation workflows, context servers, repository instructions, hooks, skills, plugins, and model-routing decisions.

The work no longer begins only with a user story and ends with a developer writing code.

It may begin with business intent and flow through a coordinated system of people and AI agents.

Agile still matters.

But Agile alone does not tell an enterprise how to govern that system.

The Missing Layer Is the Operating Model

An operating model defines how an organization turns strategy into repeatable execution.

It establishes:

• ownership,

• decision rights,

• team structure,

• governance,

• standards,

• shared capabilities,

• workflows,

• controls,

• measurements,

• and accountability.

AI development requires the same discipline.

Without an operating model, every team invents its own approach.

One team uses a large prompt.

Another creates a specification.

Another lets developers use coding agents however they choose.

Another builds an internal agent platform.

Another creates a collection of scripts, hooks, and repository instructions that no one outside the team understands.

The individual experiments may be valuable.

The enterprise result is fragmentation.

That fragmentation leads to predictable problems:

• inconsistent quality,

• duplicated tooling,

• uncontrolled model usage,

• unnecessary token cost,

• weak traceability,

• unclear ownership,

• security gaps,

• conflicting standards,

• and uneven delivery performance.

The answer is not another coding tool.

The answer is an operating model.

That Operating Model Is Intent-Driven Engineering

Intent-Driven Engineering begins with a simple principle:

Software development should begin with a clearly expressed intent and maintain a traceable connection to that intent throughout delivery.

Intent explains more than what the software should do.

It captures:

• why the change matters,

• who it serves,

• which business outcome it should produce,

• which constraints must be preserved,

• what evidence will prove success,

• and where human authority must remain.

That intent becomes the anchor for planning, execution, validation, and governance.

The operating flow becomes:

Intent → Context → Plan → Execute → Verify → Govern → Learn

That is larger than prompt engineering.

It is larger than specification generation.

It is larger than AI-assisted coding.

It is an organizational model for delivering software through coordinated human and machine execution.

Prompt Engineering Was an Important First Step

Prompt engineering taught the industry that the quality of instructions matters.

That lesson will remain important.

Clear instructions, examples, constraints, formatting requirements, and role definition all improve model performance.

But prompt engineering is primarily concerned with the interaction between a person and a model.

It asks:

How do I ask the model for a better response?

Intent-Driven Engineering asks a broader question:

How does the organization convert business intent into governed, verifiable software delivery?

Prompts will remain part of the system.

They will exist inside skills, agents, workflows, templates, repository instructions, and automation.

But the prompt is not the operating model.

It is one mechanism inside it.

Vibe Coding Expanded What People Believed Was Possible

Vibe coding played an important role as well.

It showed people that software could be created through natural-language interaction, rapid experimentation, and continuous feedback with an AI system.

It lowered the barrier between an idea and working software.

It allowed developers and non-developers to explore possibilities quickly.

That energy should not be dismissed.

Every major shift begins with experimentation.

But enterprise delivery cannot run on intuition alone.

A production organization needs:

• reproducibility,

• security,

• architectural consistency,

• verification,

• traceability,

• operational readiness,

• cost control,

• and accountability.

Vibe coding may help discover the solution.

Intent-Driven Engineering turns that discovery into an enterprise capability.

Specification Is Necessary, but It Is Not the Beginning

Spec-driven development represents another important step forward.

It improves on ad hoc prompting by creating a structured artifact that AI systems can execute against.

Specifications can define:

• expected behavior,

• interfaces,

• technical requirements,

• acceptance criteria,

• and implementation boundaries.

That is a major improvement.

But a specification usually describes what the system should do.

Intent explains why the system should exist, which outcome matters, and how the organization will judge whether the result was worth building.

The specification should flow from the intent.

It should not replace it.

The hierarchy is:

Business Intent

↓

Product and Architectural Decisions

↓

Executable Specification

↓

Implementation Plan

↓

Code and Infrastructure

↓

Verification Evidence

Intent remains upstream.

That is why Intent-Driven Engineering can incorporate spec-driven development without being limited by it.

The Enterprise AI Operating Model

A mature Intent-Driven Engineering operating model must exist at several levels.

1. Enterprise Ownership

Someone must own the AI engineering operating model.

This cannot remain an informal side responsibility spread across architecture, development, security, DevOps, and innovation teams.

The organization needs clear ownership for:

• AI development standards,

• approved models and platforms,

• cost governance,

• security controls,

• reusable capabilities,

• adoption patterns,

• maturity measurement,

• and delivery outcomes.

Ownership does not mean one centralized group controls every decision.

It means someone is accountable for the system as a whole.

2. Team Organization

AI-enabled teams need defined roles and responsibilities.

The organization must determine:

• who captures business intent,

• who converts intent into executable work,

• who designs agent workflows,

• who validates architecture,

• who governs model access,

• who owns shared context,

• who reviews AI-generated output,

• and who is accountable in production.

Traditional roles will evolve.

Developers will remain essential, but they will increasingly supervise, direct, validate, and integrate machine-generated work.

Architects will design not only software systems, but also systems of execution.

Product leaders will define outcomes in forms that humans and agents can use.

Platform teams will provide the common services that make AI delivery safe and repeatable.

3. Shared Services

Every team should not build its own AI development infrastructure.

A shared services capability should provide reusable enterprise components such as:

• MCP servers,

• model gateways,

• authentication,

• policy enforcement,

• approved skills,

• standard agents,

• observability,

• logging,

• evaluation frameworks,

• cost dashboards,

• secure context retrieval,

• and reusable delivery workflows.

Shared services create leverage.

They allow teams to move quickly without recreating the same infrastructure.

They also provide a place to implement enterprise policy once and distribute it consistently.

4. Repository-Level Standards

The operating model must reach the repository.

Enterprise strategy means little if each repository gives AI agents a different, incomplete, or contradictory environment.

At the repo level, the organization needs standards for:

• repository instructions,

• intent files,

• architecture guidance,

• test requirements,

• agent permissions,

• approved tools,

• branch behavior,

• hooks,

• quality checks,

• pull-request workflows,

• and handoff documentation.

The repository becomes the execution environment for the agent.

It should explain how work is performed there.

A mature repository may include:

• CLAUDE.md or equivalent guidance,

• an intent or feature file,

• reusable skills,

• dedicated agents,

• deterministic hooks,

• test and validation commands,

• architecture decision records,

• and automated pull-request checks.

This is where the operating model becomes real.

5. Context Architecture

AI systems are only as reliable as the context available to them.

Enterprises must decide which sources are authoritative.

That may include:

• Jira,

• Confluence,

• Figma,

• source code,

• service catalogs,

• API documentation,

• databases,

• policy stores,

• architecture repositories,

• production telemetry,

• and operational runbooks.

Intent-Driven Engineering does not simply give the model more information.

It gives the model the right information, from trusted sources, at the correct stage of work.

Enterprise context must be governed like any other critical system.

6. Human and Agent Decision Rights

The operating model must define what the agent can decide.

Not every decision has the same risk.

An agent may be allowed to:

• inspect code,

• generate a plan,

• write tests,

• implement a bounded change,

• create a branch,

• prepare a draft pull request,

• or recommend a fix.

It may not be allowed to:

• approve its own security exception,

• deploy to production,

• change a critical data model,

• alter enterprise policy,

• or bypass mandatory review.

The organization needs explicit decision boundaries.

Autonomy should increase as evidence, reliability, and confidence increase.

It should not be granted merely because the tool is capable of taking action.

7. Verification and Evidence

AI-generated software must be judged by evidence.

That evidence may include:

• passing tests,

• contract validation,

• code-quality checks,

• security scans,

• architecture conformance,

• user-interface verification,

• performance results,

• deployment readiness,

• and business acceptance criteria.

The agent should know how success will be tested before it begins implementation.

That closes the loop between intent and outcome.

The question is not simply:

Did the agent finish?

The question is:

Did the system produce evidence that the intent was satisfied?

8. Cost and Efficiency Governance

AI development introduces a new economic layer.

Model usage, context size, repeated execution, inefficient routing, unnecessary agent loops, and duplicated work can significantly affect cost.

The operating model must include:

• model selection,

• routing rules,

• context limits,

• budget thresholds,

• usage reporting,

• caching,

• reuse,

• and cost-per-outcome measurement.

The organization should not optimize only for fewer tokens.

It should optimize for the lowest responsible cost of achieving a verified business outcome.

Intent-Driven Engineering Uses What Came Before It

Intent-Driven Engineering does not need to reject earlier methods.

It will absorb and organize them.

From Agile, it takes:

• iteration,

• feedback,

• incremental delivery,

• and cross-functional collaboration.

From DevOps, it takes:

• automation,

• shared responsibility,

• continuous delivery,

• and operational feedback.

From prompt engineering, it takes:

• clear instruction,

• constraint definition,

• examples,

• and structured interaction.

From vibe coding, it takes:

• speed,

• experimentation,

• accessibility,

• and creative exploration.

From spec-driven development, it takes:

• structured requirements,

• executable definitions,

• and machine-readable delivery artifacts.

From platform engineering, it takes:

• shared services,

• golden paths,

• standard tooling,

• and developer enablement.

Intent-Driven Engineering places those capabilities into a larger hierarchy.

It gives them a common purpose.

Why Intent-Driven Engineering Will Win

Intent-Driven Engineering will win because it solves the problem enterprises actually have.

The enterprise problem is not a lack of AI tools.

It is a lack of coordination.

Organizations need a way to connect:

• strategy,

• business intent,

• product decisions,

• architecture,

• context,

• agents,

• developers,

• repositories,

• testing,

• governance,

• operations,

• and measurable outcomes.

Intent is the only concept broad enough to connect all of those layers.

A prompt is too small.

A specification is too narrow.

A coding assistant is too tactical.

A collection of agents is too fragmented.

Intent provides the organizing principle.

It establishes the reason for the work and creates the thread that must remain visible through every stage of delivery.

That is why Intent-Driven Engineering is not simply another development technique.

It is the operating model for AI-enabled software delivery.

The First Questions Every Company Must Answer

When I walk into an organization, I want to know:

• Where is your AI operating model?

• Who owns it?

• How are your teams organized around it?

• Where are your shared services?

• How do agents receive enterprise context?

• What standards exist at the repository level?

• How is business intent captured?

• How does intent become executable work?

• What can agents decide?

• What requires human approval?

• How do you prove the delivered result satisfied the intent?

• How do you measure quality, speed, cost, and business value?

If those questions cannot be answered, the company does not yet have an AI development strategy.

It has a collection of tools and experiments.

The Next Evolution of Agile

Agile is not disappearing.

It is evolving.

The next generation of Agile delivery will include human teams, AI agents, shared context, automated verification, governed autonomy, and continuous intent alignment.

The sprint will not be the highest level of organization.

The prompt will not be the highest level of instruction.

The specification will not be the highest level of truth.

Intent will sit above them.

Intent will explain why the work exists.

The operating model will determine how that intent moves safely through the organization.

And Intent-Driven Engineering will provide the structure.

The future of software delivery is not simply faster coding.

It is the disciplined conversion of intent into verified outcomes.

That is the operating model enterprises now need.

:::