Intent Does Not Stop at the Pull Request

Intent Does Not Stop at the Pull Request

Most conversations about intent-driven development focus on the moment software is created.

A team describes what it wants. An AI coding tool interprets that intent. The system generates a plan, changes the code, runs tests, and prepares a pull request.

That is important work.

But it is only the first half of the story.

Once the code has been written, it still has to be packaged, scanned, deployed, secured, observed, operated, scaled, repaired, and eventually replaced. It must move through environments, infrastructure, policies, release controls, Kubernetes clusters, monitoring systems, and production safeguards.

The intent does not disappear when development ends.

It changes.

During development, the intent is usually:

What software should exist?

During delivery and operations, the intent becomes:

What operating condition should exist?

That distinction may become one of the most important ideas in the next generation of enterprise software engineering.

Development intent is only the beginning

A development intent might say:

Build an order-management service with authentication, PostgreSQL, Kafka integration, APIs, monitoring, and automated tests.

That intent helps a development team understand the capability it needs to create.

But after the application exists, the organization needs a different kind of intent:

Release version 2.4.1 of the order-management service into production using a controlled rollout, maintain at least three healthy instances, expose it through the approved gateway, satisfy all security policies, preserve backward compatibility, monitor business and technical health, and automatically reverse the release if agreed thresholds are violated.

That is not simply a deployment script.

It is operational intent.

It defines the state the organization expects to create and maintain.

The code is only one component of that state.

The delivery pipeline should be governed by intent

Traditional delivery pipelines are usually procedural.

They define a sequence:

Build

Test

Scan

Package

Deploy

Monitor

Each stage runs because the previous stage completed.

That model is useful, but it is limited. It tells the platform what steps to execute. It does not always explain the outcome the organization is trying to protect.

An intent-driven delivery model begins with the desired result:

Safely make the approved application version active in production while preserving availability, security, compatibility, compliance, observability, and cost boundaries.

The pipeline can then determine how that result should be achieved.

It may need to answer questions such as:

• Should this release use canary deployment or blue-green deployment?

• Is the target environment healthy enough to receive the release?

• Are the container images approved and signed?

• Did the required security scans pass?

• Can the database migration be safely reversed?

• Is sufficient capacity available?

• Are latency and error rates within the approved range?

• Did customer transaction success decline after rollout?

• Should the release proceed, pause, or roll back?

The pipeline is no longer just executing steps.

It is reconciling the system against an intended outcome.

That is a much stronger operating model.

Kubernetes is already built around intent

The infrastructure world has been using intent-based patterns for years, even when it did not use the language of Intent-Driven Engineering.

Consider Kubernetes.

You do not normally instruct Kubernetes to start one container, verify it, start another, restart a failed instance, and replace it if the server disappears.

You declare the desired state:

replicas: 3

Kubernetes continuously compares the current state with the declared state.

When the two are different, Kubernetes attempts to close the gap.

The pattern is simple:

Declare the intended state

        ↓

Observe the current state

        ↓

Identify the difference

        ↓

Take corrective action

        ↓

Validate the result

        ↓

Continue reconciling

That is an intent engine.

Terraform follows a similar model:

This is the infrastructure state that should exist.

GitOps follows the same pattern:

The repository contains the approved state of the environment.

Policy-as-code expresses another form of intent:

These conditions must be satisfied before a change may proceed.

Observability platforms define operational intent:

These health, performance, and reliability conditions must remain true.

The individual technologies already understand pieces of the model.

The opportunity now is to connect those pieces into one continuous chain of intent.

Intent files should continue beyond development

Intent files should not end when the feature is implemented.

They should become a connected hierarchy.

Business Intent

      ↓

Feature Intent

      ↓

Implementation Intent

      ↓

Release Intent

      ↓

Infrastructure Intent

      ↓

Security Intent

      ↓

Runtime Intent

      ↓

Business Validation

Each level answers a different question.

Business intent

Why does the capability need to exist?

objective: Reduce manual order processing

expected_outcome:

  - 95 percent of orders processed without human intervention

  - fewer order-entry errors

  - faster customer confirmation

Feature intent

What behavior must the software provide?

capability: Create and track customer orders

requirements:

  - authenticated order creation

  - order status tracking

  - event publication

  - audit history

Release intent

How should the approved software enter an environment?

application: order-service

version: 2.4.1

environment: production

strategy: canary

initial_traffic_percent: 10

rollback_on_failure: true

Runtime intent

What production state must be maintained?

minimum_replicas: 3

maximum_replicas: 12

availability_target: 99.95

p95_latency_ms: 500

maximum_error_rate_percent: 1

Security intent

What controls must always hold?

public_access: false

authentication: oauth2

approved_secrets_provider: required

container_scanning: required

critical_vulnerabilities_allowed: 0

signed_images_only: true

Observability intent

How will the organization know the software is operating correctly?

logs: required

metrics: required

distributed_tracing: required

alerts:

  - elevated_error_rate

  - increased_latency

  - dependency_failure

  - kafka_consumer_lag

These intent files should not duplicate every implementation detail.

They should define the outcome, constraints, evidence, and boundaries that the delivery platform must enforce.

AI should interpret intent, not replace deterministic control

Intent-Driven Engineering does not mean an AI model should control every production decision.

That would be the wrong architecture.

Production systems require predictability, policy enforcement, auditability, and repeatable outcomes.

Deterministic platforms should continue doing the work they perform best:

• CI systems execute defined checks.

• Kubernetes reconciles application state.

• Terraform provisions infrastructure.

• GitOps controllers synchronize approved configuration.

• Security scanners identify vulnerabilities.

• Policy engines evaluate compliance rules.

• Deployment controllers manage progressive rollouts.

• Monitoring systems measure health.

• Alerting systems detect threshold violations.

AI becomes valuable where interpretation is required.

It can:

• Translate higher-level intent into an execution plan.

• Detect conflicts across multiple intent files.

• Explain why a release was blocked.

• Correlate failures across logs, metrics, traces, and recent changes.

• Recommend a rollback or remediation plan.

• Summarize operational risk for a human approver.

• Propose updated intent based on observed production behavior.

The design principle is straightforward:

AI handles ambiguity. Automation handles certainty. Policy governs both.

That provides the adaptability of AI without surrendering the reliability of established engineering controls.

Every operational discipline contributes intent

Once Intent-Driven Engineering reaches the delivery layer, intent can no longer belong only to software developers.

Multiple disciplines contribute to the final operating state.

Discipline

Intent contributed

Product

Business outcome and customer value

Development

Required application behavior

Architecture

Approved structure and technical boundaries

DevOps

Release movement and deployment controls

Platform engineering

Supported runtime patterns

Cloud engineering

Infrastructure topology and capacity

Security

Required protections and prohibited conditions

SRE

Availability, recovery, and reliability targets

Observability

Required evidence of health

Compliance

Audit, approval, and retention obligations

FinOps

Cost limits and resource-efficiency expectations

These should not become isolated documents passed between departments.

They should become composable layers of intent.

The delivery system should be able to evaluate the full chain:

The business intent is understood.

The feature intent has been implemented.

The architecture intent has been respected.

The security intent has been satisfied.

The infrastructure intent has been provisioned.

The release intent has been executed.

The runtime intent is currently being maintained.

The business result is now being measured.

That is end-to-end traceability.

The meaning of “done” must change

In many organizations, a feature is considered done when the code is merged.

In others, it is done when the deployment pipeline turns green.

Neither definition is strong enough for modern enterprise systems.

Under Intent-Driven Engineering, done means:

The intended business capability is operating in the intended environment under the intended security, reliability, observability, compliance, performance, and cost conditions—and the organization has evidence that those conditions are being met.

That definition includes implementation, but it does not stop there.

It includes reality.

A successful deployment is not proof that the intent was achieved.

It only proves that software moved.

The actual intent is achieved when the desired outcome exists and continues to exist.

From development lifecycle to continuous reconciliation

The familiar software lifecycle is often shown as a straight line:

Requirements → Design → Implement → Test → Deploy → Monitor

But modern systems do not operate as straight lines.

Production changes. Traffic changes. Dependencies fail. Security policies evolve. Infrastructure drifts. Costs increase. Customer behavior shifts.

The stronger model is a continuous loop:

Intent

  ↓

Plan

  ↓

Build

  ↓

Secure

  ↓

Provision

  ↓

Release

  ↓

Observe

  ↓

Validate

  ↓

Reconcile

  ↺

The intent remains active throughout the loop.

It governs what is built.

It governs how the software is released.

It governs the environment in which the software runs.

It governs the conditions that must remain true.

And when reality drifts away from those conditions, the system attempts to restore them.

Three connected layers

The complete model can be understood as three related disciplines.

Intent-Driven Development

Transforms business and product intent into working software.

Intent-Driven Delivery

Transforms approved software into a safe, controlled, and verifiable release.

Intent-Driven Operations

Continuously reconciles the running system against reliability, security, performance, compliance, observability, and cost intent.

Together, they form the broader operating model:

Intent-Driven Engineering

This is bigger than generating code from a prompt.

It is a way of connecting why the organization is making a change to what is built, how it is released, where it operates, which controls must hold, and how success is measured.

The intent file should not be discarded when the pull request is merged.

That may be the moment when it becomes most important.

Because development defines what the system should do.

Delivery defines how it should arrive.

Operations defines the condition in which it must continue to live.

And Intent-Driven Engineering connects all three.