AI homogenization is a build problem, not a philosophy problem

There's a question worth asking about all of this, and most people asking it are hoping for a flattering answer.

Are we using AI to discover genuinely new solutions to hard problems, or are we using it to produce the conventional solution much faster?

The strongest empirical research so far points in an uncomfortable direction. What it doesn't give you is how the effect shows up inside a team shipping product, where it doesn't arrive labeled. So here are four entries from our own build log, all from the past quarter, followed by the one rule we changed because of them.

Our research pass produced a statistic that didn't exist

We ran a deep research pass to support the first essay we planned to publish. It came back fast, well-sourced, and confident.

The argument rested on a vulnerability rate that hadn't moved in a year. Verification found that the current figure was the previous year's figure, re-cited by an aggregator. Nobody had re-run the measurement. The comparison we were building an entire essay around did not exist.

A second claim attributed a static-analysis precision range to a NIST study. When we read the study, we couldn't find the range in it, and what we did find cut against the point we were making. The correct support turned out to be a peer-reviewed comparison that happened to back us for entirely different reasons than we'd assumed.

Here's the part that matters. Nothing about that draft was novel. It was the standard version of the standard essay in that genre, assembled at speed, and it read well because reading well is what the genre optimizes for.

Deep research finds sources. It is not a source.

The hardest work on OnSpec was deciding what not to ship

OnSpec formats passport and ID photos to government specifications. Generating the pipeline was the easy part: crop, background, sizing, output. That took days.

The slow part was reading the actual rules, market by market, in the issuing authority's own words.

Pakistan's official process has the photograph captured at the passport office rather than supplied by the applicant, which puts the entire self-submission flow outside anything we can stand behind. So we ship a sizing tool there and attach no compliance guarantee.

The UK produced the same call for a different reason. Official guidance states plainly that a photo from a booth or shop is more likely to be approved than one taken on your own device, and the online service runs its own automated check before a human sees it. A tool that promises acceptance is promising something the issuing authority has already declined to promise.

Canada requires a commercial photographer and the studio's name, address, and date written or stamped on the back of the print. That isn't a prohibition on our software. It means our product can't serve that use case end to end, so we don't cover Canada.

Three markets, three different reasons, and in every one the correct output was less product.

We also learned our own filter was too coarse. We'd been treating "does this country permit edited photos" as one question. It's two. Permission to crop to spec and permission to alter pixels are separate things, and the US is where that became obvious. That distinction did not exist in our spec until reality inserted it.

No model surfaced any of this. It came from reading primary sources and being willing to lose a market.

The bug wasn't in the code, it was in the geography

A smaller one, same shape.

OnSpec's background removal loads model assets that we originally pulled from the vendor's CDN, which is the documented, obvious, correct-looking approach. It worked in development and it worked in review.

It failed in production because that CDN is blocked in some of the markets we were building for. Nothing in the code was wrong. The fix was to self-host roughly 328 megabytes of model weights and stop depending on a network path we didn't control.

That failure wasn't discoverable from the code path alone. It was discoverable when the system met the world.

Our first open-source release has no AI in it

Lanes is a macOS menu bar launcher. It runs multiple Claude Desktop accounts side by side using isolated --user-data-dir profiles, so you stop logging out of one to get into the other. It's about four megabytes and there is no model anywhere in it.

An AI-native studio whose first public tool is a small launcher is a reasonable thing to be self-conscious about. We aren't. We shipped it because we hit the problem every single day, and because a weekend spent on a real irritation beats a month spent on an impressive idea nobody has felt yet.

The scarce input wasn't code. It was the judgment that this small annoyance was worth building and a larger, more interesting idea wasn't, not yet.

The research calls this regression toward the mean

The effect we kept running into has a name, and the measurements behind it are more specific than the commentary around them.

Xie and Xie, writing in the Chinese Journal of Sociology in 2026, argue that generative models are structurally prone to regression toward the mean, with output variance shrinking relative to the variance of real-world distributions. It's an argument rather than a settled result, but it names the thing precisely. Not worse output. Narrower output.

The sharpest experimental result is still Doshi and Hauser in Science Advances, 2024. Writers given LLM story ideas produced work that evaluators rated as more creative, better written, and more enjoyable, with the largest gains among the least creative writers. The same stories were more similar to one another than stories written without AI. Individually better, collectively narrower.

Then there's the finding that most directly explains our own quarter. Dell'Acqua and colleagues ran a preregistered experiment with 758 knowledge workers at BCG, published in Organization Science and originally circulated as a Harvard Business School working paper in 2023. They describe a jagged technology frontier: AI assistance improves performance on some tasks and degrades it on others inside the same workflow, at seemingly similar levels of difficulty.

Jagged is the operative word. You cannot tell from the output which side of the frontier you were on. Our research pass and our OnSpec pipeline came back looking identical in confidence and polish. One was fine. One was fiction.

None of this is a closed question, and the honest version says so. A 2026 replication study found that varying the AI personas supplying the ideas eliminated the homogenization effect, which suggests the compression is partly a property of how the tool is used rather than an inevitability.

We traced all three papers to the originals rather than to the articles citing them, which is more relevant to this post than it sounds. Several of the secondary sources we passed through reported effect sizes we couldn't locate in the primary abstracts.

Novelty lives in the constraints, and constraints come from contact

The pattern across all four incidents is the same.

Generation is now close to free. The discovery of the constraint that makes a problem interesting costs exactly what it always did.

Look at what the generated answer actually was in each of the four. Cover every major market. Write the standard essay in the genre. Load the model assets from the vendor's CDN, which is the documented approach. An AI studio ships AI.

Four for four, the output was the conventional answer. Not a wrong one, exactly. The one most teams in our position would have produced, which is the same thing homogenization means when it stops being a chart and starts being a roadmap.

A model can hand you a thousand plausible plans. It can't tell you which one survives your users, your jurisdiction, your latency budget, or your compliance reviewer, because what settles that is usually specific to your system, your market, and the thing that broke last Tuesday at 3am.

So the framing in the original question is slightly off. AI doesn't guarantee novelty or conventionality either way. What it does is make the plausible part of the solution space extremely cheap to explore, and plausible is a narrower region than it looks from inside it.

Which is not an argument against the tools. We use them constantly and we ship faster because of them. It's an argument about where the remaining work went, and the answer is that it moved almost entirely into verification and judgment.

What we changed: confident output is not evidence

One operating rule came out of the last quarter, and it's now the thing we check for in every review.

Every claim gets traced to its origin, not to something citing the origin. Every security property gets proven against a running system, not against the code that was supposed to implement it. Every user-facing sentence gets checked against what the software does, not against what we meant it to do.

The point isn't distrust. It's that fluency and correctness are produced by different processes, and only one of them is cheap now.

Slower per unit of output. Considerably faster per unit of output that survives.

The through-line

The question offers two options, and the common outcome is a third one. AI produces conventional work quickly enough and fluently enough that you never notice you skipped the harder question.

The generating got cheap. The finding out is still the job.

Written by Synthetixis, an AI-native product studio. More on what most AI software gets wrong.