Appendix Q — Industry alignment (reference, September 2026)
A dated comparison of this methodology with what vendors, researchers and practitioners published about AI-assisted software delivery between mid-2025 and September 2026: where the method matches the published consensus, where it goes further, where it is behind, and where it differs on purpose. It is a reading aid for adopters and reviewers. It is not a literature review, not a conformance claim against any named framework, and not evidence that the method outperforms anything. Reviewed 2026-09-17; re-review is due with each rule-bearing release.
When to use it
Use it to decide whether a control in this method is an idiosyncrasy or an instance of a practice others also recommend, to find this method's name for a term met elsewhere, and to see which published recommendations the method does not yet cover.
Do not use it as a source of numbers. Every figure below is quoted with its evidence class, and most of the quantitative claims in this field are vendor-reported, modelled or surveyed rather than measured. Do not use it as a compliance map: a named framework appearing in a row means the ideas are related, not that an adopter satisfies that framework.
How the sources are classified
The classes are those of the factory research, with one addition for consultancy articles.
| Class | What it can support | What it cannot |
|---|---|---|
| Practitioner guidance | That a practice is recommended by a named party | That the practice works, or works elsewhere |
| First-party implementation account | That one team did this and reports these results | Generality, economics, independent confirmation |
| Survey or observational study | Associations in the sampled population | Causation, or an effect on a particular adopter |
| Controlled or corpus study | An effect within its tasks, tools and date | Later models, other workloads |
| Technical specification or guidance | What a control is and how it is named | That an installation implements it |
| Consultancy observation | That a pattern was seen by that firm | Any figure quoted without a dataset |
The comparison
Status reads: aligned (same position), ahead (the method requires more than the source asks for), behind (the source recommends something the method does not yet state), different by design (the method takes another position and says why).
| Theme | Published position | Source, date, class | This method | Status |
|---|---|---|---|---|
| What separates casual from disciplined AI-assisted work | How outputs are verified, not whether AI is used; tests for deterministic behaviour and evaluations for the rest | Google, The New SDLC With Vibe Coding, May 2026, practitioner guidance | §2.3 Evidence over claims; release validation | aligned |
| Where leverage sits | In the harness around the model: instructions, tools, sandboxes, orchestration, hooks, observability; most agent failures are configuration failures | Google, same paper; Böckeler, Harness engineering for coding agent users, 2 Apr 2026, practitioner guidance | §4 instruction hierarchy, §7.1 enforcement layers, hooks and skills in the kit; §2.10 on controls that guard the wrong property | aligned |
| Feedforward and feedback controls | Guides steer before the action, sensors observe after it; each may be computational or inferential; neither removes the need for human accountability | Böckeler, same article | Skills and instruction tiers as guides; gates, reviewers and receipts as sensors; every gate must name its mechanism (§7) | aligned, other vocabulary |
| Size of always-loaded instructions | Keep them small and load detail on demand; large instruction files dilute attention | Thoughtworks Technology Radar Vol. 34, Apr 2026: context engineering Adopt, agent instruction bloat Caution, practitioner guidance; OpenAI, Harness engineering, 11 Feb 2026, first-party account (an entry file of about 100 lines used as a map); Gloaguen et al., arXiv 2602.11988, 12 Feb 2026, controlled study (repository context files did not generally improve task success and raised inference cost by over 20 %) | Three tiers; an operating card capped at 12,000 bytes with a CI budget check; skills loaded per task (§4) | aligned, and the cap now has outside support |
| Repository knowledge as the system of record | Versioned documents the agent can read, checked mechanically for freshness and links; a recurring clean-up of drift | OpenAI, same account | §2.5 and §11 living documentation; tiered documentation-sync gates (§7.5); the monthly consolidation review with a mandate to subtract (§2.8) | aligned |
| Specifications before code | Tools converge on specify, plan, tasks, implement. Three levels are distinguished: spec-first, spec-anchored, spec-as-source. Reported problems: review burden moves to long generated documents, agents ignore their own specifications, small fixes receive elaborate workflows, and spec-as-source may repeat the inflexibility of model-driven development | Böckeler, Understanding spec-driven development, 15 Oct 2025, practitioner assessment; Google, Spec-Driven Production Grade Development, 2026, practitioner guidance, which takes the spec-as-source position that code is disposable | §2.1 Design before code with one design artifact; lighter cycles for defects and incidents (§3.2, §3.5); artifacts kept proportionate to uncertainty and risk (§3.6); documentation as views of approved intent, observed implementation and evidence, never as the generator of code | aligned with the cautious reading; different by design from spec-as-source |
| Who writes the tests | The agent that writes code must be strictly separated from the one that defines tests or reviews the output | Google SRE, AI in SRE, 2026, practitioner guidance; Anthropic, Harness design for long-running application development, 24 Mar 2026, first-party account; Banik et al., arXiv 2606.18168, 16 Jun 2026, corpus study (80.2 % of 86,156 agent-authored test patches carried weak or no oracle signal) | Independent oracles; approved expectations pinned before implementation; adverse and negative cases; mutation discipline (Appendix A §14) | ahead: required before these studies existed, and demonstrated publicly in Appendix P |
| Where humans stay | Requirements, architecture and verification remain human-paced; review what ships; oversight moves up to designs, intent and policy; risk-selected human checkpoints for consequential actions | Google, May 2026 paper and AI in SRE; Google, Spec-Driven Production Grade Development | §2.2: the human owns what and why; separate approvals of meaning, execution and release in the business intent lifecycle and the governed factory; permission tied to consequence (§15.4) | aligned |
| Separation of authority for agents | No single agent completes a high-risk process end to end; execution authority is separate from approval authority; privilege escalation needs human approval. Every stage gate has a human accountable for approval | FINOS AI Governance Framework, AIR-PREV-018, technical guidance; BCG Platinion, The agentic software factory, 26 Mar 2026, consultancy observation | Three distinct approvals: meaning by the accountable business owner, a bounded and expiring execution mandate, and a release decision on verification evidence; whoever sets intent does not build, whoever builds does not set the quality norm | ahead: no published source was found that separates approval of meaning from authorisation to execute and acceptance of a release; this is a statement about a search, not proof of absence |
| Delivery measurement | Five software delivery metrics: lead time for changes, deployment frequency, change failure rate, failed deployment recovery time, deployment rework rate. AI adoption is associated with higher throughput and with higher instability. Measure cost per accepted change and rework; do not rank people or teams by token consumption | DORA, AI Capabilities Model, 2025, and State of AI-assisted Software Development, 2025, survey of about 5,000 respondents; DORA, Finding balance in the era of tokenmaxxing, 2 Jun 2026, practitioner guidance | Appendix P: five analogues at the board's own boundary, each with a provenance label, not assessed never shown as zero, no performance tier claimed; §5.9 reports the method's own refuted throughput claim | aligned; ahead on per-figure provenance |
| The cost of verification | A temporary productivity dip on adoption, driven partly by a "verification tax"; returns depend on the surrounding system; do not plan on headcount reduction | DORA, The ROI of AI-assisted Software Development, v2026.1, modelled calculator labelled high-uncertainty by its authors | §7.9: a gate's cadence is part of its cost; §2.3 refuses productivity figures without a baseline | aligned |
| Human review in the merge path | Two published accounts remove human code review from the routine path and rely on agent reviewers, held-out scenarios and cheap correction. One of them states that this would be irresponsible at low throughput | OpenAI, same account; StrongDM, Software factories and the agentic moment, Feb 2026, first-party account | Two-stage review; reviewer agents are second opinions, "not prevention guarantees" (§5.3); human review of architecture and of consequential change | different by design: the method gates by consequence, and treats removal of human review as something an adopter earns with measured results under a bounded mandate |
| Self-written tests as the safety net | Task the agent with writing the tests that validate its own output | Google, Spec-Driven Production Grade Development | Independent oracles, as above | different by design; the same publisher's reliability guidance takes the opposite position |
| Aggregate quality scores | Grade each domain and layer with a quality score tracked over time | OpenAI, same account | Readiness is a list of named blockers, never a score (Appendix P) | different by design: one number lets unrelated obligations cancel out |
| Agent security | Agent-specific threat lists and identity work: goal hijacking, tool misuse, privilege abuse in delegation chains, over-trust in agent explanations | OWASP, Top 10 for Agentic Applications for 2026, 9 Dec 2025, guidance; NIST, AI Agent Standards Initiative, 17 Feb 2026, programme announcement | §15: untrusted input is data, secret hygiene, least privilege for tools, permission tied to consequence | aligned in substance; behind on an item-by-item crosswalk |
| Autonomy levels | Practitioner ladders exist; no standard taxonomy was found for numbered "types" of AI-native delivery | Shapiro, 23 Jan 2026; StrongDM, Feb 2026 | Factory research §1: define the level locally; three execution profiles | aligned |
Where the method is behind
Each item is a published recommendation the canon does not yet state. None is adopted by this appendix. Items that would add a rule or change a contract belong to a rule-bearing release with its own review.
- Vocabulary. The canon uses its own terms. The crosswalk below is the first step.
- Trajectory evidence. Published guidance separates judging the final output from judging the path taken: which tools were called, in which order, and whether required checks were run or skipped. The method's receipts record checks and their outcomes; they do not yet record the ordered steps an agent claims to have taken.
- Authorship of expectations as a recorded field. The method requires independent expectation authorship; the result-receipt contract has no field that states who authored the expectations, so a checker cannot verify the separation.
- Small batches and work-in-process limits. DORA's capability model reports that small batches amplify AI's effect on product performance and reduce friction. The canon states neither a batch-size rule nor a work-in-process limit; §5.9 only reports the observed cost of many open pull requests.
- User-outcome evidence. DORA reports that teams without a user-centric focus can see team performance fall when they adopt AI. The business intent lifecycle records approved meaning and business validation; neither it nor the delivery-flow board carries evidence of user outcomes.
- A stated AI usage policy and versioned prompts. DORA recommends a clear, communicated stance in three buckets (prohibited, permitted with guardrails, allowed) and reports that about one in five respondents version their prompts. The method governs model routes and instruction files but does not ask an adopter to publish such a stance.
- Semantic policy checks on allowed actions. One published pattern adds, to deterministic allow-lists, a second check of how an allowed tool is being used. The execution mandate carries allowed actions and stop conditions only.
- Framework crosswalks. No mapping exists from this method's controls to the OWASP agentic list, the NIST AI Risk Management Framework, ISO/IEC 42001 or the FINOS catalogue.
- Approval fatigue. One source names the risk that a stream of small approvals turns review into reflex. The method's answer is in its design (focused requests, consequence-based gates, a review loop treated as a design signal in §2.11) but it is not stated as a risk.
- Independent adoption. The method has been applied by its author on three systems and by one reference adopter. No independent team has reported results. This is the largest gap and no document closes it.
Vocabulary crosswalk
| Term met elsewhere | Nearest term here |
|---|---|
| Agentic engineering | The full cycle (§3.1) under the human–AI collaboration model (§2.2) |
| Harness | Instruction hierarchy, skills, hooks, gates, reviewers and memory, taken together |
| Context engineering; static and dynamic context | Instruction tiers and the operating-card budget; skills and retrieved documents |
| Guides and sensors; feedforward and feedback | Instructions and skills; gates, reviewers, receipts |
| Output evaluation | Release validation: record → payload → output |
| Trajectory evaluation | Not yet present; see item 2 above |
| Evals as gates | Blocking layers of §7 with a named mechanism |
| Human-in-the-loop checkpoint | Approval of meaning, execution mandate, release decision |
| Policy server, structural gating | Allowed actions and stop conditions of an execution mandate |
| Golden principles, garbage collection | Consolidation review (§2.8) |
| Verification tax | Gate cadence as cost (§7.9) |
| Cognitive debt | Living documentation and the AI context loop (§11.5) |
| Deployment rework rate | Rework share on the delivery-flow board (Appendix P) |
| Cost per accepted change | Cost per landed item, not assessed until billing is reconciled |
What this does not claim
It does not claim the method is better than any tool, framework or practice named here, and no comparison was run. It does not claim conformance with DORA, OWASP, NIST, ISO or FINOS material. "Ahead" means the method asks for more, which costs more; whether that cost is repaid is for each adopter to measure against a baseline. The search behind "no published source was found" covered public material available on 2026-09-17 and can be wrong. Several cited figures are vendor-reported, modelled or uncited in their source; they are repeated here only with their class.
Sources
Retrieved or re-checked 2026-09-17. Publication dates belong to the sources.
- Osmani, Saboo, Kartakis / Google. The New SDLC With Vibe Coding. May 2026. Author summary: The new software lifecycle, 16 Jun 2026.
- Boonstra / Google. Spec-Driven Production Grade Development in the Age of Vibe Coding. 2026.
- Papapanagiotou, Malesevic, Heiser, Meshenberg / Google SRE. AI in SRE. Undated, 2026.
- Böckeler. Harness engineering for coding agent users. 2 Apr 2026.
- Böckeler. Understanding spec-driven development: Kiro, spec-kit and Tessl. 15 Oct 2025.
- Thoughtworks. Technology Radar Vol. 34, Apr 2026: context engineering, agent instruction bloat.
- Lopopolo / OpenAI. Harness engineering: leveraging Codex in an agent-first world. 11 Feb 2026.
- Gloaguen, Mündler, Müller, Raychev, Vechev. Evaluating AGENTS.md. 12 Feb 2026.
- Banik, Chowdhury, Shamim. All smoke, no alarm: oracle signals in agent-authored test code. 16 Jun 2026.
- DORA. AI Capabilities Model, 2025; State of AI-assisted Software Development, 2025; software delivery metrics.
- DORA and Google Cloud. The ROI of AI-assisted Software Development. v2026.1.
- Conaway / DORA. Finding balance in the era of tokenmaxxing. 2 Jun 2026.
- FINOS. AIR-PREV-018, agent authority least privilege framework. Undated.
- BCG Platinion. The agentic software factory. 26 Mar 2026.
- OWASP. Top 10 for Agentic Applications for 2026. 9 Dec 2025.
- NIST. AI Agent Standards Initiative. 17 Feb 2026.
- Anthropic, StrongDM, Shapiro, METR: see the factory research references.