Land the title, then wait for the line to finish typing itself. Say nothing while it types.
"These slides are a component in a design system I built. Where you see the rougher typeface, a machine drafted the line. The clean one is mine. It stays honest all talk, and I am not going to point at it again."
Set the promise: one law, one confession, one receipt, one playbook you can steal.
Let's start with the accusation
"Vibe coder."
Types a wish into a chat box.
Pastes back whatever comes out.
Ships a house of cards they couldn't explain if you held their coffee hostage.
Prompt and pray. No tests, no idea, no receipts.
You know the tone. Somebody on this call has typed it as an insult this month.
Reveal the beats one at a time. Let the coffee line breathe, it usually gets the laugh.
Land "prompt and pray" flat. Do not sell it.
And yet
I call myself one anyway. I just add a word in front.
Professional vibe coder.
Which is the kind of claim that should turn up with evidence and not just vibes. So I did the one thing the label never does. I counted.
Own it. No defensiveness, no air quotes in the voice.
"Professional" is the whole talk. Everything after this is me earning that word.
Promise the number now, pay it off on slide 16. Do not leak it early.
The belief underneath everything
AI doesn't add to what you can do. It multiplies it.
what you bring6
× the same AI10
= what shipsthe gap AI opened60
A decent developer with an AI is a frighteningly fast developer.
THE centrepiece. Slow down here. Drag the slider up first: "watch the gap open."
Then drag it to zero and hold one beat. Let them read the output bar sitting at nothing. Dead air reads as a frozen stream, so one beat, not two.
"Same tool. Same prompt. Same model. The variable was never the AI."
If the chat is warm, ask them to type where they think they sit. Do not push it.
The same tool, twice
A strong developer plus an AI is a frighteningly fast strong developer.
A beginner plus the same AI ships bugs faster and can't tell which ones they are.
So "just use AI" is terrible advice for a beginner, and "never use AI" is terrible advice for a professional.
This is the slide that makes people uncomfortable, which is the job.
Be kind about it. Nobody chose to be early in their career.
Bridge: "the honest answer is in the middle, and it has an order of operations."
The order of operations
Become worth multiplying first.
One line on the screen. Say it, then hold one beat: "read that twice."
This is the sentence they will still have on Monday. Earn the silence.
Worth multiplying is a number. Here is what it is made of
Not years. Four things.
0what you bring
Nothing ticked, and the machine is still a ten. Ten times zero.
Not one of these can be bought, installed, or prompted for. That is the bad news and it is also the good news.
Tick them one at a time as you say them, and let the number climb. Same bar as slide 4, on purpose. Do not explain the callback, they will feel it.
After each one, ask out loud: "can the model supply that one for me?" The answer is no four times. Let them hear the pattern before you name it.
"Every one of those is a scar. That is the honest word for experience."
Kill the word 'years' if it comes up in the chat. A careless five years is a smaller number than a deliberate one. That is the good news in this room.
Bridge into the confession: "I know the price of that list, because I paid it the slow way."
The confession
I was the zero. For years.
eleven years, one dot per month
Torocloud, part time, still a studentmy first engineering job, and I left it
Family campsite, grown into a resorta pandemic flattened it
Marketing, for someone else's companyonly works if it is mine
A cafe, with friendsbroke even
A salon, with friendssold at break-even
A marketing firm, on my ownwent nowhere
An events platform, real moneyended badly
Real money, and a few years I can't get back.
Start on the first row and let it be the good news: a real engineering job, part time, while I was still a student. Same position half this room is in right now.
Then the turn, flat and without excuses: "I left it. I was sure the interesting things were somewhere else."
Deliver the rest flat too. No drama, no sad music. The weight is in the dots filling up.
Set it up: "for most of my twenties I was a talented amateur with just enough instinct to talk my way into rooms I had no business being in."
"It worked. That is the trap. It worked just enough to keep me doing it."
Do not skip the wink: "it turns out you cannot tell your friends what to do."
Point at the grid on the last beat. That is eleven years, one dot per month, and one of those rows was the job I already had.
Every single one had the same root cause
It wasn't the ideas.
It was me.
I kept starting things I wasn't the right person to start yet.
Two beats. "It wasn't the ideas" ... hold ... "It was me."
Then bank the lesson and move on. No wallowing, that's the rule.
The maxim it cost me to learn
You have to be the right person before you try the thing.
"I paid the tuition on that one so you don't have to."
Audience is students. This is the line aimed straight at them.
What I did about it
I stopped chasing the next launch and fixed the one variable I could actually fix.
Slowed down.
Learned the foundations properly, not just enough to pass.
Shoved myself into the parts I was worst at. Teaching. Standing on a stage.
Which is going great, thanks for asking.
what I used to ship
const ranking = scores.sort()
Tests green. Nobody asked. I could not have told you what sort compares.
what an afternoon of actually reading found
[10, 9, 1].sort()
// [1, 10, 9]
It sorts them as text, not as numbers. Every language has a handful of these, and you can use them for years before one bites.
what teaching does to you
"Sir, why is it 1, 10, 9?"
Twenty faces waiting. That is the moment you find out whether you know a thing or just use it.
Same line of code on all three cards. Say that out loud on the second one, it is the point of the panel.
Card 1: "I shipped that. It passed. It was also wrong the moment a score hit double digits, and I would not have caught it."
Card 2: ask the room what it prints before you reveal. Somebody always says 1, 9, 10. Let them be wrong, kindly.
Card 3: "Using something and being able to teach it are two different jobs. Only one of them survives a question."
The last beat is the joke, and it is at your own expense. Underplay it.
"That is my definition of professional. Not the title. The journey that lets me stand here and say this."
Mileage, not medals
I could have written every line of this by hand.
I run a team of developers, which is mostly reading other people's code and finding the problems politely.
I teach, on a platform I built because the grading was about to bury me.
And zero credentials in AI. What I have is a long list of ways I've been wrong.
Price each item, never list them clean. The point is placement on the multiplier, not applause.
If someone asks what the slides are running on, the answer is one HTML file, no build step, no framework. Do not volunteer it, it costs a minute.
The credentials admission is load-bearing. It buys everything after it.
The whole difference in one line
A beginner vibe codes because they can't write the code. I vibe code because I can.
The typing was never the valuable part.
"I'm not skipping the hard part. I did the hard part years ago, the boring way and the expensive way."
The value is knowing what to build, how it should be shaped, and when the machine has quietly done something dumb.
Directing an AI is not a new skill
Four titles. One skill set.
Give direction
a clear brief
the conventions
the lesson
a prompt plus docs
Verify anyway
review the PR
design review
grade the work
read the output
Then all four do the same last move: correct the reasoning, not just the output.
Click across the columns as you say them. Same moves down every column, only the subject changes.
"So I stopped treating the model like a magic oracle and started treating it like a fast, capable, occasionally overconfident junior on my team."
Some evenings I have five to ten sessions open at once. It feels exactly like running a team.
Pull quote to say aloud: "I'm not learning a new skill with AI. I'm spending the one I already paid for."
My one rule for students, turned on the machine
If you can't explain it, you didn't build it.
This is the rule they already know from your class, if any of them are yours.
Point out it applies identically to a junior's PR, a student's submission, and a model's output.
Enough belief. Here is the evidence
Seven repositories. Six weeks. 822 commits.
My portfolio, tjakoen.github.io, and the six repositories standing behind it: a design system, a data layer, a documentation cockpit, a testing dashboard. Not demo repos. Not tutorials. The things I actually build on, and the thing these slides run on.
Counted straight out of git, 27 June to 7 August. And 822 is not a brag, it is a denominator. What matters is what is inside them, which is the next slide.
Say the domain out loud and say it twice. Half the room will type it, and everything on the next three slides can be checked there.
Kill the applause before it starts: "the count is not the achievement. Anybody can make commits. The next slide is the one I care about."
Be scrupulous with the dates. Honesty is the credibility, and somebody will check.
Then set up the number: "there is one number in here that reframes everything else."
Guess before I show you
How much of the portfolio repo is writing, and how much is code?
tjakoen.github.io/CLAUDE.md how to work in here
README.mddocs/ the why, and the map
standards/ the rules, published
plans/ what is being built, and why
content/ the notes and the pages
src/ the code
e2e/ the end-to-end run
scripts/
the lit ones are writing
code18,876 lines↑ ↓ to move the guesswriting0 lines
48% of that repo is writing, not code. Plans, conventions, decisions, and notes to whoever opens it next.
Why that is not waste: typing is the cheap part now. Deciding what should exist is the expensive part, and it has to be written somewhere the machine can read it.
Across all seven repositories, one line in three is documentation.
Ask for guesses first and move the marker with ↑ / ↓ as they come in. More people will type a number than would ever shout one.
Say "writing", never "prose". Half the room will not know the word and none of them will admit it.
Press → to reveal. The writing bar comes up level with the code bar, from a room that guessed twenty. That gap is the whole talk in one animation.
The honest footnote, if anybody pushes: this counts committed files only, because that is the number they can check. Count the plans and agent notes that are deliberately not committed and it goes past half. I use the smaller number on purpose.
"This is the exact opposite of what vibe coding is supposed to look like."
Do not skip the why beat. Without it this is just a weird statistic. With it, it is the method: at speed the scarce thing stops being code and becomes intent.
Make it concrete for students: the writing is what you would have had to explain to a new teammate anyway. You are just doing it before the work instead of after, and the machine is the teammate.
If somebody challenges the count, agree instantly and give them the method. It is a rough line count, and the ratio survives any fair way of counting.
If that made me sound slow and fussy
One overnight sprint.
9:08pmthe small hours3:31am
0 / 50 commits
The night of 4 July. One commit every eight minutes, 4,269 lines added before it got light, every one of them co-authored with a machine.
Small commits, on purpose. Each one is a thing that already works, which is what makes the next one cheap to check.
Press → and let it play. Don't talk over the first few ticks.
Somebody is thinking "fifty commits means fifty tiny meaningless commits." Say it for them, then answer it: small is the point, because a commit you can check in a minute is a commit you actually check.
Co-authored is the honest word. Two sets of hands on every commit, I still write plenty myself.
"Both things are true at once, and that is the entire point. Fast and documented."
Do not explain WHY the night was possible here. That is the next slide, and it lands harder as its own line.
Why ten hours doesn't end in a pile of nonsense
You don't tell a fast driver to be careful. You build the track.
I'm not careful instead of fast. I did the careful part first.
The bridge from receipts into the playbook. Keep it short, they want the how now.
The distinction that actually matters
Amateur vibe coding is unstructured improvisation.
Professional vibe coding is structured delegation.
Same tools. Same speed. Wildly different scaffolding.
The machine typed. I engineered.
It has nothing to do with whether you use AI, or how fast you type.
"I don't make the AI reliable with cleverer prompts. I make it reliable by building an environment where good work is the path of least resistance."
"And that environment is a system, which means you can copy it. Here it is."
Steal this
The playbook is a loop.
keeps fast from turning into fragile
Write the rails before the features
Give the AI a memory
Make change propagate: keep a sync map
Audit relentlessly
Tests are part of the work
Document for the machine, on purpose
Write the rails before the features
A conventions doc and an onboarding doc written for the AI, before a line of features. Any model or human joining reads the same "here is how this works, here is what not to touch."
Give the AI a memory
Twenty-odd small decision records of why things are the way they are. Next session it inherits the reasoning instead of relitigating it, or worse, quietly undoing it.
Make change propagate: keep a sync map
The failure mode of fast AI work isn't bad code, it's drift. An explicit "when you change this, also update that" table turns "don't forget" into a checklist a machine can follow.
Audit relentlessly
A model earns more scrutiny than a junior, not less, because it's fluent enough to sound right exactly when it's wrong. Most of my prompting isn't "build this." It's "check this."
Tests are part of the work
Three tiers, written as features, not bolted on after. Type-checker and suite green before anything is done. The least glamorous rule, and the seatbelt that lets me drive fast.
Document for the machine, on purpose
The AI is a first-class reader, so write for it, not around it. You onboard this collaborator every time you open a session, so build the onboarding and polish it as you go.
Do NOT walk all six. Open 04 and 05, decided in advance, and stop.
For students, node 04 and node 05 are the ones that matter. Spend your time there.
Callback while the ring draws: "you don't tell a fast driver to be careful, you build the track."
Close it on the hub: it is a loop, and the loop is what keeps fast from turning into fragile.
The one everybody gets wrong first
Your prompt is not the input.
cold session, no history, one sentence
> add pagination to the notes list
what it does first
Guesses the stack. Invents a folder. Writes React into a repo that has never had any.
Same prompt every time. The only thing that changed was the room it walked into.
Start with all three off and read the output flat. Somebody will laugh, because everybody has had that session.
Name the trap: "everyone's instinct is to fix that with a better prompt. That is the amateur move, and I made it for months."
The line to land slowly: I stopped prompting harder and started leaving better notes.
Turn on the first two, then pause before the third. The third is the one nobody has, and it is the one that stops drift.
Student translation, say it out loud: one file at the root saying what this is, how it is built, and what not to touch. Twenty minutes, once, and every session after it starts smarter. That is the entire beginner version.
Give them the test: open a cold session, no history, one sentence. If it starts wrong, the gap is yours, not the model's.
Why the playbook is a ring and not a list
A prompt is one turn. The loop is what happens on the other ninety‑nine.
Briefwhat to build, what not to touch
Buildit types, you read every line
Verifytypes, tests, an end-to-end run, and somebody who is not you
Recordwhat changed, where the next session looks
Skip verify once and nothing happens. Skip it for a week and you cannot answer a single question about your own code.
Walk the four, and spend your time on VERIFY. The other three are admin. Verify is the one that decides whether any of this was real.
Verify is not a feeling. It is four concrete things: the type-checker, the unit tests, an end-to-end run against the real thing, and somebody who is not you reading it.
"I wrote it and I checked it" is one pass, not two. A fresh session, a colleague, or a test is the second one. Otherwise you are marking your own homework.
Where students feel this: the day-two problem. You come back and it has no idea what you agreed yesterday. That is not a memory bug, that is a loop you never built.
Do not let it sound like process for its own sake. Every move in there exists because I lost a night to skipping it.
What the difference actually costs
Six sessions, run two ways.
no loopPrompt, paste, hope
Six of these and you are a stranger in your own codebase.
the loopBrief, build, verify, record
Same six. Same speed. You can still explain all of it.
Click "run a session" five or six times while you talk. Do not narrate the dots, let them count.
The left column keeps collecting things nobody checked. The right closes them as it goes. Same number of sessions, same speed, on purpose. Say that: the loop is not the slow option.
Get to six. The bill only appears on the sixth click, so do not stop at four.
When it lands, stop talking and let them read it. It is the only slide in the talk where the punchline is a consequence rather than an idea.
Say the part the line cannot: "and the agent does not remember either. Whatever you taught it five sessions ago is gone, because you never wrote it down."
If the room is quiet, ask: "which column was your last project?" Nobody answers, everybody knows.
The move I'm proudest of
Make it fail loudly, or you will ship it.
A machine at speed does not produce louder bugs. It produces the same quiet ones, faster.
the trapUsed slightly wrong
designed outCannot be used wrong
A thing that fails loudly, you fix. A thing that fails silently, you ship.
Typesas you type
Unit teststhe logic
End to endthe real thing, driven like a user
Loud errorsno silent catch, no empty default
Click the left button twice. Nothing happens. No error, no warning. Let that sit, it is the whole argument.
"I kept tripping on my own system. The boring move is to squash each bug and move on."
"Instead we asked: why do I keep tripping on my own system? When half a class flubs the same question, the problem is the question, not the class."
Then click the right one. Same intent, works, because the misuse was designed out.
Now the four gates, and be concrete. Types and unit tests are the ones they already half-know. Spend the time on end to end, because almost none of them have run one.
The end-to-end line to say out loud: "unit tests prove the parts agree with you. End to end proves the product agrees with the user. An AI can satisfy the first and destroy the second in the same commit."
On loud errors: an empty catch block is the most expensive line of code a student ever writes, and an AI will write it for them without blinking unless you have said not to.
"An AI working from your docs is the ultimate stress test of clarity. It has no tribal knowledge."
Land the reframe plainly: "the mistakes stopped being bugs and started being data."
The unglamorous half, and the reason the rest holds
I audit far more than I build.
184
test files, across the seven repositories
2,159
test cases behind them
44
end-to-end specs on the portfolio alone, counted 19 August 2026
1
command that runs the lot, before anything counts as done
Most of my prompting is not "build this". It is "check this".
The second pass is done by a session that did not write the code, because the one that wrote it already believes it.
There is even a linter for the prose. The writing is part of the product, so it gets a gate like everything else.
Read the four numbers flat, no pride in the voice. They are not an achievement, they are the cost of going fast.
The line that matters: "most of my prompting is not build this, it is check this." Say it slowly, it is the single most useful sentence in the talk for a student who already uses AI daily.
On the second pass: a session that wrote the code will defend the code. A cold one will not. That is not a trick, it is the same reason you do not mark your own exam.
The prose linter always gets a reaction. Use it: "if the writing is part of the product, and I told you half the repo is writing, then of course it gets a gate too."
Anticipate the objection: "we do not have time for that at school." Answer: you do not need 104 test files. You need one, today, on the thing most likely to break.
Do not list frameworks. Nobody remembers a tool name and all of them will change. They remember "check this".
Say it, write it, or check it
A rule is only real once it can fail a build.
0times I have typed the same correction
The second time you correct it about the same thing, that correction has stopped being a conversation and started being a rule.
Click "new session" three or four times in silence. The repetition is the joke and the argument at once.
Then: "so I stopped saying it and wrote it down where the machine reads it. One line. It never came back."
Three buttons, three stages, and the slide is the stages. Say it: decays. Write it down: rots quietly. Make it a check: holds.
Do not rush to the third button. Sit on stage two, because stage two is where almost every team already is, and they think they have solved it.
Now scale the problem out loud: seven repos, seven slightly different sets of rules, drifting apart quietly, and nobody reading any of them, me included.
Two lines on the tool, no more: that is PANTRY. It installs into a project, serves the plans and docs and a map of the codebase to whatever agent opens the session, and a doctor command fails the build when the docs and the code have drifted apart.
Student version, and say it plainly: you do not need my package. A test that asserts your README's example still runs is the same move, and you can write it this week.
Honest limit, say it: it is mine, it is young, and I am the main user. The habit transfers, the code might not.
Timebox this hard. Two minutes. The link is on the last slide.
Strip all of it down
Same prompt. Same model. Same code.
The model was the same. It multiplied everything around it.
Callback to slide 4 and its slider. Name it, don't point: "same bars as the beginning."
The two chains are identical on purpose. Say that out loud: nothing in the middle row is better.
"That surrounding structure is the profession. The code is just the code."
You are not a zero, you are early. So, concretely
The same hour, spent two ways.
what you type
> write me the login form
after an hour
A working login form, and a tab you closed.
after a term
A folder of code you cannot defend, and the same first number you started the term with.
Faster output, same you. The multiplier never moved.
Then record it. In your docs, in your audit, in the file the AI reads first.
Let it learn the same lesson you just did, and hold it to that lesson tomorrow.
This is the slide they photograph. Flip the switch once, slowly, and let them read both columns.
Do not stop at the switch. The record beat is the one that compounds: the hour you spent learning something is spent once, and written down it keeps paying.
Say the accountability part plainly: "if I learned it and the model did not, I get to learn it again next week. Writing it down is how I stop repeating myself, and how I get to hold it to something."
Tie it back: this is the same move as the correction that becomes a check, at student scale. No tooling required, one file.
"I am not telling you to stay away from it. That advice is already dead, and you would ignore it anyway."
The reframe: a beginner using AI to produce is buying output. A beginner using AI to learn is buying reps. Same hour, different asset.
Answer the objection before they raise it: "but I have a deadline." Fine. Use it to produce, then pay the debt back that night by rebuilding one piece from memory.
The homework, out loud: next time it writes something for you, close the tab and rebuild it from memory. If you cannot, you did not build it, and you just found the exact thing to go and learn.
If you copy one slide, copy this one
Where to start, in order.
Pick a project you already understand.Not a new one. You cannot judge the output of a machine on a codebase you have never read, and judging the output is the entire skill.
Write the brief before the feature.One file at the root of the repo: what this is, how it is built, what not to touch. Twenty minutes, once. Every session after it starts smarter.
Turn on the cheap gates first.Types on and strict. One test that actually runs. No empty catch blocks. You can do all three before lunch and they will catch things all year.
Make it explain, then explain it back.Out loud, tab closed. The moment you cannot, stop: you have just found the exact thing to go and learn, which is worth more than the feature was.
Every correction you give twice becomes a line in that file.That is how the brief writes itself, and it is the whole of what I showed you earlier, minus my tooling.
Tell them to photograph this one. Then actually pause and let them, it takes four seconds and they will not do it if you keep talking.
Order matters, say so: people always want to start at 3. Starting at 3 on a project you do not understand teaches you nothing.
Number 2 is the one that feels like a waste of time and is not. Twenty minutes, once, and you are buying every session after it.
Number 5 is the trick that costs nothing. You are already typing the correction. You are just typing it somewhere it survives.
What to go and read is on the second to last slide. Point forward, do not read the list twice.
The habit that decides which of the two you become
Don't work for the AI. Run it.
working for itYou are the passenger
You ask, it answers, you paste.
The shape of the project is whatever it happened to produce.
When it goes wrong you ask it again, louder.
You are waiting on one chat window, doing nothing.
running itYou are the one conducting
You decide what should exist, before anything is typed.
You cut it into pieces small enough to check in a minute.
You point it at one piece, and read every line that comes back.
You accept nothing you could not defend without it in the room.
Same tool, same day, same model. One of those is a job. The other is a habit that does not survive contact with anything real.
This is the last idea in the talk, so slow all the way down. Both columns get read out.
The passenger column is not a strawman, it is how almost everyone starts, me included. Say that.
The tell is the second line on each side: who decided what should exist. That is the entire difference and it happens before a single prompt.
Some evenings I have several sessions open at once. It feels exactly like running a team, and it is the same skill: brief, delegate, verify, and never accept work you cannot explain.
Aim it at their future: "the job you are training for is not typing. It is deciding, delegating and checking. That job pays more and the machine cannot take it, because it is the thing being paid to be accountable."
The point
Bring nothing and it multiplies nothing.
Become a bigger number first. Then go make it dangerous.
Say the title of the talk here, for the first time since slide 1: ten times zero is still zero.
Aimed at students: get so good at the fundamentals that when you finally pick up the power tool, it multiplies something real.
The homework, out loud: "next time AI writes something for you, close the tab and rebuild it from memory. If you can't, you didn't build it, and you just found the exact thing to go learn."
Then one breath, and the last slide.
None of this is mine, and you should go to the sources
What to read next.
Loop EngineeringAddy OsmaniThe case that durable AI work is built from a few reusable parts, not a clever prompt. Where the loop on slide 23 comes from.addyosmani.com/blog/loop-engineering
Beyond Vibe CodingAddy OsmaniThe 70% problem: it gets you most of the way and the last stretch is where unmanaged work rots. Plan first, and treat quality gates as non-negotiable.beyond.addy.ie
Learning AI-Native Software EngineeringAlfonso GrazianoContext engineering, spec-driven development, verification gates. Most of slide 22 traces back to this one.alfonsograziano.it/book
agent-skillsAddy OsmaniThe loop, in executable form: skills an agent loads on its own. Install with one command and read them even if you never run them.github.com/addyosmani/agent-skills
Spec KitGitHubSpec-driven development, formalized and free. The most direct way to try "write the rails first" without inventing your own process.github.com/github/spec-kit
llms.txt and MCPthe conventionsHow a project tells an agent what to read first, and how an agent reaches your tools. Worth an evening each.llmstxt.org · modelcontextprotocol.io
My standards, in fullfree, and stealableThe written version of everything in this talk: the loop, the session rules, the writing standard. Take what is useful, ignore the rest.tjakoen.github.io/standards
Say the honest thing first: the ideas are not mine. I read these, argued with them, and built something that runs. That is the whole method and they can do the same.
Do not read the list aloud. Name the two you would start with and move on: Beyond Vibe Coding for the why, Spec Kit for something to do on Monday.
Paste the links in the chat now, not after. Nobody types a URL off a slide.
Thank you
I don't prompt and pray. I prompt and prove.
The whole post, receipts and all. Plus the playbook, in writing.
tjakoen.github.io/notes/ten-times-zero
The judgment is human. The typing, by design, is not.
Paste the link in the chat as this slide lands. The QR is for whoever watches the recording.
Take questions. If nobody asks, ask the chat: "who has shipped something they couldn't explain?"
1 / 34
1 / 3400:00
Next
Arrows here drive the main window · T resets the clock · the clock turns accent past 20 minutes