Engineering Insights

Delivery Has Doubled, but the Completion Constraint Is Not Yet Proven

Delivery has scaled without creating repair churn, but the flow is not yet converting started work into completed work consistently enough. The constraint is shifting from implementation quality towards planning coverage, repository controls and the speed at which review findings are resolved.

5 September 20265 min readJames SmithSoftware FactoryAI-Assisted Delivery

Delivery volume in the current phase is reported as twice that of the early build phase, with no accompanying rise in repeated repair. Raw counts, phase boundaries and cohort observation windows are not available, so this comparison cannot yet be reproduced.

Only 52.2% of changes started during the reporting period were delivered. The underlying counts and the status of the remaining changes are not provided. They may be awaiting review, blocked, rejected or still in progress.

The current hypothesis is that completion, rather than implementation quality, is the main constraint. Confirming that requires final finding dispositions and elapsed time in each blocked state.

The next improvement is not to relax review. It is to shorten the path from a valid blocking finding to an engineering decision and verified resolution.

Review is a control, but its effect on flow is not yet proven

First-pass acceptance was 91.7%. No change entered a second repair pass. The raw counts and cohort dates behind these measures are not available.

Automated reviewers raised all recorded findings. Correctness accounted for 93.8% of findings, and 59.4% were classified as blocking. The finding counts are not provided.

These results show that the review process identifies issues treated as consequential. They do not yet establish that review is the cause of lower delivery completion.

The reporting data also does not define the workflow states precisely:

  • Started is not defined.
  • Delivered is not defined.
  • Accepted is not defined.
  • Repair pass is not defined.
  • Blocking is not defined.

A blocking finding and a repair pass are not necessarily the same event. A finding may stop acceptance while the change remains under review, awaits an engineering decision or depends on work outside the implementation. It creates a repair pass only if the workflow returns the change for implementation and records that return as a repair cycle.

This distinction could explain how blocking findings coexist with no second repair passes. It cannot be confirmed until the workflow definitions and final dispositions are available.

High first-pass acceptance, no repeated repair and a lower delivered share are consistent with review constraining flow rather than creating churn. That remains a hypothesis until blocked time and outcomes are traced.

Repository readiness has two concentrated gaps

Repository readiness checks passed at 92.6%. The underlying number of checks, repositories and assessment dates is not available.

The following controls were consistently present:

  • runtime pinning;
  • lockfiles;
  • continuous integration;
  • architecture mapping;
  • one-command checks;
  • testing guidance;
  • business rules;
  • secret controls.

These controls give coding agents a more deterministic environment and reduce dependence on undocumented local knowledge.

Agent tooling and default-branch protection each passed for 33.3% of the assessed scope. The definition and denominator of that scope are not provided.

The controls cover different parts of delivery:

  • Agent tooling determines whether an agent can inspect, test and validate a repository through supported interfaces.
  • Default-branch protection determines whether the review and evidence path can be bypassed.

Improving agent tooling alone increases execution capability without guaranteeing governance. Improving branch protection alone may enforce a process that some repositories are not equipped to complete efficiently.

Readiness is part of delivery capacity. Repositories need accessible checks and supported tools. Their integration paths need to keep those checks binding.

Planning measures cover different populations

Approved plans covered 34.8% of changes in the reporting period. A separate phase comparison reports that coverage rose from none in the early build phase to 66.7% in the current phase.

These percentages should not be compared directly:

  • 34.8% applies to changes in the reporting period.
  • 66.7% applies to changes in the current phase.
  • None applies to changes in the early build phase.

The source does not provide the dates, counts or cohort boundaries for these populations. It is therefore not possible to determine how the reporting period overlaps with the current phase or to reconcile the figures numerically.

Within the reported data, first-pass acceptance was 80% for changes with an approved plan and 100% for changes without one. The underlying counts are not available.

This comparison does not show that planning harms delivery. Plans are selected through a risk-sensitive gate, so planned work may contain more uncertainty or consequence than work allowed to proceed directly. The groups need to be controlled for risk before any effect is attributed to planning.

Model routing requires separate evidence

The reported routing assigns different models to classification, planning, implementation, challenge, review and escalation according to risk.

The source does not include the evaluation process, selection criteria or fallback behaviour behind those assignments. Listing individual routes without that evidence would describe configuration rather than explain an engineering decision. The routing table is therefore outside the scope of this analysis.

The relevant design principle remains separation of responsibility. Classification, planning, implementation and independent challenge should not collapse into a single judgement.

What we are changing next

The next work follows three steps.

  1. Establish reproducible reporting. Record raw counts, cohort dates, state definitions and observation windows for delivery, acceptance, findings, repair passes, readiness and planning. Completion means each reported percentage can be reproduced from a named population.

  2. Trace blocking correctness findings. Record each finding’s workflow state, final disposition and elapsed blocked time. Completion means undelivered changes can be separated into rejected, awaiting review, externally blocked and still in progress.

  3. Address paired readiness controls. Prioritise agent tooling and default-branch protection together, then reassess the same defined scope. Completion means both controls are measured against an explicit repository population using the same assessment criteria.

Approved-plan coverage can then increase according to risk. Its effect should be assessed only after planned and unplanned cohorts can be compared on a consistent basis.

What this means

The available results are consistent with the quality gate holding as delivery volume rises, but incomplete cohort and workflow data limit that conclusion. The immediate task is to make the measures reproducible, trace blocking findings to their outcomes and test whether review is the current completion constraint.

Talk to us

Building something adjacent to this?

Lender, broker, dealer group or technology partner — if this is the kind of problem you’re working on, we should compare notes.

support@autofintech.co.uk
All insights

Let’s talk

If you’re building what’s next in the motor trade — lender, broker, dealer or technology partner — we should talk.

support@autofintech.co.uk

ICO registered — GDPR compliant — Cyber Essentials certified

AFTGROUP

Auto Finance Technology Ltd · United Kingdom