One-Third of the Web is Now AI-Written. Where Did the Depth Go?

This week, a single figure caught my attention.

Reports published separately by Originality.ai and Graphite claim that more than a third of newly published web content is generated by large language models. Some reports push this estimate up to fifty percent, because defining what counts as AI-generated and choosing which sample to scan varies from report to report. There is no single, definitive number. But the trajectory is clear: the curve is pointing up, and it is climbing fast.

When a figure like this emerges, people quickly divide into two camps. One side declares that “the internet has turned to garbage, quality is dead.” The other side argues that “AI is just a tool, content is still content, there is no real difference.” I cannot agree with either, because both sides are looking at the wrong thing. The real issue is not whether the creator is human or machine, but what remains slow while creation accelerates.

Behind the Estimate: The Illusion of Measurement

Detecting whether a piece of text was written by AI is not as simple as developers of detection software claim. These tools mostly analyze linguistic patterns, sentence length distribution, and vocabulary repetition. If a human writes like an AI, they get flagged. If an AI output is lightly edited by a human, it slips through. Whether we accept thirty-three percent or fifty percent, we are looking at an estimate, not a measurement.

Yet the estimate itself tells us something important. Before ChatGPT launched in late 2022, nobody asked these questions because there was no meaningful difference to measure. Now, major technology companies openly report that a significant portion of the code committed on GitHub is generated with Copilot or similar assistants. The same shift is happening in content. The marginal cost of production, both in prose and in code, is rapidly approaching zero.

This is where we must stop and ask the real question. If production has become so cheap, where did the corresponding cost go?

Cheap to Write, Expensive to Verify

The cost of writing a sentence has dropped to near zero. The cost of verifying that the sentence is true remains exactly the same, if not higher.

I see this in my own practice. Asking an AI tool to draft a blog post takes minutes. Verifying whether a date, a figure, or the spelling of a name in that draft is correct does not take minutes; it often takes much longer. AI writes with supreme confidence even when it is entirely wrong. The tone remains smooth, presenting truth and fabrication in the exact same authoritative voice. In the past, a writer’s primary labor lay in the writing itself. Today, the labor has shifted to verification.

The same dynamic governs software development. Generating a function is fast. Understanding why that function was written in that specific way, and how it behaves in edge cases, remains slow. Code review times have not decreased. Instead, we have added a new cognitive layer: “Did I write this, or did the model? And regardless of the source, why is it correct?” This question now hovers over every line.

This gap, the divide between sheer volume and critical judgment, is not closing. It is widening. While the production curve grows steeper, the verification curve remains stubbornly flat.

The Same Loop in Code: Accumulating AI Debt

Most engineers understand technical debt: a fast, messy solution saves time today but demands repayment with interest tomorrow. AI debt works on the same principle, but its origin is different.

Consider a component generated by an AI assistant. It works, it passes the unit tests, and it looks flawless in the demo. But no one on the team actually read the code from beginning to end, because reading code takes longer than generating it, and deadlines are tight. Six months later, when a bug appears in that component, no one can answer why it was structured that way. There is no human author to explain the reasoning, only a model that has no memory of the session.

This is closely tied to the circular nature of automation. As I wrote in my piece on loop engineering, automating a system does not mean we can stop understanding it. In fact, it requires the opposite. AI debt accumulates precisely at this juncture: when we accept the speed of automation but discard the responsibility of comprehension.

This is why architecture decision records (ADRs), the practice of documenting why a decision was made, are now more critical than ever. Leaving a trace of human intent amidst the noise of AI-generated output acts as an anchor. Without that trace, six months from now, no one will know why that specific line of code exists.

Depth Isn’t Dying, It’s Just Drowning

The year was 1545. Swiss naturalist Conrad Gessner recorded a complaint in his work Bibliotheca Universalis: the sheer volume of books produced by the printing press had reached a point where it was confusing and harmful. Gessner was trying to catalog tens of thousands of works on his own, knowing that a human lifetime was insufficient to read even a fraction of them. The printing press made information cheap, but knowing which book was worth reading never became cheap. What happened five hundred years ago with paper and ink is happening today with tokens and API calls.

Let me clarify my main thesis here: depth is not evaporating. Deep work is still being produced. People still spend hours thinking and writing, and engineers still weigh their technical decisions carefully. But that depth is now buried under a much louder, heavier mass of noise, much like Gessner searching for a few valuable manuscripts among tens of thousands of printed volumes.

If a search query returns ten articles and eight of them are rapidly generated, superficial variations of one another, the remaining two deep pieces become incredibly difficult to find. Search engines and readers alike struggle to distinguish which text represents actual thought. This is not a quality problem; it is a discoverability problem. Good content exists, but we lack the filters to separate the signal from the noise.

We see the same pattern in codebases. When a repository accumulates unnecessary abstraction layers, bloated test suites, and functions that “work, but no one knows why,” the carefully designed architectural decisions become invisible. Code readability degrades because you must now differentiate between a deliberate design choice and an autocompleted line.

There is a simple test for this, and it applies equally to prose and code: can the creator defend what they produced? Can they explain why they structured a sentence a certain way, or why they chose a specific pattern for a function? Unverifiable, undefended output is simply debt in disguise, whether in the content economy or in a codebase.

Beyond Speed: Ownership Over Output

I am not against speed. I use AI to accelerate both my writing and my code; there is no point in hiding it. What I oppose is treating speed itself as the ultimate metric.

The real question should not be “How fast did you build it?” but rather “Can you defend what you built?” One-third of the web may be written by AI, and that proportion will only grow. But the value of a paragraph or a line of code does not come from who wrote it. It comes from whether someone is willing to stand behind it.

Can you explain to someone tomorrow why you made the choice you made today? If the answer is no, then what you are accumulating isn’t progress; it is debt.