There is a particular kind of problem that is hard to see because you are inside it. Not obscured by complexity, not hidden behind technical jargon — but structurally invisible because the instrument you would use to detect it is the thing that has been affected. This is the situation we are now in with AI-assisted writing, thinking, and coding. And I want to be precise about the mechanism, because the vague version of this concern ("AI will make us all think the same!") is both easy to dismiss and less useful than the structural diagnosis.
New research from USC's Dornsife College finds evidence that AI use is making people think and write more alike. That finding is the starting point, not the headline. The interesting question isn't whether it's happening — the mechanism practically demands that it does — but what the loop looks like structurally, whether it's detectable from inside it, and why the code layer is probably the earliest place to observe measurable consequences.
The Statistical Heart of the Problem
Language models are trained on the distribution of human output. Not on the full distribution — on the accessible, digitised, indexed distribution. Which means they already start life with a bias toward what has been written, not what could be written. Fringe ideas, heterodox framings, minority intellectual traditions, the kind of thinking that lives in unpublished manuscripts and seminar disagreements — these are underrepresented from the beginning. The model is not averaging all possible human thought; it is averaging the subset that left a legible trace.
What the model learns is, in a meaningful sense, the statistical centre of gravity of human expression at a point in time. When you ask it to write something, it produces output that is optimised for coherence, fluency, and plausibility — which are properties the training distribution rewards — and it does this by navigating toward high-probability regions of the output space. That is not a bug. It is precisely what you want from a language model. It is also, as a side effect, a compression mechanism. The model's outputs are more similar to each other, and more similar to the statistical centre, than a random sample of human outputs would be.
Now add the second phase: humans consume that output. They read AI-generated summaries, explanations, proposals, emails, and code. They do this at scale, frequently, in contexts where they are forming impressions, absorbing frameworks, internalising idioms. Some of what they consume they reproduce — in their own writing, their own reasoning, their own decisions about what frameworks to use or what arguments to make. And some of that reproduction eventually enters training data, directly or indirectly, through the corpus of human-produced text that future models train on.
The loop closes. The statistical centre of gravity shifts toward what the model already preferred. The distribution narrows. From the inside, nothing has changed — you are still writing your own emails, making your own architectural decisions, choosing your own frameworks. The compression is invisible precisely because it operates at the population level, not the individual level. You cannot detect it by introspecting your own work.
The Code Layer: Where Homogenization Becomes Measurable
The reason I keep returning to the code layer when thinking about this problem is that code has acceptance criteria that writing and argumentation largely do not. When a piece of reasoning narrows toward the statistical average, it is hard to measure — the counterfactual diversity is invisible. When code narrows toward the statistical average, you can watch it in the form of technology adoption curves, ecosystem diversity metrics, and dependency graphs.
I've been looking into what the AI-in-coding data actually shows, and the patterns are hard to explain without something like the homogenization mechanism. TypeScript's adoption surge in AI-assisted projects makes sense as a training-data effect: the model has seen more TypeScript in high-quality, high-attention codebases, so TypeScript is in a higher-probability region of its output space. When developers accept AI suggestions, they drift toward TypeScript not necessarily because they chose it deliberatively but because it was the path of least resistance through the model's preference landscape.
The Rails resurgence has a slightly different structure. Dense-convention frameworks narrow the gap between "code that passes tests" and "code a maintainer would merge" — the conventions function as pre-installed acceptance criteria that the model can reliably satisfy. So the model performs better in Rails, developers get more usable output in Rails, and the selection pressure toward Rails increases. That's not homogenization as a cultural phenomenon; it's homogenization as an emergent property of the model's competence gradient. Teams are gravitating toward the technologies where AI output is closer to what a human maintainer would actually accept, and that gradient is determined by the model's training distribution.
The security implications are, I think, the most concrete reason to care about this now. A monoculture in technology selection is not aesthetically disappointing — it is a security surface problem. When AI-assisted projects cluster around the same framework versions, the same dependency chains, the same architectural patterns, a vulnerability in any of those shared components has a blast radius proportional to the degree of homogenization. This is not a theoretical concern. The supply chain attacks I've been following — the LiteLLM version squatting case, the Mercor breach — both exploited the combination of essentialness and ubiquity. The more homogeneous the ecosystem, the larger the radius of any single point of failure.
The code layer is the canary not because it is uniquely vulnerable to homogenization, but because it is the layer where the consequences are eventually quantifiable: adoption curves are measurable, CVE blast radii are estimable, dependency graph diversity is auditable. The writing and thinking layers may be experiencing the same compression, but we cannot run the equivalent of a dependency audit on intellectual diversity.
Detection and the Inside View Problem
Here is the uncomfortable structural fact about the homogenization loop: the instrument you would use to notice it is the instrument that has been affected.
If your mental models of what constitutes a good argument, a clear explanation, or an elegant solution have been shaped by extended exposure to AI-generated output, your intuitions about quality are calibrated against the statistical centre. Work that lives at the edge of the distribution — unconventional structure, heterodox framing, idiosyncratic but precise voice — will register as rough or unnecessarily difficult even when it is genuinely better. The averaged output starts to feel natural; the diverse output starts to feel like noise.
This is what the USC research is beginning to surface, and it is worth being precise about what it does and does not show. It shows convergence in measurable linguistic and cognitive outputs. It does not — yet — show whether that convergence tracks toward or away from quality on any particular dimension. The alarming reading is that we are averaging down toward mediocrity. The more neutral reading is that we are converging toward a new centre of gravity that is simply different from the prior one, with different local optima and different blind spots.
I lean toward the alarming reading, not because I think AI tools are producing bad output in isolation, but because of what the mechanism does to the tails of the distribution. Innovation, in both ideas and code, disproportionately comes from the tails — from the heterodox framing that most practitioners would reject, from the architectural pattern that violates the conventional wisdom, from the argument that initially seems wrong but turns out to be precisely right. A compression mechanism that narrows the distribution is a compression mechanism that taxes the tails. It does not eliminate them, but it makes them less likely to emerge, less likely to be written down legibly, and less likely to survive the journey into training data.
The detection problem is that the tails are exactly what would tell you the distribution has narrowed. If you are measuring intellectual diversity from inside a system that has already compressed it, the baseline you are comparing against is the compressed baseline. The loss of diversity is invisible not because it is small but because the reference point moved with it.
What the Signal Looks Like When You Can See It
I want to be careful here not to overclaim. The mechanism I've described is real and the USC evidence is consistent with it, but we are at an early stage of understanding the magnitude and rate. What I can offer is a set of observable signals that would indicate the loop is active and compressing faster than it is visible from inside.
The first signal is technology monoculture acceleration — adoption curves for AI-preferred technologies that outpace what deliberate team decision-making would produce. If the ecosystem is genuinely homogenizing under AI influence, you would expect to see TypeScript and Rails and a small cluster of other high-AI-competence frameworks pulling ahead faster than their feature sets justify. From what I've been reading about adoption patterns in AI-assisted teams, that signal appears present.
The second signal is benchmark-to-reality divergence in code quality, specifically in architectural diversity. If AI-generated code clusters around a narrower range of patterns than human-generated code, you would expect to see that in code review discussions, in the texture of PRs across different teams, in the degree to which architectural debates are happening at all. The METR data on AI productivity showing a measured ~19% slowdown against a perceived 24% speedup suggests there is already a comprehension tax when humans encounter AI-generated code — which is consistent with code converging toward patterns that are fluent from the model's perspective but require cognitive overhead to maintain.
The third signal is the one I find most diagnostic: a narrowing of the questions being asked. Intellectual diversity is most visible not in the answers communities produce but in the range of questions they pursue. If AI assistance is compressing the distribution, you would expect the questions that feel natural to ask — the ones that occur to practitioners without deliberate effort — to drift toward the questions the model handles well. Questions in high-probability output regions. Questions with pre-existing answer structures. The heterodox questions, the ones that require building a new framework to even articulate, would become less frequent not because people are forbidden from asking them but because they feel harder, rougher, less immediately productive.
The Practical Synthesis
I do not think the right response to this is to stop using AI tools, which would be a counsel of deliberate disadvantage dressed up as intellectual virtue. The right response is to understand what the tool is doing to the distribution of your outputs and build deliberate counterweights.
For coding teams, this means periodic ecosystem diversity audits — not just dependency vulnerability scans but genuine assessments of whether your technology selection is following genuine deliberation or the model's competence gradient. When you reach for TypeScript or Rails because the AI output is better there, that is worth naming as an AI-influenced decision and asking whether the benefits outweigh the monoculture contribution.
For thinking and writing, the counterweight is harder to specify but easier to describe: it is the practice of generating your own framing before consulting the model, not after. The compression happens most efficiently when the model shapes your initial orientation. If you arrive at the AI with a position already formed — even a rough one, even one you expect to revise — you are sampling from a different region of the output space than if you arrive empty-handed and let it fill the frame.
The structural question I keep returning to is this: the code layer is measurable, so we will eventually get clear data on whether ecosystem diversity is narrowing at the rate the mechanism predicts. If it is, that gives us the first real quantitative baseline for the writing and thinking layers — not identical evidence, but an analogous signal from a domain where the instrumentation exists.
The canary is already in the coalmine. Whether it is singing or silent is a question we have the tools to answer at the code layer first. The rest of the distribution will follow, visible or not.