I mentioned “Dark delivery” to a colleague last week and he laughed and said, “this is not Star Wars.” I think he was right, “Lights-Out” delivery sounds a lot less threatening. Not sure either is a settled term, but I will stick with “Lights-Out” for now. You might wonder what I mean by it? I will spend a few blog posts discussing it… and what my current thinking on it is. I am learning from my discussions with clients who are keen to push the boundaries and vendors who are keen to be part of the next iteration of software development.

One of the key questions we need to answer in the post Agile, post DevOps world is not just how much AI to use, but what kind of AI-driven delivery we are actually building towards. A useful frame for this is the distinction between “lights-on” delivery, where humans remain in the loop, observing and directing, and “lights-out” delivery, where work proceeds autonomously, unobserved, without human intervention at each step.

This distinction matters more than it might first appear. It is way more than just the next level of continuous delivery pipelines and as such it shapes not just tooling decisions, but governance, team structure, and organisational operating models. Critically, in my view these two modes are not sequential stages; organisations will not graduate from one to the other. They will run both simultaneously and learning to manage that mixed model is one of the defining challenges of AI-era delivery. It’s not unlike the multi-speed delivery we realised as our reality during the Agile/DevOps wave of improvements.

Two Models of AI Delivery — and Why Both Will Coexist

In AI-assisted delivery, the relationship between AI and human work is essentially substitutive. Engineers still produce the same artefacts (design documents, code, test scripts), but AI accelerates or assists in creating them. Whether the work is done through scripting or agents, the outcomes are familiar and inspectable. Governance can therefore operate as it always has: review the document, read the code, check the test results.

AI-native delivery is fundamentally different. Here, the organisation is not producing the same artefacts faster; it is training models directly for outcomes (such as executing a business process end-to-end) or for behaviours (such as an AI-powered agent that acts as a tester). In these cases, the traditional artefact may not exist at all. You cannot govern what you cannot inspect, which means governance must shift from reviewing outputs to measuring outcomes. The question moves from “does this code look right?” to “did the system behave correctly under real conditions?”

In practice, most organisations will operate across both models at the same time. A product team may use AI to accelerate code generation — AI-assisted, lights-on — while the same organisation runs an autonomous AI-powered agent handling regression testing in a lights-out pipeline which was trained on existing production systems. Different software architectures, different risk profiles, and different levels of platform maturity will naturally drive different points on the spectrum. The implication is that governance frameworks, tooling choices, and delivery methodologies cannot be designed for one mode alone — they must be flexible enough to span both, and clear enough to distinguish between them.

The DevOps Prerequisite

Lights-out delivery does not happen by deploying an LLM and hoping for the best. It requires very mature automation beneath it. We might call it GOFDO: Good Old-Fashioned DevOps. Cloud-native infrastructure, robust CI/CD pipelines, automated testing, observability tooling. These are not optional enhancements but prerequisites. AI amplifies the capabilities of the engineering platform beneath it; if that platform is weak, AI makes the weakness worse faster or breaks it at speed.

In a mixed model, this creates a two-speed architecture challenge. Teams operating in AI-assisted mode can tolerate more manual steps and lighter automation. Teams pushing toward AI-native, lights-out delivery need the full stack of DevOps maturity in place first. Organisations will need to be deliberate about which parts of their delivery estate are ready for autonomous operation — and honest about which are not.

This won’t be a surprise to you – but I think DevOps is even more important now. And given many organisations have lost their focus on DevOps, this requires some renewed focus even though the hype is gone (even the DevOps Enterprise Summit is gone now).

The Productivity Divergence Problem

One of the more disruptive implications of AI-assisted engineering is what happens to the distribution of productivity across a team and the impact on methodology. The gap between a skilled engineer using AI effectively and an average engineer using it poorly will grow substantially, potentially by multiples, not percentages. What is worse is that the actual volume of output might not differ (noting that lower productivity may actually mean more code, not less, as AI lowers the effort required to generate poor-quality outputs). This divergence will be felt even more acutely across teams operating at different points on the spectrum, from AI-assisted to fully AI-native.

This has serious implications for the delivery methodology. Agile, in its sprint-based form, depends on a degree of synchronisation across teams operating at roughly comparable velocities. If those velocities diverge sharply, whether due to individual skill differences or because some teams are running AI-native, lights-out pipelines while others are not, then the sprint cadence may simply be too slow a heartbeat for the most capable members. Kanban-style flow models, which are inherently more continuous and less dependent on synchronised cycles, may prove more durable in this environment. Even so, the mixed model will demand new thinking about how teams at different points on the spectrum coordinate and integrate their work and this will require some new thinking about application architecture too.

I cannot wait to see what methodologies people come up with. Just this week I heard one organisation mentioning that they are increasing the upfront effort again to shape the AI accelerated work. There will be iterations and different approaches across companies until we have a new “proven” methodology.

Governance at Machine Speed

Perhaps the most urgent structural challenge is that AI-driven productivity will outpace the capacity of traditional governance to keep up. Human review cycles, approval gates, and manual audits were designed for human-speed delivery. They will become bottlenecks. Or worse, create uncontrollable security and compliance gaps, if not redesigned. After all, as one of my clients once told me, to make a mistake is human, to create a catastrophe you need automation.

The need for a mixed model makes this harder, not easier. A single governance framework cannot treat a manually reviewed pull request and an autonomously deployed AI-native model update in the same way. Organisations will need tiered governance: lighter-touch, inspection-based oversight for AI-assisted work where artefacts exist and can be reviewed; and metrics-based, outcome-oriented oversight for AI-native, lights-out operations where they do not.

Building and maintaining this governance platform requires a dedicated central function. I see this analogous to the way FinOps emerged to bring discipline and visibility to cloud cost management and how Platform Engineering has evolved to provide guardrails for development. Without it, the mixed model becomes an accountability gap: fast where it should be careful, slow where it should be fast and no control over the cost profile of all the AI usage.

The Data and Cost Dimension

Underlying all of this is a dependency that is easy to underestimate: AI works with data, and data governance must scale alongside AI adoption. Automated data governance, including governance of the AI models themselves, will become as critical as code governance is today. In a mixed model, this is doubly complex, as teams in the organisation may be operating across the full spectrum from AI-assisted to AI-native, using different classes of model with different data access requirements and risk profiles.

There is also a cost dimension that organisations are only beginning to grapple with. As teams make choices between large language models and smaller, more specialised models, those choices carry significant cost and performance implications. I am thinking of this as FinAIOps – or should it be AIFinOps?!? – applying the rigour of financial operations to AI usage. It needs to provide systematic visibility into AI consumption, model selection, and associated spend. Who is using which models, at what cost, for what return? In a mixed model, where AI usage ranges from individual developer assistance in AI-assisted teams to fully autonomous AI-native pipelines, answering those questions requires investment in measurement and accountability structures that most organisations do not yet have. Dialling the consumption up and down based on impact will become a crucial responsibility of management across the organisation.

So, let’s get comfortable with the ambiguity in the state of software delivery at the moment, the need for a continuum from AI-assisted to AI-native methods and the upcoming evolution of methodologies. This journey is going to be fun. The path is less clear at this point, and I am looking forward to seeing many of you on our joint road of discovery – work will be more enjoyable, faster paced and perhaps a little less predictable for a while.