§ AI & AUTOMATION

AI Software Engineering Transformation

Developers are already using AI. The harder question is whether software delivery improved. Editor speed is one input to throughput, and review queues, testing, requirements and deployment can absorb every minute of it.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call What this covers

What you're seeing

Licences are active across the team and no delivery number has moved.
Usually means Adoption was measured by seats, which is always high because the licence is free to the engineer and awkward to decline. Whatever the tools changed, it was not the constraint on delivery.
Review queues grew after the coding tools arrived.
Usually means Generation capacity went up and review capacity did not, so the constraint moved rather than lifting. Throughput is now set by the reviewers, who are the same senior people as before and are now reading more code than they were.
Nobody can say which code in the repository was model-authored.
Usually means There is no signal for reviewers to calibrate against and no way to look back after an incident. It also makes the licence-provenance question unanswerable, which security will eventually ask.
Test coverage did not grow with the volume of new code.
Usually means Generation is faster than the discipline around it. The gap compounds — each release adds more code than the suite covers, and the change failure rate follows some quarters later.
Engineers report large time savings and the release calendar is unchanged.
Usually means The saving is real and local, and it is being spent somewhere else in the system. Waiting for review, waiting for environments, waiting for a decision. The editor was not the bottleneck.

Adoption is not the outcome

Every engineering organisation of any size can now report a high adoption figure. Seats are active, engineers say the tools help, and the number goes into a board pack.

Whether software delivery improved is a different question, and it is answered by different data. In most organisations that have looked properly, editor speed went up and cycle time did not, because the constraint was somewhere else in the system and always had been.

Where the time actually goes

Writing code is one station on the line. The others are requirements that arrive underspecified, review that waits for a specific person, test suites that take too long to trust, environments that are not available, deployment that needs coordination, and decisions that sit unmade.

Speeding up one station on a line changes total throughput only if that station was the constraint. This is measurable, it is measurable from data you already have, and it is the first thing we do — because it decides whether the rest of the work is worth doing at all.

What changes, in order

The baseline comes first: cycle time, review latency, deployment frequency, change failure rate, from the repository and the pipeline.

Then the constraint gets addressed, whatever it turns out to be. Frequently it is review — which means smaller changes, better automated checks, clearer standards and more people able to review, before generation volume is increased. Sometimes it is testing, sometimes requirements, and sometimes the honest answer is that the tools are already doing what they can.

Then AI is integrated where it holds: issue preparation, implementation, pull-request review, test generation, documentation, migrations and refactoring, incident investigation, and retrieval over the engineering knowledge that currently lives in people’s heads.

Governance runs alongside rather than afterwards — what may be generated, what has to be reviewed by whom, how provenance is recorded, and how dependency and licence risk is handled for code no one wrote line by line.

Where it sits

This is the inward-facing edge of AI & Automation: the customer is your own engineering organisation. It shares most of its diagnosis with engineering velocity, which starts from the same delivery metrics without assuming AI is the intervention — if you are not sure the constraint is AI-shaped, start there instead.

The narrower version, focused on getting measured value out of the coding tools themselves rather than redesigning the delivery system, is AI consulting, and the tool-level mechanics live in the capability page underneath both.

The uncomfortable part

Redesigning a delivery system around AI is an organisational change dressed as a tooling one, and the resistance it meets is rarely about the tools.

Senior engineers who built their standing on writing the hard parts are being asked to spend more of the week reviewing work they did not write. Reviewers who were already the constraint are being asked to absorb more volume. Teams that were measured on output are being measured on a system-level number they do not individually control. None of that is solved by a better model, and all of it decides whether the programme holds after the first quarter.

So the work includes the parts that are not engineering: what the standards are, who owns them, how review is staffed and rewarded, and what gets said to the people whose jobs are changing shape. Those conversations happen either deliberately at the start or accidentally six months in.

What this covers

Each of these is a capability with its own page, its own order of work and its own outputs.

Capability What it means
AI Engineering Enablement Getting a measurable return from AI coding tools. Baseline first, then rollout with the review and security practices adjusted for code a human did not write line by line.
Delivery Metrics Delivery measured from the systems that already record it. Cycle time, deployment frequency, change failure rate and recovery time, reconstructed from your history rather than estimated.
Process Rebuild Rituals, review flow and deployment cadence rebuilt around how the team actually works. The output is a shorter path from decision to production, not a longer set of meetings.
Code Security Review A manual review of the code that handles trust decisions, with automated scanning wired into the pipeline behind it so the same class of defect does not return.
CI/CD Pipeline A pipeline fast enough that people wait for it. Build time is a delivery constraint, and a twenty-minute pipeline changes how a team batches work whether anyone intends it to or not.

Next step

Describe the situation and we'll tell you whether this is the right shape.

Request a call

How we decide

  • Review capacity is expanded before generation is

    Costs It delays the visible win and spends senior time on process rather than on features.

    Every unit of extra generated code has to be read by somebody, and reviewers are the scarcest people in the organisation. Rolling out generation first moves the queue to them, lengthens cycle time and produces the outcome that discredits the whole programme. Smaller changes, better automated checks and clearer review standards come first.

  • Model-authored code is identifiable in the history

    Costs It adds process, and some engineers read it as surveillance, so it has to be introduced carefully.

    Reviewers calibrate differently when they know how a change was produced, and after an incident the question of what was generated and what was written is the first one asked. It is also the only way to measure whether the generated code has a different defect profile, which is the question the whole programme turns on and which nobody can answer without the label.

  • The finding is allowed to be that nothing improved

    Costs It is an uncomfortable result to deliver, and it is not what the sponsor was hoping for.

    The measurement is worthless if the conclusion is fixed in advance. Where the baseline shows the constraint is requirements, environments or decision latency, the honest answer is that coding tools will not move it — and knowing that before the next licence renewal is worth more than a favourable report.

Four responses to AI in engineering

Most organisations have done the first. The difference between the rest is what gets measured and who owns the outcome.

Approach What changes How it is judged When it fits
Redesigning the delivery system Review, testing, requirements and deployment, together Delivery metrics against a baseline The organisation is large enough for process to be the constraint
Buying licences Individual editing speed Seat activation A first step, and a cheap one
A mandated tool policy Which tool, not how work flows Compliance with the mandate Where security or licensing genuinely requires one answer
Leaving it to teams Whatever each team decides Nothing, consistently Small organisations with strong engineering judgement

The second row is not a mistake. It is a reasonable first move that gets mistaken for a programme, and the gap between them is what this page is about.

Is this you?

  • AI coding tools are in use and delivery metrics have not moved
  • Review has become the constraint since adoption
  • An engineering organisation large enough that process, not talent, is the limit

How we run it

Delivery metrics are baselined before rollout

Cycle time, review latency, deployment frequency and change failure rate are recorded before anything changes, from the repository and the pipeline rather than from a survey. Self-reported time savings are what every vendor quotes and what every retrospective produces, and they measure enthusiasm.

Frequently Asked Questions

Redesigning how software gets delivered so that AI participates across the lifecycle rather than only in the editor — requirements, implementation, review, testing, documentation, migration and incident work — with governance for code no human wrote line by line, and delivery metrics measured against a baseline taken beforehand. The unit of change is the delivery system, not the toolchain.
A rollout distributes licences and measures activation. This starts by measuring where delivery time actually goes, and it frequently finds the constraint somewhere the coding tools do not touch. Where that is the case, the useful outcome is knowing it before the next renewal rather than after another year of unchanged cycle time.
Cycle time, review latency, deployment frequency and change failure rate, taken from the repository and the pipeline rather than from a survey, with a baseline recorded before anything changes. Those four were being collected for other reasons already, they are hard to game, and they cannot be improved by people feeling good about a tool.
By the same standard as any other code, with two additions. The change is labelled so the reviewer knows how it was produced and can calibrate. And the automated checks are strengthened first — tests, static analysis, dependency and licence scanning — because raising generation volume without raising the automated floor puts all the new load on people.
It changes what the senior ones spend their time on, and it usually increases the demand for judgement rather than reducing it. More code arriving means more architecture decisions, more review and more responsibility for what ships. The organisations that struggle are the ones that cut the reviewing capacity on the assumption that generation replaced it.
The baseline is available almost immediately, because the data is already in your repository and pipeline. What takes time is a signal that separates from normal variance — delivery metrics are noisy at a weekly resolution, and any honest read needs enough history on both sides of the change to be worth acting on.