Notifications
Clear all
Topic starter
06/09/2026 6:21 pm
TL;DR: AI development maturity is defined by the slowest link in the delivery chain, not the fastest, according to SafeBreach, and coding gains are being offset by manual testing, QA, and release readiness. The editorial position is that security-critical code must remain under mandatory human review while AI is applied to the bottlenecks that actually govern safe delivery, not just code generation.
NHIMG editorial — based on content published by SafeBreach: My Manager Wants More AI. I Want More Honesty
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: What breaks when AI coding outpaces testing and QA?
A: The control chain breaks, not just the schedule.
Q: When should organisations prioritise AI in testing over AI in code generation?
A: They should prioritise testing and release controls when implementation is already faster than verification.
Q: What are the signs that AI-assisted delivery is creating hidden risk?
A: Common signs include thinner human review, rising reliance on QA as an implicit safety net, more manual hand-off work after code is finished, and customer-found defects that do not fall despite faster delivery.
Practitioner guidance
- Map AI maturity across the full delivery chain Assess spec, implementation, finish work, QA, release readiness, and ship as separate control points.
- Keep security-critical paths under mandatory human review Require human approval for authentication, secrets, customer data segregation, multi-tenant boundaries, and crypto-sensitive changes.
- Move AI into test generation and validation Use AI to create regression suites, security checks, synthetic test data, environment setup, and release readiness artefacts.
What's in the full article
SafeBreach's full article covers the operational detail this post intentionally leaves for the source:
- The detailed conversation about where AI should stay at L3 and where lower-risk work can move toward L4.
- The examples of what fully AI-assisted testing, QA, architecture review, and release readiness would look like in practice.
- The team’s concrete metrics for deciding whether a maturity level is genuine or just a perception of speed.
- The reasoning behind the Tier A and Tier B split for work that can never be treated the same way.
👉 Read SafeBreach's analysis of AI-first development maturity and security-critical review →
AI-first development is outpacing testing, QA, and release readiness?
Explore further
06/09/2026 6:21 pm
AI maturity is a control-chain problem, not a coding problem. Organisations often measure AI adoption by how fast code is produced, but that metric hides whether testing, QA, and release readiness can still provide meaningful assurance. The real question is whether every stage in the delivery pipeline can sustain the same trust level. For identity and security leaders, this is the same logic that applies to lifecycle governance: a fast upstream step cannot compensate for a weak downstream control.
A question worth separating out:
Q: How should teams decide which software changes can move toward more autonomous execution?
A: Use the risk of failure as the boundary. Internal tooling, refactors of well-tested modules, and other low-impact work can progress further if evaluation coverage and rollback paths are strong. Authentication, secrets, tenant isolation, and customer data paths should remain under stricter human review because the cost of error is materially higher.
👉 Read our full editorial: AI-first coding is not mature if testing still lags behind
