From Access to Output
How a global vehicle remarketing team built production-ready AI workflows in five weeks
Global Vehicle Remarketing Platform · 5 weeks
Enterprise AI coding tool adoption doubled between 2023 and 2025. The bottleneck is no longer access. It's the gap between having a tool and knowing how to use it against real work, in real codebases, with real teammates watching.
The Situation: Deep Expertise, Shallow Tooling
A global vehicle remarketing platform, the company's engineering organization spans multiple domains: title procurement, buyer and seller workflows, B2B integrations, imaging and mobility solutions, and international auction platforms. Team tenures average 10 to 15 years. Domain knowledge runs deep, but it lives almost entirely in people's heads.
The organization had acquired GitHub Copilot licenses roughly three to four months before this engagement. Individual developers were using it mostly for documentation, small fixes, and unit test generation. One manager had already cut his annual performance review process from seven days to one day using Copilot and Claude. A few engineers were experimenting with MCP servers and CLI workflows on their own. On paper, the team was AI-enabled.
In practice, adoption was thin and uneven. There was no shared prompting methodology, no instruction file standards, no documented patterns for working with AI in the context of their own codebases. Each person had developed their own habits in isolation. The tools were licensed and installed. The capability to use them well had not yet been built.
The Trigger: Licensed but Not Equipped
When the engagement opened, nine engineers and managers joined the first group session. The instructor asked a direct question: what issues have you run into using AI? The responses surfaced something that Copilot licenses alone could not fix.
"There are a couple of legacy applications which are very old. Whenever Copilot suggested something, we were trying to fix it. But that had a lot of changes in other places too. We were just trying to focus on where the defect is, because in those legacy applications there are a lot of things to test."
— The team's longest-running Copilot user
"Each and every one of them are having their own way of creating the prompts. One team member having the prompts in his style and another team member having the prompts in her style. I see a space: how to efficiently use the skills, prompts, and other things."
— Engineering manager describing adoption before the engagement
The adoption spectrum across the cohort ran from engineers actively experimenting with MCP servers and agent workflows to others who had written a handful of basic prompts and stopped there. Tool proficiency scores for the nine participants averaged below 2.5 out of 5. No one had a repeatable workflow. No one was sharing what was working.
The Barrier: Three Obstacles No License Could Solve
- Infrastructure Friction
Developer machines were running out of memory when running local agent processes alongside existing dev servers. The team's standard IDE supported only two of four Copilot modes. VPN policies were blocking connections to Anthropic's servers. Monthly token limits on the Copilot Business tier were being hit mid-month. These were not hypothetical friction points. They came up in the first group session. - Siloed Knowledge, No Shared Practice
Nine participants worked across seven distinct application domains with no shared codebases. There were no shared prompt libraries, no instruction file templates, no standards for feeding AI context about the company's own systems. Months of individual Copilot experience had never been pooled. Every person had developed their own approach in isolation."Each and every one of them are having their own way of creating the prompts... I see a space."
- Identity Resistance to Automation
Not every barrier was technical. One engineering manager, a longtime hands-on developer turned people leader, described coding as a craft done with hands and mind together. AI producing code from a prompt felt like giving that craft away. He chose to join the engagement over a planned family trip specifically to work through it. His evaluation noted an identity-level attachment to manual creation, not just professional preference.
The Solution: Structured Sessions. Real Codebases. Measurable Progress.
The Supervised Slingshot is built around one principle: growth happens when people apply new tools to real work, under real pressure, with someone watching. The five-week engagement ran 25 group sessions and 44 individual 1:1s, structured to move each participant from observer to producer.
Every session was anchored to the participant's actual backlog. No synthetic prompts or sandbox exercises. Engineers worked inside their own codebases on their own open tickets. Managers applied AI to their real reports, review cycles, and documentation debt. The question each session was not 'can you do this in theory?' but 'what did you ship since last time?'
Each week combined a shared group session with individual 1:1 time. Group sessions surfaced what was working, created peer pressure to have something to show, and generated the demo moments that shifted team sentiment. Individual sessions gave each participant space to work through their specific technical context, blockers, and skill level.
Participants were not just learning to use AI tools. They were building skills, instruction files, and automated workflows that would outlast the engagement. By week five, the team had a shared repository with contributed skills, a peer review process for new automation, and multiple participants running independent work between sessions without prompting.
Measuring What Changed
Progress was tracked weekly across six dimensions: engagement, comprehension, tool proficiency, initiative, collaboration, and adaptability. Evaluations were based on observed behavior during sessions and independently reported work between them, not self-assessment. Scores were calibrated weekly. The team moved from an average of 3.08 in week one to 3.91 at close.
The Results: Individual Transformation
The Skeptic Who Did the Math
An engineering manager overseeing 15 engineers arrived framing every AI use case for his teams, not himself. Through three sessions he had zero personal tool usage. By week five he had built a skill that drove measurable results on an internal automation project and walked into a leadership debate with numbers in hand.
"There is a discussion whether we need to go to the BMAD approach or the Code Captain approach."
"I'm pushing and I already have the numbers to prove it. I can be a spokesperson if needed, to demonstrate on the numbers perspective."
From Zero to Champion
One senior engineer entered week one with no hands-on AI experience and a passive listening pattern that worried early evaluators. By week two he had independently stood up a Docker MCP server and completed an accessibility research cycle ending in a formal manager recommendation. In the final week he shipped two skills on personal time and was named one of three Champions.
"The initial mindset was how I can utilize this for work. But slowly, by the end of the sessions, I was thinking: how can I utilize this for my daily life too, not only professionally but personally."
The Quiet One Who Ran 56 Stories in Minutes
One engineer had the lowest starting score in the cohort and attended sessions at 2 AM from a remote time zone rather than miss them. She hesitated for weeks to run an execute-epic on a live backlog because the scope felt too large. In her final session, 56 stories became 18, and 18 became done in minutes.
"It was really, really quick. Those 18 stories were finished within minutes. I was so glad I tried that."
The Builder Who Ran Five Agents at Once
One senior engineer worked on a separate application from the rest of the cohort, which limited peer collaboration throughout. He used that isolation as fuel: running parallel Claude agents against multiple controllers simultaneously and migrating a separate application to .NET 10 with Copilot, producing the cohort's highest tool proficiency score by the final session.
"I didn't choose to minimize the usage. I just went all in."
The Manager Who Finally Multiplied
One engineering manager with 12 direct reports had already cut his annual review cycle from seven days to one. Evaluators flagged the same gap three sessions running: he understood the tools and was not passing them to his team. His final session: 20 transcripts downloaded, an Obsidian curriculum built for his reports, and a skip-level meeting with his VP to extend the program.
"Now it's our responsibility. Giving it to others is the most important thing."
Before and After
| Dimension | Before | After |
|---|---|---|
| AI Workflow | Copilot autocomplete for isolated tasks. No shared patterns or instruction files. | Skills, hooks, and agents running against real production stories, epics, and migrations. |
| Tool Proficiency | 2.76 team average. Three participants had never triggered a live prompt in their own codebase. | 3.86 team average. Three participants shipped production utilities. Multiple participants ran independent work between sessions without prompting. |
| Collaboration | 2.46 team average. Individual exploration only. No peer sharing, no team demos, no skill reuse across the cohort. | 3.59 team average. Cross-team skill sessions, Champion designations, peer-reviewed repositories, and internal advocates. |
| Initiative | 3.23 team average. Self-directed learners, but learning stayed personal and untethered from work output. | 4.12 team average. Between-session independent work led to peer-reviewed skills and VP-level curriculum proposals. |
| Comprehension | 3.04 team average. Could restate tool features but rarely connected concepts to their own work architecture. | 4.01 team average. Team members mapped skills to Jira epics, traced agent failures back to skill language, and connected tool costs to product strategy. |
Team-Wide Impact
The dimensions that improved most were not the ones the team expected. Comprehension scores were already reasonable at baseline. The biggest gains came in collaboration and tool proficiency, the two dimensions that most directly reflect whether people are using AI alongside their teammates, not just alone. That is the pattern that tends to stick.
Institutional Impact
One participant built a .NET migration planner skill that reduces a full repository migration from hours of manual dependency resolution to minutes. It passed peer review with engineers from a separate team and is now published in the shared Code Captain repository, available to the full engineering organization.
One manager built a six-session training curriculum from the engagement transcripts within hours of the final session, working in an Obsidian vault with AI-generated structure. He brought it to his VP before the engagement formally closed. His VP was already considering an extended coaching arrangement before the request was made.
By the final week, participants from the cohort and engineers from a separate team were meeting weekly in the office to share and trial each other's skills. Two managers committed to lead biweekly cross-pollination sessions. One participant scheduled a Code Captain demo for his remote team the day after the final group session.
Two participants independently sketched full production monitoring workflows during the engagement: one a skill chain that monitors logs, identifies the relevant commit and PR, drafts a fix, and opens a PR automatically; another a triage skill for open incidents breaching SLA. Both arrived unprompted from thinking against real operational problems.
The Lesson: AI Is an Amplifier, Not a Replacement
The dominant fear entering any AI training program is the same: the tool will replace the person. That fear shapes how people approach the first sessions. They are cautious with what they share, skeptical of what gets generated, and slow to apply what they learn to real work. The organizations that invest in structured training do so precisely because that fear, left unaddressed, produces exactly the outcome everyone wants to avoid: surface-level adoption, low retention, and tools that sit installed but unused six months later.
This cohort came in with that full range. One senior developer had built a personal SQL chatbot before the first session and sketched an agent-based monitoring platform he had not yet started. Another said he fell in love with hands-on work and was not sure AI belonged in it. A third attended her first session at 2 AM from India rather than miss it. Five weeks later, the first developer had a peer-reviewed migration skill in the team repository. The second had scheduled a Code Captain demo for his remote team. The 2 AM attendee had run a 56-story production epic in minutes. The common thread was not the tool. It was the decision to stop observing and start shipping.
The data shows comprehension is not the bottleneck. Comprehension improved 32% across the cohort, but collaboration improved 46% and tool proficiency improved 40%. The team did not need more explanation. It needed more repetitions against real work, with people watching. The participants who moved fastest were not the ones who understood the concepts earliest. They were the ones who applied the concepts to something that mattered to them before the next session, showed it to someone, and iterated.
"Everybody will have to shift from writing the code themselves to improving the agents or skills which are writing code for them now."— Staff Software Engineer
That is not a developer who learned a new tool. That is a developer who learned a new way to work.
Let's build AI fluency into your team.
The Supervised Slingshot is purpose-built for engineering teams that have AI tools and need to actually use them. Five weeks. Real work. Measurable results.
Book a Strategy SessionFree. Real assessment. Results you can project from day one.