How We Actually Trained 300 Engineers to Be AI-Native

Licenses Don’t Build Muscle Memory

You can’t just throw AI tools at engineers and expect them to get value. We learned this firsthand.

We’d already been using Cursor across engineering and seeing real productivity gains from it. But when I started using Claude Code in December, the difference was immediate; it felt like a genuine step function and not just an incremental improvement. I set up a trial with a small group of AI-curious engineers and the feedback confirmed what I felt: this was an inflection point. The leap in capability was so significant that licenses and a training session wouldn’t be enough. Effective AI-assisted development at this level is a genuine skill, one that requires structured practice.

Before You Train Everyone, Train Someone

Before we trained the whole org, we had to train the trainers.

One of the first things we did was form our AI Champions group, engineers across teams who’d go through the curriculum first, then serve as mentors when we scaled. We selected people based on their enthusiasm as well as their technical skill. We also deliberately included skeptics, because a group of pure believers would have been an echo chamber.

The early weeks were uncomfortable. I remember sitting in our first Champions meeting thinking: What’s our mandate? We didn’t have a lesson plan yet, didn’t have a clear role, and the org-wide training was still being planned. The Champions’ purpose only crystallized once the training program itself took shape and we realized we needed more than just lecturers. We needed embedded agents of change within the teams.

But they had to earn that title the hard way. They were the first ones through the program, stress-testing early drafts, identifying gaps, figuring out what confused people, all before anyone else saw it. During the first cohort, they shadowed every session, watching what landed and what needed to change. By the time Cohorts 2 and 3 rolled around, they weren’t just AI-fluent engineers anymore; they were mentors, leading their own teams through the same program that had shaped them weeks earlier. The skills the AI Champions picked up on and taught others were decomposing problems for an LLM, verifying the output, and how to refine a prompt to do the job perfectly on the first attempt. The tool was the vehicle. The fluency was theirs.

Hitting the Ground Running

We taught the curriculum using Claude Code, but our goal was always that the fundamentals of agentic coding would be what carried over. The syllabus was a five-session progression:

Agentic Coding 101 — We demoed Claude Code with nothing extra: no plugins, no skills, no sub-agents. Just the bare tool and a real task, building an API using a simple plan-implement-review workflow. The macro-level flow was the lesson, but we kept stopping to zoom in on the agentic fundamentals: context window management, task decomposition, and grounding the plan in facts to reduce hallucination.
Deterministic Guardrails — Before we went too far, we had to instill the boundaries of what LLMs are good at, and what humans should keep doing. This provided a framework for when deterministic tooling like scripts should be used instead of the LLM. The more important takeaway from this was a proper security posture and mindset for the org.
Making It Yours — The first two sessions taught us how to work with AI. This one taught us how to reshape it. We learned to encode complex workflows into skills and wire hooks into our development process so the tooling enforced habits we wanted. The warmup exercise was writing a “tell me a joke” skill; the room filled with groans at what everyone’s Claude came up with. But the point landed quietly: if you could teach it to tell a joke, you could teach it anything. This was the session where the tool stopped feeling borrowed and started feeling like ours.
The Full Orchestra — We went back to the demo from the first session and rebuilt it using everything we had learned. Sub-agents handled brainstorming, implementation, and review in parallel, each with its own clean context. Verification loops caught errors before we ever saw them. By that afternoon, people were already adapting the workflow for their own codebases, reshaping it with the skills and hooks they had built the session before. The “AI as junior developer” metaphor quietly died, replaced by something closer to the truth: AI as a coordinated team you can architect.
The Moonshot — This was a hands-on workshop targeting an advanced technique that we did not expect everyone to pick up. The premise was a future where the model has all the context it needs without us providing it manually. The first concrete step toward that was one-shot development, giving the LLM everything in a single prompt and letting it run the full cycle from brainstorm through verification. One of our co-founders captured where this was all heading: “Skills are the new algorithms. The chat loop is the new technical debt.”

But here is what we did not anticipate: the syllabus was the easy part. We were asking people to rewire years of ingrained habits, and no single session could do that. Lessons did not land the first time — or the second. We taught the same concept differently each time, trusting that repetition was not failure but the actual shape of learning.

Building Habits

Every morning, each team gathered with their assigned AI Champion for thirty minutes with one rule: no talking about your actual sprint. Only agentic coding related questions, blockers, and lessons were allowed. The questions we got were real because they were working on their normal sprint work; the key was setting the tone and expectation that whether or not the work was done was not important. We wanted to use the work as a vehicle to help people practice these agentic coding skills.

We expected awkward silence in these stand-ups. Instead, people leaned in. Someone would share a prompt that had produced something genuinely cool, and the room would light up — not politely, but with the specific energy of people realizing they were not the only ones finding this thrilling and terrifying at the same time. When someone hit a wall, the ask was simple: “Can you share your screen?” And then the whole team would crowd around it, guided by gentle nudges from the Champion in the right direction, trying different approaches until something worked.

One morning, an engineer showed something clever they had built, and the Champion asked: “Do you think that could be a skill?” They said yes — and what happened next was unscripted. The whole team started pitching prompt ideas, riffing on each other, building the skill live in the room. It was not a lesson or planned. The magic was a group of people who had been handed something unfamiliar and decided to figure it out together.

What made this work was psychological safety. Not the corporate abstraction. The real thing: sharing your screen when something was broken and watching your whole team lean in to fix it with you.

Show & Tell

No slides, no scripts. Just show what you built. This was the short and sweet mandate for our last day of training; this was demo day.

The range was staggering: an analytics agent that queried our data warehouse conversationally. A skill that caught flaky tests and autocorrected them. A system that predicted production failures before PR merge. A delivery engine that scaffolded entire features from epics.

One engineer journaled a massive codebase migration — timestamping each step, then building a dashboard showing actual time versus manual estimates. The speed-up made the room go quiet. Another discovered the tooling worked in Spanish, eliminating the overhead of translating thoughts into English before translating them into prompts — an accessibility dimension none of us had considered.

And yet the shift that mattered was a change in how people talked about their work. They stopped saying “my code was broken, AI helped me fix it.” They started saying “my code was broken, and here is how I taught AI to fix it.” One of our co-founders said it best: the most important thing we will be building is not the code. It is the environment where an AI can thrive.

But getting there was not clean.

Difficult lessons learned

We moved fast because we had to. That meant some engineers got polished content and others got early drafts. We went back and patched the gaps, but the unevenness was real, and pretending otherwise would not be honest. The speed was necessary. It also had costs, and we walked into some of them with our eyes open.

Uneven training. Because we built content during Cohort 1, not everyone received the same quality of instruction. We identified the gaps and circled back, but some participants had to relearn material that later cohorts got right the first time.
Transition gaps. We trained people on the new workflow but did not do enough to bridge from the old one. Engineers invested in existing tools deserved a clearer path: here is how you used to do this, and here is how you do it now. We skipped that step, and it created friction we could have avoided.
Roadmap friction. Slowing down normal work for weeks meant teams’ roadmaps took a hit. While we applied the AI upskilling to their normal work to set the tone that AI use is core to core work, we made the deliberate choice to trade near-term product velocity for long-term capability — but that trade created real tension for teams with external commitments.
Metrics. We still have not figured out the best way to measure the impact. We made that choice firmly believing the speed-up would justify itself. We cannot pretend we have the full picture yet, but we are working on it.
Content half-life. Training ran over six weeks. What we taught at the beginning was sometimes no longer best practice by the end. The tooling moves fast enough that any static curriculum has a shelf life, and ours was no exception.

If we ran the program again, we would run into most of these same pitfalls — because most of them were the price of moving at the speed the moment required. The one thing we would do differently is think harder about longevity from the start. We did build mechanisms for continuous learning, but we could have invested more upfront in making the training a living system rather than a fixed event.

The Floor, Not the Ceiling

The moment it clicked for me was quiet. I wrote a prompt with a complex and vague problem statement, but a sharp verification criteria. Then I walked away. I came back to a working, and more importantly, correct solution. My verification guardrail forced the output to be nothing but correct. That is what AI-native actually feels like: delegation with confidence.

I was not the only one who had a moment like that. The skeptic arc was remarkably consistent across every cohort: arms crossed at the start, then something shifted. For some it was sudden like a single prompt that produced something they did not think was possible. For others, it was quieter, a daily accumulation of small wins that rewired intuition before they noticed it happening. We never forced the epiphany. We just kept creating the conditions for it, and trusted that when the environment is right, the shift finds its own way in.

Takeaways

For engineering leaders considering something like this, here is what we would pass along.

Train the trainers first. We made an early critical decision that embedded mentors and internal advocates with real experience will always outperform any vendor.
Structure beats access; a curriculum paired with daily support is worth more than a thousand tool licenses.
Make it mandatory and make it inspirational; mandatory without inspiration is compliance theater.
Measure outcomes and not the activity. Do not count prompts sent or lines of code accepted. Instead look at what people built, and what categories of work quietly disappeared.

The problem was a lack of fluency and the fix is not with a license or found on a slide deck. It is built through practice, through structure, through the kind of investment that asks an organization to pause and believe the slowdown will be worth it. The cost was high: three hundred engineers, taking weeks of time to upskill versus shipping features. But the investment was supported from the very top, by our CEO and CTO, and well worth it. This investment is why we are where we are today. And where we are today is not the destination. Everything we did — every session, every check-in, every awkward first prompt — was just establishing a floor. The training was base camp, and the real work is continuing to climb the mountain together.

Eugene Yao is a Senior Staff Engineer at Zocdoc, where he is one of the leaders for the AI-native training program across the engineering organization. This is Part 2 of a series on Zocdoc’s AI transformation — read Part 1 by Kamini Dandapani for the strategic story behind the decision.