SolutionsDelivery

Delivery the business is waiting on. The capacity is not missing. It is committed.

Commitments move out of the quarter because the engineers who would have delivered them are absorbed by remediation and by upgrades. This is rarely a separate problem. It is the other two seen from the other end of the same team, and it is the one the business actually feels.

Available · Beta Release Bring us a population How the delivery path runs →

Reign Factory is in beta and being productized. It is not generally available; beta access is agreed with us and scoped in writing before anything runs.

Where the capacity is a shape, not a measurement

The roadmap is not competing with nothing. It is competing with two populations that are the same path pointed at different work.

The cost

The roadmap is not competing with nothing. It is competing with two populations.

A quarter that slips is usually described as a prioritisation problem. It is more often an allocation fact: the same people were already committed to work that had a date, a finding number or a support ticket attached to it.

01It is not a third problem

Remediation pressure and upgrade pressure are what delivery pressure is made of.

The two populations on the other two pages are the ones absorbing the people who were promised to the roadmap. Treating waiting delivery as its own problem produces its own plan, and that plan competes with the same team for the same hours.

AskIf you removed the remediation and upgrade load for one quarter, what would actually ship?

02Work with a date on it always wins

And it should. That is why the residue is structural rather than fixable by asking harder.

A finding with a regulatory clock, an incident, a customer escalation — each of these correctly outranks a roadmap item every time it comes up. The roadmap does not lose because nobody values it. It loses because it is the only thing on the list with no external clock.

AskWhat proportion of last quarter’s unplanned work had a date attached to it?

03AI saved the time. It did not become roadmap work.

More than half of all code is now AI-generated, and the share of engineering time spent on new capability did not move.

This is the finding most likely to be argued with in the room, and it is the reason this page does not open with a productivity claim. The hours were real. They were reabsorbed by the same two populations rather than released to the fourth.

AskHas anything actually shipped that would not have shipped two years ago?

04What the business hears is different from what happened

Not “we spent the quarter on maintenance.” Just: it slipped again.

The two populations are invisible in the report the executive reads, because they do not appear as commitments. That gap is why the conversation repeats every quarter with the same shape and no new information in it.

AskCould you show, in one page, where last quarter’s engineering capacity went?

What is actually measured

The capacity split is measured, and so is the thing that did not fix it.

Every figure below is somebody else’s, named with its date and its population. Two of them are about AI and neither of them is the number an AI vendor would lead with. They are here because this page is about where the capacity went, and that is where it went.

What is measured	Whose figure, and when	Why it is on this page
At the median organization, roughly 42% of engineering time goes to maintenance, support and bug fixes. Organisations with more than 2,500 engineers are the worst.	DX, Core 4 Innovation Ratio benchmark. 500+ companies, 200,000+ data points. DX publishes no date on this benchmark and we are not going to invent one.	It is the split, measured rather than estimated — and it gets worse at exactly the size of organization this page is written for.
More than half of all code is now AI-generated, up from 34% one quarter earlier. Over the same period the Innovation Ratio — the share of time on new capability — stayed flat.	DX, The State of AI Impact in Engineering, Q2 2026, 22 July 2026. 500+ organizations.	The sharpest single fact available on this subject. The time was saved and it did not become roadmap work. Everything else on this page follows from that.
AI-assisted development shows a 35–40% productivity gain on simple, greenfield tasks — and around 10% or less on complex legacy code.	Google / DORA, The ROI of AI-Assisted Software Development, May 2026. Sample not disclosed in the published coverage.	Your roadmap is not greenfield and neither is your backlog. This is Google’s own number for the case that actually applies.
Individual developers using AI complete more tasks and merge more pull requests. Across whole companies there was no significant correlation between AI adoption and improvement.	Faros AI, The AI Productivity Paradox, 23 July 2025. 1,255 teams, 10,000+ developers, telemetry rather than survey.	Team-level gains do not aggregate, because the bottleneck moved downstream to review and release. That is the same constraint the other two pages describe.

On the METR randomised trial that found experienced developers 19% slower with AI: it is real, it is the best-designed study in this area, and METR themselves reported on 24 February 2026 that the effect shrank and lost statistical significance on re-run, with selection bias identified. We are not citing it as a finding, and we would rather explain why than leave it out silently. None of the figures above is an iTmethods measurement.

How the work runs

The same path, pointed at the work that is already defined.

Nothing here is a claim about your roadmap. The path works a population that is defined, scoped and waiting on hands — which describes most remediation, most upgrade work, and some of what is currently sitting in a backlog labelled delivery.

01 Agree what is actually defined Work where the answer is known and the constraint is capacity. If it needs a design decision or a product owner, it is not this population. In writing

02 Eligibility decides scope Which repositories, which classes of change, and what is excluded outright. Narrow first, and it widens only when both sides want it to. Yours to set

03 A named engineer Embedded for the population, running the work with your team rather than receiving tickets from it. Not a queue

04 A merge request in your repository Under your branch rules, against your review policy, sized so a reviewer can hold it in their head. Your repo

05 Checks report, they do not gate The checks that already run on that repository run on the change. No check confers permission to merge. No auto-merge

06 What is not defined comes back Anything that turns out to need a decision rather than hands is returned as declined, with what was learned. It is not guessed at. Refusal recorded

07 Your reviewer decides Reign Factory does not merge, does not release and does not decide what ships. The gate does not move. Named approver

The only figures we publish about this way of working are our own. Across eight of our own repositories, 326 merge requests were merged. Median time from merge request open to merge was 19 hours. 326 of 326 merged with a recorded approval from a named iTmethods engineer. Measured on our own engineering, 11 July to 11 August 2026, GitLab, release commits excluded, internal environment only, two-person team. The method is written up in full at what we measured. It is not a customer result, and we do not present it as one.

Where the record fits

Where the capacity went becomes a record instead of an argument.

Every model call the Factory makes passes Reign Gateway and is recorded there, attributed to the population and the item it was working. That is a governance record first. It is also, incidentally, the only version of this conversation in which the answer to “where did the quarter go” is a query rather than a recollection.

What the record carries

For each call: the identity that made it, the policy that applied, the decision taken, the model that answered, and the time. Joined to the merge request it produced and to the population it belonged to — so remediation work and upgrade work can be told apart in the record rather than in somebody’s memory of the quarter.

The part worth being precise about. This is a record of how a change was produced. It is not a capacity-planning system, it is not a forecast, and it says nothing about work the Factory did not touch. iTmethods makes no compliance, certification or accreditation claim under any framework. How the boundary works → · Regulatory alignment →

The four motions

Where this sits against the rest of Reign.

Four motions at four different stages of maturity. We state the stage every time, because the stage matters more than the description.

Operate Reign Ops The delivery toolchain run as a managed estate, with change control, access control and a recorded history of who did what. Available today Build Reign Factory The motion that produces the work itself, under review, with a named approver on every merge. In beta and being productized; beta access is agreed and scoped in writing. Available · Beta Release Govern Reign Gateway Where model access, policy and logging sit, so the use of a model in the delivery process is a governed event with a record rather than an unobserved one. Available today Assure Reign Assurance Organises the evidence a reviewer needs into a form they can work through. It does not certify, does not attest, does not issue an audit opinion and does not provide independent assurance, in any tense. Co-design development

A single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both are available today; Google Cloud is planned for 2027. Air-gapped and sovereign are in development. There is no multi-tenant or shared option at any tier. Deployment options →

Shared responsibility

Who holds what, and who decides what ships.

Written down before anything runs. The second row is the important one on this page: nothing in this arrangement moves a roadmap decision to us.

Who	What they hold
Reign Factory, automated	Attempt the eligible items in the agreed population. Open one merge request per item. Run the checks the repository already runs. Carry the record of what was tried, under which policy, and against which population.
Customer authored	The roadmap, and every decision on it. Which population is in scope and which is not. The eligibility rules. Your branch, review and release policy, unchanged. Every merge decision. What ships, and when.
Operating partner engagement	The named engineer embedded for the population. What came back declined and why. The honest read on which parts of your backlog this path does not suit.

Before the scoping call

The questions that arrive every time.

Can we buy this today?

Reign Factory is in beta and being productized. It is not generally available; beta access is agreed with us and scoped in writing before anything runs. The population and the eligibility rules are agreed first, and either side can stop.

Are you claiming this will speed up our roadmap?

No. We are claiming something narrower and more defensible: two populations are absorbing engineers who were promised elsewhere, and those two populations are the shape of work this path is built for. What that is worth to your roadmap is your measure, in your environment, and we would rather agree how to take it than assert the answer now.

Will the Factory work on our feature backlog?

Mostly no, and the FAQ is a better place to say so than the sales call. Feature work usually needs a design decision or a product owner, and that disqualifies it from this population. Where a piece of it is defined and waiting on hands, it qualifies on the same terms as everything else.

We already have AI coding assistants. Is this the same thing?

No. An assistant is a person at the keyboard being helped, and we operate those too — see AI-native governed SDLC. The Factory is the case where nobody is at the keyboard: it works an assigned item in an isolated environment and opens a merge request. Same boundary, same record, same pipeline, different thing at the keyboard.

How would we know whether it worked?

You would measure it, and we would agree how before we start. The measures that survive contact are usually the boring ones: how much of the agreed population was attempted, how much was accepted at review, how much came back declined, and what your reviewers thought of the changes. All four are visible in your own systems without asking us.

Which deployment shapes can we have?

A single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both are available today; Google Cloud is planned for 2027. Air-gapped and sovereign are in development. There is no multi-tenant or shared option at any tier. Deployment options states which is which without softening any of them.

AWS Advanced Tier Services Partner SOC 2 Type II on Reign Ops

AWS Advanced Tier Services Partner and Validated Managed Service Provider. Twenty-one years operating regulated engineering environments.