Lighthouse Chart — Sam Park

1. Opening / Bearings

You have been writing Python and running your own server for four years, and now you want the AI tools to actually keep up with you — not slow you down with suggestions you have to undo. Three specific things are on the table: catching your own bugs before a PR lands, getting real test coverage on a module you already know works but cannot prove it, and shipping one portfolio project that demonstrates you can take something from blank repo to live URL. That last one matters more than it might look on the surface, because it is the artifact that will do the talking when college applications open.

Four weeks, three sessions a week, 45 minutes a session. That is 12 sessions total — enough to build real habits without burning out on evenings you do not have. The plan below treats your time as the constraint it is.

One thing worth naming at the start: you already know the craft. The AI tools here are not teaching you to code — they are giving you a faster feedback loop on code you already know how to write. That framing matters, because it changes how you use the tools. You are not asking Claude or Copilot to think for you; you are asking them to be a second pair of eyes that never gets tired.

2. Track Context

Your track is Developer Camp — specifically the flavor of it that is about integrating AI into a solo engineering workflow rather than learning to build AI systems from scratch. That distinction is worth being clear about, because the two paths look similar from the outside but pull in different directions.

The developer-camp track for someone at your level is about three things:

Closing the feedback loop. Right now, the gap between writing code and knowing whether it is correct is filled by running it, reading it again later, or having someone else review it. AI shrinks that gap. A well-prompted Claude review of a diff takes about two minutes and surfaces the class of bugs — off-by-one errors in date ranges, missing None checks, SQL edge cases — that are easy to miss when you wrote the code five minutes ago.

Generating the scaffolding you already know how to write. Copilot is best used not for the interesting parts of your code but for the parts you could write yourself in ten minutes but would rather not: boilerplate test fixtures, repetitive route handlers, standard error-handling patterns. Let it generate those so you spend your 45 minutes on the parts that require judgment.

Building a paper trail. For university applications, "I used AI tools" is less interesting than "here is a live project, here is the test suite, here is the commit history." The goal of this plan is to produce exactly that paper trail — concrete, public, and yours.

The secondary track here is teammate-developer, which reflects the open-source contribution habit you already have. The PR review workflow you build in week one will transfer directly to the quality of the PRs you submit to external repos.

3. Goals and Success Metrics

Your three outcomes, in priority order:

1. Use AI code tools to review and improve your own pull requests before merging. The metric is five PRs reviewed with AI before submitting. This is the highest-leverage habit in the plan because it compounds — every project you work on for the rest of your life will have PRs, and a reliable pre-merge review habit pays dividends indefinitely. The goal in week one is not to find the perfect prompt; it is to run the workflow on real diffs until it becomes automatic.

2. Generate tests for an existing Python module you built last year. The metric is 70% coverage on that module. Note what 70% actually means: it is not "AI wrote tests and you ran them." It is "the tests execute 70% of the code paths and each test has a meaningful assertion." Coverage without assertions is a false sense of security. The sessions in week two are structured to catch that distinction early.

3. Ship one portfolio project using AI-assisted development from start to finish. The metric is the project live on GitHub Pages or equivalent by end of week four. "AI-assisted from start to finish" means you used AI at every stage — spec, scaffold, code review, debugging, deployment config — not just autocomplete. The commit history and the README should make that visible to anyone reading your repo.

What is not in scope: learning a new language, working in a team environment. Both of those are real things worth doing eventually, but they are not what the next four weeks are for. Keeping the scope tight is how you actually ship the portfolio project.

4. Baseline and Pacing Note

You are coming in with a strong foundation: four years of Python, Git fluency, VS Code, Copilot on the student plan, and Claude.ai. Your comfort with building with AI is already a 3 out of 5 — meaning you have used these tools and gotten something out of them. The gaps are in writing with AI (2/5) and automation (2/5), which maps directly to the two skills this plan develops: prompting Claude for code review and test generation, and building a repeatable workflow you do not have to think about each time.

The pacing is front-loaded by design. Weeks one and two focus on the two highest-priority goals — PR review and test generation — because those are the habits that will make week three and four (the portfolio project) go faster. If you nail the PR review workflow in week one, you will use it naturally on every PR you open during the portfolio build.

A note on the 45-minute sessions: that is a real constraint, not a suggestion. Each session in this plan has a single deliverable and a "done when" criterion. If you hit the criterion before 45 minutes, stop. If you are not going to hit it, narrow the scope rather than running over. Consistency across 12 sessions beats one heroic four-hour block.

5. Tasks and Projects

Week 1 — PR Review Workflow (Sessions 1–3)

Session 1: First AI-reviewed PR. Open a recent personal project diff with git diff main..HEAD. Paste it into Claude.ai using the ready-to-paste PR review prompt included in this chart. Read the output critically — you are not looking for Claude to be right about everything, you are looking for at least one thing you would not have caught on your own. Apply that fix, commit it. That is the session. One PR down, four to go.

Session 2: Tune the prompt. Run the same prompt on a second diff. Find one type of feedback that was too vague to act on — "consider adding error handling" is not useful; "the db.execute() call on line 14 has no try/except and will raise an unhandled exception on a connection timeout" is useful. Edit your prompt to ask for that level of specificity in the areas you care about. Save the revised prompt in a local prompts.md file. This file becomes your personal AI toolkit.

Session 3: Manual review first, then AI. Before running the prompt, spend 10 minutes reviewing the diff yourself and writing down what you find. Then run the AI review. Compare the two lists. This comparison is the most useful calibration exercise in the plan — it tells you exactly where AI adds value for your specific coding patterns and where it does not. Commit the PR with a note about one AI-suggested change you accepted.

By end of week 1: three of five PRs reviewed, a tuned prompt in prompts.md, and a clear sense of where AI review earns its keep in your workflow.

Week 2 — Test Generation (Sessions 4–6)

Session 4: Generate the initial test file. Open the Python module you want to test. Read through it and note every public function — this step matters because it primes you to evaluate the AI output rather than just accept it. Paste the source into Claude.ai using the generate-tests prompt. Save the output as test_[module_name].py. Run pytest --cov=[module_name] test_[module_name].py and record the starting coverage number. Do not try to improve it yet — just establish the baseline.

Session 5: Target the gaps. Run pytest --cov=[module_name] --cov-report=term-missing. The term-missing flag shows you exactly which line numbers are uncovered. Pick the three largest uncovered blocks and paste them into Claude.ai asking specifically for edge-case tests targeting those lines. Add the new tests. Re-run coverage. The goal is at least a 10-percentage-point increase from the baseline.

Session 6: Quality pass. Get to 70%. Then read every test in the file. If a test calls a function and only checks that it does not raise an exception, ask Claude to improve it with a meaningful assertion — what should the return value actually be? Remove or rewrite any test you do not understand. A test you cannot explain is a liability, not an asset. By the end of this session, you should be able to defend every test in the file.

This outcome — "Generate tests for an existing Python module I built last year" — will live in OpenBrain by Week 2. Specifically: after Session 6, capture the module name, the final coverage percentage, the test generation prompt that worked, and the coverage command you used. Store this in OpenBrain so that in any future Claude conversation you can ask "what was my test generation workflow?" and get a useful, specific answer — not a generic one.

Week 3 — Portfolio Project: Spec and Build (Sessions 7–9)

Session 7: Spec the project. Write a 2-3 sentence description of your project idea. Run the portfolio scaffold prompt. From the output, take the folder structure and the first three tasks — do not take everything, just those two things. Create the repo on GitHub (public), populate the README using the README template in this chart, and make the first commit. The repo existing and being public is the deliverable. Everything else is ahead of schedule.

A few project ideas that work well given your backend background and the free-hosting constraint: a self-hosted URL shortener with click analytics, a reading or habit tracker with a Flask API and SQLite backend, a personal finance log with a CSV import and a static summary page. Any of these can be built in the time available and demonstrates real backend skills. Pick one you would actually use.

Session 8: Build the core feature. Implement the single most important function or route. Use Copilot for the boilerplate — route handlers, database setup, standard error patterns. Use Claude.ai for design questions: "should this endpoint return 404 or 400 when the resource does not exist?" Write at least one test for the core function before moving on. This is the habit you built in week two; apply it here. Commit with a clear message.

Session 9: Second feature, first self-reviewed PR. Implement the second feature on a new branch. Open a PR against your own main branch and run your saved PR review prompt on the diff. Apply at least one suggestion. Merge. This is PR four of five. The PR review workflow you built in week one is now running on the portfolio project — that is the through-line of the whole plan.

Week 4 — Ship It (Sessions 10–12)

Session 10: Deploy. Get the project live. For a static front end or a pre-built export, GitHub Pages is the right call — it is free, it is already in your GitHub student pack, and it has zero ongoing cost. For a backend that needs to stay running, Render's free tier works for a personal project at this scale. Use Claude.ai to debug any deployment config errors — paste the error message and the relevant config file and ask what is wrong. Confirm the live URL works end-to-end. Update the README with the URL.

Session 11: Polish PR — fifth and final. Write a final PR with polish changes: better error messages, README improvements, a small UI fix, or a missing edge case you noticed during deployment. Run the AI review prompt one last time. Apply quick wins. Merge. This is PR five of five. The portfolio project is now in its final state and live.

Session 12: Capture and close. This session is about making the work durable. Open Claude.ai and run the "learn this session" loop: paste your prompts.md, your test coverage result, and the live project URL. Ask Claude to summarize your AI-assisted development workflow as a short checklist you can hand to your future self. Save that checklist back into prompts.md. Then ask yourself one question: what would you do differently on the next project? Write one sentence. That sentence is more valuable than any tool recommendation.

6. Setup and Constraints

Devices: Your M2 MacBook Pro is the primary machine for all sessions. The personal Linux server is available for anything that benefits from running continuously — a deployed backend, a cron job, a persistent process — but nothing in this plan requires it. Do not add complexity by splitting work across machines unless a specific project need demands it.

Accounts: GitHub student pack is already active — make sure GitHub Pages is enabled on your account (it is free with the student pack). Claude.ai free tier is sufficient for all the prompting in this plan; the sessions are designed around focused, single-purpose prompts rather than long multi-turn conversations that would hit rate limits. Copilot student plan covers autocomplete in VS Code.

Constraints: Free and open tools only — every tool in this plan is free. No paid APIs, no paid hosting tiers. Evening availability is limited — the 45-minute session cap is a hard constraint, not a suggestion. Each session has a single deliverable and a "done when" criterion specifically so you can stop at 45 minutes without feeling like you left something unfinished.

One tool worth adding to your setup: install pytest-cov if you do not have it already (pip install pytest-cov). That is the only new dependency this plan introduces.

7. OpenBrain — Foundational Setup

OpenBrain is a personal knowledge layer that travels with you across Claude.ai, Claude Desktop, Claude mobile, and any other surface where you use Claude. The idea is simple: instead of re-explaining your context every time you open a new conversation — "I am a Python developer, I have this module, I use this workflow" — you capture that context once and Claude can draw on it in future sessions. It is designed to be easy to set up, and it works especially well for a developer workflow where the context is technical and specific.

Setup on your M2 MacBook Pro:

1. Clone the OB1 repo: git clone https://github.com/NateBJones-Projects/OB1
2. Follow the README to install the MCP server locally — it runs as a lightweight background process
3. In Claude Desktop (download free from anthropic.com), connect the OB1 MCP server per the README instructions
4. Once connected, you can tell Claude to "learn" things and it will store them in your personal knowledge layer, queryable in any future Claude conversation

If you prefer to stay in the browser for now, Claude.ai's Projects feature (available on free tier) gives you a lighter version of the same idea — a persistent context window for a project that carries across conversations.

Three usage patterns for your track:

First, capture your PR review findings. After each AI-reviewed PR, tell Claude: "Learn this — I reviewed a PR for [project], the AI caught [finding], I accepted/rejected it because [reason]." Over time, this builds a log of the patterns in your own code that AI catches most reliably. You can query it later: "What kinds of bugs does AI review usually catch in my code?"

Second, store your working prompts. After you tune the PR review prompt in Session 2, tell Claude to learn the final version. Same for the test generation prompt after Session 6. These live in OpenBrain, not just in a local file — so if you are on a different machine or in a mobile session, you can ask "what is my PR review prompt?" and get it back.

Third, capture project decisions. When you make a significant technical decision during the portfolio project — choosing SQLite over Postgres, choosing GitHub Pages over Render — tell Claude to learn it and the reason. This is the kind of context that is expensive to reconstruct later and cheap to capture in the moment.

The "learn session" loop: At the end of any session where you made a meaningful decision, built something, or figured something out, open Claude.ai and say: "Learn this session." Paste the key outputs — a prompt that worked, a coverage number, a deployment URL, a decision and its rationale. Future sessions inherit that context. The habit takes about two minutes and pays back every time you start a new conversation without having to re-explain yourself.

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 specific" and "give examples" sections before Session 2 when you tune your PR review prompt. The core idea — that a prompt is a specification, not a request — will change how you write them.

GitHub (your home base) https://github.com Your student pack is already active. Confirm GitHub Pages is enabled on your account before Session 7.

30 minutes

OB1 — OpenBrain MCP server https://github.com/NateBJones-Projects/OB1 Read the README before Session 12. The setup is straightforward for someone comfortable in the terminal. The MCP server runs locally on your MacBook and connects to Claude Desktop.

pytest getting started https://docs.pytest.org/en/stable/getting-started.html Worth a skim before Session 4. You know what a unit test is; this fills in the pytest-specific conventions (fixture syntax, parametrize, conftest.py) that the AI-generated tests will use.

Deep dive

GitHub Pages documentation https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages Read before Session 10. Covers custom domains, Jekyll, and the difference between user pages and project pages — relevant if you want the portfolio URL to look clean.

Ollama — run models locally https://ollama.com Not required for this plan, but worth knowing: Ollama lets you run open-weight models (Llama, Mistral, CodeLlama) locally on your MacBook or Linux server with no API key and no rate limits. Useful for code-related tasks where you want to paste proprietary or sensitive code without sending it to a third-party service. Cross-platform — works on Mac, Linux, and Windows.

Osaurus — Mac-native local AI server https://github.com/osaurus-ai/osaurus The Apple-Silicon-native companion to Ollama. Uses MLX under the hood, which means it runs faster on your M2 than the generic cross-platform builds. OpenAI-compatible API, so anything that talks to the OpenAI API can talk to Osaurus with a one-line config change. Worth trying on your MacBook if you want local inference with better performance than Ollama on Apple Silicon.

9. Closing / Signals from the Keeper

Four weeks is a short time to build three durable habits. The way to make them stick is to finish each session with something you can point to — a merged PR, a coverage number, a live URL. Not "I learned about testing today" but "the coverage is now 58% and I know exactly which lines are uncovered."

The portfolio project is the thing that will matter most when you sit down to write college applications. A live URL and a clean commit history say more than any description of what you know. Build the thing. Ship it. Let it speak.

One last signal: the AI tools in this plan are good at the things you are good at too — reading code carefully, finding edge cases, naming things clearly. Use them as a mirror, not a crutch. When Claude catches something you missed, ask yourself why you missed it. That question is worth more than the fix.

The path is clear. Start with the first PR.