Pick your practice repository
The exercises need a real codebase. Which one you choose determines how much you actually learn.
You can read this course against a toy project, but the lessons that matter — exploration, steering, decomposition — only bite on code with real history and real mess.
What a good practice repo has
- Enough size that you cannot hold it in your head. Roughly 10k–200k lines. Below that, context management is never tested. Above that, the exercises get slow.
- A working test suite and type checker. You need the feedback loop from the previous lesson to actually exist.
- Some internal inconsistency. Two ways of doing the same thing, a legacy corner, a module everyone avoids. This is a feature, not a problem: it is what Module 05 teaches you to encode.
- Stakes low enough to experiment. A branch you can throw away without a conversation.
Three good choices, ranked
| Option | Why | Cost |
|---|---|---|
| A repo you own at work | You can grade every answer the agent gives, which is the whole point. You also get real value from the exercises. | Check your employer’s policy on sending code to a model provider first. This is not optional. |
| A side project you have neglected | You know it, nobody else is affected, and the neglect means it has real mess in it. | Test suite may be thin; you may have to build one in Lesson 4.6. |
| A mid-sized open-source project | Real history, real conventions, public issue tracker full of well-scoped tasks. | You do not know it, so you cannot grade the agent’s claims without checking — which slows you down but does teach verification. |
Watch out
Before pointing any agent at work code, know where the code goes. Which provider, under what data-retention terms, and whether your organisation has approved it. "The tool was already installed" is not an approval. If you are unsure, do the exercises on a side project and apply the process at work once the policy question is answered.
Set a task list
Pick three real tasks in that repo now and write them down: one small bug fix, one new feature that touches two or three files, and one thing you have been avoiding because it spans a lot of the codebase. Module 04 uses the first two. Module 06 uses the third.
Try it
Choose your repo, create the branch, and write your three tasks at the top of your scratch log. Be specific: "fix the date parsing bug in the CSV importer" beats "fix the importer".
Takeaways
- Use a codebase too big to hold in your head — that is the only way context lessons land.
- Existing inconsistency is useful material, not an obstacle.
- Settle the data-handling question before pointing an agent at employer code.
Why is an unfamiliar open-source repo a weaker choice than your own messy project?
Because you cannot grade the agent. Much of this course is about noticing when an agent is confidently wrong, and that requires ground truth you already hold. Unfamiliar code teaches you to verify, but it hides the failure modes you most need to see.
A course by Pieter Zandbergen