Notifications
Clear all
Topic starter
06/06/2026 2:27 am
TL;DR: AI-generated code is shifting the delivery bottleneck downstream, making testing, security scanning, deployment verification, and rollback automation the real control points as software moves to production, according to WorkOS’s interview with Harness CEO Jyoti Bansal. Static CI/CD pipelines no longer match machine-speed development, and delivery governance now has to adapt to AI-generated change volume.
NHIMG editorial — based on content published by WorkOS: Jyoti Bansal on how Harness is rethinking AI for software delivery
Questions worth separating out
Q: How should security teams govern AI-native CI/CD pipelines?
A: Security teams should govern AI-native CI/CD pipelines by treating test selection, deployment approval, and rollback authority as policy decisions, not engineering defaults.
Q: Why do AI agents change delivery governance assumptions?
A: AI agents change delivery governance because they can generate and move code at machine speed, while many CI/CD controls still assume a human-paced workflow.
Q: What breaks when CI/CD pipelines rely on static YAML alone?
A: Static YAML breaks down when release conditions change dynamically, because a fixed workflow cannot always reflect real-time risk, code impact, or production health.
Practitioner guidance
- Define pipeline authority boundaries Document exactly which delivery decisions are machine-driven, which require human approval, and which can be auto-executed based on live telemetry.
- Govern test selection as a control Review whether code-change analysis is allowed to skip tests, and require evidence for the rules that decide test scope in each release path.
- Bound automated rollback rights Set explicit thresholds for rollback triggers, define who can override them, and validate that the system can stop promotion before blast radius expands.
What's in the full article
WorkOS's full interview covers the operational detail this post intentionally leaves for the source:
- The specific AI-native delivery decisions Harness is embedding into testing and rollout workflows
- Examples of how canary and rollback automation are being used to manage production risk
- The interview context around developer productivity, cloud spend, and deployment verification
- The reasoning behind the distinction between AI-assisted tooling and AI-native platform design
👉 Read WorkOS's interview on AI-native software delivery and AI agents →
AI-native software delivery: what it means for CI/CD teams?
Explore further
06/06/2026 4:08 am
AI-native delivery turns CI/CD into an identity governance problem. Once AI systems can generate meaningful production code and participate in testing and deployment, the delivery pipeline starts behaving like a non-human identity with broad delegated authority. That means access scope, approval gates, and rollback rights are no longer just engineering concerns. They become governance questions about who or what is allowed to move change into production, and under what controls. Practitioners should stop treating the pipeline as a neutral transport layer and start treating it as an identity-bearing actor.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
A question worth separating out:
Q: How do teams decide when to automate rollback versus require approval?
A: Teams should automate rollback only when the telemetry is reliable, thresholds are explicit, and the blast radius is tightly bounded. If those conditions are weak, rollback should require human approval so the release process does not amplify bad signals into unnecessary production disruption.
👉 Read our full editorial: AI-native software delivery is exposing limits in static CI/CD
