“At Harness, we’ve focused on helping engineering teams validate resilience much earlier in the delivery lifecycle” – Mr. Uma Mukkara, Head of Resilience Testing, Harness

AI is enabling engineering teams to generate code significantly faster than before. Why hasn’t this translated into faster or more reliable software releases?

AI has significantly increased the speed at which code is produced, but software delivery extends well beyond writing code. Everything that follows—building, testing, securing, validating, deploying, and monitoring applications in production is a different challenge altogether. These stages still depend on coordination across teams, governance, approvals, and operational judgment, none of which automatically become faster because code is generated more quickly.

As more code moves through delivery pipelines, every downstream stage comes under greater pressure. If testing, release processes, and operational workflows remain manual or fragmented, generating code faster doesn’t improve delivery outcomes. It simply shifts the bottleneck further downstream. The opportunity isn’t to slow code generation, but to modernise everything that happens after code is written so that software can be delivered with both speed and confidence.

Harness’ State of DevOps Modernisation Report highlights how AI is reshaping software delivery. What are the report’s key findings, and what do they reveal about the biggest challenges enterprises face in testing, release management, and operational resilience today?

Our research shows that while teams are producing code faster, many are struggling to keep the rest of the software delivery lifecycle operating at the same pace.

Among organisations that rely heavily on AI coding tools, 69% of very frequent AI coding tool users say that AI-generated code leads to deployment problems at least half the time. 79% say their pipelines are plagued by flaky tests and deployment failures. 71% report being required to work evenings or weekends a few times a month or more because of release-related tasks or production issues. And 72% of respondents say their current ways of working will not be sustainable over the long term.

Put together, this isn’t a story about AI failing. They highlight that testing infrastructure, release processes, and resilience practices were designed for a much slower development model. As software is produced at higher speed and greater volume, those delivery practices need to evolve as well. Otherwise, organisations end up dealing with more operational strain, longer recovery times, and engineering teams that struggle to keep pace with their own development velocity.

As AI-generated code becomes the norm, why are testing, validation, and production readiness emerging as the biggest bottlenecks in the software delivery lifecycle?

Testing and validation were built on the assumption that engineers could meaningfully review and reason about every unit of change before it reached production. That worked when code was written incrementally. It becomes much harder when a single engineer using AI can generate what previously took an entire team days to build. AI models also frequently generate both the application code and its accompanying tests. When those tests aren’t grounded in real application behaviour, organisations end up with flaky, unreliable checks that may pass one day and fail the next without any meaningful change to the software.

Production readiness is where these limitations become most apparent. Distributed systems fail—that isn’t hypothetical, it’s an inevitable consequence of operating at scale across multiple services and dependencies. Code can successfully pass every test in the pipeline and still behave unpredictably once it encounters real traffic, failure scenarios, and infrastructure conditions in production. That’s precisely the gap resilience testing is designed to address, and it’s one that continues to widen as AI-generated code increases without a corresponding evolution in validation practices.

At Harness, we’ve focused on helping engineering teams validate resilience much earlier in the delivery lifecycle. Capabilities such as passive risk detection identify potential failure patterns before an experiment even runs, while Composite Load Tests combine chaos experiments with synthetic load testing in a single pipeline step. Together, they generate resilience scores that teams can use as objective release gates, giving them greater confidence that software is ready for production before it reaches customers.

The industry appears to be moving beyond automating pipelines toward making smarter release decisions. What is driving this shift, and how do you see software delivery evolving over the next few years?

The shift is being driven by the realisation that speed without judgment is dangerous. A successful pipeline run confirms that predefined steps completed successfully, but it doesn’t necessarily indicate whether a release is ready for production.

Organisations increasingly need platforms that can evaluate deployment readiness using multiple signals, including production health, resilience scores from chaos and load testing, test outcomes, security posture, and compliance status, rather than relying on manual reviews and isolated approval processes. As software delivery accelerates, engineering teams need systems that help them make informed release decisions consistently and at scale.

We’re already seeing this transition take shape. Release platforms are beginning to evaluate operational signals together instead of treating them as separate checkpoints. At the same time, organisations are recognising that traditional pre-deployment testing cannot capture every behaviour introduced by increasingly dynamic software systems. This is driving greater emphasis on runtime validation and evidence-based release decisions.

Governance is another important consideration. Current industry estimates suggest that only a few organisations have mature governance practices for autonomous AI activity within software delivery pipelines, despite growing adoption. Closing that gap will be an important focus over the next few years.

Looking ahead, software delivery platforms will increasingly move beyond executing workflows to continuously assessing release confidence using real-time operational evidence. Engineering teams will spend less time managing approvals and more time defining the policies and guardrails that govern software delivery.

Many enterprises have successfully accelerated software development using AI. What changes should they now prioritise to ensure their release and resilience practices keep pace with this new level of development velocity?

There are three priorities I would highlight.

First, organisations should treat the software delivery platform as a strategic product rather than simply a collection of pipelines. The primary bottleneck has shifted away from writing code toward delivering it consistently. Standardised workflows and self-service capabilities allow engineering teams to move faster while maintaining governance across the organisation.

Second, resilience testing needs to become part of the development lifecycle rather than something addressed after an incident. Chaos engineering and other resilience practices help teams understand how systems behave under failure conditions before those scenarios occur in production. The organisations making the most progress are embedding these practices directly into their delivery pipelines—running chaos experiments alongside load tests as part of the same pipeline stage and using the resulting resilience score as an automated release gate before promoting software to the next environment. This shifts resilience from a reactive exercise to a continuous validation process, allowing teams to identify weaknesses early and build confidence in every release.

Third, security should be embedded throughout the software delivery lifecycle rather than introduced as a final approval step before deployment. Continuous security validation allows issues to be identified earlier, reducing both delivery delays and operational risk.

Ultimately, the objective isn’t to slow development. It’s to ensure that release confidence is built through continuous validation rather than a single review at the end of the process.

Looking ahead, what will differentiate organisations that successfully embrace AI-native software delivery from those that continue to struggle with release confidence and operational resilience?

Over time, AI coding assistants will become standard across the industry. Competitive advantage will come from how organisations manage everything that happens after code is written.

The organisations that succeed will integrate testing, release management, security, observability, and governance into a unified software delivery process. Release decisions will be based on real-time operational evidence rather than manual approvals or isolated checkpoints. They’ll continuously validate system resilience instead of discovering weaknesses during production incidents.

Organisations that continue to struggle are likely to rely on fragmented processes, manual coordination, late-stage security reviews, and approval models that were designed for a much slower pace of software delivery.

AI hasn’t created these challenges, it has simply made existing weaknesses much more visible.

The organisations that invest in disciplined software delivery, operational resilience, and continuous validation will be best positioned to translate faster software development into faster, more reliable software delivery.