For twelve months, between June 2025 and May 2026, I worked with Ligentia, a globally distributed logistics business, on what began as a tooling engagement and ended as a programme of change that reshaped how the company shipped software. The brief, delivered directly by Boris Rabkin, their Chief Information Officer (CIO), was deceptively simple: enable his development team to ship higher-quality features, faster. The outcome, by the close of the engagement, was a 75% improvement in feature delivery measured through their own DevOps Research and Assessment (DORA) dashboards, a pull request review pipeline with Artificial Intelligence (AI) doing the first-pass review, and Claude or Claude Code in daily use across most of the globally distributed company.
None of this came from a flagship programme or a billion-pound transformation initiative. It came from a pilot that was small enough to be honest, a champion-based rollout that respected the team’s professionalism, and a flywheel of weekly innovation sessions that pulled the rest of the business in alongside engineering. What follows is the longer story behind the short version that appears in my AI Moonshot blog post.
The Brief
Boris Rabkin had been Ligentia’s CIO for around a year when he reached out to me directly. His goal was to give his development team the means to ship higher-quality features faster. Logistics is a sector that rewards reliable, well-tested change; if you ship a bug into a workflow that moves freight, the cost shows up across customers, partners, and operations within hours. Boris wasn’t looking for a flashy AI strategy he could put on a slide. He was looking for outcomes he could measure on the dashboards his team already trusted.
There was a formal scope document at the start. It set the high-level objectives: evaluate AI tooling options for the development team, design and run a structured pilot, and establish the conditions under which the team could measure the impact and decide whether to scale further. The document was deliberately light on prescription, which suited both of us. Engagements of this shape always evolve. The scope we agreed in June 2025 was the right brief for June; by Christmas it had quietly extended its reach, and by May 2026 it had reshaped itself into something neither of us would have predicted at the start.
Ligentia is a multi-country business with a globally distributed development team. I never met all of them, and would not have expected to; what I did spend time with was a representative slice of the team, the Director of Engineering (DoE) reporting directly into Boris, and a Head of Automation who would turn out to be the most important operational ally of the engagement. The cultural distance that comes with a distributed team is real. People do not pop into the kitchen and overhear each other’s frustrations; adoption stories travel slowly; a programme designed for an office of forty engineers in one building would not have survived contact with this organisation.
The question that ran through the engagement, in some form, throughout was this: what does it actually look like to give a sceptical, multi-country engineering team the conditions to ship higher-quality features, faster? The brief told me the destination. The team would tell me the route.
The Tooling Evaluation
The first job was to choose tooling. I worked alongside the Director of Engineering through this phase, which turned out to be one of the better structural decisions of the engagement. Bringing the DoE in from the start meant the evaluation was technically credible to the wider team from the moment it landed. A tooling decision the consultant arrives with looks like a vendor pitch. A tooling decision the engineering leadership has been part of looks like leadership doing its job.
We evaluated a small number of options against criteria the DoE and I drafted together: fit with the team’s existing stack, the operational shape of the licensing and access model, the security and compliance surface for an enterprise rollout, the workflow ergonomics that would shape day-to-day usage, and the depth of available enterprise support. I am deliberately keeping the runners-up unnamed; the comparative exercise is not the most useful part of this story, and the right tool for Ligentia is not necessarily the right tool for the next team I work with.
The choice we settled on was Claude Code Enterprise. It fit the kinds of work the team did, it had the enterprise security model their compliance posture required, and it had the operational shape that would let us run a deliberately reversible pilot rather than a one-way door.
The choice of tool, however, was the easy part. I have evaluated AI tooling for multiple clients now, and across all of those engagements one pattern holds: the tooling decision rarely turns out to be the bottleneck. The bottleneck is what comes next.
The Resistance
What came next was resistance. Not from Boris, who had commissioned the engagement, and not from the DoE, who had selected the tool with me. The resistance came from the development team itself. And the developers’ objections were not stupid; they were the objections any consultant who introduces AI tooling to a mature engineering team will recognise immediately. They are also the objections you can read on Hacker News any morning of the week and find on GitHub issues most days. As I write this, the Rsync project has had to litigate the same conversation twice this week. This is not a Ligentia phenomenon. It is an industry one.
Four objections, in roughly the words I heard them:
“It produces crap.” The quality argument. Some AI output is bad; some AI output is good; the dividing line is rarely the model and almost always the operator. This is a fair concern that deserves a serious answer; it cannot be dismissed with a vendor demo.
“The training data was gathered unethically.” The ethics argument. This is a real and ongoing debate in the industry. A consultant who pretends it isn’t is doing the work badly. The right response is to acknowledge the concern, point at the steps Anthropic has taken, and let the developer make their own informed call.
“Don’t make me give up on typing.” The identity argument. Plenty of developers came into the profession because they love the craft, and the craft for many of them is the typing. To frame AI tooling as a way to write less code is to threaten an identity. The honest answer is that the typing was never the job; the job was always shipping software that solves problems. (I have made this point at greater length in a Continual Professional Development (CPD) review of Thinking in Systems, and discussed it with Safia Abdalla on The Modern .NET Show earlier this year.) But that answer lands very differently in a one-to-one conversation than it does in a town hall.
“I’m too old to learn new things.” The agency argument. Sometimes this is meant as a joke; often it isn’t. People who have been senior in a particular workflow for a long time can be reasonably reluctant to be junior again, however briefly, in a new one.
Anthropic offered the team free training sessions during the early weeks of the engagement. The development team largely did not attend. The rest of the business was, by contrast, champing at the bit. That asymmetry was an early signal of the pattern that would define the engagement.
The Pivot
It became clear quickly that an edict would not work. You can mandate that a developer uses a tool. You cannot mandate that they engage with it. Telling a sceptical engineer to use AI tooling because the CIO has asked them to is a recipe for technically compliant disengagement; the tool will sit unused after the obligatory first day, the developer will continue working the way they always have, and the impact on delivery will be precisely zero.
The Head of Automation and I had already started a different intervention in parallel: a weekly innovation session, open to the entire business, running on a request-based slot system. Anyone could request twenty to thirty minutes to demonstrate something they had built, prompted, or experimented with. The sessions were not engineering-only; they were not even technical-only. Anyone in the business could come, demo, or watch. They were optional. We did not track attendance, and we did not pressure people to come.
This was the open-door flywheel. It worked, but it worked unevenly. The non-engineering parts of the business arrived for the first session and almost never stopped showing up. Operations colleagues began sharing prompts they were using to draft customer responses. Finance shared workflows they had automated for reporting. Sales operations showed how they had turned an unwieldy spreadsheet manipulation into a half-page prompt. Engineering attendance, by contrast, was sparser and slower. Some senior developers came regularly; others, by my best recollection, never came at all.
That second group needed a different intervention. An open-door programme works on the people who choose to walk through the open door. A sceptical engineer who has decided the door leads somewhere they do not want to be does not walk through it on their own. They need a colleague, a real piece of work, and a context in which the choice to engage feels professional rather than political.
That is what the next phase of the engagement was designed to deliver. The Head of Automation continued running the weekly innovation sessions. I picked the engineering champion track. And the channel I used for the engineering champion track was a concrete client project that needed building anyway, paired with the team’s strongest AI sceptic.
The Proving Ground
The proving ground was a two-person integration build for one of Ligentia’s own clients. Categorically, it was a real-time logistics event feed: a service that captured Ligentia’s own shipment events and published them to the client as soon as the events became available. Some logistics companies offer their clients a delayed feed they can subscribe to; this was designed to be the opposite, delivering bleeding-edge news on the client’s shipments at the speed Ligentia themselves had the information. The technical stack was Microsoft Azure, .NET 10, and Azure Service Bus. There was no user interface to build; the system was purely event-driven and ran as a set of services in Azure.
The integration was, on paper, a fairly standard piece of work. In practice it had one specific challenge that would have made it a difficult build under any tooling regime: the shape, the types, and the frequency of the events on Ligentia’s side were in flux for a long time. New event categories appeared mid-engagement as Ligentia’s own internal systems revealed what they could surface. Existing event shapes shifted. Frequencies that had been characterised as “daily” turned out to mean “daily during business hours in the originating region, except for these other ones, which arrive on a different cadence entirely.” That kind of moving target usually translates into a stretched timeline and a long tail of rework. The original scope was three months.
The application was effectively built in one month. I want to be specific about what “effectively built” means here, because the phrase does a lot of work in summaries of consulting engagements and rarely earns it. By the end of the first month we had a working Continuous Integration / Continuous Deployment (CI/CD) pipeline, a working development instance, a working deployment pipeline running into a first shape of the production environment, the data model in place, and OpenTelemetry (OTeL) integration providing the observability the team would need to debug the moving-target events as they arrived. We had real, end-to-end production scaffolding. The remaining engagement time on this project was not spent building the architecture; it was spent extending the application’s behaviour as the partner’s event surface revealed itself.
The reason the architecture absorbed change so well was the choice to make it data-driven. New event types were not new code; they were entries in a JSON configuration file. Once the shape of a new event had been ratified with the partner, the integration would handle it within seconds of the configuration being updated. This is the same architectural instinct I applied on the Bossie Hurley reporting platform earlier this year. The domain is different; the pattern is identical. Move the parts of the system that change most often out of compiled code and into evaluated configuration. Reduce the surface area where the compiler can catch you, knowing that you will pay that back in flexibility.
ℹ️ Note
The data-driven configuration pattern carries across domains. When the parts of a system that change most are operational and business-shaped rather than algorithmic, moving them out of code and into evaluated configuration earns you back the time the compiler used to save.
The other reason the architecture absorbed change so well was the pairing. I built this integration with the development team’s strongest AI sceptic. That was a deliberate engagement-design choice rather than an accident of scheduling. The weekly innovation sessions were not reaching this person; to my recollection they did not attend many of them, if any. The open-door flywheel works on those who walk through the door, and we needed a different channel for those who would not. A real client project, with a real deadline, paired with a consultant they could observe up close, was that channel.
What they observed up close was the workflow. They watched the prompts I used. They watched the iterations I went through with the tool. They watched the moments where I caught and corrected the tool, and the moments where the tool caught me. By the end of the first month, the same person who had told me that AI tooling “produces crap” was using it themselves on the parts of the integration they were leading.
The Flywheel Pays Off
Outside the two-person integration project, the weekly innovation sessions had been quietly compounding for months. By the time the proving-ground work was substantially complete, the shape of the sessions had evolved. The opening slots had been short, modest, low-stakes demonstrations: “I used this prompt to do this work.” A few months in, the sessions started featuring longer, more ambitious demonstrations: “I have built an entire application that uses Claude to perform this task.” That progression, from prompt to product, was the engagement’s most reliable internal signal. It told me that the people running the sessions were no longer treating AI tooling as a curiosity; they were treating it as something they could compose with.
Almost all of those longer demonstrations came from non-engineering parts of the business. Operations, finance, sales operations: the people who had walked through the open door from the first week kept walking through it, kept building, and kept showing up to demo their work. Engineering attendance climbed slowly throughout this period. The reason it climbed was uncomfortable for the engineering team to articulate, but it was clear from the conversations I had one-to-one with senior developers around that time. The developers were watching their non-developer colleagues compose AI tooling into the rhythm of their everyday work, and they were starting to realise that other parts of the business had pulled ahead of them on this particular dimension. Not in technical depth; in productive intuition.
Around the same period, CVE-2025-55315 broke. The Common Vulnerabilities and Exposures (CVE) identifier described a serious vulnerability in older versions of .NET affecting any ASP.NET application that handled HTTP/1 chunked requests, with the most dangerous shape being applications acting as reverse proxies in front of another service. Microsoft rated it 9.9. Ligentia’s stack was running some out-of-support versions of .NET that needed to come current. The engineering team had cautioned, fairly, that the upgrades would be non-trivial and time-consuming because of customisations they had built up over the years. I disagreed but did not push hard on the timeline, because we had to do the upgrade either way. The upgrades shipped within a single sprint. Whether the developers used Claude Code to accelerate the work, I cannot say for certain; the timing suggests that either they substantially overestimated the difficulty in their original characterisation, or they reached for the tooling they had previously argued against. I have my suspicions. I covered the CVE itself in a separate blog post and discussed it with Hayden Barnes on The Modern .NET Show shortly afterwards, for readers who want the technical detail.
By the closing months of the engagement the dynamic inside engineering had inverted. Developers who had patiently explained their four objections to me earlier in the engagement were now daily-driving Claude Code on real work. Some had moved on from that into more specialised territory: a handful were experimenting with GitHub SpecKit; one developer had begun fine-tuning small language models on internal data. (That developer subsequently handed in their notice and moved on to the next stage of their career, but the model work itself was, while it lasted, a useful signal of how far the team’s relationship with the tooling had come.) The innovation sessions kept running, the demonstrations kept getting more ambitious, and the engagement’s energy had shifted from convincing engineers to compounding their gains.
The Outcome
By the time the engagement closed, the team’s feature delivery had improved by 75%. The metric was not vanity. Ligentia’s engineering organisation runs DORA measurements on custom dashboards that feed directly into their reporting calls with project owners. We had a defensible baseline from before the engagement began, the same measurement methodology running throughout, and a clean before-and-after that we could point at without caveats.
The team had to redesign their release cadence as a consequence. They were generating pull requests faster than the existing reviewer rotation could clear them; the bottleneck of the system had shifted from “how quickly can we write code” to “how quickly can we review it.” That is the kind of bottleneck shift you want to have. It tells you the previous bottleneck has been resolved.
To address the new one, we scoped a pull request (PR) review pipeline that used Claude Code’s built-in /code-review command as a first-pass reviewer before human reviewers were added. The pipeline shipped just as my engagement ended. Their source control platform supports a YAML pipeline syntax compatible with the GitHub Actions ecosystem, which made the integration straightforward. The intent was not to replace human review; it was to take the rote part of review off the humans’ plates so that they could spend their attention on coding standards, process, and domain knowledge. Early indications, at handover, were that this was beginning to work.
The wider rollout was the most striking outcome and the one I had expected the least. Once the pilot proved Claude Code’s value to engineering, Ligentia onboarded the rest of the business onto Claude and Claude Code in only a few days. The flywheel of the weekly innovation sessions had already done most of the cultural work. The rollout was, by that point, a procurement and provisioning exercise rather than a change-management one. Today, most of the globally distributed company daily-drive Claude or Claude Code as part of their normal workflow. That outcome was nowhere in the original scope document.
The shape of the engagement had moved a long way from the brief Boris had signed off on twelve months earlier. We had begun by trying to give a sceptical engineering team the conditions to ship higher-quality features faster. We had ended with a company-wide programme of AI fluency, an engineering team that was daily-driving the tooling they had originally rejected, and a 75% delivery improvement that the team owned and could defend through their own dashboards.
Boris summarised the engagement very kindly toward the end:
Within a week of him working with us, he had already identified five different areas for improvement, given two inspiring talks, and created a handful of engaging demos, all leading to almost immediate ROI.
I will take any compliment about Return On Investment (ROI) from a CIO who measures it for a living.
What Other Engineering Leaders Can Take From This
The repeatable pattern, if you are sitting where Boris was sitting twelve months ago, is the pilot that becomes the programme. Start small, with a deliberately reversible pilot. Choose a real piece of client work as the proving ground rather than a sandbox prototype. Pair your champion track with your most respected sceptic. Run an open-door flywheel for the rest of the business in parallel, because the engineering team is rarely the part of the organisation that adopts AI first, and the rest of the business will give the engineering team a useful reason to catch up. Measure the things that already matter to you, using the dashboards you already trust. Do not introduce vanity metrics for the AI rollout; if your existing measurements are good enough to inform engineering decisions, they are good enough to evaluate an AI engagement.
I wrote about the higher-altitude argument for this kind of approach in Stop Chasing the AI Moonshot: The Case for Small, Deliberate Wins. The Ligentia engagement is the longer story behind the shorter argument in that post. Both are, in the end, the same observation: the company that quietly improves the way it works will out-deliver the company that bets everything on a single transformative programme.
If you are thinking about running a programme of this shape inside your own organisation; evaluating tooling, designing the pilot, picking the champion, or simply working out where to start; you can book a consultation and we can talk through it.