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. Tenhaw publishes both halves of it, The Tenhaw Way as the product delivery lifecycle and a build method that took a proof of concept from blank repository to working in two weeks inside a regulated insurer. 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 takes lifecycle and operating-model change, so what a story must carry, what review looks like and what good is defined as all have to be settled. 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 Tenhaw's 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, and 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 or rebuilding it, and be willing to rebuild. A proof of concept is optimised to answer a question, so it carries shortcuts in identity, error handling and data handling that cost more to unpick than to redo, while the requirement corpus and the evidence it produced are worth keeping. From there it is ordinary: the whole requirement set at once, high automated and unit test coverage, performance testing, key journeys tested by hand, a security review roughly every fifth prompt, and a named owner who agreed the acceptance criteria. Tenhaw took one from a blank repository to working in two weeks inside a regulated insurer, and is productionising it over four to six weeks with a dedicated team.

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.

Because generation speeds up and human review does not, so the queue simply moves from writing code to reading it. Staffing review up does not fix that. Redesign it instead, deciding what gets automated first-pass, what a human must see, and what standard the code is checked against. The deeper change is moving the control from authorship to verification, so instead of reading every line, a reviewer verifies high automated test coverage, performance results and the key user journeys. Teams that skip this redesign end up with the same throughput as before and more code to maintain.

Outcome-driven epics that describe the behaviour of the system rather than the tasks someone will perform. Tenhaw's own definition of done no longer decomposes work into stories describing what a developer will build. The epic states the business objective and the system behaviour, and development starts by pasting it into Claude or Codex in the editor and iterating until both the objective and the code are met. That only works if the epic genuinely describes the outcome, so the human effort moves up a level, away from specifying tasks and towards resolving ambiguity in the requirement itself.

Less than you might expect, because the first step does not need a consultancy at all. Writing your own engineering standard, explicit enough for an agent to enforce, is a fortnight of work with your own principal engineers, and every later decision hangs off it. Where outside help earns its keep is designing the operating model around it: the roles, the governance and the adoption plan, which runs two to four months and ends on a sequenced plan your own engineers execute. Much of what you need is free either way, since Tenhaw publishes the method in full and its 72-rule engineering handbook as open source, adoptable without hiring anyone.

Start with the engineering standard, and write it yourselves. An AI-native SDLC hangs off a definition of good that is explicit enough for an agent to enforce rather than for a human to remember, and every later decision follows from it, including what review automates, what a definition of done carries and what the model is allowed to produce. The second move is getting requirements out of tickets and into a machine-readable corpus, then running a gap-and-contradiction pass before anyone builds. Do those two in order, because each makes the next cheaper. The standard tells the model what good looks like, the corpus tells it what to build, and only then is redesigning review worth the effort.

Only if the lifecycle changes with them. The 2025 DORA research on AI-assisted software development found that AI acts as an amplifier, magnifying an organisation's existing strengths and weaknesses rather than lifting everyone by the same amount, which is why two engineering functions buying identical licences get very different results. Generation gets faster on day one. Delivery only gets faster if review is redesigned around what a human must actually see, if the requirements exist somewhere the model can read in full, and if the standard is enforced from the first prompt. Judge it on real work shipped, not on tool telemetry.

Usually yes, and it is the first real piece of work rather than an afterthought. If the model can only see one ticket at a time you have bought a faster autocomplete, because the leverage comes from giving it the whole requirement set at once. In practice that means converting the requirement estate into structured markdown, mapping the relationships between the pieces, and running a gap-and-contradiction pass before any code exists. That pass is usually where a team finds out how much of the specification was living in somebody's head, which is far cheaper to discover there than halfway through a build.

Write it for a machine to apply rather than a human to remember. Tenhaw publishes its own as an open-source handbook of 72 rules, free to take as a structure, and agreeing your version is a fortnight of work with your own principal engineers. The mechanics are stable identifiers on every rule so an agent can cite the one it is applying, RFC 2119 severities so must, should and may are not left to interpretation, and rules specific enough to be checked rather than admired. The content is the part only your own principals can settle, and the argument is worth having, because without it a model will produce code that passes every test and violates every convention you hold.

Less than the lifecycle around it does. Tenhaw runs Claude Code, OpenAI models and Gemini, picking the best tool for the case and running it inside the client's own infrastructure under their policies, and its build work starts by pasting an outcome-driven epic into Claude or Codex in the editor. What decides the result is whether the model can see the whole requirement set, whether an enforceable standard is applied from the first prompt, and whether review has been redesigned around it. Those hold whichever vendor you pick, which is just as well, because the tooling turns over quickly and the operating model does not.

Judgement work, mostly. The human effort concentrates on resolving ambiguity in the requirement, deciding what to proceed without, and owning the last few percent of correctness, which is where a model is weakest and where being wrong costs most. Rather than reading every line, an engineer checks high automated and unit test coverage, performance results and the key user journeys, and keeps the requirement corpus and the engineering standard current as the system changes, which moves the control from authorship to verification. Less typing, more deciding. The typing is what disappears, not the responsibility for what ships.

Weeks for the mechanics, longer for the judgement. On a Tenhaw engagement inside a regulated insurer, the client engineer who paired through a two-week build finished it 70% confident they could run the process unaided, which is a fair picture of what two weeks of pairing buys: the workflow, the standard, the prompts and the test discipline, with the harder calls still shared. Capability transfers by building together rather than by handover or training, so the pairing has to be real work on your own codebase rather than a demonstration. Two weeks does not make anyone an expert, it makes them able to start.

The first change lands inside a fortnight, the design of the operating model around it runs two to four months, and after that it is a rolling programme. The fortnight is agreeing an enforceable engineering standard with your own principal engineers, and teams feel it immediately in what the model is allowed to produce. Tenhaw runs this work on live engagements, and took a proof of concept from blank repository to working in two weeks inside a regulated insurer. The two to four months covers the roles, the governance, the redesigned review and the adoption plan. It stays a rolling programme because what changes is behaviour rather than tooling, and behaviour changes team by team rather than on a launch date.

The standard, the definition of done and review, in that order. Tenhaw publishes its own engineering standard as 72 rules with stable identifiers and RFC 2119 severities, and a Claude Code enterprise implementation holds across teams only when yours is that explicit and enforced from the first prompt, which is a fortnight of work with your own principal engineers. Then the definition of done moves to outcome-driven epics, because the epic is what gets pasted into the editor. Then review shifts from reading every line to verifying coverage, performance and the key user journeys. Tenhaw runs all of it inside your infrastructure under your policies, or inside your own enterprise AI tenancy where you have one.