There is a term for what is happening here. Cory Doctorow coined it: enshittification.1 The pattern is familiar from social media platforms — start by genuinely serving users, then degrade the product to serve business goals, then extract whatever remains. Applied to AI interfaces, the mechanism is slightly different but the result is the same: tools that looked impressive in the demo and erode under daily use.
The specific degradation this article is about is markdown. Every major AI chat interface — ChatGPT, Gemini, Claude, Copilot — takes your markdown in and gives you rendered HTML back. What should be a frictionless loop between text and model becomes a series of small obstacles, each individually manageable, together exhausting.
Markdown is where AI thinks
Large language models are trained on enormous corpora of text. A large proportion of that text is markdown: GitHub README files, documentation pages, forum posts, technical articles, code comments. The models have an unusually deep understanding of markdown syntax — not just as formatting markup, but as a semantic signal. A # heading tells the model something about structure. A code fence tells it something about context. A bullet list tells it something about how the items relate to each other.
When you write a prompt in markdown, you are speaking the model's first language. When you receive a response in markdown, you have something you can carry forward — paste into a spec document, use as the basis for a new prompt, feed into a pipeline. The format is a feature, not decoration.
The loop that should exist: Write markdown → Model responds in markdown → You refine and continue, all in the same format. No conversion step. No cleanup. Just text moving through a system that understands it.
The rendering trap
Every major chat interface renders AI responses as formatted HTML. Asterisks become bold. Hash signs become headings. Backticks become styled code spans. The result looks polished to a first-time user. To someone who needs the raw markdown, it is a wall.
Getting raw markdown out requires either prompting the model to wrap its entire response in a code block — which works unreliably and breaks down completely for longer responses or responses that themselves contain multiple code blocks — or using the copy button and cleaning up afterward. Neither should be necessary.
The frustration is sharpest when the response contains code. Ask any AI assistant to generate a markdown document with embedded code samples. It will return something that looks correct in the rendered view. The moment you need to use that response as input to something else — another prompt, a file, a pipeline — you are working against the interface rather than with it.
The input box that edits your input
The rendering problem does not start at the output. It starts the moment you begin typing your prompt.
Most AI chat interfaces apply live markdown formatting to the input field. Type a backtick-delimited phrase and it becomes an inline code span before you finish the sentence. Type two asterisks and the cursor lands inside a bold scope. The interface is trying to be helpful. What it is actually doing is modifying your input in ways you did not ask for, in a field where you cannot always see what the underlying text has become.
The practical consequence: if you continue writing after an inline code span, the formatting can bleed into the surrounding text. You submit a prompt that looks correct on screen but contains hidden formatting markup that the model interprets differently than you intended. You do not notice until the response is wrong in a way that is hard to diagnose.
This problem is compounded in tools like Claude and Copilot Chat, where the input field also processes pasted content. Paste a markdown snippet and the interface may render it before it reaches the model — what the model sees is the rendered representation, not the source.
The copy button illusion
Every AI chat interface has a copy button. It copies the response. This sounds like a solution to the rendering problem, and for short responses it sometimes is: the clipboard receives the raw markdown, you paste it into your editor, done.
For longer responses it breaks down. The copy button gives you everything — the markdown you wanted, plus surrounding text you did not, plus whatever framing the interface added around the response. You paste into a text editor and face a cleanup task before you can use the content. The copy button moved the friction rather than removing it.
There is also a subtler failure: selecting text manually from a rendered response and copying it — as you would with any web page — does not give you markdown. It gives you plain text stripped of all structure, or in some cases rich text that carries the rendered formatting into wherever you paste it. The two copy paths — button and selection — produce different output, and neither is reliably the one you want. We cover this in detail in Copy button vs. selection: what you actually get.
Inconsistent exports
Some interfaces offer structured exports. Gemini, for example, includes an option to export a response to Google Sheets or to copy it in a format suited for spreadsheets. For tabular data this can work reasonably well — the structure maps onto cells and the result is usable.
Export the same content to a word processor and the result is frequently a single block of unseparated text. Paragraphs collapsed. Lists gone. The structure that existed in the markdown, and that was correctly represented in the rendered view, disappears entirely in the exported document.
This is not a failure of the underlying technology. Converting markdown to a .docx file is a solved problem — there are open-source libraries that do it correctly.2 The export features were built to cover a specific demo scenario. The adjacent use cases were not tested, or were tested and deprioritised.
The form interface
GitHub Copilot Chat and Cursor have introduced a pattern where the assistant responds to certain prompts by presenting a form — a set of labelled buttons or a short multiple-choice list — rather than asking a follow-up question in plain text. The intention is to reduce friction for common decisions: naming conventions, framework choices, file structure options.
The form achieves the opposite of what it promises. If you want to answer differently from the available options, you cannot modify one of them — you dismiss the entire form and lose the question context. If you want to qualify your answer, explain a constraint, or combine two options, the interface gives you no way to do it. The prompt-response loop, which works by allowing the user to express anything in language, is replaced by a widget that accepts only what the designer anticipated.
This is the starkest example of the pattern: a feature designed to look helpful in a five-second demo that actively degrades the experience for anyone who uses the tool seriously.
Streaming artifacts
AI responses arrive as a stream of tokens. The interface renders markdown in real time as those tokens arrive. The result is a class of visual glitches that only exist because the interface chose to render rather than display: a code block that appears to open, renders several lines of formatted output, then closes and re-renders as the model produces the closing fence; a heading that momentarily appears as a paragraph; a table that reflows as columns are added mid-stream.
These are not serious functional problems. They are symptoms. An interface that displayed raw markdown as it arrived would have none of them, because there would be nothing to reparse. The glitches exist because the interface made a rendering choice that is difficult to execute correctly and easy to get wrong.
What this is, really
None of these problems are technically hard to solve. Displaying raw markdown is simpler than rendering it. A toggle between rendered and raw view is a single button. Consistent export is a library call away. A plain text input field is less engineering than a live markdown editor.
The reason these problems persist is that the people evaluating these interfaces are not, in the main, people who use them daily for markdown-heavy work. They are people running demos, looking at screenshots, evaluating first impressions. A rendered response looks more impressive than a raw one to someone seeing the tool for the first time. A form with buttons looks more polished than a follow-up question in plain text.
The optimisation target is the moment of evaluation, not the month of use. That is enshittification applied to a product cycle that moves too fast for the degradation to register before the next version ships.
"Platforms initially offer high-quality services to attract users, then pivot to abusing those users to favour business customers, and finally claw back all value for themselves."
— Cory Doctorow, coining the term in 2022The irony is that markdown is the reason AI assistants are as useful as they are. It is the format that makes long responses parseable, that makes code distinguishable from prose, that makes a model's structured thinking visible and portable. The interfaces built around these models have decided, product feature by product feature, that their users should not see that. The result is a set of tools that are harder to use seriously than they need to be, optimised for a first impression that the daily user has long since moved past.
1 Doctorow introduced the term in a January 2023 essay on Pluralistic. The Wikipedia article on enshittification documents its spread.
2 The markdownword.com converter, among others, handles this conversion correctly — including code blocks, tables, and nested lists — precisely because it treats the problem as an engineering task rather than an afterthought.
Further reading: How AI interfaces break the format they run on · Copy button vs. selection — why they give you different text · Which Markdown flavor for AI?