Coding agents such as Claude Code and Codex can now do much more than make coding more efficient. They can perform many computer-based tasks, including research and documentation.

I often work on platform and infrastructure tasks, which require careful research using primary sources and thorough investigation of how changes might affect other parts of a system. For that reason, I often organize information into a document and align with the team before starting a task.

Recently, I have been delegating this kind of research to Claude Code. I first have it organize the findings in a Markdown file or similar format, then review the document before moving on to design and implementation.

Research that would take a human anywhere from several hours to several days can be completed by an LLM in minutes. However, making sense of the resulting document takes surprisingly long. I can understand it if I read it carefully, but LLM-generated writing is difficult to read and extremely tiring.

In this post, I want to share something I recently realized about why reading LLM-generated research documents can be so exhausting.

Faster Research Does Not Mean Faster Reading

An LLM can complete research that would normally take hours in just a few minutes and compile the results into a single document. Naturally, even though the document arrives quickly, it still contains a substantial amount of information.

Reading one document is manageable. But when I work on two or three different tasks in parallel and a document is generated for each one, reading them all takes an enormous amount of time. Because it takes so long, I ask the LLM to summarize them, and if there is anything I do not understand, I ask the LLM more questions.

Sometimes I start another task during the few minutes I am waiting for the research. But when I return to the results after thinking about something else, I find myself wondering, “What was this about again?” I have to start by restoring the context in my own mind.

I may feel as though I am moving several tasks forward efficiently, but I end up spending my time reading documents and switching contexts. This process is exhausting, but for a long time I could not put the reason into words.

The Information Is at the Wrong Level of Abstraction

Recently, I realized that this fatigue may come from a mismatch between the level of abstraction of what I want to know and what the LLM generates.

For example, when adding a new feature, the first thing I want to understand is how the change will affect other parts of the system. I want to consider whether the change would be a local optimization when viewed in relation to the rest of the system, and which overall direction we should take.

By contrast, concrete details such as which parts of the implementation will be affected and how the current implementation works can wait until after the direction has been decided. I do not need that level of detail for the initial decision.

However, an LLM dives into the details from the very first step and combines the high-level direction and the concrete implementation in a single document. The information I want is certainly there, but information I do not yet need is presented at the same level of prominence.

As a result, humans have to work through concrete details while extracting the information needed to make a more abstract decision. I think this gap, created precisely because LLMs are capable enough to investigate the details, is what makes their writing so tiring to read.

The Shift in What Humans Care About

In the past, humans wrote programs themselves and took a strong interest in the details of implementation. But as LLMs increasingly write the code, I find myself thinking more often that the specific implementation approach may be better left to AI.

At the same time, humans still need to make decisions at a higher level of abstraction, such as identifying the problem and deciding on the implementation direction. I think I find documents that mix in concrete details tiring precisely because these higher-level decisions are what I want to discuss.

We are now in a transitional period between an era when humans wrote programs by hand and one in which AI writes them. Perhaps that is why the concrete information we used to need and the information humans will want to make decisions about in the future are still mixed together in the same documents.

If we eventually shift completely to AI-written code, it will become difficult for humans to review every detail of the enormous amount of code generated in a short time. That is why I feel that natural-language documents written for human decision-making will become more important than ever.

Closing

In this post, I considered why reading LLM-generated writing can be so tiring.

The difficulty of the research and the volume of information are not the only causes. I feel that a major cause is that the abstract concepts humans need in order to make decisions and the concrete information needed after a direction has been chosen are mixed together in a single document.

As the concerns of humans and AI diverge, the documents that bridge the gap between them will become increasingly important. If documentation is where the current challenge lies, then I think this is the time to invest in ways to close the abstraction gap and improve the environment surrounding LLMs.