"The AI's writing is so long I don't actually read it properly 😅"
"I'm paying over 15,000 yen a month for Claude Code, but I don't feel like I'm getting my money's worth."
Many people are satisfied just with the fact that they are using AI, but only a few are actually turning it into results. It's a state of "feeling like you've used it."
Have you had these experiences with Claude Code?
- You ask it to "summarize last week's competitor trends" on Monday morning, and it returns a long report. You glance at it and leave it unread.
- You suspect that if you aren't reading the AI-generated materials properly, there's no way your team members are reading them either.
- You pay over 3,000 yen monthly for Claude Code, but the outputs have never been used in a meeting or proposal.
- ChatGPT and Claude.ai outputs look beautiful, but why does Claude Code only output Markdown, making it so exhausting to read?
This article is for those people.
By the time you finish reading, you will be able to naturally generate materials from Claude Code that both you and others will actually read.
You'll also walk away with the perspective that "what format you output in" is a much bigger factor in user judgment than "what you ask Claude Code to do."
Thariq Shihipar (@trq212), a developer at Anthropic who actually builds Claude Code, wrote about a mindset spreading within the company on X, and it has become one of the most saved and shared posts in the Claude Code community.
It received a huge response immediately upon release.
This isn't just a minor tip for AI geeks; it's a story about the person who built the tool challenging Markdown, which has been the implicit standard of the AI industry, saying "it's no longer the way."
I thought this was important, so I decided to explain it in Japanese immediately.
Two things before you start reading:
- Bookmark this. Just for this week, secure some time to try outputting in HTML.
- If you have team members using Claude Code, share this with them. The way your weekly reports and PR reviews are "read" will visibly change starting next week.
I will break down and explain the content while translating it into how it works in the Japanese business scene 👇
Original post here:
https://x.com/trq212/status/2052809885763747935
The Anthropic Developer Himself No Longer Uses Markdown
This is the starting point. Thariq Shihipar (@trq212), who wrote the original post, is the developer building Claude Code at Anthropic. The behavior where Claude asks questions back to the user in "plan mode" to refine requirements was a feature he personally implemented.
He says he no longer accepts Markdown from the tool he is building. In his own words, Markdown has become a restrictive format for him.
This isn't just personal preference. Thariq mentions that HTML adoption is spreading within the Claude Code team itself. The people making the tool are abandoning the Markdown it produces and switching to HTML.
And the evidence is available to touch. On the demo site https://thariqs.github.io/html-effectiveness/, there are 20 self-contained HTML examples. A comparison of three approaches to debounced search, micro-interactions that create a sense of accomplishment for task completion, design system token lists, tabbed explanations for code examples, and reading material with a glossary in the margins. All of these are real examples of replacing "documents you just glance at" with "documents that are read to the end." You can open them in your browser right now.
Reading this, you should realize something. The Artifacts you usually receive in ChatGPT or Claude.ai—those "UI with tabs," "colored diagrams," and "interactive buttons"—are actually output as HTML. The realization here is: "The reason they looked so good was the difference in the format itself." Now, that same world can be brought to your fingertips with Claude Code.
Until now, AI-generated text was almost exclusively Markdown. The person building it is quietly starting to object, saying "not anymore." That's the core of the news. But for you, who works with AI every day, this is a story that will be effective from Monday morning.
Markdown Was the Implicit Standard of the AI Industry
Let's confirm the assumptions we took for granted. Without this, the switch to HTML might just look like a matter of taste.
Until now, Markdown was the de facto standard for AI output. Think back to the text you see every day:
- CLAUDE.md in the project root, *.md for agent definitions, SKILL.md for Skills.
- Anthropic's official documentation, Claude.ai Help, and various Claude Code guides.
- Competing AI development tools, Cursor rules, GitHub Copilot instructions, and Cline instructions are all based on .md.
- Internal Wikis, GitHub READMEs, text exported from Notion, and meeting minutes pasted into Slack.
- Summary text copied from ChatGPT chats.
Everything has been built on the assumption of Markdown. It's harder to find a format other than Markdown in the text information you encounter when dealing with AI.
The phenomenon of Karpathy's CLAUDE.md pattern gathering over 80,000 stars on GitHub happened precisely because Markdown was the common language of the industry.
To use Thariq's words, Markdown has become the mainstream format for agents. He is someone who has built tools on the Markdown premise for a long time.
That person has now clearly stated: Markdown has become a restrictive format for me. This is the moment an Anthropic insider threw a stone at the premise the entire industry has been riding on.
To put it simply: the Markdown you get from Claude Code, the rules Cursor reads, and the AI outputs on your internal Wiki were all part of the same "Markdown is fine" flow. The person who created it has started drawing a different channel.
From here, we'll get into the specifics of why Markdown doesn't reach people and what to replace it with.
5 Reasons Why Markdown Isn't Read
Let's organize the limitations of Markdown. This isn't about technical specs; it's about your daily experience from Monday to Friday. I've listed the benefits of HTML from the original article by flipping them to show Markdown's weaknesses.
① If it exceeds 100 lines, even you won't read it
Thariq himself writes that when a Markdown file exceeds 100 lines, he stops reading it.
When you ask Claude Code to "summarize last week's competitor trends," you've likely had the experience of closing the 120-line response without scrolling. If the person who generated it doesn't read it, no one on the team will. The reality is that not just the author, but other members of the organization, are also just skimming.
② Even if shared, it doesn't open beautifully in a browser, so no one touches it
Markdown is not rendered beautifully natively in browsers. Line breaks break in Slack, formatting is ruined in emails, and it takes effort to convert it to PDF or take screenshots for proposals.
Every time you share, someone has to do the work of converting it into a "readable form." Markdown is a format that creates friction every time it's shared, to the point where links often aren't even clicked.
③ No colors or diagrams, so only the outline is conveyed
You want to emphasize a difference in numbers, show a warning in red, or show a flow with arrows. To do this in Markdown, you end up drawing diagrams with ASCII characters or expressing colors with Unicode box-drawing characters.
No one wants to decipher that, and the writer gets tired. Even if Claude tries hard to draw a diagram, it ends up being skimmed over.
④ You can't touch or move it, so it ends with just reading
You want to try a slightly calmer color, test the speed of an animation, or see how it looks if you increase a value by 1.5x.
In business, there are frequent situations where you need to "try it out" to make a judgment. You can't do that with Markdown. You read it, simulate it in your head, and then send back instructions in text—an inefficient loop.
⑤ It breaks when opened on mobile
Slack, email, or Notion on the go. In the Japanese business scene, half of shared materials are first opened on mobile.
Markdown layouts don't follow screen width. Tables overflow horizontally, code blocks are wrapped awkwardly, and heading hierarchies become invisible. The desire to read vanishes at that moment.
Let's give this a name. Every time you produce unread Markdown, fatigue builds up for both the sender and the receiver even before opening it. The cost of scrolling 100 lines, fixing line breaks in Slack, the failure to communicate due to lack of diagrams and color, the delay in judgment because you can't interact, and the breakage on mobile.
All of these are hidden fees paid every day. In this article, we call this the "Format Tax."
This is not a small tax. More than half of Claude Code's value is determined not by the content of the output, but by "who it reaches and how far." By outputting in a format that doesn't reach people, you are essentially throwing away half of your subscription.
How to Switch: Just Add "Output as an HTML file"
You don't need to overthink this. There is much less to do than you think.
Just add one line to the end of your usual Claude Code request. The following three mean the same thing:
- "Output as an HTML file"
- "Output as a single-page HTML"
- "Make it HTML so the reader can open it directly"
If you feel more comfortable writing in English, "make a HTML file" or "make a HTML artifact" is fine. The result is the same.
Claude Code can pull context from MCP, browsers, git, and the file system. The strength of Claude Code is that it can bundle much broader information sources into a single HTML than the web chat versions of ChatGPT or Claude.ai.
This connects back to what we discussed earlier. The Artifacts you received in ChatGPT or Claude.ai and thought were "beautiful" were output as HTML.
You can now receive that same world on the Claude Code side. It's not a difficult technical story; by changing one line in how you ask, materials that actually reach people will come out.
Thariq emphasizes one point in his article: "I don't want this to be made into an /html Skill yet; I want people to get used to it through prompts first." This is despite him being a developer on the Claude Code team who produces Skills.
He isn't dismissing making it a Skill. He's saying, "If you package it before the usage is solidified, you'll miss the parts that are truly effective."
Within Anthropic, HTML outputs that have become frequent are starting to be componentized into things like Playground plugins. Instead of waiting for a finished product from the start, try it with a one-line prompt first to find the pattern that fits your work. Only after reaching that point should you move to making it a Skill.
Writing "output in HTML" in every prompt might seem like a task, but choosing the format itself is not a task. The moment you switch from Claude outputting Markdown to Claude outputting HTML, you have moved half a step toward being the one who "designs the output before waiting for a pre-designed Skill."
5 Business Scenes That Change Just by Switching to HTML
This chapter is effective for actual work from Monday to Friday. I've reordered the five use cases from the original article in order of frequency in the Japanese business scene: Weekly Reports/Research Summaries, Parallel Comparison of Proposals, Design Tweaks, Decision-Making Editing Screens, and PR/Spec Reviews.
Each scene is summarized with the current problem, Before/After, and finally a sample instruction to give to Claude Code.
[Scene 1] Delivering Weekly Reports and Research Summaries with Diagrams
A common occurrence in Japanese business. Monday morning, your boss asks, "Summarize last week's trends."
Before: You paste 120 lines of Markdown into Slack. Line breaks break. Your boss doesn't open it. It doesn't get included in management meeting materials. You end up explaining it verbally, saying, "I had Claude do it."
After: You summarize it into a single HTML page incorporating Slack logs, Linear or Notion ticket history, git logs, and internal documents. You include a simple business flow diagram using SVG and place three key points in colored blocks at the bottom.
If you put this in internal storage and share the URL, your boss can open it on their phone while commuting, management can quote it, and it can be pasted into meeting minutes.
The key here is that Claude Code can pull context from MCP, browsers, git, and the file system. Even if you ask a web chat to "make an HTML," it's difficult to bundle so many information sources into one. This is a weekly report that only Claude Code can create.
Thariq himself wrote that he made the diagrams for his articles by having Claude Code read all the HTML in his code folder and summarizing them into one page. A "weekly report that gets read" and a "diagram for an explanatory article that gets read" are structurally the same.
▼ Sample Instruction:
"Read all of last week's Slack interactions, Linear ticket completions, and git logs, and output a weekly report as a single HTML page that my boss can grasp in 1 minute. Include a simple business flow diagram in SVG and three key points in colored blocks at the bottom. Make sure it doesn't break when opened on a smartphone."
[Scene 2] Showing 6 Proposal/Research Options Side-by-Side
Which direction should we take for next week's proposal? A common scene in planning, sales, and corporate planning where multiple options are created and aligned with decision-makers.
Before: You send six options in six separate Markdown files. The client can't open and compare them one by one. They ask, "Which one is your top recommendation?" and you realize you hadn't fully compared them yourself.
After: You arrange six options with different tones, densities, and target audiences in a grid on a single HTML page. You add a one-line trade-off under each option. The decision-maker compares them all on one screen and immediately responds, "I want to mix this and this" or "Use the target from #3 with the density of #1." The resolution of the discussion changes the moment you show them in parallel.
For a decision-maker, the time it takes to judge is worlds apart between receiving six files and having six options lined up on one screen. It's less about "getting them to read it" and more about "enabling them to make a decision."
▼ Sample Instruction:
"Create 6 proposal options for next week's presentation with different tones, densities, and target audiences, and arrange them in a grid on a single HTML page. Write a one-line trade-off under each option. Also, add a button at the bottom to copy the result as Markdown once a decision is made."
[Scene 3] Deciding on Designs and Prototypes by Touching Them
When deciding on colors, sizes, or movements, you should give up on aligning through text. This is a scene where marketing, PR, and planning go back and forth many times over thank-you emails or landing page buttons.
Before: You communicate with words like "a slightly calmer blue" or "make the movement fluffy." The receiver's image deviates every time. Looking at the version that came back after one round, you add more words: "No, not that kind of calm."
After: You have Claude Code create an HTML where you can move sliders for color and animation speed. You create prototypes for thank-you email buttons or LP CTA buttons as single HTML pages and send the URL to stakeholders. Everyone touches it, decides on the best values, and just copies those values back to Claude. Text back-and-forth decreases, and time to agreement shortens.
Related to this, Anthropic Labs is starting to formalize this "touch to decide and copy the operation back to Claude" concept as a Playground plugin. HTML output is not just a small trick; it's a direction Anthropic itself is nurturing as a pattern.
▼ Sample Instruction:
"Create an HTML where I can decide the color and animation speed of the button in the thank-you email using three types of sliders. Add a button at the bottom to copy the decided values."
[Scene 4] Making a Judgment Screen in 3 Minutes
Which measures should be assigned to Now, Next, Later, or Cut for the next term? Sorting 30 tickets to decide priorities is a typical "judgment task" for PdMs, planners, and corporate planning.
Before: You line up 30 items in a spreadsheet and manually fill in the priority column one by one. You sort, rethink, move to another sheet, and move back. Some days you spend 30 minutes and still don't have a conclusion.
After: You ask Claude Code to "make an HTML where I can drag and drop items into four columns: Now, Next, Later, and Cut." A dedicated editing screen is ready in 3 minutes. You drag the 30 cards, and when finished, copy the results. The time for judgment tasks shrinks by an order of magnitude.
There is a design principle here that is easily overlooked but highly effective. It's the sentence where Thariq writes, "Always end with an export." When making an editing screen, always include buttons for "Copy as JSON," "Copy as Prompt," or "Copy as Markdown."
Without this, you can't return the results of your sorting to Claude, and it ends as just a task tool. An editing screen becomes a judgment device only when you create a loop: judge in HTML, then return the structured text result to Claude.
This same idea can be used for editing feature flags, side-by-side system prompt editors, or dataset approve/reject/tagging. "Creating a dedicated, disposable UI in 3 minutes" is where the true value of Claude Code is most clearly demonstrated.
▼ Sample Instruction:
"Create an HTML where I can drag and drop 30 measures for the next term into four columns: Now, Next, Later, and Cut. At the end, place a 'Copy as Markdown' button so I can output the sorting results with reasons for each line."
[Scene 5] Handing Over PR Reviews and Spec Sharing with Color-Coded Diffs
Finally, a scene for collaborating with engineers. Even if you don't read code, as a PdM, director, or editor, you might be called in for PR reviews or spec confirmations.
Before: You are asked to open the GitHub diff screen. You can't tell which part of the diff is important and which can be ignored just by looking. You have to read the comments to follow the story. People who don't read code often just say "let me know if there's anything" and close it.
After: You ask Claude Code to "turn this PR into an HTML review document that someone who doesn't read code can grasp in 30 seconds." Comments are attached next to the diffs, the scope of impact is color-coded, and a summary of three concerns is provided at the end. If you upload this to internal storage and share the URL, PdMs and directors can provide feedback with one button. Those collaborating with engineers can finally participate in reviews.
HTML is not a language for engineers; it's a tool for delivering a story. The meaning of the diff, the risks, and the scope of impact—this "information that requires deciphering" is delivered with annotations, color, and layout. That is the meaning of HTML conversion.
▼ Sample Instruction:
"Turn this PR into an HTML review document that someone who doesn't read code can grasp in 30 seconds. Attach comments next to the diffs, show the scope of impact with color coding, and summarize three concerns at the end."
While you continue to output in Markdown for these five scenes, the format tax is quietly but daily accumulating. Whether you stop it the moment you notice will be the difference starting next week.
6 Questions That Arise When Switching
Reading this, several questions likely come to mind. I've reordered the FAQ section from the original article in the order Japanese business readers are likely to encounter them.
■ Does it use more tokens?
Yes, it does. The original article states it takes 2-4 times longer to generate than Markdown. However, Opus 4.7 has a 1M token context, so the risk of conversations breaking due to context limits from returning HTML is virtually gone.
Thariq's conclusion is: "The numbers increase, but if you choose the result that gets read, it pays off for the total work." It's a choice of whether to use your 3,000+ yen monthly contract for 1,000 lines of unread Markdown or one page of HTML that gets opened.
■ Won't the design be ugly?
This is a valid concern, but there are countermeasures.
One is to use Claude Code's frontend design plugins. Another is to provide Claude with a sample HTML from your company's site or existing materials. If you provide a reference file and say "in this tone" or "with this font and palette," Claude will output HTML that matches your company's look. Keeping a file like design-system.html in your codebase allows you to reference it every time.
■ Isn't editing HTML a hassle?
You don't need to edit it yourself.
Thariq himself writes that he doesn't directly touch the HTML. If you tell Claude, "Calm this color down a bit" or "Make the third section a bit smaller," it will fix it for you. As long as you use it for specs, brainstorming, or reference materials, you can leave all editing to Claude.
■ How do I open it? How do I share it?
Opening it is easy. Just open the HTML file Claude Code produced locally in your browser.
You can even ask Claude to "open this file," and it might open it in your browser for you. When sharing, the easiest way is to upload it to internal storage or S3 and provide the URL. If you paste the link in Slack or email, the recipient can open it in their browser. That extra step of converting Markdown to PDF completely disappears.
■ What about version control?
To be honest, HTML is not very suitable for Git diff management. Fixing one line might move diffs elsewhere due to formatter settings. Thariq himself writes that HTML is the biggest weakness of version control.
That's why the practical solution is: "Deliverables for people" are HTML, and "specs or records you want to keep history for" are Markdown. It's not about abolishing Markdown, but switching to a mindset of choosing the format based on the purpose of the output.
■ Can I stop using Markdown altogether?
No. Records, change histories, and structured text you want to keep in the repository should remain as Markdown.
CLAUDE.md and SKILL.md are easier to manage and track diffs for if they stay as Markdown. HTML is suited for "delivering to people," "letting people touch it," "lining up multiple options," and "letting people judge with color." If you understand it broadly as "Markdown for interacting with AI, HTML for distributing to people," you won't get lost.
By now, your initial doubts should be cleared. An article that includes drawbacks is more trustworthy—that's my belief as a writer.
Will You Keep Paying the Format Tax or Move to the Design Side?
Finally, let's raise our perspective to close.
We've previously discussed the "Prompt Tax"—the cost of re-typing the same premises to Claude. Then, the story of moving to the design layer with the .claude folder. This "Format Tax" is the third theme in that series. After the conversation layer and the design layer, we have now addressed the output layer.
Let's define "Format Tax" as something we can share with readers:
If you keep choosing output formats that aren't read, fatigue builds up for both you and others even before opening. You pay over 3,000 yen a month for Claude Code, yet the deliverables are never used in meetings. That feeling comes from not making a judgment on format selection. This is the Format Tax.
Outputting in Markdown is a task. Choosing HTML is a judgment. Even using the same Claude Code, a single judgment in format selection significantly changes the distance your deliverables reach.
And HTML is not a language for engineers. It's a tool for creating materials that get read. Put aside the idea of building a website for a moment. Just try outputting the weekly report, proposal, or review document you're writing this week in HTML. That's enough.
Let's talk about the bigger picture.
The era where Markdown was the implicit standard of the AI industry is quietly ending inside Anthropic. While CLAUDE.md, SKILL.md, and Cursor rules were all built on a Markdown premise, the output format is starting to switch first. Readers who witness the moment the standard changes can move half a step ahead.
Of course, once you realize "I do this every week," you can then choose to evolve it into a Skill.
Inside Anthropic, patterns with high frequency for HTML output, like design-related Playgrounds, are gradually being nurtured as components. However, for the first week, a one-line prompt is enough. Tonight, try outputting just one weekly report in HTML. Next week, try lining up six proposal options in a single grid. Start there, and the format tax will quietly begin to decrease.
Thariq himself writes at the end of his article: "I had a fear of stopping deep reading of Markdown and leaving judgments entirely to Claude. Since switching to HTML, I feel more like I'm back in the loop with Claude, and above all, it's simply fun to create."
Choosing a format is a switch to regain initiative when working with AI, and at the same time, a switch to bring a little heat back to your daily work.
Will you continue to produce unread Markdown, or will you move to the side that chooses the format? The next week will be the boundary.
Summary
- The developer building Claude Code at Anthropic declared he no longer uses Markdown. HTML adoption is spreading within the internal team.
- Until now, Markdown was the implicit standard for AI—from Claude Code and Cursor to GitHub Copilot, Cline, internal Wikis, and ChatGPT outputs. The creator has now challenged that industry standard.
- There are 5 reasons Markdown isn't read: can't re-read at 100 lines / breaks when shared / no color or diagrams / can't touch to judge / breaks on mobile. These hidden costs are the "Format Tax."
- To switch, just add one line: "Output as an HTML file." Making it a Skill can wait until usage is solidified.
- 5 business scenes—weekly reports, parallel proposals, design tweaks, judgment screens, and PR reviews—transform into materials that are opened, judged, and returned just by switching to HTML.
- Choosing a format is a judgment, not a task. Outputting in Markdown is a task; choosing HTML is a judgment. The difference between Claude Code users opens up here.
For those who found this article helpful:
The University of Tokyo Claude Code Laboratory (@ClaudeCode_UT) is an account run seriously by a team of UTokyo students. We are also working on joint Claude Code business development with major companies, and we only share designs and know-how that actually work in the field.
We deliver "genuinely useful" information and know-how specialized for practical work every day 👇
■ Free release of Claude Code skills usable in practice
■ Translation and restructuring of primary overseas AI information into a Japanese business context
■ This is the only place to receive skills and tools developed seriously by the UTokyo team that are "genuinely useful" for free ❗️
If you're interested, please follow and check us out.
LINE is here ⇩
