# The Curation Trap: Why Builders Should Ignore the "Curation Over Creation" Trend > Source: > Published: 2026-07-15 01:26:36+00:00 Somewhere around 1am, staring at a wall of GitHub stars – fifty different vector database wrappers, all claiming to be “production-ready,” all with roughly the same README – you have to ask yourself a question. Am I picking the right tool, or am I just afraid to build the thing myself? That question is the whole shift, condensed into one tab of your browser. ## The Curation Instinct Is Everywhere There’s a real cultural argument going around right now that curation, not creation, is the scarce skill of the moment. Ivan Mato at Elmwood put it plainly: when AI unlocks near-infinite output, the bottleneck moves from making things to choosing things – what’s worth pursuing, what actually fits the brief, what cuts through a pile of “pretty good” options ([Creativepool](https://creativepool.com/magazine/leaders/the-one-skill-that-matters-in-2026-curation-not-creation.34233)). Saks Afridi frames it almost the same way from the agency side: in a world where anyone can generate anything, what separates good from great isn’t creation – it’s curation ([LinkedIn](https://www.linkedin.com/pulse/curation-new-creation-why-taste-still-matters-creatives-saks-afridi-voloe)). Even the softer, more personal version of this argument – [someone moving from B2B product marketing into social media management and noticing the exhaustion of constant output](https://thehubpublication.com/why-id-ask-you-to-consider-curation-over-creation-07b91452dbf2) – lands on the same conclusion: taste over volume. All of that is true. For marketing, for editorial, for anyone drowning in AI-generated “content” that all reads the same, curation is the differentiator. [Matteo Azzolini’s interviews with working curators](https://whyyoushouldcare.substack.com/p/the-creator-curator-hybrid) make the same case from the culture side – audiences want someone with taste to filter the noise, not more noise. But we build software. And for builders, the arrow points the other way. ## Where the Argument Flips Here’s the tension, and I want to name it directly instead of pretending it doesn’t exist: the content world is moving toward curation because creation got cheap and undifferentiated. The engineering world is moving toward creation because *building your own thing* got cheap enough that curating someone else’s half-fit solution stopped making sense. Same underlying cause – AI collapsed the cost of production – opposite conclusion, because the unit of value is different. A marketer’s output is a piece of content competing against a billion other pieces of content. An engineer’s output is a system that either solves your specific problem or doesn’t. You can’t curate your way out of a schema mismatch. We felt this directly building our own RAG pipeline. The tempting move, early on, was to curate: grab a hosted vector search product, wire up an off-the-shelf retrieval SDK, call it done. We went the other way – running the whole thing locally with [Ollama and pgvector](/posts/from-data-silos-to-smart-answers-building-a-local--735689d4), owning the embedding pipeline, owning the schema. That’s not curation. That’s creation, and it’s the harder path, and it was worth it because the retrieval quality problems we hit – stale chunks, bad reranking, context windows blown out by irrelevant matches – needed control we wouldn’t have had if we’d curated a black box. We wrote up what breaks when you move a RAG system from proof of concept into something that survives production traffic [here](/posts/from-proof-of-concept-to-production-the-art-of-bui-31fb70ff), and almost every failure mode traced back to a decision we made when building the retrieval layer ourselves, not to a vendor limitation we’d inherited by curating. ## Curation Still Has a Job. It’s Just Smaller Now. None of this means curation is worthless for builders – it just moves to a different stage of the process. I don’t want to overcorrect into “always build, never buy.” That’s its own kind of dogma, and it’s expensive. Where curation still earns its keep, in our own workflow, is at the review layer – after creation has already happened. We run a subagent-driven development process where dispatch roles split cleanly along this line. Some agents are read-and-plan only – code-architect, code-reviewer – they’re pure curators. They look at what’s been built, judge it against a spec, flag what’s wrong, and stop. They don’t touch the code. Anything that needs to actually edit a file goes to a general-purpose dispatch instead, because that’s where creation happens. That split isn’t accidental. It’s a two-stage review process: spec compliance first, then code quality – curation applied twice, after creation, not instead of it. When we ran a full operations audit recently – three parallel agents, each in an isolated worktree, one on code and architecture, one on security and OSS hygiene, one on pipeline operations – every agent was curating. Reading, judging, flagging. None of them fixed anything. That’s deliberate. You don’t want your judgment layer and your production layer sharing state, for the same reason you don’t want a code reviewer also writing the PR they’re reviewing. So the honest version of the thesis is: creation is where the leverage moved, curation is where the safety net stayed. You still need both. You just can’t confuse which one is doing the heavy lifting anymore. ## The Cost of Creation Actually Collapsed That safety net matters, but it’s not where the real change has happened – the real change is in how cheap creation itself has become. This is the part that’s easy to say and easy to underrate. Five years ago, writing your own CI/CD pipeline from scratch instead of curating a managed one was a multi-week bet with real opportunity cost. We built ours from scratch anyway, and the specifics matter – the actual mechanics of getting a pipeline to a state where you trust it, not a vendor’s marketing page about trust – are in the writeup [here](/posts/the-architecture-of-trust-building-production-read-2a13e4e3). That decision made more sense than it would have a few years back, because the tooling around building your own has gotten so much better that the “just curate a hosted product” default isn’t automatically the safe choice anymore. Sometimes it’s the riskier one – you’re trusting someone else’s abstraction to match a problem it wasn’t built for. Same logic showed up when we wrote a Python interpreter from bytecode up, instead of curating one of the dozen existing toy interpreters floating around GitHub ([here’s the build](/posts/beyond-the-bytecode-building-a-python-interpreter--490)). Not because existing ones were bad – because owning the execution model taught us things a curated dependency never would have surfaced. You can’t curate your way to understanding a system. You have to build it, at least once, to know where the edges are. And when we needed persistent memory across restarts for our voice-driven agent room – the thing that lets a `claude -p` process remember context across calls without losing state on a container bounce – we didn’t curate a memory-as-a-service product. We built it, hit an ImportError that crashed persistence on restart, fixed it, shipped a resume-recovery mechanism so the deployment actually held state through a crash instead of quietly forgetting everything ([PR #1085](https://github.com/Glad-Labs/poindexter/pull/1085)). That’s a small, unglamorous fix. It’s also exactly the kind of thing you only get right by creating the system yourself, because a curated memory product doesn’t know your specific failure mode until you’ve already hit it in production. We go deeper on why memory is the actual bottleneck for local agents, not raw model quality, in [Breaking the Memory Wall](/posts/breaking-the-memory-wall-how-to-give-any-open-sour-346f4919). ## What This Looks Like for Indie Devs and Tinkerers This isn’t just a lesson for teams running production infrastructure – it applies just as directly if you’re running local models on your own hardware instead of renting API access. If that’s you, you’ve already made this call once, whether you noticed it or not. Curating a cloud subscription is the “someone else already solved this” path. Running your own stack – picking your quantization, tuning your context window, owning your inference server – is creation, and it’s the direction more indie developers are moving in, for the same reason we did: control matters more than convenience once you’ve been burned by a rate limit or a pricing change you didn’t see coming. We laid out the case for going local in [The Offline Revolution](/posts/the-offline-revolution-why-local-llms-are-the-back-1a51d7e0), and the throughline is the same one running under this whole post – creation gives you a system that fits your actual constraints. Curation gives you a system that fits someone else’s average case. That doesn’t mean never curate. It means curate your dependencies at the boundary, and create at the core. Curate the operating system, the compiler, the base model weights – stuff where reinventing it would be pure waste. Create the retrieval logic, the review pipeline, the memory layer, anything that touches your specific problem directly. The line between those two isn’t fixed. It moves as tools mature. Five years ago you’d have curated a vector database wholesale. Now, with pgvector sitting inside Postgres you already run, creating your own retrieval layer on top of infrastructure you already trust is often less work than curating and babysitting a third product. ## The Version Control Test Knowing that the line moves is one thing; knowing where it sits for your own project is another. Here’s a rough heuristic that’s held up for us: if you can describe exactly what’s wrong with the curated option in one sentence, and fixing it yourself would take less time than working around it forever, build it. If you can’t articulate what’s actually broken – you just have a vague feeling that “we should own this” – that’s ego talking, not engineering. Curate. We ran that test on our SEO content pipeline recently. There was a `word_count` and `reading_time` field sitting in the schema, populated by a direct string manipulation – `len(content.split())` – instead of using the content database’s own pre-computed values. That’s a curation failure hiding inside a creation decision: we’d built the schema ourselves, then quietly curated a lazy shortcut around it instead of finishing the job. The fix was small – add the fields to the create-post schema properly, backfill the existing rows with a migration – but the insight underneath it was the useful part: a missing seam in your own system is worse than a missing feature in a vendor’s, because nobody else is going to notice it and fix it for you. When you create the whole stack, the debt is entirely yours. That’s the tradeoff, stated plainly. ## Where This Leaves You The content world’s version of this shift – curation over creation, taste as the scarce resource – is real, and it’s driven by the exact same force that’s pushing engineering the opposite direction: AI made raw output cheap. When output is cheap and undifferentiated, judgment becomes the moat. That’s true for a Substack curator picking which five links matter this week, and it’s true for the code-reviewer agent in our own dispatch pipeline that never touches a file, only judges the ones that come back. But when the output is a system – a retrieval pipeline, a CI/CD flow, an interpreter, a memory layer – cheap creation doesn’t dilute the value the way it does with content. It changes who can afford to build instead of rent. We’ve made that trade more than once now, and every time, the thing we built ourselves fit our actual problem in a way the curated option never could have, because it was never built for our problem in the first place. It was built for the average one. So pick your spots. Curate the boundary – the OS, the base model, the compiler, the stuff that’s genuinely solved. Create the core – the part that touches your actual constraints, your actual failure modes, your actual users. Do that consistently, and you end up with a system nobody else could have handed you, running on infrastructure you understand well enough to fix at 1am without opening a support ticket. That’s the whole bet. It’s paid off every time we’ve made it. ## Sources [https://creativepool.com/magazine/leaders/the-one-skill-that-matters-in-2026-curation-not-creation.34233](https://creativepool.com/magazine/leaders/the-one-skill-that-matters-in-2026-curation-not-creation.34233)[https://www.linkedin.com/pulse/curation-new-creation-why-taste-still-matters-creatives-saks-afridi-voloe](https://www.linkedin.com/pulse/curation-new-creation-why-taste-still-matters-creatives-saks-afridi-voloe)[https://thehubpublication.com/why-id-ask-you-to-consider-curation-over-creation-07b91452dbf2](https://thehubpublication.com/why-id-ask-you-to-consider-curation-over-creation-07b91452dbf2)[https://whyyoushouldcare.substack.com/p/the-creator-curator-hybrid](https://whyyoushouldcare.substack.com/p/the-creator-curator-hybrid)[https://github.com/Glad-Labs/poindexter/pull/1085](https://github.com/Glad-Labs/poindexter/pull/1085)