Getting Better

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.

Four questions, asked honestly, tell you more than any amount of feeling productive:

1. 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. 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. 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. 4

   Do you catch bugs before shipping?

   If users find them and your review does not, the review is decorative.

Volume alone does not build skill — the same shallow loop repeated stays shallow. Three exercises worth doing on purpose:

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.

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:

1. 1
   Knowing what the model can and cannot see

   Explains most of its behaviour, and no version bump changes that.

2. 2
   Working in small, verifiable steps

   Predates AI by decades and will outlast it.

3. 3
   Reading a diff properly

   The skill that makes speed safe.

4. 4
   Knowing when not to use it

   Judgement is the part that is yours.

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.