Level 01 · Ground school
You have an idea, a chat window, and no idea what you are looking at.
This is where most people either build the habit that carries them for years, or quietly conclude they are not technical. The difference is rarely talent. It is knowing what the machine is doing and what it will never tell you.
You are here if
- You can describe what you want, but you cannot judge what comes back.
- It worked, then it stopped, and you cannot tell which change did it.
- You have started the project over more than once because it got tangled.
- You do not know what half the files are for, and you are afraid to open them.
What the model is actually doing
A coding model predicts plausible code. That is not a criticism, it is the mechanism, and knowing it changes how you work. It has no memory of your project beyond what is in front of it, no way to run what it writes, and no concept of whether the file it just edited is the one your app actually loads.
It also has no way to say “I do not know”. Faced with an unfamiliar library it will invent a function that sounds exactly right. The code will look correct, read correct, and fail on the first run. Your job at this level is not to write code. It is to supply the context the model lacks, and to check the one thing it cannot: whether the thing runs.
The loop that works
One change at a time. State the goal and the constraint (“add a delete button to the task row; do not touch the styling”), read what changed, run it, and commit the moment it works. The commit is the important half: it is the point you can return to when the next change goes wrong.
The loop that fails looks like asking for five things at once, accepting all of it, running none of it, and discovering an hour later that something in the middle broke. When that happens you cannot bisect the problem, because there is no moment you know was good.
The twenty minutes that save a fortnight
You do not need a computer science degree. You need six ideas: what a file and a folder are, what it means that a server is running, what a package is and why versions matter, what an environment variable is and why it is not in your code, what a commit is, and how to read an error message from the bottom up.
That is genuinely most of it at this level. Everything else you can ask for. But without those six, every explanation you receive lands on nothing, and you end up pattern-matching instead of understanding.
How to tell when it is confidently wrong
The tells are consistent: a function that calls something you have never installed, an import from a file that does not exist, configuration for a service you are not using, and the phrase “this should work”. Anything hedged is worth checking first.
There is only one reliable check, and it is not reading. Run it. Then read the actual error text and hand that text back verbatim, not a summary of it. “It broke” starts a guessing game; the stack trace ends one.
Run it yourself
The checklist we would run.
There is nothing held back in it. If you work through this list and nothing on it is open, you have left this level, and you did not need us to do it.
- 01
Git is initialised and you commit after every working change
Not at the end of the day. After every change that works, with a message that says what it does.
- 02
You can start it from a fresh terminal in under a minute
If you cannot, write the command down in a README. Future you will not remember it either.
- 03
You can get back to yesterday
Practise it once, on purpose, while nothing is broken. Reverting for the first time in a panic is how projects get abandoned.
- 04
The model gets the real error text
Copy the whole thing, including the file and line. Paraphrasing throws away the part that identifies the bug.
- 05
You keep a plain notes file of decisions
Three lines per decision: what you chose, what you rejected, why. It is the context you will need to give the model in a month.
- 06
Nothing secret has ever been typed into a file you committed
Keys, passwords, tokens. If one has, treat it as public and rotate it: git remembers deleted lines.
What done looks like
- You can break it and get back within a minute.
- You can describe a bug precisely enough that someone who cannot see your screen could work on it.
- Your commits are small and their messages are true.
Where it usually goes wrong
Starting over instead of reverting
A tangled project is almost never worth rebuilding at this level. The tangle will reappear, because the tangle is the process, not the code.
Asking for a rewrite instead of a fix
“Rewrite this file to also do X” throws away everything that worked. Ask for the smallest change that makes X true.
Letting one small change touch ten files
If the diff is bigger than the request, stop and ask why. It is usually the model solving a problem you did not have.
If you want company
We teach the loop that actually works: what to ask for, how to read what comes back, when the model is confidently wrong, and which twenty minutes of fundamentals save a fortnight. No curriculum, your project as the material.
If you would rather learn this on your own project than on a course, that is exactly what we do at this level.
It starts with a conversation and innovate@isyncso.com, subject Hangar. Tell us the level you landed on and what is in front of you. If the answer is on this page, we will say so.