This one happens before the fixed-price story I've told elsewhere on this site — it's actually this programme that built the trust and the shared toolchain between AP Advisory and EnergIQ, the same trust we later drew on to rebuild a fixed-price bid from scratch a few months on. Most AI-adoption stories get told from the vendor's side: a platform, a rollout, a usage dashboard. This one is told from inside a large IT engagement, where AP Advisory ran a joint generative-AI industrialisation programme with EnergIQ, across several application-maintenance teams — the same TMA teams who would later carry the functional knowledge of the Atlas platform. The programme moved from a controlled experiment to an enterprise-wide adoption mandate — and, along the way, became the proving ground for an in-house "AI factory."

The programme started as a productivity experiment. It became a governance model — and it was the governance model that made the productivity credible.

1. A joint programme, not a tool rollout

The initiative was framed from day one as a programme co-led by EnergIQ and AP Advisory, not a licence deployment. A four-phase roadmap paced the work: a four-week kickoff to align stakeholders, sponsors and the technology framework; a two-week planning phase to identify pilot teams and stand up governance; two to three months running proofs of concept on live workstreams; then a four-month scale-up phase covering licensing, infrastructure and change management. EnergIQ's own generative AI platform was chosen as the programme's single platform, with code-assistance tools and LLMs — including Gemini Code Assist and, on certain workstreams, Claude — layered in for specific use cases.

Four workstreams carried the pilot, each given its own name to anchor the programme's internal vocabulary: AI4DOC (documentation), AI4CODE (augmented development), AI4OPERATIONS (operations and support) and AI4TEST (testing).

AI4DOC — DocumentationAutomated generation of technical and functional documentation, back-documentation of existing code, structured knowledge transfer.
AI4CODE — Augmented developmentCode generation and refactoring across open-source and legacy stacks, with human review at every step.
AI4OPERATIONS — OperationsAutomated ticket analysis, request summarisation and translation, resolution-procedure drafting for L1–L3 support.
AI4TEST — TestingTest-case generation across the existing estate, automated execution of functional and non-regression tests.

2. A four-level maturity model, built to sequence — not to sell

Rather than presenting AI adoption as a binary switch, the programme used a four-level maturity model to place each team and set realistic expectations: conversational generation and one-off prompting; "vibe coding," where functional prompting accelerates prototyping but stays risky on code meant to last; agentic AI, where chains of agents work from shared reference documents; and "team AI," where AI connects across functions and feeds CI/CD pipelines. At the point of the pilot review, most teams sat between the first two levels — a deliberately modest, factual reading rather than a headline number. I make this same point at every steering committee where I present a model like this one: an honest maturity model protects a programme's credibility far more than an optimistic productivity figure does.

3. What the pilots actually showed

Across four application-maintenance teams, estimated gains ranged from 10% to 30% depending on the type of activity, with a weighted average of around 20%. That spread mattered more than the average: documentation and back-documentation showed the cleanest gains, augmented development showed real but uneven gains depending on language and framework, and some legacy or highly specific technical contexts resisted assistance from the current generation of tools. That case-by-case granularity — not team-by-team — became the basis for every scale-up decision that followed.

4. The pivot: when productivity became a commercial conversation

Pilot results don't stay internal for long. As soon as EnergIQ had visibility into the productivity gains the experimentation phase was producing, the client translated that expectation directly into commercial terms: a 10% reduction on run-mode billing, effective from an agreed date, betting that AI-driven productivity would absorb the gap. That's a natural — and, in my experience, increasingly common — next step in any AI-adoption journey once pilots move from "interesting" to "credible": clients ask for the value to flow back to them.

AP Advisory responded by turning what had been a set of pilot workstreams into an enterprise-wide adoption programme, extending the same tools, training and governance model to every team on the account — not only the ones that had run the initial pilots — with the explicit goal of meeting, or exceeding, the productivity ask through broader, measured adoption rather than headcount reduction alone.

5. Governance discipline: separating "declared adoption" from "measured value"

The programme's most consequential design choice wasn't technical, it was procedural: adoption and value were tracked as two separate metrics. Adoption was a monthly, self-declared number, broken down by activity type and manager — a leading indicator of behaviour change. Value was a factual, backward-looking comparison of actuals against a frozen economic baseline: revenue, cost, margin and headcount, tracked by team, with productivity gains only recognised once realised — not forecast — figures were logged against that baseline. Across the teams following this cadence, declared adoption reached roughly half of the tracked headcount, on a base of over a hundred people and close to €1M in monthly reference revenue — but the programme's own reporting was explicit that no productivity gain could be banked until realised data caught up with the forecast.

That discipline was carried by a formal three-tier governance structure — what the programme's own steering documents called its "comitology": a monthly steering committee bringing together sponsors and delivery leadership, a weekly operating committee for coordination and portfolio decisions, and an execution hub running the workstreams day to day. A Design Authority sat above the individual pilots and, later, above the agentic AI initiative described below, reviewing scope, architecture and Go/No-Go decisions on a fixed cadence rather than leaving them to each team's discretion.

6. Building the case for an in-house AI factory: an agentic pilot

Alongside the main industrialisation programme, AP Advisory ran an agentic AI experiment on modernising a legacy application — a system built on an end-of-support technical stack that could no longer be maintained safely. Rather than a classical rewrite, the team structured the work around a pipeline of specialised agents — discovery, architecture, analysis, development, quality, documentation, performance and change-management agents — each responsible for one step of an analyse–design–build–validate–deploy sequence, with human review and Design Authority sign-off built into every step rather than pushed to a final acceptance gate.

The result: a minimal team delivered 86 prioritised features across four three-week sprints — roughly twelve weeks from kickoff to a production-ready scope — with weekly demos and a formal Go/No-Go review closing each sprint. The pilot's goal wasn't only to deliver the application faster; it was to produce a first defensible proof point on the feasibility, at scale, of an in-house "AI factory" — a durable, agent-assisted delivery capability — rather than a demo-day ambition.

The spec-driven agentic development approach used on this modernisation carries its own productivity estimate, tracked separately from the main industrialisation programme: an expected gain on the order of 40% (estimated, pending completion) on development effort itself — well above the 10–30% range observed on the documentation, code-assistance and testing workstreams, and a strong signal on the potential of agentic delivery once specifications, architecture and human validation gates are designed in from the start. It's this same agent pipeline, refined on this pilot, that we later reused to re-price the Atlas migration.

What a leader can take from this

Three lessons reach well beyond this one programme. First, sequence adoption with a maturity model before promising gains — it protects credibility with both the client and the delivery teams. Second, separate declared adoption from measured value from day one, and govern that separation formally; that's what turns an AI programme from a communications exercise into a defensible operating decision. Third, treat agentic AI pilots as conviction-building exercises with their own governance, rather than as a shortcut to a scale-up decision already made — the modernisation pattern above is a template for building that proof responsibly, sprint by sprint, with human validation at every gate. I teach a simplified version of this governance model to my executive-MBA students, and it's consistently the point that surprises them most: the hard part of AI adoption is almost never the technology.

Alin Popovici
About the author

Alin Popovici

Executive advisor, transformation and delivery leader, currently leading AI-adoption and right-shoring initiatives across a €60M+ delivery portfolio — and a guest lecturer on complex-programme leadership for the Executive MBA at Bucharest Business School (ASE Bucharest, in partnership with CNAM Paris).

← Back to Insights Discuss this topic →