Build an AGIBeginnerLesson 686 min read
Teaching this to the next builders
How to mentor someone β a curious teenager or a junior engineer β so they build systems that matter instead of another wrapper around a chat box.
Lesson in motion
In 60 seconds
Teaching this to the next builders
How to mentor someone β a curious teenager or a junior engineer β so they build systems that matter instead of another wrapper around a chat box.
1/6
In simple words
The best thing anyone can teach you is not how to make the computer talk. It is how to make the computer prove it is right, and then how to find a real problem worth pointing it at.
Three disciplines, in order. Almost everyone skips the first two and wonders why their project stalls.
1 Β· Deterministic guardrails over pure prompting
The instinct of every beginner is to fix a wrong answer by improving the prompt. It works just often enough to be a trap.
What a beginner builds
- A long, clever prompt.
- "Please be accurate" as an instruction.
- Fixes each failure by adding another sentence.
- Ships something that works in the demo.
- Cannot say why it failed on Tuesday.
What a builder builds
- A short prompt and a hard checker.
- Accuracy enforced in code, not requested in English.
- Fixes each failure by tightening the check.
- Ships something that works on inputs nobody imagined.
- Can replay Tuesday exactly.
Do this
The sentence to make them repeat until it is reflex: the model proposes, the compiler disposes. Once someone genuinely believes that, they design differently forever.
2 Β· State management
Every newcomer assumes the AI remembers. It does not β Module 5. Until that lands, they will build systems that mysteriously forget, and blame the model.
- 1
Make them prove it to themselves
Ask the model its own name in a fresh session. Watch them realise nothing carried over. Ten seconds, and it teaches more than an hour of explanation. - 2
Then hand them the paper metaphor
Everything the model knows this turn is on one sheet you hand it. It reads the sheet, replies, and forgets. Memory is you writing a better sheet. - 3
Then make them build the sheet
A conversation list. Then a state object. Then a database. Then retrieval. In that order β each step motivated by a limit they hit themselves. - 4
Then show them the cost
Print the token count each turn. Watching it climb makes context budgeting real in a way no lecture does.
3 Β· Solving real constraints
This is the one that separates a portfolio project from a company. Another chatbot wrapper is not 0-to-1 β it is 1-to-1.001, and there are ten thousand of them.
Point them at high-friction human workflows where the grunt work carries liability. The pattern to look for:
| Signal | Why it matters | Example |
|---|---|---|
| Someone does it manually every week | Real, recurring pain | Reconciling invoices against a ledger |
| Getting it wrong has a cost | Somebody will pay to be sure | Missing a compliance deadline |
| Correctness is checkable | You can build a verifier | Does this citation resolve to a real case? |
| The work is tedious, not creative | Nobody defends the status quo | Reading 400 pages for three clauses |
| A specialist is the bottleneck | Value is obvious and measurable | Only one person can review security questionnaires |
When all five are true, an autonomous loop is not a demo β it absorbs work a person genuinely does not want, and the checkability means you can prove it worked.
A first project that teaches everything
- Pick something checkable from their own life. Marking practice maths. Validating a CSV. Checking whether their code has tests.
- Build it as tier 1 first β just a prompt. Watch it be wrong.
- Add a checker. Watch it get reliable. This is the lesson.
- Add a loop so it fixes itself. Watch it recover from an error.
- Add state so it survives a restart.
- Ask them: what could this do if it were wrong and nobody was watching? Then build that limit.
- Only now, let it touch anything real.
Real example
The habit worth more than any framework. Every time they build something that acts, make them answer three questions out loud: What is the worst this could do? Who decided that was acceptable? How would we know? A builder who asks those automatically will be trusted with real systems β and a builder who does not, eventually should not be.
What to warn them about
- Demos lie. Anything works on the input you chose. Test on inputs you did not.
- Confident output is not correct output. The model's tone carries no information about its accuracy.
- The interesting part is not the model. It is the loop, the checker and the limits β all ordinary software they already know how to write.
- Autonomy is a dial, not a switch. Start at "suggest only" and earn each notch (Module 13).
- Ship something small that is actually used. One real user beats ten impressive prototypes.
Watch and read more
Lab
A first project for a beginner, designed by you.
The problem
Design a first AI project for someone new: checkable, useful, and with no chat interface allowed. Write the seven steps from Module 68 for their specific project, including the risk question they must answer before it touches anything real.
You are done when
Hard questions
Try to answer before you reveal. If you can answer these, you understood the lesson.
Q1Your student's tier-1 version works fine on their test cases. They see no reason to add a verifier. Convince them with an experiment, not an argument.Reveal
Have them generate 50 new test cases they did not write β from a different source, a different format, or a friend β and run the tier-1 version on those. The accuracy drop is the argument. Then add the verifier and re-run the same 50. Do not tell them the expected result; the gap between 'works on my examples' and 'works on examples I did not choose' is the single most useful thing they can discover for themselves, and it is far more persuasive than being told.
Questions people ask
What age can start this?
Anyone who can write a for-loop. The concepts here β propose and check, remember what you tried, stop when you are done β are not hard. The maths is optional and mostly irrelevant to building.
Should beginners use a framework?
Not for their first loop. Writing the twenty lines by hand teaches what the framework is doing. After that, use whatever saves time β the understanding is the point, not the line count.
How do I keep them from building another chatbot?
Ban the chat interface for their first project. Force the output to be a file, a report, a pull request, a passing test. It changes the whole design conversation.
What if they want to train a model instead?
Send them to Track E, Module 36 β the tiny-model project. An afternoon training a 10M-parameter model teaches more than months of reading, and it costs almost nothing.
Lesson test
5 questions. Get 3 right (60%) to pass and complete this lesson.
Sign in with your phone number to take the test and save your progress