What changes when AI joins the delivery team, and what does not

We changed how we build things. We did not change what we owe the client, and the second half of that sentence is the one that matters commercially.

By August the AI assistance in our delivery was no longer an experiment at the edges. It was in requirements work, in engineering, in test design, in the documents that go with a release. Enough of it that the question stopped being whether it helps and became a harder one: what exactly is different now, and what must stay identical.

What genuinely changed

The first-draft cycle shortened. Requirements packs, test plans and migration approaches can now reach a reviewable state sooner, although we have not yet established a publishable before-and-after measure. We expect that to compound, because a draft that exists can be argued with, and an argument is where the thinking happens.

Breadth became affordable. Considering four approaches instead of one used to be a luxury paid for out of somebody's weekend. Now the second, third and fourth options get a serious look, which is where we expect most of the quality improvement to come from. The gain is that a better question survives to the end.

Documentation no longer has to lag. The artefacts that used to be written last, under pressure, when everyone had moved on, are now designed to be produced alongside the work.

Testing moved into the build. Tests are now generated alongside the code and run in the pipeline for every change before it is committed. An engineer reviews them, and a generated test counts only once it executes and passes. Human QA still reviews every milestone before a client sees it, so the automated layer adds coverage without replacing a person.

What did not change, and must not

A named person is accountable for every deliverable. Not a team and not a tool. If something goes out with our name on it, somebody signed it. That is the whole basis on which a client can hold us to anything, and no efficiency is worth trading it.

Review did not get shorter. This is the point most often misunderstood. If a tool produces four times the draft material and the review stays the same size, the review is now a quarter as thorough and the arithmetic will catch up with you. Review effort has to scale with what is produced, and where it does not, the organisation is accumulating a debt it has not written down.

Client confidentiality did not move an inch. What may go to which system, under what controls, is set by policy and does not bend for convenience. Our position on that is published, so a client can read it before they ask.

The engagement shape is the same. A conversation about the outcome, a scoped start that produces something working, iterative delivery, and a review of whether the value showed up.

The trap in the middle

There is a failure mode we have watched others walk into and have had to steer around ourselves.

Assistance makes production cheap. Cheap production makes it tempting to produce more. More produced means more to review. If review capacity is fixed, the surplus is absorbed by lowering the standard, usually without anyone deciding to.

Nobody announces that. It shows up later as defects in places where the team was sure it had looked.

The discipline that avoids it is unfashionable: produce less than you could. Use the capacity on the options worth considering and on the review, rather than on volume. Activity is the easiest thing to increase and the least likely to be what anyone is paying for.

What to ask a supplier who says they use AI

The claim is now universal and therefore worthless on its own. Four questions get past it.

• Who signs off the work, and what do they actually check?
• How has your review effort changed since you started using assistance?
• What may not be sent to an external service, and where is that written down?
• What did you do with the time it saved?

That last one separates the two kinds of supplier. If the saving went entirely into margin, you are paying the same for the same and someone else is better off. If it went into more options considered and documentation that exists, you are getting something.

Where this leaves us

AI has changed how we deliver. The useful version of that is smaller than the marketing version: the early part of the work reaches a reviewable draft sooner, alternatives became affordable to consider, and nobody's name came off anything.

For a client the visible difference is in the calendar and in the paperwork. Sprint 0 is designed to end with a working prototype the client has used and approved, and every deliverable carries the name of the person who approved it. The full engagement model is on AI-assisted engagement and delivery, and the engineering practice behind it under software development and engineering.

Which raises the obvious question. If the engine is faster, how much faster is the business? Before we get to that, the next piece sets out the framework that connects an AI output to a decision somebody is prepared to own, because without it none of the speed matters.