The Best Thing Claude Code Taught Me Was Something I Already Knew

• When building gets easy, the thing that derails you isn’t complexity. It’s opportunity. Ideas spiral before you can evaluate them.
• The icebox, a parking lot for every idea you’re not allowed to chase yet, was the most valuable thing I built. Not the code.
• PM fundamentals (scoping, prioritizing, parking ideas) saved this project. They transfer directly. They might be the point.

In the previous post, I wrote about testing whether building your own tools was actually accessible. This is what it looked like when I went deeper.

Everyone who’s used Claude Code says the same thing: you describe what you want and it just builds it. I’d heard it enough times to be jaded about it. But within a couple of hours of shipping v1 of this site, I was building something more ambitious: a system that could ingest client documents and answer questions about them. It was working the same day.

And that’s when the trouble started. Because when building is that immediate, ideas don’t stay ideas. They become prototypes. Prototypes become features. Features suggest other features. You look up and you’ve got this sprawling thing made of a dozen half-explored directions, and you realize: it’s very hard to make a move from here.

I’ve managed projects like this before. The ones where the scope starts expanding faster than anyone can evaluate what’s actually worth doing. I recognized it. I just didn’t expect it to happen to me this fast. The excitement, the potential, the sheer possibility of it. That’s what can derail you. Not the complexity. The opportunity.

I needed a plan. Not eventually. Immediately.

I threw everything into a conversation with Claude: ideas, goals, documents, questions. Help me make sense of this. Come up with a game plan.

What came back was a sprint structure, done criteria, and a focused proof of concept. If you’ve managed projects or run sprints, you know the shape of this: a backlog, a focused scope, and a parking lot for everything else. That’s the icebox. A list of every idea and feature I wasn’t allowed to build yet.

I’ve used some version of this on every project I’ve managed. The surprise wasn’t the technique. It was that it applied directly, one-to-one, to a side project I was building alone. The same discipline that keeps a team focused kept me focused.

Kieran Klaassen, who writes about building with AI at Every.to, argued recently that AI made us sloppy because it made us forget how to plan. I’d frame it a little differently. I didn’t forget to plan. I got swept up. The building was so immediate that I skipped the part where I figured out what I was building.

The icebox fixed that. Every time a new idea came up, it went on the list. Not thrown away. Parked. I could glance at it and know nothing was lost, just deferred. It was the difference between seeing this through and getting stuck in a feature hellscape of half-finished ideas.

If you’ve ever been in the middle of a project and felt that tension between the thing you’re supposed to be finishing and the idea that just showed up that feels way more interesting, the icebox is for that. It turns a distraction into inventory.

The POC tested a specific question: could AI extract key concepts from documents and track how those ideas evolve across files? I uploaded meeting transcripts, strategy notes, brain dumps. It worked, and where it broke was almost more useful.

The system confidently identified “Speaker Yeah” and “Like That” as key strategic concepts from my meeting transcripts. With confidence scores.

I laughed. Reading raw transcripts is brutal. They’re messy, full of filler, hard to learn from. But seeing how the system tried to filter and represent that data, watching it attempt to surface what mattered and fail in specific ways, that grounded me in the problem. It engaged the part of my brain I love working in: how do you represent messy information so it becomes useful? How do existing tools handle this invisibly? What layers of filtering and classification sit between raw data and something you can actually act on?

I started logging those questions. Not answers. Questions. I was learning to formalize the discovery phase, to treat “I don’t know yet” as progress instead of a blocker. Those question documents became some of the most useful output from the entire project.

Here’s the part I didn’t expect.

I came into this wanting to learn about AI tools: embeddings, retrieval systems, how models process documents. And I did learn some of that. But the thing that actually made the project work wasn’t technical. It was scoping. Prioritizing. Knowing when to park an idea instead of chasing it. Keeping momentum going forward instead of outward.

I’d been building those skills on other people’s projects for years, across branding, marketing ops, web, packaging. I just didn’t realize they’d be the most valuable thing I brought to this.

Building is an opportunity to exercise and evolve skills you already have. Not replace them. The technology handles the implementation. The strategy skills handle everything else. And building sharpens them in ways that managing someone else’s project never quite does.

Next post: everything that ended up on the chopping block, and why none of it was wasted.