AI can increase the number of changes entering delivery. Architecture, security, and compliance review capacity does not automatically increase with it.
More approval gates will not solve that constraint. Teams need clear risk criteria, automated evidence, and accountable human decisions where the consequences warrant them.
The governance speed gap
Governed agentic delivery needs a harness that guides work and verifies results, together with a review process that directs human attention according to risk. Both are necessary when AI increases change volume faster than people can assess the consequences.
AI-assisted and agentic delivery can increase the number of changes a team can generate, test, and revise. Human capacity to assess the architectural fit, or security consequences, and even the business trade-offs does not necessarily increase at the same rate and pace of AI/agentic velocity. This creates a governance speed gap between the work entering a delivery pipeline and the capacity to make sound, accountable decisions about it.
The gap is most visible where agents produce complete changes or pull requests faster than specialists can review them. It will vary by team and workload. Leaders should measure where work accumulates and which decisions consume the limited review capacity.
Treat the queue as a control signal
An architecture, security, or compliance queue can signal that governance arrangements no longer match the flow of work. Long waits can encourage informal workarounds; rushed reviewers may have too little time for difficult decisions. Both risks deserve monitoring.
Start with the delivery and recovery value streams. DORA recommends mapping the path from code commit to production, including handoffs and wait times, and separately examining the path for recovering from failed changes. Its guide identifies lead time, deployment frequency, change failure rate, and failed-deployment recovery time as useful measures of those flows [1].
Adding a sign-off or review meeting can be appropriate for a new risk. It does not, by itself, add the people or information needed to make a difficult decision. Applied uniformly, more gates can add waiting time to every change. Examine what each review must decide, what evidence it needs, and whether the decision has already been settled by an approved pattern.
The harness is required delivery infrastructure
A coding-agent harness is the surrounding set of specifications, context, instructions, constraints, automated checks, and feedback mechanisms that guide the agent’s work. Adapted, to your own constraints, project and organizational principles. For governed agentic delivery, it must provide guidance before generation and verify results throughout the delivery lifecycle. Böckeler’s harness-engineering guidance describes the need for both preventive guidance and feedback that helps agents correct their work before it reaches human reviewers [2].
Specifications establish intended behavior and acceptance criteria. Architectural rules define boundaries and approved dependencies. Tests, type checks, static analysis, dependency scanning, and policy-as-code check the requirements that can be expressed and assessed automatically. Production monitoring provides evidence about behavior under actual operating conditions. So - the ideas and concepts to solve all the challenges and questions are known and (mostly) clear. The harness must connect these elements so that failures lead to correction or escalation.
The harness also needs a way to stop work when the specification is incomplete or contradictory. An agent may produce code and tests that share the same misunderstanding. A passing test suite cannot resolve ambiguous business intent; the responsible product or domain owner must clarify it. The harness-engineering source explicitly identifies behavioral verification and excessive reliance on AI-generated tests as unresolved challenges [2].
Human decisions remain necessary for architectural fit, customer-impacting trade-offs, and safeguards for irreversible changes. Reviewers need the relevant specification, the affected boundaries, and evidence of the checks performed. Their time should go into the unresolved decision. Here we see, that their roles shift to become more a reviewer or moderator.
Make risk classification operational
Consistent review requires shared classification rules and clear ownership. Integrate those rules into existing architecture, security, change-approval, and compliance processes. Make it consumable, from humans and AI-agents. Knoweldge graphs are currently the first choice. Use the delivery pipeline to collect evidence and apply the required review path, with records retained under the organization’s existing requirements.
Maintain a small, versioned registry of approved patterns and escalation triggers. Classify each change by:
- customer or operational impact
- data sensitivity and regulatory relevance
- architectural boundary crossed, including dependencies on critical services
- reversibility and the cost of rollback
- novelty: whether the change fits a previously approved pattern
The delivery team proposes the classification as part of the change record. The owner of the affected boundary, such as the domain architect, security owner, or product risk owner, defines the triggers and decides exceptions. The pipeline records the classification, controls run, evidence produced, and approval where one is required.
Consider a change to internal logging that uses an approved library (e.g. log4j), exposes no sensitive data, and is fully reversible. It may proceed through team review and automated controls. A new customer-facing API processing personal data should trigger security and architecture review before deployment. Regulated decision logic or an irreversible data migration needs a named accountable owner, stronger evidence, and explicit approval. Each organization must set these review requirements against its own boundaries and obligations.
If a team cannot classify a change confidently, the pipeline should route it to a higher review tier. Give the escalation path a named decision owner and an agreed response time. Record the reason for escalation so that recurring questions can improve the classification rules. Review classifications again when implementation changes the scope or affected dependencies.
The “Governed AI-Assisted Engineering” (GAIE) preprint proposes a similar fail-safe principle and separation between generation and approval. Its evaluation uses analytical methods, with production validation still outstanding [3]. Organizations adopting its ideas should test their effectiveness in their own delivery environment.
Review the harness as well as the code
Harness engineering creates a second review workload. Changes to shared specifications, agent instructions, checks, permissions, or approval rules can affect many subsequent deliveries. Moving expert attention into harness engineering therefore requires a review process for the harness itself.
Assign owners to shared harness components and classify changes by their reach and effect on control. For example, a clarification to a local instruction and a change that disables a mandatory security check require different review paths. Keep a versioned record of the proposed change, its rationale, test evidence, and the authorization required by the affected boundary.
Reviewers should be able to see which services or teams inherit the change and how its effect was tested. Test automated checks against known acceptable and unacceptable cases, and monitor false alarms, missed failures, and opportunities to bypass them. Where AI-assisted review contributes judgment, identify that evidence as probabilistic. It needs its own evaluation and escalation criteria.
Use bounded trials and a rollback path for changes to shared harness components. Repeated exceptions may justify improving an approved pattern; they may also reveal a control that teams find difficult to satisfy. The responsible owner must investigate before changing the rule.
Separation of duties remains essential. An agent may generate code, run tests, and collect evidence, but it should not approve its own deployment or modify the controls that judge its work without independent authorization. Teams may deliver autonomously within approved boundaries; decisions that change those boundaries or accept material risk need clearly assigned human accountability.
Architects maintain the delivery controls
This governance approach changes the work of architects and control functions. They define reusable patterns, set risk thresholds, decide exceptions, and improve controls when evidence exposes a weakness. They also review changes to the shared harness that encodes those decisions.
Morris describes working “on the loop”: people improve the specifications, quality checks, and workflow guidance governing delivery [4]. When a defect recurs because an agent follows an incomplete instruction or an inadequate test, correct the instruction or test as well as the immediate artifact. Harness engineering makes maintaining those controls an ongoing responsibility [2].
Production can expose failure modes that specifications and test suites did not capture. Use incidents, security signals, service-level indicators, and failed-change data to review both classification rules and harness controls. Agents reusing the same instructions or generated tests across many changes can propagate the same weakness. Runtime feedback should lead to a specific action: amend a rule, strengthen a test or monitoring check, narrow an approved pattern, raise a review tier, or retire the pattern pending remediation.
What leaders should do now
- Map delivery and recovery flows, including review queues, handoffs, wait times, and recovery time. Include reviews of shared harness changes.
- Define approved patterns, escalation triggers, evidence requirements, and decision owners within existing governance processes.
- Establish the harness guidance and checks for a bounded workload. Test the controls and define how changes to them will be reviewed and authorized.
- Pilot the approach against a baseline. Track lead time, change failure rate, and recovery time alongside review-queue age, escalations, and failures missed by controls. Examine whether apparent delivery gains coincide with growing review queues or additional risk.
Before expanding the pilot, review cases that received too little or unnecessary examination and adjust the classification rules. Apply the same review to harness changes, where a single decision can influence many releases.
References
- DORA, “How to Use Value Stream Mapping to Improve Software Delivery”, retrieved 2026-05-29. Mapping wait times and handoffs helps expose delivery constraints; the guide distinguishes feature-delivery and recovery value streams.
- Birgitta Böckeler, “Harness Engineering for Coding Agent Users”, 2026-04-02. Describes guidance and feedback controls around coding agents, their limits, and their ongoing maintenance.
- Richard Kang, “Governed AI-Assisted Engineering: Graduated Human Oversight for Agentic Code Generation in Regulated Domains”, arXiv:2606.22484v1, 2026-06-21. A proposed graduated-oversight framework evaluated analytically; production validation remains outstanding.
- Kief Morris, “Humans and Agents in Software Engineering Loops”, 2026-03-04. Explores human responsibility for designing and improving the delivery loop.
Disclaimer
This article is part of a series exploring challenges and approaches in AI for SDLC and PDLC, covering architecture, methods, and sovereignty.
The AI space moves fast. What works today may feel outdated tomorrow and wrong the day after. Review these ideas critically and decide what applies to your context.
These views reflect the state of knowledge at the time of writing. No guarantee of correctness, especially as the field evolves.
AI assistance was used to support drafting and editorial refinement, including language polishing, as English is not the author’s native language.
Last Updated: 2026-06-30