SolutionsDelivery

Accelerate software delivery.

Give defined backlog work a path to review. Factory adds implementation and test capacity to remediation and upgrades so engineers can spend more time on product direction and roadmap decisions. Factory attempts the work; your team keeps every merge and release decision.

Available · Beta Release Discuss your delivery backlog See what reaches review →

Delivered through Reign Factory · Available · Beta Release. Start with one repository, one delivery path and work whose intended change and acceptance criteria are already defined.

Where the capacity is a shape, not a measurement

Remediation and upgrades draw on the same team and delivery path as roadmap work.

Where capacity goes

Remediation and upgrades draw on the same delivery capacity as the roadmap.

When a quarter slips, the allocation usually explains it: the same engineers were already committed to work with a date, finding number or support ticket attached.

01Remediation and upgrades are delivery work

They draw on the engineers assigned to the roadmap.

Planning them separately creates competing plans for the same team and hours.

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.

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.

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.

Benefits

What you gain.

Accelerate remediation, upgrade and roadmap work

Defined work keeps moving toward review, across remediation, upgrades and roadmap items alike.

Increase capacity for software delivery

Factory adds implementation capacity across remediation, upgrades and roadmap work while software engineers focus on product direction, architecture and work that needs their judgment.

Keep your delivery controls

Existing approval, release and production controls continue to govern every change.

Receive every change in a consistent form

Reviewers receive the work item, checks, results, findings and open issues together, ready for a decision. Customer policy determines who reviews, approves, merges and releases it.

Observations on engineering capacity

Published findings on engineering capacity and AI-assisted development.

Each figure comes from a named external source and retains its date and population.

What is measured	Whose figure, and when
At the median organization, roughly 42% of engineering time goes to maintenance, support and bug fixes. Organizations 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.
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.
AI-assisted development shows a 35–40% productivity gain on simple, greenfield tasks — and around 10% or less on complex legacy code.	Stanford University (Denisov-Blanch et al.), cited in Google / DORA, The ROI of AI-Assisted Software Development, 22 April 2026. Telemetry from approximately 100,000 developers.
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.

Read together they locate the constraint: the code got faster and the release did not, because the bottleneck moved downstream into review. That is the constraint Reign Factory is built around — one merge request per item, checks that report rather than gate, and a named approver who decides what ships.

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. AI coding at scale is the foundation capability of Reign Factory: an agent attempts each item and a named iTmethods engineer runs the population. 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 The agreed population keeps moving Embedded for the population, running the agent's 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 into the merge request The checks that already run on that repository run on the change. Your approval gate is the sole authority for the merge. No auto-merge

06 Unresolved decisions return early 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 Release authority stays with your team Your team keeps every merge, release and shipping decision. Named approver

The only figures we publish about this way of working are our own, measured on our own engineering and written up in full at what we measured. It is not a customer result, and we do not present it as one.

What the path can take

An item whose intended change is already decided and whose acceptance is already written down. Four things have to exist: a named repository and the delivery path it enters, a change somebody has already specified, checks in that repository capable of judging the implementation, and a reviewer who can say yes or no when it comes back. Which items are in scope stays yours to set. This is the shape of an item the path can work.

What it hands back

An unresolved product requirement. An architecture or design decision. Work with no acceptance path, where nobody can yet say what finished looks like. And every question of priority, merge and release, which were never on this side of the line. These come back named, with the reason and whatever was completed before it stopped. They are not attempted quietly and left to fail in review.

Where the record fits

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

Model calls the Factory sends through Reign Gateway are 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 context →

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 estate stays current, with change control, access control and a recorded history of who did what. Available today Build Reign Factory Defined work reaches 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 Gateway-routed interactions follow agreed policy and leave a record, so the use of a model in the delivery process is a governed event rather than an unobserved one. Available today Assure Reign Assurance Reviewers can work through connected evidence. Every run to date uses synthetic workflows and data. 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 deployment are supported. 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.

FAQ

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 deployment are supported. There is no multi-tenant or shared option at any tier. Deployment options states which is which without softening any of them.

A small software team produced an initial working version of Reign Gateway in about three months.

iTmethods used Reign Factory in its own production engineering, then continued building and hardening the product through the same source-control, test, review and approval path its software engineers use today.

This is one internal product-development example, not an expected customer timeline or a comparison with traditional development.

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.