AI assistance made a difference to our delivery that we did not expect. It widened the gap between work built on something proven and work started from nothing.
An accelerator is an unromantic idea. It is a piece of software that already solves a recognised problem, that has been through production somewhere, and that gets extended rather than rebuilt for the next client with the same problem.
We expected AI-assisted development to weaken that argument. If generating a component is cheap, why carry the overhead of a shared base?
The opposite happened.
The intuition that reuse saves typing is correct and almost irrelevant. Typing was never the constraint.
What takes the time on an enterprise delivery is the decisions. How tenancy is isolated. Where identity comes from and what happens when it is unavailable. What the audit record has to contain to satisfy a regulator who had not yet asked. How the thing behaves when a downstream system is down for four hours. What the data model does when the client's fourth region has different rules from the first three.
On a proven base, those decisions exist. They were argued once, implemented once, and they have been in production long enough that the bad ones have surfaced. Starting from nothing means taking every decision again, usually under time pressure, usually with less information than the first team had.
Generating code faster does not help with that. It arrives at those questions sooner.
Here is the part we did not anticipate.
When a tool drafts the work, the reviewing effort does not fall in proportion. It falls a little on familiar ground, where a reviewer knows what correct looks like and can scan for the places it usually goes wrong. It falls very little on unfamiliar ground, where the reviewer has to reason about the problem from scratch to know whether the answer is right.
So the benefit of assistance is largest exactly where the pattern is known, which is to say on top of something that already exists. On genuinely novel work the generation is quick and the review is slow, and the slow part dominates.
Reuse and AI assistance compound. Novelty and AI assistance do not.
In our own delivery the proven base is nVisionIT.Framework, our in-house application base, which every web-based build starts from, including the working prototype a client approves at the end of Sprint 0. Tenancy, identity, audit and error handling arrive already decided, so the first two weeks go on the client's problem. The prototype the client signs off becomes the foundation production is built on, which is why Sprint 0 ends in something that runs.
Reuse only works if the thing being reused is genuinely common. The failure mode is a catalogue that lists twenty products, of which four are real and the rest were built once for a client and given a name.
We went through that exercise and came out with a materially shorter list. Every item on it had to answer the same question: has this solved the same problem for more than one organisation, and would we put our own money on it solving it for the next one? Things that could not answer it went back to being what they always were, which is good client-specific work.
The shorter list is more useful to a buyer and more honest. It is also easier to keep current, which matters, because an accelerator that has not been maintained is a liability wearing the language of an asset.
If a supplier offers you an accelerator, the questions that separate a real one from a slide are direct:
A real accelerator has uncomfortable, specific answers to those. A slide has enthusiasm.
We hold our own solution accelerators to the same four questions.
Most of the time this gets discussed as build versus buy, which sounds like the decision and is not. That framing has caused more wasted quarters than almost any other in enterprise software, and the next piece in this series is about why.
Part of Insights series. Get new articles by email or follow the RSS feed.
AI changes the rate at which delivery work is produced. It changes nothing about who is answerable for it. Where that line sits decides whether AI-assisted delivery is an advantage or a liability.
The build-or-buy debate treats a sequencing problem as an ownership problem. The better question is which parts of this you will still want to control in five years.
Last of three. A process can be dramatically faster while the business barely moves. The smaller number was far less impressive and much more useful.
