Codified Governance: Building Software the Correct Way with AI-Native SDLC

The Numbers Don’t Add Up

Nine out of ten developers now use AI tools at work. That’s not projection — that’s the finding from the 2025 DORA report, surveying nearly five thousand technology professionals. And yet the same report delivers a sobering counterpoint: AI adoption has a negative relationship with software delivery stability.

Teams that adopted AI tools heavily saw 98% more pull requests. Review time grew 91%. Bugs increased 9%. Core DORA delivery metrics (the industry standard for measuring software delivery performance) remained unchanged. One of the most rigorous independent studies to date, a METR randomized controlled trial, found that experienced open-source developers using AI tools took 19% longer to complete tasks than those working without them, while simultaneously believing they were 20% faster.

The tools are everywhere. The discipline isn’t.

This isn’t an argument against AI in software development. It’s an argument against ungoverned AI in software development. Speed without structure doesn’t produce better software, it produces more of whatever was already happening, faster. In organizations with strong engineering practices, AI accelerates good outcomes. In organizations without them, it accelerates the problems.

The DORA report’s central conclusion deserves to be quoted directly:

“The success of AI in software engineering depends less on the sophistication of the tools and more on the strength of the organizational systems surrounding them.”

This article is about building those systems.

The Industry Is Converging

The reaction to ungoverned AI development has produced a wave of structured methodologies, each arriving independently at similar conclusions.

BMAD (Build More Architect Dreams) assigns 12+ specialized AI agents to roles that mirror a real development team — Product Manager, Architect, Developer, QA Engineer, Scrum Master. Each agent operates with tightly scoped context and produces governed artifacts before handing off to the next. With over 46,000 GitHub stars, BMAD makes the case that production-ready development requires methodology, not just capability.

AWS AI-DLC (AI-Driven Development Life Cycle), introduced at re:Invent 2025 and open-sourced at awslabs/aidlc-workflows, structures development into three phases (Inception, Construction, and Operations) with human oversight at every decision gate. AI proposes; humans validate; AI executes. The implementation uses steering files that travel with repositories to keep AI agents context-aware across platforms.

OpenSpec treats specifications as living code, versioned, persistent artifacts that travel alongside the codebase and serve as the primary context layer for AI agents. Rather than ephemeral chat-based planning, it establishes structured specs that persist across sessions and team members.

AI-SDD (Spec-Driven Development) frames the root cause directly: the specification bottleneck is why AI investments don’t translate to organizational delivery improvements. As one practitioner put it: ”Developers generate working code in minutes, only to discover days later that it doesn’t match what the system actually needed.” The spec is the constitution, everything else derives from it.

GSD, released in December 2025, reached 61,000 GitHub stars in under five months (the fastest adoption signal in the spec-driven space) reflecting how rapidly teams are converging on structured, specification-first AI development.

These frameworks are not competing. They are converging. Each identifies a version of the same missing layer: governance. Not tooling. Not prompts. A versioned, structured, enforceable system where standards are encoded into the development process itself; not written in a wiki somewhere that nobody reads under deadline pressure.

The Foundation: Documentation as Codified Context

Before any skill or agent can enforce standards, those standards must exist in a form agents can consume. This is the premise that separates AI-native engineering from AI-assisted engineering.

The industry already understands documentation as code, Markdown in version control, rendered by documentation platforms, reviewed in pull requests. This solved the human problem: docs live where the code lives, subject to the same discipline.

In an AI-native SDLC, this principle is not optional, it is the structural prerequisite for everything else. Every artifact produced across the development lifecycle lives in the repository:

• Problem Definition Records and Product Requirements: the “why” and “what” before any design begins
• Architecture documentation: system context, components, deployment, quality attributes
• Architecture Decision Records: very significant technical decision, its context, and its rationale
• Technical Design Documents: the low-level “how”: table schemas, migrations, interfaces, risks
• Test plans and test evidence: what was designed to be tested, and proof that it was

The repository is not a code store with documentation attached. It is the single source of truth for the entire delivery, and because every artifact is versioned, reviewable, and diff-able, the full history of decisions and their consequences is permanently traceable.

The harness depends on this completely. An agent that needs to assess the impact of a change can only load the component map, the active decision records, and the existing contracts if they live where the agent can reach them, in the repository, structured for consumption. A Confluence page, a Notion doc, a shared drive: none of these can be reliably loaded as codified context. The governance only travels if the documentation travels with the code.

Codified context is the next step: documentation structured specifically for agent consumption, not just human reading. The distinction matters. A human can infer meaning from an ambiguous sentence. An agent cannot reliably enforce a constraint it has to interpret.

Andrej Karpathy named this discipline in 2025: context engineering, “the art of filling the context window with just the right information for the next step.” It is not prompt engineering. It is the architectural decision of what knowledge an agent receives, when, and in what form.

Recent research (arxiv, 2026) has formalized a practical architecture for codified context in complex systems:

Harness Architecture

Tier 1 — The Constitution (Hot Memory)

A compact document loaded into every agent session. It contains the identity of the system, the core standards, and a map of where deeper knowledge lives. It must be concise enough not to crowd out the task itself. Think of it as the project’s operating contract.

Tier 2 — Specialized Skills

Domain-primed agents, each loaded with the specific knowledge required for their task. A requirements skill loads stakeholder context and scope definitions. An architecture impact skill loads the current system’s component map. A testing skill loads quality contracts. Each skill knows exactly what it needs — and nothing more.

Tier 3 — The Knowledge Base (Cold Memory)

Architecture documentation, decision records, technology standards, requirements history, loaded on demand, per skill, per invocation. This is where institutional knowledge lives. The research finding that crystallizes why this tier matters: ”When developers repeatedly explain the same domain concept across sessions, that’s a signal to codify it.”

The mechanism that delivers this tiered context to agents at runtime is the harness: the infrastructure layer that manages the lifecycle of context from intent capture through execution, verification, and artifact persistence. Not the model. Not the prompt. The system that makes the model reliably correct by ensuring it always has the right context and never has excess noise.

The implication is direct: governance encoded in your architecture documents and decision records is no longer advisory. It is enforced at invocation time.

When the impact analysis skill loads your architecture document’s component map, it cannot propose a change that ignores the constraints described there. The standard is not a document to be consulted, it is the context the agent reasons within.

The AI-Native SDLC Pipeline

The pipeline described here spans eight phases, from context initialization through production deployment. The diagram below shows these phases across four swim lanes: the Developer (intent, judgment, approval), AI Skills and Agents (execution, generation, validation), the Governance Layer (standards delivered as context via the harness), and Artifacts (the outputs that persist and feed the next phase).

SDLC Pipeline

The Decisions Layer: Where Governance Matters Most

The upstream phases (problem definition, requirements, impact analysis, architecture decisions, technical design) are where AI development does its most irreversible damage when ungoverned. A poorly framed requirement, an unassessed impact, an architectural decision taken without context: these don’t just create bugs. They create compounding constraints that affect every phase downstream.

This is also where the governance layer pays its largest dividends.

Pipeline Phases

Phase 0 — Context Bootstrap

Before any work begins, the repository’s harness is initialized. CLAUDE.md (a compact entry point) points to the AI Harness manifest, which maps each skill to the context tiers it requires. Stack information, architecture governance references, active decision records, skill-specific loading instructions: all resolved before the first invocation.

The engineer doesn’t configure this per task. The harness travels with the repository.

Phase 1 — Problem Definition → Requirements

A feature request arrives. Before any solution is proposed, a problem definition skill structures the problem: what is actually being asked for, who is affected, what constraints apply. The PDR (Problem Definition Record) is the pre-condition for everything downstream.

A product requirements skill then translates the structured problem into formal requirements, loading the system’s existing scope and stakeholder context from the architecture document. The output is a versioned PRD, not a chat summary, but a reviewable artifact that enters version control like any other file.

For complex requirements, a multi-pass requirements pipeline sequences four perspectives automatically: elicitation → formalization → systems review → architectural review. Four specialized views of the same requirements, producing a document that has been stress-tested before a single line of code is considered.

Phase 2 — Impact Analysis → Solution Proposal → ADR

This is the gate that prevents architectural drift.

An impact analysis skill evaluates the proposed change across seven dimensions (services, APIs, data model, contracts, integrations, security, observability) by loading the current architecture’s component and deployment views. It produces a verdict: Significant Change or Localized Change.

For significant changes, an architecture proposal skill explores alternatives with documented trade-offs. This is where decisions are made, not in code, not in Slack, but in a structured document with explicit reasoning.

A decision record skill formalizes the selected approach as an Architecture Decision Record. That ADR immediately becomes part of Tier 3 context, available to every skill invoked downstream. Future impact analyses will load it. Future reviews will reference it. The decision is not in someone’s head or buried in a PR description. It is codified.

Phase 3 — Technical Design

A technical design skill translates approved decisions into an executable low-level design: table mappings, migration plans, component interfaces, implementation risks. Its pre-condition is enforced: no technical design without an approved architectural decision upstream. The skill will not proceed without it.

The output is a TDD (a Technical Design Document) that a developer can implement against without needing to re-derive the architectural rationale.

Phase 4 — Story Planning

With the TDD approved, the backlog writes itself, or close to it. A story quality skill decomposes the Technical Design Document into user stories validated against INVEST principles: each story is independent, estimable, testable, and small enough to ship. A planning agent then creates the structured backlog (stories, acceptance criteria in Given/When/Then format, dependencies, priorities) directly from the approved design artifacts.

The key governance property here is sequencing: stories are not created before the TDD exists. The backlog is a derivative of the design, not a parallel speculation. This eliminates the most common source of story-to-implementation misalignment.

Phase 5 — Implementation

Implementation is the first phase where AI shifts from governance to generation. Developers work against TDD and validated stories, the constraints are already defined. A unit test skill generates test coverage aligned to the acceptance criteria. A code review skill validates each change against the team’s quality standards, architecture guidelines, and the active ADRs before a pull request is opened.

The governance layer is still present: the code review skill loads the relevant ADRs and the TDD as context, so any implementation that deviates from the approved design is flagged at review time, not in production.

Phase 6 — Quality as a Design Output

The same principle that governs the decisions layer applies downstream. Once a Technical Design Document exists, a test design skill can read it (together with the requirements it traces back to) and produce a complete test strategy. Not a list of suggestions. A structured test plan, with artifacts generated per environment: fuzz and chaos scenarios for the local sandbox, contract tests and regression suites for CI, end-to-end topology tests for staging, performance baselines and SLO validation for the load environment.

The test strategy is derived from the design, not improvised after the code ships.

A trace analysis skill then maps execution results back to the architecture, surfacing regressions before they reach production. A test evidence skill closes the traceability loop: each requirement maps to at least one verifiable test case, and gaps are declared risk, not silent omission.

The quality policy principle that drives this phase is worth stating plainly: ”Quality is built, not audited.” Defects caught in production cost orders of magnitude more than defects caught at design time. AI-governed quality moves the detection point upstream, and makes the coverage visible.

Phase 7 — Production Readiness Review & Deploy

The final gate before production is not a checklist filled manually under deadline pressure. A PRR skill loads the full architecture documentation alongside the test evidence produced in Phase 6 and evaluates the system against its defined quality attributes: availability targets, performance baselines, security posture, observability coverage, rollback capability. Every dimension is validated against what was designed, not against what the team remembers.

The PRR approval is the pre-condition for deployment. A deployment skill then formalises the change record (the who, what, when, and rollback plan) derived directly from the artifact trail built across all previous phases. The engineer does not reconstruct context from memory. The pipeline already captured it.

This is where the governance loop closes. The artifact trail that started with a problem definition in Phase 1 ends with a verified, traceable release in Phase 7. Nothing is implicit. Nothing is tribal knowledge. Everything is in the repository.

The Scale Thesis

Consider what this means for a new engineer joining a team.

They receive a feature request. They do not need to have attended the architecture review three years ago. They do not need to extract the correct context from a senior engineer’s memory. They invoke the pipeline. At each phase, the harness delivers the right context tier. The skills enforce the standards encoded in the team’s governance documents. The engineer’s job is judgment and approval, not ceremony.

The governance travels with the repository. Not with the senior. Not with the architect. It scales by design.

The Governance Layer: Skills, Agents, and Pipelines

Three primitives make this system work:

Skills are specialized, focused AI tools with a defined job. A skill has a versioned input contract, a versioned output format, and a specified context loading instruction. It is not a prompt, it is a governed asset. Skills have changelogs, evaluation suites that measure output consistency, security review, and deprecation paths. The same engineering discipline applied to production code is applied to the tools that produce it.

Agents are autonomous specialists that orchestrate multi-step work. An agent coordinates multiple skills in sequence, manages handoffs, and produces compound artifacts. A requirements pipeline agent (elicitation → formalization → dual review) is an example: a four-phase workflow encapsulated in a single invocation.

Pipelines are orchestrators that sequence agents for end-to-end phase coverage. They handle the macro-level flow: what runs first, what depends on what, what gates exist between phases.

The lifecycle of these assets matters as much as their behavior. Skills and agents are reviewed before being added to the system, tested against evaluation suites that validate their outputs against known-good examples, monitored for drift as the underlying models evolve, and deprecated when they no longer meet standards. This is not prompt management. It is AI asset governance.

The DORA 2025 report identifies the organizational capabilities that determine AI success, and all of them are governance properties: clear AI policies, healthy data ecosystems, strong version control practices, quality internal platforms. The frameworks themselves are secondary. The systems surrounding them are primary.

The correct way becomes the easiest way. Not because engineers are forced to follow a process. Because the process is the tool.

Conclusion

The convergence is real. BMAD, AWS AI-DLC, OpenSpec, AI-SDD, and GSD are each, independently, building toward governed AI in the software development lifecycle. The space is not emerging, it is arriving.

What each of these approaches points toward but doesn’t fully formalize is governance as infrastructure: versioned, testable, lifecycle-managed AI assets, underpinned by codified context that makes institutional knowledge available to every agent at every invocation.

The 2025 data is clear: high AI adoption without this infrastructure produces more pull requests, more review time, more bugs, and unchanged delivery metrics. With it, the DORA report’s finding inverts — AI becomes an accelerator of organizational strengths rather than an amplifier of weaknesses.

Starting point for teams considering this path:

1. Codify one piece of context. A technology radar, an ADR template, a single section of your architecture documentation. Structure it for agent consumption: concise, explicit, versioned.
2. Build one skill around one phase. Start upstream: problem definition or requirements. The governance dividend is highest there.
3. Let the harness deliver the context. Wire the skill to load that context at invocation. Watch the correct behavior become the default.

The goal is not AI-assisted development. It is AI-native engineering — where governance is not overhead, but infrastructure. Where the correct way is not enforced by heroic senior engineers holding the line under deadline pressure, but by the tools every engineer uses every day.

References and further reading: DORA 2025 State of AI-Assisted Software Development · METR Developer Productivity Study (arxiv 2507.09089) · Stack Overflow Developer Survey 2025 · AWS AI-DLC (awslabs/aidlc-workflows) · BMAD Method · OpenSpec (openspec.dev) · Codified Context: Infrastructure for AI Agents (arxiv 2602.20478)