Why the core catalog?

The skill worth building is synthesis, and implementation is where you practice it under controlled conditions. Reasoning about a system means holding its pieces in your head at once: what each one has to guarantee, the techniques required to fulfill each requirement, and how they constrain each other. That's hard to learn on a real system, because a real system buries the reasoning under everything incidental, like the build setup, the legacy decisions, the ten files you read before the relevant one makes sense. Implementing something self-contained strips all of that away. It doesn't remove the friction entirely. It trades the incidental noise of a real system for one deliberate kind: the noise of writing the code itself. That trade is the whole point. The code is friction you can put in front of a judge, something with a correct, expected behavior you either match or don't, which means the skill can be trained and measured in isolation instead of tangled up in everything a real system drags along.

And yes, a model can probably one-shot questions like "implement vector" or "implement a decision tree." Most of these exercises are one-shottable, and that's easy to read as proof they're pointless. It's the opposite. A model solves them precisely because both things it needs are already handed to it. The spec is complete, so all that's left is translating it into code, which is the part models are best at. And the problem is standard, so the model already carries the knowledge of how the pieces fit, because that fit has been worked out a thousand times before. Both of those are exactly what the exercise is supposed to build in you. When you do it yourself with minimal help, you're not just practicing the translation. You're deriving why these pieces go together instead of receiving it pre-assembled, which means you come away both better at connecting techniques and with a deeper understanding of each component. The model having that knowledge baked in is the tell: that knowledge is the prize, and letting the model supply it is how you never acquire it.

So you might ask the obvious question: then why not test that directly? Drop the implementation and just test whether someone can take a goal, name the techniques, and assemble them into a spec. The honest answer is that you can't grade that in a controlled loop with a right and wrong answer, and the whole value here came from having a judge that does. If you're confident you don't need the reps, there is a real alternative, which is to go build projects. That's the same synthesis, just ungraded and in the open. But notice who can already do it: the people who build real projects are almost always already strong at implementation, because that's how they got there. "Just build projects" isn't a way around implementation. It's implementation with the training wheels off.

That's why we built the core catalog. Real work doesn't come with a spec, it comes with an idea, and nobody hands you the components and their contracts. You start from "I want to build X" and have to decide what X decomposes into, which techniques realize each piece, and how they connect. Practicing that on something like vector, where the spec is small enough to fit in your head, is the rehearsal that lets you do it later on specs that are yours to write and systems large enough that getting the decomposition wrong actually costs you. If you've already built something big and real, you probably don't need us. Most people haven't, and that's usually exactly why they're stuck.