4 minute read

Series: AI Bubble, Software Commoditization, and Industrial AI

Series map: Part 1 Part 2 Part 3 Part 4
Part 2 of 4. Previous: AI Bubble or Platform Shift? Capital, Costs, and Commoditized Software Next: Infrastructure Inequality: Power, Silicon, and the Capital Stack

Summary

Part 1 argued that software creation is being deflated while capital intensity is rising. Part 2 answers the operating question that follows: when first-draft software becomes cheap, what becomes scarce?

The scarce asset is not code. It is trusted throughput.

Trusted throughput means you can increase change volume without increasing incident volume, security exposure, and compliance risk. It means you can move fast without letting failure cost compound faster than delivery gains.

That capability is what I call quality capture.

Quality capture is not QA as a late-stage gate. It is a full operating system that converts AI-driven speed into durable production outcomes. Teams that build this system compound. Teams that skip it get a short productivity spike and a long reliability tax.

The operating truth teams need to accept now

Do not treat AI-assisted software development as a faster version of the old process. Treat it as a different process with different failure physics.

In the old process, code volume was naturally constrained by human typing and review throughput. In the AI-assisted process, candidate-code volume can increase much faster than review quality, test coverage, and governance maturity. That mismatch is where hidden risk accumulates.

The most dangerous failure mode is not obvious breakage. It is a quiet drift where output metrics rise while trust metrics degrade.

That is why execution has to change at the system level, not just at the tool level.

The evidence pattern is consistent

The available evidence points in one direction: speed gains are real, but delivery quality does not improve automatically.

  • Developers using GitHub Copilot completed a coding task 55.8 percent faster in a controlled experiment (Microsoft Research).
  • DORA 2024 reported that higher AI adoption was associated with an estimated 1.5 percent reduction in throughput and 7.2 percent reduction in stability in its dataset (Google Cloud DORA 2024, DORA report PDF).
  • A large user study found AI assistance can produce less secure code while users remain confident in it (arXiv 2211.03622).
  • Stack Overflow’s 2024 and 2025 surveys show adoption is broad and daily usage is now common, meaning this is not a niche workflow anymore (Stack Overflow 2024, Stack Overflow 2025).
  • Stanford’s AI Index shows the economic driver behind this adoption: model and hardware economics are improving rapidly, including large inference cost declines for GPT-3.5-level performance (Stanford HAI).

Taken together, this is not contradictory. It is exactly what you should expect in a transition phase: local productivity improves first, system quality improves only after governance and operating models catch up.

Why speed gains do not automatically become delivery gains

A practical decomposition helps.

AI is compressing cost and time in ideation, scaffolding, initial implementation, and some support workflows. But the hardest cost centers are not shrinking at the same pace: integration complexity, verification burden, security assurance, compliance evidence, and incident response under scale.

That imbalance creates a managerial trap.

Teams see visible acceleration in the front half of delivery and assume the back half will self-correct. It does not. Back-half costs are where trust is priced.

The result is predictable: releases speed up, risk controls lag, incidents rise, and leadership mistakenly calls this “growing pains” instead of “operating model mismatch.”

Do not let this become your default curve.

Execute quality capture as a production system

Run quality capture as a closed loop, not a compliance checklist.

  1. Encode intent as measurable acceptance and risk criteria before generation begins.
  2. Generate quickly with AI assistance inside explicit policy boundaries.
  3. Enforce verification gates that are calibrated to risk tier, not team preference.
  4. Ship with runtime instrumentation that links behavior back to change lineage.
  5. Feed incident and drift signals directly into tests, prompts, and release policy.
  6. Review loop performance monthly and tighten controls where failure cost is rising.

If any link in this loop is optional, the loop is broken.

Stop running all initiatives in one lane

Most organizations underperform because they run low-risk and high-risk initiatives with one governance template.

Do not do this.

Classify every AI initiative by blast radius and control burden, then run each lane with explicit execution rules.

Execution lane What to run here Non-negotiable controls Owner model Release rule Metrics to hold Kill criteria Scale criteria
Lane A: Low consequence / productivity Internal workflow acceleration, draft generation, low-liability support assist Baseline security scan, data handling policy, rollback within one sprint Functional owner plus engineering lead Fast release cadence with lightweight gates Cost per task, cycle time, adoption depth, rollback frequency No measurable efficiency gain after 2-3 iterations Repeatable productivity gain with flat incident profile
Lane B: Medium consequence / customer trust Customer-facing automation, moderate-reliability product paths, non-critical decision assist Risk-tiered review, stronger test harness, output guardrails, incident attribution Product + Eng + Security + SRE shared accountability Stage rollout; escalate gate strictness after each incident Change failure rate, MTTR, complaint rate, security findings, conversion quality Incident severity trend worsens for two release cycles Throughput gains with stable trust and reliability indicators
Lane C: High consequence / regulated or safety-linked Mission-critical systems, regulated workflows, high-liability decisions, cyber-physical interfaces Formal verification evidence, strict change control, human override authority, traceability end-to-end Business owner + Risk/Compliance + Security + Operations + Engineering No release without explicit go/no-go signoff against control matrix Control compliance pass rate, severe incident count, recovery time, audit evidence completeness Any unresolved control breach or unbounded failure mode Sustained performance under audit and stress with no control regressions

Treat lane migration as normal. A Lane A system can become Lane B when it touches billing or policy. A Lane B system can become Lane C when it influences regulated outcomes.

Reclassify quarterly. Do not freeze lane assignment at kickoff.

Build the metrics stack that governs behavior

Teams optimize what leadership reviews. So review the right stack.

First, hold delivery and resilience metrics at the core: deployment frequency, lead time, change failure rate, time to restore (DORA metrics).

Second, hold security and control metrics with equal weight: vulnerability introduction rate, time-to-remediate critical findings, high-risk change review coverage, and evidence completeness against internal standards aligned to frameworks like NIST SSDF (NIST SSDF, NIST SP 800-218 r1).

Third, hold AI-specific reliability metrics: incident attribution to AI-assisted changes, rollback rate by risk tier, model/prompt drift indicators, and decision traceability completeness.

Do not separate these into independent dashboards with independent owners. Force one integrated review where trade-offs are explicit.

Fix the failure patterns before they scale

Most failures in this phase are execution failures, not model failures.

Pattern 1: Tool rollout without workflow redesign

Copilots are deployed, but review ownership, release gates, and incident handling remain unchanged. Result: change volume outruns control capacity.

Execute this correction: redesign review and release policy before raising AI-assisted throughput targets.

Pattern 2: Output metrics replacing outcome metrics

Teams celebrate code volume, story points, and generation rates while reliability and trust decay.

Execute this correction: tie performance evaluation to reliability and customer outcome metrics, not output volume.

Pattern 3: Security confidence illusion

Generated code appears plausible and passes superficial checks, while deeper vulnerabilities accumulate.

Execute this correction: add AI-specific secure coding checks and mandatory threat review for high-risk surfaces.

Pattern 4: Liability blind spots in customer-facing automation

Organizations assume model responses shift responsibility away from the company.

Execute this correction: assume full liability for generated output and enforce policy/response controls accordingly. The Air Canada chatbot case is the warning signal (American Bar Association).

Pattern 5: Siloed accountability

Model teams optimize local quality, product teams optimize velocity, and SRE absorbs consequence.

Execute this correction: create shared quality budgets with clear ownership of failure economics.

Run a 120-day execution program, not an open-ended transformation

If quality capture is strategic, run it like an execution program with dates and gates.

Days 0-30: establish baseline and control map

  • Baseline reliability, security, and incident attribution metrics.
  • Classify systems into execution lanes (A, B, C).
  • Define minimum controls and go/no-go conditions per lane.
  • Freeze rollout in lanes where controls are undefined.

Days 31-60: enforce lane-specific gates

  • Implement risk-tiered review policy.
  • Add AI-aware security checks for generated-code paths.
  • Build targeted regression packs for known AI failure patterns.
  • Require rollback playbooks for Lane B and Lane C releases.

Days 61-90: close runtime attribution loop

  • Instrument production to trace incidents back to change lineage.
  • Add drift and behavior alerts for AI-assisted decision surfaces.
  • Run monthly operating review across Product, Eng, Security, SRE, and Risk.

Days 91-120: scale only proven lanes

  • Expand only initiatives with stable quality metrics and measurable value capture.
  • Pause or kill initiatives that fail kill criteria.
  • Reclassify migrated systems and tighten controls where blast radius increased.

The goal is not perfect safety. The goal is bounded failure with increasing learning velocity.

Treat quality capture as a margin engine

When software creation commoditizes, margin does not come from output volume alone. It comes from the ability to operate faster without paying an exponential reliability and compliance tax.

That is why quality capture is a growth capability.

Organizations that execute quality capture can:

  • ship faster without destabilizing service,
  • reduce incident and remediation drag,
  • pass procurement and compliance scrutiny faster,
  • and earn trust that increases adoption in higher-consequence workflows.

Organizations that skip it can still ship features quickly, but they convert speed into hidden liabilities and later-stage margin compression.

Apply consequence economics explicitly

Do not use one tolerance model across domains.

In low-consequence systems, allow rapid experimentation and fast rollback.

In medium-consequence systems, require tighter governance because failures directly affect retention, contract performance, and support economics.

In high-consequence systems such as regulated finance, critical infrastructure, rail, energy, and safety-linked industrial environments, enforce standards-aligned evidence as part of product delivery, not post-release documentation (IEC 61508, IEC 62443).

The repeated strategic failure is applying low-consequence operating assumptions to high-consequence systems.

Falsification test: keep the thesis honest

A serious strategy should be falsifiable.

The “quality capture is the moat” thesis weakens if, over a multi-year window:

  • teams with minimal process change and heavy AI usage consistently improve both speed and stability,
  • security incident rates stay flat while generated-code share rises materially,
  • and regulated deployments scale without stronger evidence and governance systems.

If that happens, quality capture is less scarce than argued.

Current evidence does not point there. But keep measuring.

Bottom line

Do not frame this phase as “AI versus quality.” Frame it as “AI speed requires a new quality operating system.”

Run lane-based execution. Enforce gate discipline. Instrument attribution. Tie incentives to trusted throughput.

If you do that, quality becomes a compounding moat.

If you do not, speed becomes expensive noise.

Bridge to Part 3

Part 2 focused on internal execution: how to convert software commoditization into trusted outcomes.

Part 3 shifts outward to a second compounding asymmetry: infrastructure inequality in power, compute, and capital, and why that determines who can run these quality loops at sustained scale.

Comments

You May Also Enjoy