Source quality

How to filter AI-generated engineering content from your feed.

AI-assisted writing has made technical blogs faster to produce and harder to evaluate. Here is what to look for.

HexbriefJuly 11, 20263 min read

Filtering AI-generated engineering content has become a real skill, not a niche concern. Generating a plausible-sounding "how we built X" post now takes minutes, and a growing share of what shows up in engineering-blog aggregators was written to rank for a keyword rather than to document a real decision.

This is not an argument against AI-assisted writing. Plenty of engineers use it to draft faster and then add the real substance themselves. The problem is content that was generated and published with no engineer ever having made the decisions it describes.

Why this is suddenly a real problem

Marketing and content teams have always produced technical-sounding posts with a thin engineering core, but the volume was limited by how fast a person could write. That constraint is gone. A team can now produce a dozen "engineering" posts a week without a single engineer reviewing the technical claims, and each one is written well enough to pass a skim.

This raises the cost of the old heuristics. "Well-written" used to correlate with "written by someone who understood the system." That correlation is weaker now, because generated text can be fluent while being technically hollow.

The signals that separate real from generated

Real engineering writeups tend to include numbers that are oddly specific rather than round: "p99 latency dropped from 340ms to 61ms" reads differently than "significantly improved performance." Generated content tends to stay in safely vague territory because there is no real measurement behind the sentence.

Real posts also admit failure along the way. A team describing a migration usually mentions what broke first, what they rolled back, or what assumption turned out wrong. Generated content is disproportionately smooth: architecture in, architecture out, with no scar tissue in between. That absence of friction is one of the most reliable tells.

Author identity is another signal. A named engineer with a consistent posting history and a real technical footprint elsewhere (talks, open-source contributions, other posts) is harder to fake than a generic "engineering team" byline attached to a suspiciously prolific publishing schedule.

What AI-generated content usually gets wrong

It over-explains widely known concepts and under-explains the specific decision. A generated post about caching will spend three paragraphs describing what caching is and one vague sentence on why this team chose a particular eviction policy. A real post does the opposite: it assumes the reader knows what caching is and spends its length on the one decision that was actually hard.

It also tends to avoid naming a real regression or a specific incident, because there was never an incident to name. Watch for posts that describe an architecture in confident present tense without ever explaining what came before it and why it wasn't good enough.

Where filtering fits into a reading habit

None of this means avoiding company blogs, or treating every fluent post with suspicion. It means applying the same test that already separates good engineering writing from bad: does this describe a real constraint, a real decision, and a real consequence. That test filters out generated content and thin marketing posts equally well, which is exactly the editorial screening Hexbrief applies before a post reaches the daily six.