All Concepts
Engineering Governance

How CI/CD
Pipelines
Must Evolve

Every engineering team has a CI/CD pipeline. Most pipelines are missing the one gate that matters most in the AI era: the design intent gate.

The pipeline as it exists today

Every modern CI/CD pipeline runs a predictable sequence of gates. PR opened. Build and compile. Unit and integration tests. Code quality analysis — SonarQube, ESLint, ArchUnit. Code review. Merge.

These gates are well understood, well tooled, and widely adopted. They ask a set of questions about the code: Does it compile? Do the tests pass? Does it meet the quality threshold? Is it reviewed?

What none of them ask is: does this design decision conform to the architectural intent of the system?

Today's pipeline
PR OpenedBuildTestsCode QualityCode ReviewMerge

No gate checks design intent. The pipeline is structurally incomplete.


The gate that is missing

Between Code Quality and Code Review, a gate is absent: the Design Intent gate. This gate asks whether the code change, as a design decision, conforms to the architectural intent of the system — its declared principles, approved boundaries, and published constraints.

This question cannot be answered by SonarQube, ESLint, ArchUnit, or any code-structure analysis tool. These tools are bounded by what can be expressed as code rules. Design intent is not always expressible as a code rule.

An ADR that established a service boundary cannot be encoded as a package dependency check. A compliance constraint that applies to all components in the payments domain cannot be detected by a linter. A Steering principle that requires a Design Review before any new public API endpoint ships has no corresponding SonarQube rule. These violations pass every gate in the current pipeline — silently.


Why the gap matters more now

AI coding tools — Claude Code, Cursor, Copilot — generate significant proportions of production code at organizations that have adopted them. The code is syntactically correct. It has no memory of architectural intent.

The agent writing a new service does not know about the ADR that forbade direct service-to-service database access four ADRs ago. It does not know about the compliance constraint added to the Steering artifacts six months ago that applies to every component touching the payments domain. The code passes every quality gate. The design principle violation is silent.

In teams shipping significant amounts of AI-generated code, the rate at which design principle violations reach merge has multiplied. The pipeline has not evolved to match the pace of the tools generating the code.


The evolved pipeline

The evolved pipeline adds one gate — the Design Audit gate — between Code Quality and Code Review. Implemented as a Continuous Design Audit, it runs at every PR, automatically, before a human reviewer sees the code.

The evolved pipeline
PR OpenedBuildTestsCode QualityDesign AuditCode ReviewMerge
Conformant PR → proceeds normally. No architect required.
Approved drift → proceeds with record. Change Intention was pre-approved.
Unplanned drift → blocked. CHI auto-drafted. Architect notified of specific finding.

The architect's time is preserved for decisions that require judgment — not for manually reviewing every PR from an AI agent to catch design principle violations that a gate could have caught automatically. The CDA handles the routine enforcement. The architect handles the exceptions.

This is not a future state. It is the pipeline that AI-era engineering organizations need now. The tools that generate code at scale have already arrived. The pipeline that governs that code at scale is the missing piece.


Every CI/CD pipeline that lacks a design audit gate is one step behind the pace of AI-generated code. The evolved pipeline enforces design intent at CI/CD speed — every PR, every time, without an architect having to be present for every review to have teeth.