Agentic Development Enablement

Two quarters, 400+ engineers, and a little over $500K of tooling took R&D from no AI-assisted output at all to more than two million lines of agent-produced material.

The problem

AI adoption across R&D was fragmented. A few teams had dabbled with one-shot prompting. Most had never touched an agent. There was no shared platform, no training infrastructure, and no standard for how an engineer should work with AI. Leadership had no way to tell which experiments were real. Every team that tried anyway paid the same onboarding cost in parallel.

The approach

The program ran procurement first and training second: tools in hands before theory on slides. A long shortlist of coding assistants and agent platforms narrowed to two selections, the Cognition platform (Devin Desktop, Devin CLI, Devin Cloud, Devin Review, Devin Automation, and DeepWiki) and Claude Code. Everything else failed our enterprise-readiness checks, and the ones that passed stopped at autocomplete when we needed something that could run a task end to end.

Each procurement started with a proof-of-concept period. A small group evaluated the tool, worked out the practices worth keeping, and then became the mentors who trained everyone else. Sending early adopters out with real credibility and real context is what brought the skeptics along.

Training ran in every format engineers actually learned in: office hours, formal sessions, innovation-hour showcases, hands-on labs, and vendor-led workshops with the tool creators themselves. Smaller working groups and async cohorts picked up the long tail. Written documentation held the reference backbone.

Three audiences needed three different approaches. Skeptics were cautious for good reason, since plenty of AI products oversell, so the work with them was finding the specific spot in their day where an agent genuinely helped. Senior engineers who were sure manual work was faster went into the PoC group, where they could measure it. Over-eager junior engineers got structured training in prompt and context engineering, which moved their attention off the prompt string and onto the context they hand the agent, and off raw output and onto outcomes delivered in small verified steps.

Alongside training, the program built the internal ai-resources catalog of reusable agents, skills, rules, and workflows, and pushed a contribution culture where a shared agent could help teams across the organization. Each entry carried metadata that made it discoverable, composable, and safe for another squad to invoke:

# A skill from the internal ai-resources catalog, callable by any squad's agent.
name: compliance-scan
description: Triage product-compliance findings in a PR diff.
owner: architecture-services
tools: [read, grep, bash]
loop: observe-plan-verify

Reliability here meant one thing: the workflow repeats. The program adopted a universal problem-solving loop as its foundational algorithm, Observe, Think, Plan, Build, Execute, Verify, Learn. The loop keeps state and context consistent, forces a verification step before anything is called done, and stops a hallucination from compounding into the next stage. A workflow clears the bar when the loop runs end to end, repeatedly, measurably, and without error.

The outcome

Over two quarters the program trained 400+ engineers across 50 teams and deployed over $500K in AI tooling. The organization went from zero AI-assisted output to more than two million lines of agent-produced material across software development, documentation, data analytics, and other use cases. On individual contributor workflows that worked out to a 10× multiplier.

One team was responsible for building governance guardrails across agentic integrations, and the program bootstrapped it with the same tools it was governing. Within months it was running agents end to end to ship the controls protecting data in source systems: research, analysis, planning, development, testing, verification, and delivery. That meta-loop turned out to be the clearest evidence the program had.

I went in assuming engineers wanted AI to replace their work. What they asked for was relief from the mundane, the repetitive tasks that drained capacity without engaging judgment. Once AI absorbed drafting, note-taking, and boilerplate, engineers spent the recovered hours on data-driven decisions, creative problem-solving, and the innovative work that volume had squeezed out. The output volume was the number leadership asked about. The hours it handed back were the number that changed how the teams worked.

What I’d change

Context engineering training should have come before tool distribution. Teaching engineers to structure a workflow scientifically, set guardrails for the agent, and aim at a testable outcome would have raised adoption quality from the first week. Without that foundation, early usage defaulted to unstructured prompting, and the program spent time correcting habits that training up front would have prevented.