Case Studies/AI Enablement
An energy technology scale-up·AI Enablement

The AI habit that stayed after we left.

A scaling energy company had engineers reaching for AI daily, with no way to tell if any of it was working. We made it measurable, and the numbers moved in every direction.

from 17%
67%
highly confident with AI
nearly a 4× rise
from 50%
100%
using AI daily
half the team to all of it
from 83%
100%
would recommend AI
every respondent
 
3
teams aligned
Engineering, QA, Product
The context

A rapidly scaling energy technology company runs a large ERP platform that its customers depend on daily. Inside engineering, AI was already in the building: some teams fluent with it, others barely past setup.

Leadership wanted to turn that scattered experimentation into a durable, measurable capability. The hard constraint: do it without rewriting the ERP underneath, by making the existing environment and practices work with the tools rather than around them.

What was breaking

The usage was real but uneven. A pulse survey put high confidence at just 17%, and AI use ranged from daily for some engineers to occasional for others. Capability concentrated in a few teams does not lift an organization.

The environment itself fought the tools. Inconsistent style, tests wired to live databases, oversized files that overran the model's context, and high-friction components all made AI assistance slower and less safe than it should have been.

No shared practice held it together. Prompts, workflows, and conventions lived in individual heads. Without a common foundation, AI-generated code drifts from hand-written code, and whatever one engineer figures out never reaches the next.

0%

of engineers highly confident with AI, up from just 17%.

How we moved

The team measured before and after with a pulse survey, then built the infrastructure the practice needed: MCP integrations for Azure DevOps, GitHub, and New Relic; Claude Code configured across active engineers; a shared library of slash commands for QA-field generation, issue logging, and capturing what worked; and an AI-assisted pull-request review pipeline wired into the standard DevOps flow. A custom context-priming command pulled the full context of each work item, attachments and dependencies included, into the model so its output started from real ground.

Rather than touch the ERP, the team aligned the environment around it. Linting moved into CI. Tests gained isolation through mocks and service abstractions. Dependency injection and smaller files cut the context rot that quietly degrades AI output.

To make any of it last, This Dot stood up an Agentic AI Community of Practice led by the company's own strongest adopters, the mechanism that keeps standards, prompts, and shared learning alive after the consultants leave.

0%

of the team using AI daily, up from half before the program.

Before vs. after enablement
67%
Highly confident with AI
from 17%
+50 pts
100%
Using AI tools daily
from 50%
+50 pts
33%
Rate AI "very effective"
from 17%
+16 pts
100%
Would recommend AI adoption
from 83%
+17 pts
Pulse survey, before and after.
0

teams aligned on one practice: Engineering, QA, and Product.

What changed

The follow-up survey moved in every direction that matters. Engineers reporting high confidence with AI rose from 17% to 67%, a 4× jump, while neutrality dropped to zero. Daily use went from half the team to all of it. The share rating AI "very effective" doubled, and every respondent now said they would recommend adopting it.

Individual wins showed the range. One engineer was productive on Claude Code the same day an access blocker was cleared. A product manager wired Copilot into Azure DevOps for backlog and story work. QA automated repetitive test scaffolding, and an engineer turned raw work items into structured development plans straight from schema context.

The practice now runs on its own rails: a cross-functional Community of Practice is live, a shared prompt and slash-command library exists, and an internal Agentic AI Playbook is taking shape, led by the team, not by us.

Why it matters

Adoption that depends on a vendor staying in the room is not adoption. The real work was making the team able to keep going on its own: shared tooling, an environment that fits the tools, and a community to maintain both.

Working through something similar? Let's talk.

Start a conversation