Blog.

The hardest part of moving a team to agent-first delivery is not the tooling. It is the morning a capable engineer works out that the way they have built software for years is changing, and nobody has been honest with them about what that means.

Honesty is the whole foundation. People can tell when a transformation is a cost exercise wearing the language of innovation. If the plan is to reduce the team, say so. If it is not, prove it: a change framed as opportunity has to actually be one, in the work the team is given afterwards.

Three things earn the trust. The first is credibility: we build the agent systems ourselves before we ask anyone else to, so the advice comes from having done the work rather than from a slide. The second is reframing: spec-driven, agent-orchestrating work is a higher-value skill than hand-writing every line, and the people doing it should be able to see that in their own progression. The third is evidence: cycle time, throughput, the ratio of time spent architecting against time spent implementing. Measured change moves belief in a way that promises never do.

We learned the failure mode the obvious way. The early framing was too abstract. A team does not adopt a methodology because the argument is elegant; it adopts it when someone sits with them and shows the thing working on their code, on their problem, in the time it actually takes.

The underlying view is that a constraint is a design input. The point of agent-first delivery is force multiplication, more capability per practitioner, not the same work with fewer people. A leader who treats it as the latter should not be surprised when the team treats the change as a threat, because it is one.

Do the transformation with the team or it does not land. There is no version of this that works while the people doing the work are the last to be told.

A technically sound programme can still fail the test that funds it: whether the people paying for it can see that it works. Excellence that nobody can see is, to the people who decide budgets, the same as no excellence at all.

We have watched good delivery go unnoticed because the team treated communication as overhead. The work was right. The reporting was an afterthought. From where the budget holder sat there was no evidence, so there was doubt, and doubt is what gets remembered.

Three things close that gap. A live view of progress the stakeholders can read without asking for it. Premortems that put the risks on the table before they bite, so candour is the default rather than the apology. Rehearsals and runbooks, so the work survives contact with the people who depend on it.

Visibility is part of the real work. It is not a tax on the work. A communication plan deserves the same attention as the technical plan, and self-service evidence removes the practitioner as the bottleneck. A team nobody sees is a team that is forgotten when the money is allocated.

Do the work. Then make the work legible to the people who will never read the code.

A recurring question on AI work is whether to fine-tune a model on a client's domain. The honest default answer, for most of the systems we build, is no. The model is the part that ages; the corpus and the retrieval around it are the parts that compound.

Fine-tuning buys a natural house style and some implicit behaviour baked into weights. It costs a frozen artefact that ages badly, a general loss of capability as the model narrows, and a retraining bill every time the base models move. They move on a cycle of months. Retraining does not.

Retrieval at inference keeps the system current and keeps it honest. The model stays replaceable as better ones arrive. Every answer can point at the source it came from, which matters when the work has to be defensible rather than merely plausible. A claim folded into billions of weights cannot be audited; a claim drawn from a named document can.

So the data is the flywheel. Models are infrastructure we expect to swap. The discipline is to invest in the corpus, its structure, and its retrieval quality now, because that asset carries forward into whatever model is best next year.

Three things would change the reasoning. Hard real-time latency, where retrieval overhead does not fit the budget. Stylistic nuance that retrieval genuinely cannot carry. Or base-model progress slowing enough that a fine-tuned snapshot stops going stale. None of those hold for most business systems today.

Build the corpus. Borrow the model. Revisit the decision when the trade-offs actually change, not before.