Level 02 · First flights
It runs on your machine, you are moving fast, and it is starting to fight you.
Everything still works, and every change costs a little more than the last one. That curve is not inevitable. It comes from a codebase that has outgrown what the model can hold at once, and from features that were never finished, only demonstrated.
You are here if
- A change in one place breaks something in a place you were not looking.
- There are files you avoid opening.
- The model keeps rewriting things you did not ask it to touch.
- It works when you demo it, and falls over when someone else clicks around.
A shape the model can hold
The practical limit is not the context window, it is comprehension. A 1,200-line file that does routing, database access and rendering will get edited correctly about half the time, because the model has to hold all three concerns at once and guess which one you meant.
Split by job, not by size: this file talks to the database, this one decides what happens, this one draws. Name things for what they are. The payoff is immediate, because from then on you can point at one small file and say “only here”.
Diffs, not rewrites
Ask for the change, not the file. “Add pagination to the list query, leave everything else alone” produces something you can read in ten seconds. “Update this file to add pagination” produces a new file you have to re-verify entirely.
When a model does return a whole file, do not paste it in. Ask what changed. If it cannot tell you in three lines, it does not know either, and you are about to accept a rewrite you cannot review.
A working feature versus one that demos
The demo path is the happy one: the right data, one user, nothing empty, nothing slow. A feature is finished when the other five states are handled: empty, loading, error, refreshed mid-action, and a second person doing it at the same time.
This is where most vibe-coded projects quietly accumulate their debt. Not in the architecture, in the states nobody clicked. Adding them later is three times the work, because by then the code has been built on the assumption they cannot happen.
When to stop asking and read
If you have asked for the same fix three times and got three different wrong answers, the model does not have the information. Stop. Open the file, read the twenty lines around the problem, and describe what you see. Almost always the missing piece is something only you can see: a value that is not what you assumed, a file that is not the one being loaded.
You do not need to be able to write the code to read it. Reading is a much lower bar, and it is the skill that ends the loop.
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
No file does more than one job
Data, decisions, and display separated. It is the single highest-leverage change at this level.
- 02
A README that says how to run it and what it needs
Three commands and a list of environment variables. Write it for someone who has never seen the project, because in three months that is you.
- 03
Experiments happen on a branch
So a wild afternoon with the model is never the thing standing between you and a working version.
- 04
You can explain every dependency you added
If you cannot say what it does and why the built-in option was not enough, remove it. Each one is code you now maintain.
- 05
Every feature handles empty, loading and error
Check them by making them happen, not by reading the code.
- 06
You have opened it in a second browser as a second user
It is the cheapest test there is, and it catches an entire class of bug at once.
What done looks like
- A change in one place does not surprise you in another.
- You can point at the one file that owns a behaviour.
- Someone else could clone it and run it from the README alone.
Where it usually goes wrong
Refactoring everything at once
Split one file, run it, commit. A four-hour reorganisation with no working checkpoint is how a good week ends badly.
Adding a framework to solve a discipline problem
A new tool will not stop the model rewriting your files. Smaller asks will.
Treating the demo as the finish line
The gap between demo and product is mostly the states nobody clicked, and it is bigger than it looks.
If you want company
The habits that keep speed past week three: version control you trust, a shape the model can keep in its head, prompts that produce diffs instead of rewrites, and a way to tell a working feature from one that only demos.
If it is fighting you and you cannot see where the tangle is, a second pair of eyes on the shape of it is usually a short conversation.
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.