Most AI adoption advice is aimed at the wrong end of the org chart. Learn prompting. Automate the tedious parts of your role. Get faster before the next reorg. That advice works fine for juniors, and it produces exactly what you would expect: juniors running prompts nobody senior has ever reviewed.
Andy Crestodina wants to flip it. In his session at MAICON 2026, previewed by Marketing AI Institute on September 14, he argues the best person to build a marketing teams AI assistant is the person who already does the job well. Not the most prompt-curious person on the team. The expert.
It sounds backwards until you sit with it for a minute. Then it sounds obvious.
The reframe: stop wearing the tool, start building it
The standard pitch for AI at work is speed. You keep your job; the assistant trims the hours off it. Crestodinas pitch is ownership. Parts of your job, he argues, should stop being tasks you perform and become tools that perform them — for you, then for everyone on your team, then for whoever joins after you.
The difference shows up on paper within a quarter. Speed saves one person some hours. A tool compounds. If your best campaign-audit process lives as a documented prompt chain instead of inside one senior persons head, every analyst gets to run it at near-expert quality on day one. AI becomes what he calls a skill-transfer device: the expert encodes judgment into prompts and workflows, and everyone else inherits it.
That framing also settles an argument most teams are still having: who should own AI adoption, the practitioners or a central team. In Crestodinas model the practitioners own it, because output quality is the whole product, and only practitioners can judge it.
The four rungs you cannot skip
The core of the session is a sequence. Workflows evolve through four stages, and each one requires the one before it:
1. Manual, with human hands
You run the process yourself, start to finish, no AI. This is the rung everyone wants to skip and the one that matters most. If you have never run a competitive audit manually, you do not know which sources matter, which numbers are garbage, or what a good output actually reads like. Skip this and every later stage inherits your ignorance.
2. Prompted, with human hands
Now you write the prompts and run them yourself, checking every output against the manual version you already know cold. This is where the judgment gets encoded. The prompt is bad at first. You revise. You test it against edge cases. That iteration loop, done by someone who knows what good looks like, is the entire game.
3. Assistant, with human review
The tested prompts get assembled into an assistant that runs the workflow with a human reviewing outputs. You are still in the loop, but the assistant does the assembly work. The experts role shifts from doing to evaluating — which is precisely the thing juniors cannot do yet, and precisely why the expert had to build it.
4. Workflow, lightly supervised
Prompts from across the team get combined into shared workflows that run with light supervision. Your campaign brief prompt plugs into the analysts audit prompt plugs into the designers asset spec prompt. At this point the capability lives in the org, not in any individual.
Crestodina is blunt about the ordering: you cannot jump rungs. Teams that try to buy stage four off the shelf, without ever doing stage one, get workflows that look automated and produce work nobody can defend.
“Your prompts are code”
The most quotable section of the talk borrows from Andrej Karpathy — “the hot new programming language is English” — and takes it literally. If prompts are code, they get treated like code:
- Versioned, so you know which prompt produced which result
- Tested, against both typical and edge-case inputs
- Stored centrally, in a shared library the whole team can pull from
- Combined, because single prompts stay toys while chains become infrastructure
Compare that to how prompts actually live at most companies: pasted into chat, lost to scrollback, quietly re-derived from scratch by five different people every month. The shared prompt library is the least glamorous idea in the session and probably the most valuable one. It converts individual cleverness into an asset that survives turnover.
What to do this week
You do not need a strategy deck for this. One task, moved up the ladder:
- Pick a recurring task you personally have done at least ten times. Something with a repeatable shape: a content brief, a competitive snapshot, a weekly report.
- Write the prompt while doing the task manually, narrating your own decisions as you go. Every judgment call becomes a line in the prompt.
- Run it five times on five real inputs. Fix it each time. Ten iterations is better, but five gets you a usable draft.
- Hand it to a teammate with the prompt alone, no verbal coaching. Whatever they get wrong tells you what the prompt fails to encode.
- Put the finished prompt somewhere shared, with your name on it and a note on what it is for.
That is rung two, completed honestly. Repeat it on three or four tasks and you have the raw material for an assistant. Do it across a team and you have a library.
The honest caveats
Two things temper the enthusiasm. First, Crestodinas line that “the only gap is our own imaginations” is doing marketing work. The real gaps are mundane: maintained prompts, someone accountable for quality, and the willingness to retire a prompt when the underlying model changes behavior. Prompt libraries rot like any other code, except nobody schedules their refactors.
Second, the expert-builds-it model has a shelf-life problem. The experts time is the most expensive on the team, and encoding judgment is slow, quiet work. Organizations say they want it and then staff the easy thing instead. If your team wont protect senior hours for this, the ladder stays a slide deck.
Still, this is the most honest adoption framework I have seen a marketer describe this year. It asks for sequence over speed, and for code review over magic. The teams that follow it will build something they own. The teams that skip to the top rung will rent theirs and wonder why the output reads like everyone elses.
