Lighthouse Chart — Alex Torres

1. Opening / Bearings

Three months ago you had no code, just curiosity and a willingness to poke at things. Now you have VS Code installed, a GitHub account, and a concrete thing you want to build: a web tool that tracks your reading list. That is not a small distance to have traveled, even if it does not feel like it yet.

The next six weeks have one job: get you from "I can follow a tutorial" to "I built this, I deployed it, and I can explain how it works." Not a portfolio. Not a job application. Just the satisfying, specific feeling of typing a book title into something you made and watching it come back with a real answer from the internet.

The plan below is built around your three goals in the order you prioritized them — Python first, then the web tool, with debugging woven through the whole thing rather than saved for the end. Every session has a concrete output you can hold. Every debug session is designed to make you stronger rather than more dependent. Sixty minutes, four times a week, for six weeks. That is enough.

2. Track Context

You are on the Developer Camp track — which is the right place for someone crossing the gap between "I use tools" and "I make tools." This track is not about becoming a professional engineer. It is about reaching the point where you can read a script, understand what it is doing, change one thing, and not be afraid of what breaks.

The specific shape of your six weeks looks like this:

Weeks 1–2: Python foundations. You already know what a variable and a function are. That is more than nothing — those two concepts are the skeleton of almost every script you will ever read. The first two weeks build on that skeleton: lists, loops, reading data, and making your first real API call. By the end of week 2 you will have fetched live data from the internet with a script you wrote yourself.

Weeks 3–4: Flask and the web layer. Flask is a lightweight Python framework that turns a script into a web page. It is the right tool for your reading list project — small, free, and well-documented. You will build the form, connect it to your API logic, and handle what happens when things go wrong.

Weeks 5–6: Deploy, debug, and document. Getting something running on your laptop is one thing. Getting it running at a URL anyone can visit is another. Week 5 is deployment. Week 6 is the thing most tutorials skip: writing down what you built in your own words, line by line, until you can explain it without notes.

The secondary track signal here is Creator/Comms — because the reading list tool is also a personal project you might want to share, and the habit of explaining your own code clearly is the same muscle as explaining anything clearly to an audience.

3. Goals and Success Metrics

Your three outcomes, in priority order:

1. Understand enough Python to read and modify simple scripts with AI help. The success condition here is not memorization. It is the ability to look at a script you did not write and say, "I know what this part does, and I know which line to change to get a different result." AI is explicitly part of the toolkit — using Claude to explain code is not cheating, it is the skill.

Metric: One working Python script that you can explain line by line. This is Session 11 in your plan — you will write a comment above every meaningful line of your finished app, read it aloud to Claude, and refine anything imprecise. That annotated file is the artifact.

2. Build a small web tool that connects to an API and displays results. The reading list tracker is the project. Open Library has a free, no-auth-required search API that returns book titles and authors in plain JSON. You will build a Flask app with a search form, connect it to that API, and deploy it on Render's free tier so it has a real URL.

Metric: One deployed personal project on a free hosting service. Session 9 is deployment day.

3. Reach a point where I can debug basic errors without giving up. This one is the hardest to measure and the most important. The plan builds in three explicit debug sessions — Sessions 4, 7, and 10 — where the goal is to work through a real error using AI coaching rather than asking for the answer. Each session adds an entry to a running error-log file.

Metric: Three debug sessions completed without asking for a full answer first. The error-log file is the evidence.

What this plan does not do: It does not try to get you job-ready or introduce a second language. Python only, for six weeks, until it feels like yours.

4. Baseline and Pacing Note

You know what a variable and a function are. You have used Claude for conversation, Replit for running code in a browser, and VS Code is freshly installed. Your comfort with building and automation sits at 1 out of 5 — which is honest and useful information, not a problem.

The pacing note is this: sixty minutes is enough for one thing. Not three things, not a whole concept — one thing with a concrete output at the end. Every session in this plan is scoped to fit that window, and every session ends with something you made rather than something you read.

A few calibration points for the early sessions:

• Python 3 is already on your M1 MacBook Air (macOS ships with it or prompts you to install it). Verify with python3 --version in Terminal before Session 1.
• VS Code with the Python extension is your primary coding environment. Replit is a useful backup when you want to test something fast without opening VS Code, but the main project lives locally.
• GitHub is set up. You will use it from Session 5 onward to commit your work — not for collaboration, just for version history and deployment.

The jump from comfort level 1 to "I built a deployed web tool" in six weeks is real but not unreasonable at four sessions a week. The sessions are sequenced so each one builds exactly one new concept on top of the last.

5. Tasks and Projects

Current work: tutorials and AI experimentation

You are following free coding tutorials and experimenting with Claude. Both of those habits are worth keeping, with one adjustment: make the tutorials produce something rather than just demonstrate something. After any tutorial you follow, open a new file and rewrite the example from scratch without looking — that gap between "I watched it work" and "I made it work" is where the learning actually happens.

For AI experimentation, the three ready-to-paste prompts in your content assets are designed for exactly where you are right now. Use the line-by-line explainer whenever you hit a script you do not fully understand. Use the debug coach whenever something breaks — before you ask for the fix. Use the API fetch starter when you are ready to build the reading list tool in Session 3.

The reading list web tool — session-by-session build

This is the main project. Here is how it unfolds across the six weeks:

Week 1 (Sessions 1–2): Python foundations. Session 1 is setup and your first script — three lines, a variable, a function, a print call. The goal is not to write something impressive. The goal is to run something and understand every word of it. Session 2 introduces lists and loops using book titles as the data, which is a direct on-ramp to the reading list project.

Week 2 (Sessions 3–4): First API call and first real debug. Session 3 is the moment the project becomes real: you will call the Open Library API with the requests library and print a live book title to your terminal. This is not a simulation — it is actual data from the internet, fetched by code you wrote. Session 4 is the first intentional debug session. You will break your own script in two specific ways, read the error messages, and fix both bugs using AI coaching rather than copying a solution. The error-log file starts here.

Week 3 (Sessions 5–6): Flask and the web layer. Session 5 introduces Flask — just enough to get a page visible in your browser. One route, one hardcoded book title, one commit to GitHub. Session 6 connects the form to your API logic: a text input, a submit button, and a live result. By the end of Session 6 you have a working local web app.

Week 4 (Sessions 7–8): Error handling and polish. Session 7 is the second debug session, focused on a real problem: what happens when you search for something that does not exist in the API. You will handle the empty-response case without crashing. Session 8 adds basic HTML structure to the results page and pushes everything to a public GitHub repo in preparation for deployment.

Week 5 (Sessions 9–10): Deploy and fix. Session 9 is deployment day. Render's free tier supports Flask apps, connects directly to GitHub, and does not require a credit card. You will get a live URL. Session 10 is the third debug session — one real bug from the deployment process, worked through with coaching, added to the error log.

Week 6 (Sessions 11–12): Document and reflect. Session 11 is the annotated walkthrough of your complete app.py — a comment above every meaningful line, refined until Claude confirms the explanations are accurate. By Week 6, your annotated app.py and your project understanding will be captured in OpenBrain (see Section 7), making it queryable from any future Claude conversation. This is the artifact that satisfies the first success metric: one working Python script you can explain line by line. Session 12 is reflection — evidence for each success metric, one fuzzy concept identified, one next project chosen.

OpenBrain artifact binding

By Week 6, your annotated app.py, your error-log notes, and your line-by-line explanations will be captured in OpenBrain as a queryable memory. This means any future Claude conversation — on your MacBook, on your phone, anywhere — can pick up exactly where you left off without you having to re-explain the project from scratch. The outcome "Understand enough Python to read and modify simple scripts with AI help" lives in OpenBrain by Week 6, not just as a file on your laptop.

6. Setup and Constraints

Devices: MacBook Air M1. Python 3, Flask, and all the tools in this plan run natively on Apple Silicon with no workarounds needed.

Accounts: Claude.ai free tier, GitHub (just created), Replit. You will add Render (free tier) in Week 5 for deployment. No paid accounts are required at any point in this plan.

Budget: Everything in this plan is free. Open Library API requires no key. Flask, requests, and gunicorn are free Python libraries. Render's free tier is sufficient for a personal project at this scale. GitHub is free. Claude.ai free tier is sufficient for the session volumes here.

Time constraint: Four sessions a week at sixty minutes each is 240 minutes — four hours. That is a real commitment alongside a part-time job. A few practical notes: sessions 1, 3, 5, and 9 are the highest-stakes ones (setup, first API call, first Flask page, deployment) — if a week gets compressed, protect those four. The debug sessions (4, 7, 10) can flex to 45 minutes without losing much. Session 12 (reflection) can be done in two shorter sittings if needed.

Privacy note: All the tools in this plan (Open Library API, Flask, Render, GitHub) are appropriate for public personal projects. Nothing in the reading list tool requires handling private data.

7. OpenBrain — Foundational Setup

OpenBrain is a personal knowledge layer that travels with you across Claude.ai, Claude Desktop, Claude mobile, and any other Claude surface you use. Think of it as a memory that Claude can actually read — so instead of re-explaining your project, your skill level, and your goals every time you start a new conversation, Claude already knows. It is designed to be easy to set up, and you do not need any coding experience to get it running.

Setup on your MacBook Air M1:

1. Install Claude Desktop from claude.ai/download — the Mac version runs natively on Apple Silicon.
2. Clone the OB1 repository: open Terminal and run git clone https://github.com/NateBJones-Projects/OB1.git
3. Follow the README in that repo to add the OpenBrain MCP server to your Claude Desktop configuration. The README has step-by-step instructions; it takes about ten minutes.
4. Once connected, Claude Desktop will have access to your OpenBrain memory layer. Claude.ai on the web and Claude on your phone will also be able to read from it when you are signed in.

Three usage patterns for your track:

• After a debug session: Capture what the error message said, what you tried, and what actually fixed it. Ask Claude to "learn this session." Future sessions will know your error-log history and can reference it when similar bugs appear.
• After building a new feature: Capture what the feature does, which files it touches, and any decisions you made about how to structure it. Ask Claude to "learn this session." When you come back after a few days away, you will not have to re-read all your code to remember where you left off.
• After a concept clicks: When something like request.form.get() or a Flask route finally makes sense to you, write a one-sentence explanation in your own words and ask Claude to learn it. This builds a personal glossary that travels with you.

The "learn session" loop: At the end of any meaningful working session — whether you built something, fixed something, or just understood something — ask Claude: "Learn this session." Describe what you did, what you made, and what you now understand. Claude will store that as a memory in OpenBrain. The next time you open a Claude conversation anywhere, that context is already there. Over six weeks, this compounds: by Week 6, Claude knows your whole project, your error history, and your mental model of Python — without you having to paste any of it again.

8. Resources and Links

5 minutes

Prompt engineering overview — Anthropic docs https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview Read the "Be clear and direct" and "Use examples" sections. These two techniques will immediately improve every prompt you send Claude during debug and explanation sessions.

OB1 — OpenBrain MCP server https://github.com/NateBJones-Projects/OB1 The README has the setup steps for Claude Desktop on Mac. Skim it before Session 1 so the Section 7 setup feels familiar.

30 minutes

Replit https://replit.com Useful as a scratchpad when you want to test a small idea without opening VS Code. Not your main environment, but worth keeping open in a tab for quick experiments in Weeks 1–2.

Flask quickstart https://flask.palletsprojects.com/en/stable/quickstart/ Read this before Session 5. It is short, and it covers exactly the three concepts you will use: routes, functions, and return values. The official docs are clearer than most tutorials for Flask.

Requests library quickstart https://requests.readthedocs.io/en/latest/user/quickstart/ Read the "Make a Request" and "Response Content" sections before Session 3. Two pages. Covers everything you need to make your first API call.

Deep dive

Next.js Learn https://nextjs.org/learn This is the right next step after Week 6 if you want to move from Flask (Python web) toward a JavaScript-based frontend. It is free, interactive, and well-paced. Do not start it during the six weeks — finish the Python plan first, then come back to this.

Render deployment docs — Flask https://render.com/docs/deploy-flask Read this in Week 5 before Session 9. It covers the exact steps for connecting a GitHub repo and configuring the start command. Having it open during deployment is fine.

9. Closing / Signals from the Keeper

Six weeks from now you will have a URL you can send to someone. It will fetch real data from the internet, it will handle a bad search gracefully, and you will be able to explain every line of the code that makes it work. That is not a small thing.

The plan is sequenced so that each session builds exactly one new concept. If a session runs long or something does not click, that is not falling behind — that is the work. The debug sessions are the most important ones in the whole plan, not because debugging is fun, but because every time you find an error yourself, the next error is a little less frightening.

One last thing: the error-log file you start in Session 4 is worth keeping long after these six weeks. The bugs you fix yourself are the ones you remember. Keep adding to it.

The path is lit. Go build something.