The AI-native delivery lifecycle, answered in full.

A software delivery lifecycle redesigned around AI doing the research, drafting, scaffolding and first-pass review, rather than one with a coding assistant bolted on. In practice it means requirements maintained as a machine-readable corpus rather than as tickets, gaps and contradictions resolved before code is written, review redesigned because generation is no longer the bottleneck, and an engineering standard explicit enough for an agent to enforce.

Because the first cohort adopt for their own reasons and everyone else adopts only when their role, measurement and definition of done change. Additional training and enablement reliably fail to move it, because awareness was never the constraint. Moving it requires lifecycle and operating-model change: what a story must carry, what review looks like, and what good is defined as. The 2025 DORA research points the same way from a different angle, finding that AI amplifies an organisation's existing strengths and weaknesses rather than lifting everyone equally, which is why the same licences produce different outcomes in two different engineering functions.

It does if there is no enforceable standard, because a model will produce code that passes tests while violating conventions the team holds, and it will do so faster than humans can review. The mitigation is a standard specific enough to be machine-enforced, applied from the first prompt rather than in review. Tenhaw publishes its own as an open-source handbook with stable rule identifiers and RFC 2119 severities.

By taking the objection seriously rather than treating it as change resistance. In our experience engineers who push back for a specific technical reason are usually correct, the model is doing something that genuinely violates a standard or a constraint they can see and you cannot. That is nearly always fixable by updating a skill file or instruction so the behaviour stops. Engineers whose objection gets answered that way tend to adopt fastest, because they were listened to rather than overruled. Sitting with people and showing the value works; mandating it does not.

By changing the control from authorship to verification. High automated and unit test coverage, performance testing, manual testing of key user journeys, and a published engineering standard the code is generated against. If all of those pass, the system carries no more risk than human-written code, the difference is that output volume is considerably higher. Tenhaw also runs static analysis, dependency and secrets scanning on every commit and a model-led security review roughly every fifth prompt, which in practice makes proofs of concept more compliant than a lot of legacy code.

Decide first whether you are hardening it or rebuilding it, and be willing to rebuild. A proof of concept is optimised to answer a question, so it usually carries shortcuts in identity, error handling and data handling that cost more to unpick than to redo, while the thing worth keeping is the requirement corpus and the evidence about what works. From there the route to production is the ordinary one: the requirements as a machine-readable corpus, a build against the whole set rather than ticket by ticket, high automated and unit test coverage, performance testing, manual testing of key user journeys, a security review roughly every fifth prompt, and a named owner who has agreed the acceptance criteria in advance. Our own evidence here: a proof of concept taken from a blank repository to working in two weeks on a live engagement inside a regulated insurer, with that build now being productionised, scoped at four to six weeks with a dedicated team, which is exactly what our build teams exist for.

Not by licence activations. By whether the lifecycle actually changed: whether requirements are maintained as a corpus, whether review has been redesigned, whether the engineering standard is enforced, whether throughput moved on real work, and how confident engineers are that they could run the method unaided. That last one is measurable, so ask them, and take the honest number.