Teaching Tens of Thousands to Build With AI: What Sticks

I've watched the same moment happen thousands of times: someone sees an AI tool do something impressive, their eyes light up, and then nothing changes in their actual work. The demo lands. The behavior doesn't. After teaching tens of thousands of entrepreneurs to actually build with AI through VADYM.AI in Ukrainian and KIERUNEK.AI in Polish — and training people at Instytut Kryptografii in Poland — I've stopped being surprised by the gap. My thesis is simple: AI skill that lasts has almost nothing to do with the model and almost everything to do with a few small, unglamorous habits. The people who ship and the people who only watch sit in the same room, hear the same thing, and walk out completely differently.

Why does almost everyone stall right after the demo?

A demo is a lie of omission. It shows the model doing one thing, once, under good conditions, with someone experienced driving. It hides the part that actually matters — doing the same thing reliably, on your own messy data, on a Tuesday when you're tired and the first output is wrong.

When people stall, they almost never stall because the tool is too hard. They stall because they confused "I saw it work" with "I can make it work for me." Those are different skills. The first is recognition; the second is production. Recognition feels like learning, which is exactly why it's dangerous — you leave the session convinced you've got it, and you've got nothing you can repeat alone.

The honest version of teaching is to make people produce something in the room, on their own problem, before they leave. Not "here's how you'd do it," but "do it now, with your actual data, and let's fix it when it breaks." Because it will break. That's not a teaching failure. That's the lesson.

What actually separates the shippers from the watchers?

The single clearest predictor I've found: the shippers tolerate a bad first output and fix it. The watchers see a bad first output and conclude the tool isn't ready.

This is a mindset I earned the hard way, not in education but in hardware. I describe my own path as a road from failure to failure, and I mean it literally. At Dronehub, before we had a drone that could land itself reliably in its docking station, we went through version after version. The early ones were, by any honest definition, failures. But each failure was information, and the information was the product. If I had treated the first attempt as a verdict on whether autonomous landing was "possible," there would be no company.

That's the exact instinct the watchers lack. They treat the first AI output as a verdict. The shippers treat it as one step in a long iteration. Same tool, same prompt, opposite outcome — and the difference is entirely between the chair and the keyboard.

So when people ask me how to "get good at AI," my real answer is unsexy: get comfortable being wrong fast and cheap. AI made iteration nearly free. A prompt that fails costs you ten seconds. The people who win are the ones who've stopped flinching at failure because they've redefined it as the work itself.

Which habits make the skill durable instead of a novelty?

A novelty is something you did once because it was fun. A skill is something you reach for without thinking. The bridge between them is repetition tied to real work.

Here's the rule I teach in every program, and it's the one thing I'd want someone to remember if they forgot everything else: if I do something twice, I think about automating it; if three times, I automate it. I've written about this more fully in Do It Twice, Think About Automating; Three Times, Automate, but the principle matters most here because it's what makes a skill stick. A skill attached to a one-off curiosity — "let's see if it can write a poem" — evaporates within a week. A skill attached to a chore you genuinely repeat gets reinforced every single time the chore comes back.

This is why I push people, in the room, to pick something from their own week. Not a clever use case. An annoying one. The weekly report nobody wants to write. The same five emails they answer every Monday. The spreadsheet cleanup that eats an hour. When the AI removes that pain, the lesson reinforces itself, because the pain returns on schedule and now there's a tool waiting. Durability isn't a property of the AI. It's a property of how tightly you wired it to something that recurs.

The corollary: don't teach people impressive things. Teach them repeatable things. An impressive demo gets applause and changes nothing. A boring automation that saves two hours every week changes how someone works forever — and, more importantly, teaches them to go looking for the next two hours on their own. That self-propagation is the whole goal. I want people to leave able to find their own automations, not waiting for me to hand them the next one.

How do you teach AI at scale without the hype?

The temptation in AI education is enormous: promise transformation, lean on the magic, fill the room with possibility. I refuse to do it, and not out of modesty — because hype actively destroys durable adoption.

When you oversell, you set people up to feel cheated the moment reality intrudes, which it always does around output number two or three. The model hallucinates, the integration is fiddly, the result needs editing. If I've spent the session promising magic, that friction reads as betrayal and people quit. If I've been honest — "this is a fast, fallible assistant, and here's exactly where it lies to you" — that same friction reads as expected, and people keep going.

My whole framing is build-first: actually build with AI, not just talk about it. Talking about AI is the entire problem. The internet is drowning in people talking about AI who have shipped nothing. I'd rather a student leave with one ugly, working automation than a beautiful mental model of the future. The ugly working thing compounds. The mental model decays.

Scaling this honestly is mostly about lowering the first step, not raising the ceiling. Most entrepreneurs assume they need to code, or understand how a transformer works, to get leverage. They don't. The format that works at scale is the same every time: plain language, one guaranteed early win, and a task small enough that success is nearly certain on the first real attempt. You don't scale by making the material more advanced. You scale by making the first build impossible to fail at — and then getting out of the way. I dig into the broader honesty gap in What Most Entrepreneurs Get Wrong About AI, but the teaching version is just this: confidence built on hype is brittle, confidence built on a shipped result is permanent.

How do you know whether the skill actually stuck?

Anyone can look capable for the length of a demo. What's real is what survives weeks of use, and what someone will actually spend their own time and money maintaining. Time is the verifier. So when I want to know whether a cohort genuinely learned to build with AI, I don't look at how the final-day projects landed. I look at what's still running a month later.

The workflow that's quietly saving someone an hour every Friday — that's the real result. The flashy project that got applause and was never opened again — that was theater. Durable skill reveals itself over time, not in a first demo, because the first demo only proves enthusiasm, and enthusiasm is the cheapest thing in the room.

This is the metric every team leader should actually care about. Adoption isn't the number of people who attended training or the excitement in the room on day one. Adoption is retention: the automations still alive after the novelty wore off. And retention follows directly from everything above — small wins, recurring tasks, honest expectations, and a tolerance for the first ugly output. Most AI enthusiasm doesn't survive contact with time. The habits do.

There's a build-versus-buy dimension to this too, because durability also depends on owning the right things — I worked through that in Build vs. Buy: When an SME Should Wire Its Own AI Workflow. But for an individual learning the skill, ownership is simpler: own the habit of shipping, and the tools become interchangeable.

Where I'd start if I were you

If you're an entrepreneur, a team lead, or an educator trying to make AI adoption stick past the first demo, don't start with a strategy. Start with a chore.

Pick one task you genuinely repeat every week — the more annoying, the better. Sit down and rebuild it with AI today, not later. Accept that the first output will be wrong and fix it instead of quitting; that's iteration, not a verdict. When it works, notice that it'll keep working every week, because you tied it to something that recurs. Then, the next time you catch yourself doing something for the third time, automate that too.

That's the entire method. No hype, no magic, no promise of transformation — just a build-first habit, an honest tolerance for failure, and the discipline to attach new skills to real, recurring work. I've taught it to tens of thousands of people across two languages, and the ones it sticks for are never the most technical in the room. They're the ones who shipped something ugly on day one and kept going. Time will verify the rest.

If you want the other end of the same idea — finding the highest-value first automations when you're working alone — I'd read AI Automation for Solo Founders: The First High-Leverage Wins next. And if you'd rather just talk through where your team is stalling, reach out. The model is the easy part. The habit is the whole game.