Effective AI coding assistant training is structured practice on real work, not a tool overview or a one-day workshop. A four-week plan works well: two weeks of coached practice on a shared workflow, then two weeks applying that workflow to real backlog items, measured against a baseline. The goal is daily use, shipped work, and internal coaches who keep the practice going.
Most engineering organizations already have the licenses. What they often lack is a consistent way of working that turns those licenses into delivered software. We cover that broader problem in AI Coding Tool Adoption Doesn't Equal Value Delivered: Why Productivity Stalls and How to Fix It. This post focuses on one part of the fix: how to train developers so that AI-assisted work becomes a daily habit rather than an occasional experiment.
Why don’t lunch-and-learns or vendor onboarding make developers effective with AI tools?
Because they teach the tool, not the way of working. A lunch-and-learn or vendor onboarding session shows engineers what a product can do. It rarely changes how they plan, write, and review code once the session ends.
Giving a team access to GitHub Copilot, Cursor, Codex, or Claude Code is not the same as giving it a shared way of working. After a rollout, the usual pattern is uneven usage: a few engineers fold the assistant into most of what they do, many use it occasionally for autocomplete or quick questions, and some stop opening it at all. Tool-only training tends to produce exactly that spread, because it leaves each person to work out an approach on their own.
One-off demos also rarely build muscle memory. Watching someone generate a working feature in a few minutes is persuasive, but the next morning engineers return to their own codebase, their own deadlines, and the same unstructured habits they had before. Without repeated practice on realistic work, the new behavior does not stick.
That is why training should be tool-agnostic and focused on the workflow. The useful questions are about practice: how a change is specified before code is generated, what context the assistant needs from the repository, and how generated code is reviewed before it merges. Those habits carry across assistants and survive the next product update.
To be clear about scope: Liatrio does not help teams pick an AI coding assistant. Choosing a vendor is a separate decision your organization makes on its own terms. The training described here works with whatever tools your engineers already have.
This connects to the larger argument in our pillar post: when AI coding adoption stalls, the gap is usually the workflow, not the tool. Training is where that workflow gets built.
What should a four-week plan include?
A four-week plan should include two weeks of coached, hands-on practice on a reference codebase, followed by two weeks applying the same workflow to the team’s real backlog, with fluency and delivery measured before and after. The structure matters as much as the content: a stable cohort, the same coaches throughout, and engineers freed up to do the work full time.
Here is how the four weeks break down, week by week.
Week 1, learn the workflow on a reference codebase. Engineers work through instructor-led, hands-on exercises and pair programming on a shared reference codebase rather than on production systems. The focus is a spec-driven workflow: writing down what a change should do, then using the assistant to carry it out. Starting on a lower-risk codebase lets people experiment, make mistakes, and compare approaches before anything high-stakes is involved.
Week 2, build repetition with coaching. The cohort keeps practicing the same workflow, still with coaching and pairing, until it starts to feel routine. Regular demos let engineers see how their peers specified, prompted, and reviewed similar changes, which is often where much of the useful learning happens.
Week 3, move to the real backlog. Engineers apply the workflow to real backlog items in their own repositories. That work goes through the team’s normal code review process, with no special exceptions, so the output is held to the same standard as any other change.
Week 4, ship, measure, and demo. The cohort continues delivering backlog items, compares delivery speed against the team’s pre-training baseline, and finishes with a demo that leadership can see. The demo shows shipped work, not slides about what the tools might do.
Measurement runs through all four weeks. Fluency should be assessed at the start and at the end; Forge for Builders, for example, scores each engineer across six skills. Delivery speed should be compared against the team’s own baseline, captured before training begins, so the comparison reflects your work rather than a generic benchmark.
The cohort itself needs a deliberate setup:
Cohort size of 8 to 12 engineers. That is large enough for shared learning and peer comparison, and small enough for each person to get real coaching.
The same coaching team for all four weeks. Continuity means feedback builds on what the coaches have already seen, rather than starting over with each session.
Protected, full-time participation. Engineers need to be freed up to do this work. Squeezing training into leftover hours between sprint commitments usually fails, because urgent work tends to win.
What do engineers practice, day to day?
Day to day, engineers practice a repeatable loop: write a reviewable spec, steer the assistant from that spec, prepare the repository so the assistant has good context, and review generated changes against tests and acceptance criteria. The aim is habits they will use the next morning, not techniques that only work during the training window.
The core practices are:
Spec first, then code. Before generating or changing code, the engineer writes a short spec that a teammate could review: what the change should do, what it should not do, and how success will be checked. The assistant is then steered from that spec rather than from an open-ended, ad hoc chat. This makes the work easier to review and the assistant’s output easier to judge.
Repository preparation. Engineers improve the documentation, coding conventions, and context files that AI assistants rely on. This work outlasts the training: the team keeps using and maintaining those files, and later sessions with an assistant benefit from them.
Reviewing diffs with evidence. AI-generated diffs are checked against tests and acceptance criteria, not just scanned for style or plausibility. Engineers learn to ask whether the change does what the spec said, whether the tests actually cover it, and whether the assistant changed anything it was not asked to change.
Habits that last past the workshop. Each practice is designed to fit an ordinary working day. If a technique only works with a coach in the room, it is not yet a habit.
For a deeper explanation of the workflow behind these practices, see What Is Spec-Driven Development? A Practical Guide for AI-Assisted Engineering Teams.
These practices are deliberately independent of any one assistant. An engineer who writes a clear spec, keeps the repository’s context current, and reviews diffs against tests will work better with GitHub Copilot, Cursor, Claude Code, or Codex, and will keep those habits if the organization’s tooling changes.
How do we know the training worked?
You know the training worked when you can point to three things: individual fluency improved between the start and the end, real backlog items shipped through normal review at a pace you can compare to the team’s baseline, and a few engineers in the cohort are ready to coach others. Attendance numbers and license activity alone do not show any of these.
Each signal deserves a closer look:
Individual fluency, before and after. Score each engineer at the start and the end of the program. The scores should be backed by work in the team’s own repositories, not only by exercises in a tutorial repo, because fluency on a clean sample project does not always carry over to a real codebase.
Shipped backlog work against a baseline. Count the real backlog items that went through ordinary review, and compare delivery speed to the pre-training baseline. Measuring against your own history keeps the comparison honest.
Engineers ready to coach. Identify two to three engineers per cohort who can coach others afterward. This is the Forge model, and it is what lets the practice spread beyond the first cohort without depending on outside help.
If any of these is missing, the training is not finished. A team that scores well but has shipped nothing has not yet proven the workflow on real work. A team that has shipped but has no one ready to coach will struggle to extend the practice to the next group.
How does this plan map to our approach?
The four-week plan above follows the structure of Forge, Liatrio’s program that teaches software engineers to use AI coding tools through a spec-driven workflow. Weeks 1–2 are coached practice on a Liatrio reference codebase, and weeks 3–4 are a timed Flashbuild on the team’s real backlog, ending with a demo day for leadership.
In practice, the program runs like this:
Coached practice in weeks 1–2: instructor-led sessions, hands-on coaching, and pair programming on a Liatrio reference codebase.
A Flashbuild in weeks 3–4: a timed build using the team’s real backlog, with work shipped through normal review and a demo day for leadership at the end.
Continuity across all four weeks: a cohort of 8 to 12 engineers, the same Liatrio coaching team throughout, and demos along the way to compare approaches.
The program is designed to leave specific outcomes behind:
Before-and-after fluency scores for each engineer across six skills.
Real backlog items shipped through normal review, with delivery speed measured against the team’s baseline.
Repositories prepared for AI-assisted work, with documentation, conventions, and context files the team keeps using.
A workflow playbook tailored to your organization.
Two to three engineers equipped to coach others after the program ends.
Forge for Builders is designed for software engineers and tech leads who are comfortable with Git and the command line. It fits teams where AI tool usage is uneven and delivery hasn’t picked up, and it requires freeing engineers up full time for the four weeks.
You can run this plan yourself using the structure in this post. If your team would rather run it with dedicated coaches, that is what Forge is built to do.
Frequently asked questions
Can we train developers on AI coding tools in a single workshop?
A workshop can introduce features, but it rarely changes daily practice. Effective training needs repeated, coached reps, followed by real backlog work that has to pass ordinary review. If the goal is lasting fluency, plan for weeks, not hours.
Do we need to standardize on one AI coding assistant first?
No. Train the workflow, and let engineers use the tools the organization already has, whether that is GitHub Copilot, Cursor, Claude Code, or a mix. Standardizing on a vendor is a separate decision, and it is not a prerequisite for better practice. Liatrio does not help teams pick the tool.
How many developers should be in a training cohort?
A group of 8 to 12 engineers is large enough for shared learning and small enough for serious coaching. The same coaches should stay with the cohort for the full four weeks. Engineers also need to be freed up to participate; squeezing this work into leftover time usually fails.
What should be true after week four?
Engineers should be able to run a spec-driven workflow on their own work, some backlog items should have shipped through normal review, and two or three people in the cohort should be ready to coach others. If all you have at the end is a slide deck and a license report, the training did not finish the job.
The bottom line
Training developers to use AI coding assistants effectively is less about the tool and more about building a shared, repeatable workflow through practice on real work. Four weeks gives a team enough time to learn that workflow on a reference codebase, prove it on its own backlog, and measure the result against its own baseline. The outcome to aim for is not a completed workshop. It is engineers who use the workflow every day, work that has shipped through normal review, and internal coaches who can carry the practice to the next cohort.
If you want to run this plan with a dedicated coaching team, learn more about Forge.
