Here is a fair objection, and one we hear from the sharpest people who look at Hexbrief: anyone can now point a language model at a pile of engineering blogs, ask it to score each post for "depth and novelty," and keep the top results. If that is the whole product, it is a weekend clone. The objection is correct about the easy part and wrong about where the work is. Scoring a single post is cheap. Deciding which few posts deserve a reader's limited attention, every day, without drifting into noise, is a different problem — and it is mostly not a model problem.
This post is about that gap. Not the mechanics under the hood, but the judgment: what a scoring pass actually buys you, where it quietly fails, and why filtering engineering blogs well still depends on things a prompt cannot supply.
Scoring a post is the cheap part
Ask a capable model whether a single engineering post explains a real problem, names a concrete approach, and reports a result, and it will do a decent job. Modern models are genuinely good at reading one document and telling you whether it contains substance or just borrows the vocabulary of substance. That capability is real, it is widely available, and it is not a moat. If your entire filter is "rate this post 1 to 10 for depth," a competitor reproduces it in an afternoon.
The trouble is that a per-post score answers the wrong question. A reader does not want to know whether a post is good in isolation. They want to know whether it is one of the best few things they could read today, given everything else that was published, given what they already read last week, and given that their attention is the scarcest resource in the whole system. A score ranks documents. Curation decides what a person should actually spend twenty minutes on. Those are not the same job, and the second one does not fall out of the first for free.
A filter is only as good as the universe it searches
Most of the quality in a curated feed is decided before any single post is scored. It is decided by the set of sources the filter is even allowed to look at. A model that scores the open web will confidently rank a well-written launch announcement above a rough but valuable incident writeup, because launch announcements are polished and incident writeups are often not. Garbage that is fluent still reads as high quality to a scorer that has no view of the source's track record.
So the first real decision is not "is this post good" but "is this source the kind of place that publishes real engineering — architecture changes, migrations, postmortems, hard tradeoffs — rather than marketing with a code snippet stapled on." That judgment is slow. It comes from reading a source over time, watching what it does after its most successful post, and noticing whether the depth survives once the launch is over. It is taste, accumulated, and it is the part nobody shortcuts with a better prompt. The model works inside a universe that human judgment has already narrowed. That narrowing is where a lot of the value lives, and it is invisible in any demo.
What actually gets a post rejected
When you look at what fails the bar, most rejects are not badly written. They are the wrong genre. A launch post announcing a feature. A customer success story wearing an engineering costume. A conference recap. A shallow how-to that names five tools without explaining a single decision. A "we're excited to share" essay that is really a hiring-brand play. None of these are bad on their own terms; they are simply not the thing an engineer opens Hexbrief to learn from.
The tell is almost always the same: the post uses the language of engineering without exposing a decision. It describes what a team built but never says what pressure forced the change, what they considered and rejected, or what the choice cost them. A strong post makes the forcing function visible — the service could not keep up with write volume, the cache was hiding correctness bugs, rollback had become too expensive to risk. A weak post hides exactly there, in the place where learning would have happened. A scoring model can be taught to notice some of this. But the line between "technically detailed" and "actually teaches something transferable" is a judgment call that shifts by topic and by reader, and it is exactly the call that decides whether a feed is worth returning to.
The failure mode nobody scores for
There is one failure that a per-post scorer will walk straight into, because scoring is blind to it by design: rewarding the same handful of famous companies every single day. The most polished engineering writing tends to come from a small set of large orgs with dedicated writers and editors. Score posts independently and you will end up serving the same five logos on repeat, because their average post is cleaner than a smaller team's average post.
That is the lazy failure mode, and it makes a feed worse even when every individual pick is defensible. A reader learns more from a strong incident report at a mid-sized company they had never heard of than from the fourth well-produced post from a name they already follow. Fighting this requires constraints that live above the score: diversity across sources so no single org dominates the day, diversity across topics so it is not the same subsystem six times, and active effort to keep expanding the source set past the obvious top tier. If a curated feed ever reads as "the usual five companies, daily," that is not the design working — that is a bug. And it is a bug that a scoring model, left alone, actively creates.
Why a human still says no
Even after a post clears the genre test and the diversity checks, automated approval is not the same as being worth publishing. A generated assessment can wave through a post whose result is hollow, or whose framing is technically fine but reads as awkward, or that is fifteen minutes of setup for one small idea. Automated "this passed" means the mechanical bar was met. It does not mean a careful editor would put it in front of an engineer and stand behind the choice.
That is why there is still a person in the loop who can say no after everything upstream said yes. Not because the model is bad, but because the last step of curation is a standard, and a standard is something you hold, not something you compute. The model proposes; judgment disposes. Over time that human "no" is also what keeps the whole system honest — it is the feedback that stops the bar from quietly sliding down toward whatever is easiest to approve.
The model is the copyable part
So, to answer the objection directly: yes, anyone can score engineering blogs with a model now, and no, that is not the thing that is hard to build. The defensibility is in the boring, slow parts — a source universe narrowed by taste, a standard for what earns a reader's time, constraints that fight the same-five-companies drift, and a person who still vetoes what the machine approves. The scoring is the cheap, copyable layer on top. The curation and the "no" are the product.
The deeper point is one every engineer already knows from their own systems: the model is a component, not the architecture. Deciding what is worth reading is a harder and more human problem than summarizing it, and it does not get solved by a bigger prompt. It gets solved by holding a line, every day, on what deserves attention.
If you want a small daily set of engineering reads where that line has already been held for you — filtered from real company writeups, not scraped from everything — that is what Hexbrief is for.