The unreasonable effectiveness of not reading anything

An engineer on a competing agentic coding team published a post this week titled “The Unreasonable Effectiveness of HTML.” The core argument: markdown files have become too hard to read, so the AI should generate HTML files instead, because they’re prettier and therefore easier to read.

We read the post twice to make sure we understood correctly. The problem being solved is that a developer doesn’t read the text files his AI generates. The solution is to have the AI generate more complex files, with CSS and SVG and interactive sliders, which the developer will read because they’re nicer. The file format has been promoted. The developer’s attention span has not been addressed.

The key admission

Buried in the middle of the post is a sentence that deserves its own blog post: “I’m also increasingly not editing these files myself.”

Let’s sit with this. The workflow is now: the AI writes a plan. The AI formats the plan as HTML. The developer opens the HTML in a browser. The developer looks at the HTML. The developer tells the AI to implement the plan. The AI implements the plan. The developer tells a verification agent to check the work. The verification agent checks the work.

At no point in this pipeline does the developer write code, edit a file, or make a structural decision that the AI didn’t draft first. The developer’s role is to look at things, nod, and type instructions for the next thing to look at. It’s interesting to watch the tooling adapt in real time to the fact that the human’s primary function is now “reading comprehension and attention span, optional.”

The format arms race

The post argues that markdown is a “restricting format” because it can’t convey colour, diagrams, or interactive elements. This is true. Markdown is plain text. That’s the point of markdown. It was designed for humans to write and read. When neither of those things is happening anymore, the design goals stop mattering.

HTML can convey “almost no set of information that Claude can read that you cannot fairly efficiently represent,” the post says. This is the kind of sentence that sounds like a capability unlock but is actually an admission that the AI’s output has outgrown the human’s capacity to process it. The solution is presented is to make the output prettier so it feels more manageable. This is, you might say, the information equivalent of drinking from a fire hose and ‘solving it’ by adding food colouring.

The post includes a screenshot of the AI attempting to represent colours in markdown using Unicode characters. This is offered as evidence that markdown is insufficient. We’d offer it as evidence that the AI is doing too much.

”It’s Joyful”

There’s a section headed “It’s Joyful.” The full text: “Making HTML documents with Claude is just more fun and makes me feel more involved and invested in the creation, and that by itself is enough.”

We want to engage with this sincerely, because we think it reveals something important about where agentic tools are headed. The developer isn’t writing the HTML. The developer isn’t writing the code the HTML describes. The developer isn’t editing the plan the HTML presents. But making the AI produce a pretty version of the thing the developer isn’t writing feels good. The developer feels “more involved and invested in the creation.”

This is the IKEA effect applied to software development. You didn’t build the bookshelf. The AI built the bookshelf. But you chose the colour of the bookshelf from a slider the AI also built, and now it feels like your bookshelf. The joy is probably real. It’s just attached to … something else.

The throwaway editor

The most revealing section in the original post describes “custom editing interfaces”, one-time HTML tools that the AI builds for a single task. Need to prioritise 30 tickets? Have the AI build you a drag-and-drop interface. Need to edit a config file? Have the AI build you a form with validation. Need to tune a prompt? Have the AI build you a side-by-side editor with live preview.

Each of these tools is built from scratch, used once, and discarded. They are single-serving applications that exist for the sole purpose of letting the developer interact with data through a GUI instead of a text file.

There’s nothing wrong with this. It’s genuinely clever. But there’s a pattern here that nobody in the post acknowledges: the developer has stopped being comfortable with text. Not because text is insufficient — you can reorder 30 tickets in a text file — but because text doesn’t feel like doing something. Dragging cards between columns feels like doing something. The interface exists to produce the sensation of work, which is different from work, which the AI is doing.

The FAQ

The post includes a FAQ that answers several questions honestly:

“Isn’t it less token efficient?” — Yes. But the context window is a million tokens now, so it doesn’t matter. This is the AI equivalent of “I have unlimited data so I’ll stream everything in 4K.” The resource exists, so we’ll use more of it, to solve a problem that is fundamentally about attention, not bandwidth.

“Doesn’t this take longer to generate?” — Yes. 2-4x longer. But the results are “worth it.” Worth it compared to what? Compared to the markdown file the developer admitted he doesn’t read? The HTML takes four times longer to generate, costs four times the tokens, and the developer might read it, which is an improvement on definitely not reading the markdown, but is not the productivity breakthrough the post implies.

“What about version control?” — “This is honestly one of the biggest downsides.” HTML diffs are noisy and hard to review. The post acknowledges this and moves on. We’d like to linger, because version control is how teams maintain shared understanding of what changed and why. Abandoning readable diffs in exchange for prettier documents that individual developers enjoy looking at is a trade with consequences that show up later, usually at 3 AM, usually when something is broken.

What’s actually happening

The post is best understood not as a technical recommendation but as a document about the changing relationship between developers and their tools. The developer has stopped writing code. The developer has stopped editing plans. The developer has stopped reading documents over 100 lines. The developer’s remaining function is to look at things the AI has produced, decide whether they seem right, and tell the AI to proceed.

This is a real workflow. Lots of people work this way now. But when the primary challenge is getting a developer to look at the AI’s output, and the solution is to make the output shinier, something has shifted that’s worth naming. The human is no longer the author. The human is the audience. And the tooling is evolving to make the audience experience more pleasant, the way Netflix auto-plays trailers to keep you from leaving.

The post ends: “I feel more in the loop than ever before when using HTML.”

In the loop. Not in control. Not in the driver’s seat. In the loop. It’s a precise choice of words, whether intentional or not. A loop is something you’re carried around by. It suggests proximity to the action without responsibility for it.

This post was written in markdown. It’s somewhere around 1,200 words. We don’t know if you’ll read the whole thing. But at least we didn’t build you a slider.