What Should Your AI Guy Learn First?

Not a tools list. The first things your AI guy should learn are: how to brief an AI in plain language and get real work back, how to map your company's workflows and rank the bottlenecks, and how to ship one automation end to end into your existing stack. Tools change quarterly; those three skills transfer to every tool that comes next.

This is where most self-directed learning goes sideways. The curious employee — the one already playing with Claude on their lunch break — defaults to YouTube, and YouTube teaches tools: "top 10 AI apps," feature tours, demo projects. Six weeks later they know a lot of interfaces and have shipped nothing your business runs on. The order below is the difference between an AI tourist with opinions and an AI architect with shipped systems.

Why not start with a tools list?

Because tools are the output of the decision, not the input. Which automation layer, which model, which integration — those choices fall out of your stack and your bottlenecks. Learn tools first and you get solutions hunting for problems: the classic "I made a Zap once" energy, where the tool got exercised and the business didn't change.

There's a second reason: tool knowledge depreciates. Interfaces change, vendors get acquired, this quarter's hot app is next quarter's abandonware. Briefing skill, workflow mapping, and shipping discipline don't depreciate. Train the durable layer and the tools take care of themselves.

First: learn to brief AI like it's a smart new hire

The foundational skill is talking to frontier models in plain language: state the outcome, give the context a smart person would need, define what done looks like. No magic phrases, no 47-line prompt templates — those were workarounds for weaker models. Someone who can brief well gets real work out of AI on day one; someone who can't gets generic mush out of the best model on the market.

This matters double for a champion, because they'll eventually teach the whole team to do it. The full method — and why plain speech beats ceremony — is worked through at plainenglishprompts.com.

Second: learn to see workflows the way an architect does

Your ops lead already knows where the pain is. What training adds is the sorting lens: for each workflow, which steps require human judgment and which are pure mechanism — copying data between apps, drafting the same email the same way, compiling the weekly report. The mechanism steps are the automation surface.

The practical output of this phase is a ranked bottleneck list: what it costs the team weekly, how hard it is to automate, what breaks if it goes wrong. That list becomes the champion's build queue — and it's the founder's insurance that the building happens on company priorities, not hobby projects. (Skipping this list is mistake #3 in the mistakes companies make with their AI champion.)

Third: ship one real automation, end to end

One. Real. Shipped. Not three half-built demos — one bottleneck taken from "annoying manual process" to "system the team actually uses." End to end means all of it:

• Pick the target off the ranked list — real work the team feels weekly.
• Build the automation with AI doing the heavy lifting.
• Wire it into the existing stack — the CRM you already run, the inbox you already live in — without breaking anything.
• Test it against the messy real cases, not the happy path.
• Hand it to the team, train them on it, and watch it survive a week of contact with reality.

The first shipped automation does something no tutorial can: it converts the team from skeptics to requesters. The day someone says "could you also automate the follow-up emails?" your champion has stopped being a trainee and started being infrastructure.

Then what? The loop, on repeat

Everything after the first ship is the same loop at higher speed: see the workflow, spot what should be automated, build it, wire it in, train the team, wake up tomorrow and take the next bottleneck. Compounding lives here — automation #5 reuses the plumbing from automation #2, and the build time per system keeps dropping. That trajectory, and what it looks like at the 30-day mark, is mapped in how long it takes to train an AI guy.

What the loop needs from you, the founder, is protected time and a clear mandate. A champion learning the right things in the right order on stolen hours will still lose to a mediocre curriculum on protected time. Give them both.

FAQ

Does my AI guy need to learn to code?

No. Modern AI tools respond to plain language, and AI agents write the code that's needed. What your AI guy must learn is how to describe outcomes precisely, verify the result, and wire systems together — thinking skills, not syntax.

Which AI tools should they learn on?

Whichever frontier model and automation layer fits your existing stack — the specific logo matters far less than founders think. Tool-first learning is the trap: tools change quarterly, while briefing, workflow mapping, and shipping discipline transfer to every tool that comes next.

Should they practice on sample projects or real work?

Real work, from the first week. Sample projects teach sample skills. The first automation should attack a real bottleneck your team feels weekly — that's what turns training cost into payback, and it's what earns the champion credibility inside the team.

How much of their week does learning take?

Treat it as a real allocation on work time, not homework after hours. The offset is that the first shipped automation starts reclaiming team hours before the 30 days are up — the learning pays for its own calendar space quickly.