Choose your starting point · 04 / 15
Start here: vibe coder
You already know how to turn an idea into a demo with AI assistance. Keep that speed. The next step is becoming the person who can read the changes, find the bug, protect the data and keep the application running after the demo.
Your first week · 10 focused hours
- 1 hour: choose one of your existing apps. Draw the path from a button click to the server, database and model. Identify where credentials live.
- 2 hours: read one request handler line by line. Explain each dependency and remove code you cannot justify.
- 2 hours: write tests for one feature. Make a test fail intentionally before fixing the code. Watch CS50P Unit Tests ↗.
- 2 hours: diagnose a deliberately broken API URL, missing environment variable and invalid JSON response. Write the exact failure and fix.
- 2 hours: rebuild a small endpoint from a blank file using documentation and targeted hints.
- 1 hour: make a small Git branch and review the diff before merging it.
Choose the size of your bridge
If functions, loops and dictionaries still feel unfamiliar, use the beginner route. If those are comfortable but tests, HTTP, SQL or deployment are weak, complete the foundations diagnostic topic by topic. Being able to generate a working screen is useful evidence of product thinking, but it does not substitute for operating the system.
An AI-assisted workflow you can defend
- Write the acceptance criteria yourself before generating code.
- Ask for a small change with an explanation of the tradeoffs.
- Read the diff and run meaningful tests, including a case the generated code handles badly.
- Explain the change without the chat history. Rebuild a critical function once unaided.
- Save a short engineering log: what changed, why, what failed, and how you verified it.
Planning allowance: 160–240 focused hours, about 16–24 weeks at 10 hours/week. Spend the extra bridge time on the areas your diagnostic reveals. You do not have to stop using AI tools to become an engineer; you do have to own their output.
You can add a feature, write a test that detects a real bug, follow a request across the app, diagnose a deployment failure, and explain the security boundary. If any part is guesswork, return to that foundation.
Your lesson resources
Download these files to follow along and put the lesson into practice.