AI Training for Engineering Teams

Your team thinks AI is coming for their jobs. So nothing changes.

You bought the licences. You sent the memo. Six months later almost nobody's workflow looks different, and the people who were going to figure it out anyway are the only ones who did.

I've been on both sides of this. I gave my engineering team the tools and told them they could be ten times more productive. What I got back was resistance — and honestly, from where they sat, it was rational. So I learned it myself. Thirteen months later I'd shipped more, solo, than we had in the three years before.

Book a free 30-minute call What the training covers

Resistance isn't stupidity. It's self-preservation.

Most AI rollouts fail for reasons that have nothing to do with the tools. If you don't deal with these first, the training won't stick either.

The real blocker

“This is how I get replaced”

Nobody says it out loud. They just don't adopt. Until an engineer can see how this makes them more valuable rather than less, no amount of licence spend moves the needle.

The credibility gap

They tried it and it wrote nonsense

One bad experience with a hallucinated function becomes the whole opinion. What's usually missing is the workflow around the tool, not the tool.

The demo trap

It works on a to-do app

Every tutorial builds something green-field. Your team works in a decade-old codebase with real constraints. That's a different skill, and it's the one worth teaching.

The quiet one

Nobody wants to look slow

Senior engineers won't admit they're behind on something a junior picked up in a weekend. Training has to give them a way to learn without losing face.

What we actually do

Hands-on, in your repository, on your real tickets. Not slides.

Start in your codebase, not a sandbox. We pick real work off your backlog and do it together. Whatever we build in the sessions is work you keep.
Teach the workflow, not the tool. How to scope a task so a model can actually do it, how to review what comes back, when to throw it away and start again, and where it will confidently lie to you.
Deal with the fear directly. I say the quiet part out loud in the first session. Engineers who understand where this genuinely leaves them stop resisting; engineers who are guessing keep resisting.
Set the pace expectation. Small things in days, medium in two weeks, large in four to six. Once a team has seen that rhythm hold, it becomes the norm rather than the exception.
Leave them with your own playbook. Written down, specific to your stack and your constraints, so it survives after I'm gone and new hires can pick it up.

Is this for you?

Yes, if

You have engineers and adoption has stalled
You're paying for tools nobody really uses
Your roadmap is quoted in quarters and competitors ship in days
You suspect the blocker is people, not technology
You want your team upskilled — not replaced

No, if

You want a conference talk or a slide deck
You're looking for a certification programme
You've already decided to cut the team and want cover for it
Nobody senior will actually attend
You want a vendor to hand you a tool and leave

Why me for this specifically

There are plenty of people who'll teach your team prompting. Very few have run the transition inside their own company, with their own money and their own team.

I hit this exact resistance

My own engineering team saw AI as a threat and dug in. I understand the objection from the inside, because I had to work through it with people I'd hired.

I actually ship with it

Thirteen months building solo — full stack, servers, agents, live customers on it. I'm teaching a working practice, not a theory about one.

Twenty-plus years before that

Distributed teams across six countries, plus two decades in the industry I was building for. I know what a real engineering org can and can't absorb in a quarter.

I'm not selling you a tool

I have no vendor relationships and nothing to upsell. If the honest answer is that your team is fine and the problem is elsewhere, I'll say so.