I’ve started to notice some patterns in how I work on software projects.
Specs as mini-pools
I often sit down and just write a spec. Even if I never build it, the spec itself is a kind of temporary pool: a place where scattered ideas turn into something concrete enough to extract from later.
When I say “write a spec”, I actually start with a “brief” and the spec flushes out over time. AI helps to build out the spec through back and forth, and by reverse-extracting changes to a system. I’m excited for more tools that will help with extraction and syncing. If we can get there, specs can become the source of truth.
It’s important to do so. I was talking to a friend recently who works on spec driven systems and we kept discussing the analogy of building a house.
Imagine meeting with your architect and having a conversation about what you want to build. It starts high level, and the architect comes back with options which you iterate on together. The architect flushes out actual designs, and you can communicate around the nice 3D models vs. the blue prints.
Now imagine meeting with the GC and you just start riffing on what you want to built. Obviously crazy… things get written down and everyone aligns around the same shared sources.
We also have inspectors to verify that that build matches the design and follows all of the building codes. Yes, we have building codes that are shared sources of truth and constraints.
Right now we are still relying on a lot of “talk to the builder and they go off and try to build what you just said” with chat based agents. Over time we will add more shared sources, will have better verification, and this will enable us to scale what we build.
Faster cheaper smaller models
We often think about how specifying things well leads to higher quality output from models. This is true. What is often under appreciated is that it also means that you can use a variety of models to do the job.
Asking a SOTA galaxy brain that has knowledge of Genghis Khan, every language, and on and on can often be overkill. You can do hundreds or even thousands of “flash” calls for the price of one larger call. Thus, having the right knowledge available can allow a small model to give you what you need very quickly and cheaply… especially if a fix loop is applied.
Throwaway projects
I spin up tiny projects all the time, just to try something out. Most of them don’t live very long, but that’s the point—they’re cheap experiments that give me a quick pool of learning before I move on.
Shopify’s Tobi published a repo that helps make this easy:
Repo extractions
Sometimes I yank code out of a larger repo, or glue pieces together from a few repos, and build something smaller and more focused. By narrowing the scope, I create a pool that’s easier to wade into.
Because LLMs are so great at taking different information and translating it for your needs, this can happen in interesting ways. Where I would look for more abstractions and shared libraries in the past, it’s more murky now when I can easily create exactly what I need.
It turns out, all of these are me making temporary pools of extraction. And once I noticed that pattern in my own work, I started seeing it everywhere—especially in how LLMs and even our own brains operate.
Pools of Extraction in LLMs
LLMs have two big pools to fish from:
- The latent pool: everything baked into their weights from training. Big, deep, and fuzzy.
- The contextual pool: whatever you feed them right now—repos, docs, examples. Sharp, specific, but fleeting.
If you ask a model a question without any context, it dives into the murky depths of its latent pool and hopes to surface something useful. Hand it your relevant code repo, and suddenly it’s swimming in a nice, clear backyard pool with everything it needs right there.
That repo context might not live beyond the session, but while it’s there, it massively increases the odds of good output.
Pools of Extraction in Humans
Humans work in a parallel but messier way. If someone asks me about a library I used years ago, I might dredge up the answer from long-term memory. But if I’ve got my old notes or an example in front of me? Way easier.
Psychologists call these retrieval cues—they reactivate the right pathways so memory reconstructs itself. And unlike LLMs, every time I do recall something, I actually change the memory. My brain’s wiring shifts a little. With LLMs, nothing changes in the weights—context pools evaporate when the session closes.
Conclusion: Build Better Pools
Specs, toy projects, repo extractions—these are all ways I give myself better pools to draw from. LLMs need the same treatment: without context they flail, with it they shine. Humans too: notes, cues, and scaffolds make the difference between blank stares and “aha!”
So now when I’m stuck, I don’t just hope the big pool will have the answer. I ask myself: what’s the smallest pool I can create right now to make extraction easier?
It’s all open book tests from here.
That’s when things click.
