The one idea
Never run code you have not read.
Not "read and fully understood" — that comes later, and takes years. Read means: you have looked at every line, you know roughly what each one does, and there is nothing in there you cannot account for.
AI writes code fast. Running it is the moment you take responsibility for it. Those are two separate decisions and you should make them separately.
Look at what it does before you let it do it. Especially anything that deletes, sends, or overwrites.
Read for three things first: what it touches on disk, what it sends over the network, and what it deletes or overwrites. Then run it on a copy.
Treat generated code as untrusted input. Review side effects before execution, run in an isolated directory, and prefer a dry-run mode before a destructive operation.
The loop
Building is not "describe it, receive it, done". It is a loop you go round several times. Each pass makes the thing more real and you more confident.
| Step | What you do | Why it matters |
|---|---|---|
| Describe | Say what it does, for whom, with what input and output | Vague input, vague output |
| Receive | Get code, and an explanation of it | Code without explanation teaches nothing |
| Read | Every line. Ask about anything unaccounted for | This is the safety step |
| Run | On sample data, in a folder you can afford to lose | Reality disagrees with plans |
| Change | Alter exactly one thing | Proves you understand where things live |
| Break | Feed it something wrong, on purpose | Shows you how it fails |
| Fix | Make it survive the wrong input | This is the actual engineering |
Build it now
The thing you build here is deliberately tiny: a script that reads a list of names and email addresses from a text file and tells you which lines are not valid email addresses. Small enough to read fully. Useful enough to be real.
Idea to working script
1 of 8Describe it properly before you ask.
Not "write me a script to check emails". Instead: "Write a Python script. It reads a file called
contacts.txtin the same folder. Each line is a name and an email separated by a comma. It prints each line number where the email looks invalid, and the reason. It must not modify the file. Add a comment on every section explaining what it does."Notice what you supplied: the language, the input format, the exact output, one hard constraint, and a request for explanation. That is the difference between a prototype and a guess. This is the same discipline as
frame-the-task-before-you-prompt.
A classmate builds the same thing by pasting the first answer and running it. It works on their machine. Yours also handles a missing file, an empty line, and a line with no comma — because you deliberately fed it all three.
At a viva or an interview, both projects "work". Only one of you can answer "what happens if the input is malformed?"
Someone asks you for a script to tidy a shared drive. You write it, but the first version only prints what it would rename, without renaming anything. You run it, read the list, spot two files it would have caught wrongly, fix the rule, and only then let it act.
That dry-run-first instinct is worth more at work than knowing any particular language.
Try this
An AI hands you a script and says it "cleans up your downloads folder". You see these three lines among others:
import os, shutil
for f in os.listdir(path):
os.remove(os.path.join(path, f))
What is wrong, and what would you ask for instead?
Your challenge
Level 3 · IndependentBuild one small tool that you will actually use this month. A file renamer, a CSV filter, an expense splitter, a text cleaner. Your choice, but it must solve a problem you genuinely have.
You have succeeded when all four are true:
- You can explain what every line does, in your own words.
- It handles at least two wrong inputs without crashing.
- You changed something in it after it first worked, on purpose.
- You used it for its real job at least once.
Point 4 is the one people skip, and it is the one that turns this into a skill.
What people usually get wrong
- Running code straight from the chat window. Read it first. Every time. The ten seconds this costs is the cheapest insurance in software.
- Asking for the whole thing at once. A hundred lines you cannot read is worse than twenty you can. Ask for the smallest version that does one thing.
- Not creating your own test input. Without a known-correct answer, you cannot tell success from a convincing failure.
- Changing five things then running. When it breaks you have five suspects and no information.
- Treating a crash as failure. A crash is a precise report of where the program stopped. Silent wrong output is far worse.
- Building in your real folders. Work in a scratch folder until the thing earns your trust.
How someone experienced does it
Experienced people make the destructive version last. The first version prints what it would do. The second version does it to a copy. Only the third version touches anything real. It feels slow the first three times and then it stops feeling like anything, because it prevented a disaster you never found out about.
They also ask AI for the smallest thing that works, not the most complete. A short program that does one job can be read in a minute and fixed in five. A long one with error handling, logging and configuration you did not ask for cannot be read at all, so you end up trusting it — which is the thing you were trying to avoid.
And they notice when the AI is confidently wrong about their own machine. It will suggest a command for the wrong operating system, or assume a tool is installed. That is not the AI failing; it genuinely cannot see your computer. Tell it what you are on, and what the error said.
Prove it
Record two things about the tool you built: the exact input that broke it the first time, and the change you made so it no longer breaks.
Those two lines are proof you did the loop rather than accepting the first answer. Keep them — this is what you describe when someone asks whether you can build things.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned building and running a small program with AI assistance. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood building and running a small program with AI assistance. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at turning an idea into a small working program — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.