Getting Better
How to tell whether your output is actually improving, instead of just feeling faster.
The last chapter, and the one that determines whether the other twenty-eight compound. Vibe coding has a specific trap: it feels like improvement long before it is improvement, because output volume goes up immediately and skill does not.
Speed is not the same as skill
In week one you will produce more code than you ever have. That is real, and it is not evidence that you got better at software — it is evidence that typing was never the bottleneck.
The honest question is not “how much did I ship?” It is: could I maintain what I shipped? A project you cannot debug is not an achievement that has been delivered early; it is a debt that has been taken out.
Measure something real
Four questions, asked honestly, tell you more than any amount of feeling productive:
- 1
Can you explain your own project?
Pick a file you accepted last week. Without looking at it, describe what it does. Then check.
- 2
How often do you accept without reading?
Count it for one day. The number is usually higher than people expect, and it is the single best predictor of a codebase you cannot maintain.
- 3
How many prompts to a working result?
Going from five to two on the same kind of task is real, measurable prompting skill.
- 4
Do you catch bugs before shipping?
If users find them and your review does not, the review is decorative.
Practice that actually builds skill
Volume alone does not build skill — the same shallow loop repeated stays shallow. Three exercises worth doing on purpose:
Try each of these
- →Predict before you read. Before opening a generated diff, say what you expect it to contain. Then check. Your prediction accuracy is a direct measure of how well you understand your own project.
- →Write it yourself first, sometimes. Attempt it by hand, then ask for a critique. You get the struggle that builds skill and the feedback that corrects it.
- →Explain the code to someone. Or to a text file. You will discover the parts you only think you understood within about two minutes.
Turn the tool on your own work
The AI is a reasonable reviewer of your process, not just your code — provided you ask it to be critical rather than encouraging:
Here are five prompts I wrote this week and the resultsI got. Do not be encouraging — tell me what is weak abouthow I am asking, what context I keep failing to provide,and what I should do differently.Models default to being agreeable. You have to explicitly ask for the other thing, and when you do, the feedback is usually specific and usable.
What to keep as the tools change
Most specifics in this course have a shelf life. Model names will change; the tool you set up in Chapter 4 may not exist in three years. What survives is smaller and more durable:
- 1Knowing what the model can and cannot see
Explains most of its behaviour, and no version bump changes that.
- 2Working in small, verifiable steps
Predates AI by decades and will outlast it.
- 3Reading a diff properly
The skill that makes speed safe.
- 4Knowing when not to use it
Judgement is the part that is yours.
The shape of what you built
Twenty-nine chapters is a lot to hold at once, so here is the shape of it compressed to one line per part — not to re-teach any of it, but so you can see what you actually assembled.
You went from an empty terminal to a running app you built with a tool, not despite one.
You learned what the model can actually see, which explains most of what used to look like guessing.
Prompt, generate, review, test, commit — the cycle you now do without thinking about the steps.
You learned that the same prompt means something different in someone else's fifty-thousand-line repository.
Debugging, tests, and a security pass — the checks that catch what confidence alone does not.
Getting it in front of people, and the unglamorous work of keeping it alive afterwards.
Agents, orchestration, and tools of your own — the parts of the job that scale past one person typing.
What this course could not teach you
None of that is the hard part, and it would be dishonest to end here implying it is.
A course example is sized to be solvable in an afternoon. A real codebase carries three years of decisions nobody remembers making, a stakeholder whose “make it faster” means five different things depending which week you ask, and an incident at eleven at night where the fix has to be right the first time because there is no second deploy window before the meeting.
None of that is teachable from a chapter, because the skill involved is not a technique. It is judgement, built from having been wrong enough times to recognise the shape of a mistake early. This course can hand you the loop, the checklists, and the vocabulary for the trade-offs. It cannot hand you the accumulated hours of having been burned by a plausible-looking answer that was wrong in a way only experience would have caught in time.
Where this leaves you
None of that is a reason to stop, and it never has been the point of a first course anyway.
You started this course being told what vibe coding is. You now have a project you built, a workflow you can repeat, and — more useful than either — a sense of when the tool is helping and when it is quietly making things worse.
The people who get the most out of this are not the ones who prompt the most. They are the ones who stayed curious about the code that came back. Keep reading what it writes, keep asking why, and the tools will keep getting better underneath you.
Key takeaways
- Output volume rises immediately; skill does not. Do not mistake the first for the second.
- The real question is whether you could maintain what you shipped.
- Count how often you accept without reading. It predicts everything else.
- Predict what a diff will contain before opening it — that measures real understanding.
- Ask the AI to critique your prompting, and explicitly tell it not to be encouraging.
- What survives the tools changing: knowing what it can see, small steps, reading diffs, and judgement.
- A course can give you the loop and the checklists. It cannot give you the thousand hours of judgement only repetition builds.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 3 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.