> For the complete documentation index, see [llms.txt](https://stateofdocs.com/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stateofdocs.com/blog/the-writing-was-never-the-hard-part-notes-from-the-state-of-docs-panel-with-wtd-nyc.md). # The writing was never the hard part: notes from the State of Docs panel with WTD NYC AI can draft docs now, so why do writers still matter? Notes from our State of Docs panel with Write the Docs NYC on where the real work lives. **We ran a State of Docs panel in New York last week, co-organized with Lois Patterson and Write the Docs NYC. It poured all evening — the kind of rain that makes staying home the reasonable choice — and the people who came out anyway were some of the most engaged I’ve had in a room.**

The panel: Ravind Kumar, Casey Brown, and Nikita Jotwani, moderated by Tal Gluck (photo courtesy of Chris Cho)

The panelists were Ravind Kumar, Principal Curriculum Engineer at MinIO; Casey Brown, Senior Technical Writer at Squarespace; and Nikita Jotwani, Principal Developer Advocate at HubSpot. Each has a different role related to documentation, and they kept circling the same idea from different sides. The panel covered a lot of ground: how people are actually using AI in their docs work, where it helps and where it quietly doesn’t, and how the docs field and the role of technical writer are changing. In this post, I want to focus on one thread which came up a few times and has been on my mind since working on this year’s State of Docs report. ### The conclusion everyone’s drawing Now that AI can write a decent first draft, a lot of people have landed on the same conclusion: if writing is cheap, writers must not matter much anymore. And at first glance, this seems reasonable. The title is “writer” and writing is the visible output. The visible output is the part a model can now handle, so the job looks finished with little effort. I think it’s the opposite. Writing was never the hard part — it was the last step. Before you write anything, someone has to understand the thing well enough to explain it, work out who’s reading and what they’re actually confused about, decide what to leave out, and catch the sentence that’s technically correct but still might mislead someone. They need to understand the broader context around the docs, and know how to get and shape that context. The writing only starts once all that is done. Ravind put it plainly: use AI to test, use AI to scaffold, but don’t let it write your prose for you. Of course an LLM can produce the sentences. But handing it the prose hands off the one easy step and skips the hard ones underneath it. Casey described what that looks like in practice at Squarespace. She’s doing less writing now and more reviewing — and because publishing no longer eats all her time, she’s finally getting to the work that used to sit on the back burner: restructuring, templates, the information architecture of the whole doc set. Rather than replacing her job, AI took the mechanical part off her plate so she could get to the harder one. ### The judgment is the job One of the things the panel got specific about was what actually makes docs good. It wasn’t simple polish, but instead it was someone knowing enough to catch the thing that will hurt a reader — the instruction that reads fine but actually walks a particular kind of user off a cliff three steps later. To make docs good, you need someone who puts themselves in the position of the user to say, no, that’s going to mess with someone. And that’s the part that needs a person in the loop. A model can tell you a sentence is grammatical and consistent with the rest of the page. But it’s much less reliable at telling you the reader came in confused about something else and is about to misread a line, because that depends on things that live outside the text. Things like talking to customers, or to the people filing the tickets. The tools are getting better at supporting this, but someone still has to hold it. ### Cheap text raises the stakes The flood of easy writing makes that judgment matter more than it used to. When text was expensive to produce, the fact that a page existed told you a person had spent real time on it, but now that signal is gone. Correct and plausible-but-wrong look the same now, and there’s a lot more of both. So what separates good docs from noise is the review and the judgment that were doing the real work all along. The readers are changing too. Nikita described a now-familiar use-case: HubSpot writing with a dual lens now, for people, and for the agents reading docs on someone’s behalf. A person who hits a confusing line can reason around it, but an agent takes a wrong instruction and repeats it, confidently, to everyone who asks. An audience that can’t tell when it’s been misled makes it that much more important to get the underlying work right. If you have LLMs both writing the docs and reading the docs without anyone stepping in to verify their accuracy, then you’ll get chaos. Ravind thinks people are starting to notice. There’s a backlash building against machine-generated content. He pointed to Kelsey Hightower’s line: “if you didn’t write it, I’m not reading it.” The teams reading “writing is cheap” as “we can cut the writers” are, he suspects, about to find out what the writers were for. ### Where this leaves us The mistake is reading the job by its title. Writing was always the visible surface over a lot of harder work that didn’t have a tidy name, and that pile is the part that survives — because it was never really writing. The people who were good at the underlying work, and the teams building tools to help them do it at this new volume, are the ones who come out ahead. That’s a different job than the name of the role suggests. And while we’re starting to see new titles pop up — context engineer, knowledge engineer, content engineer — I don’t think the tooling, metrics, or org charts have fully caught up to it yet. Which is more or less what State of Docs is for. I suspect we’ll be working on this for a while, which is as good a reason as any to keep showing up, rain included. Thanks again to Ravind, Nikita, and Casey, and to Lois and everyone at WTD NYC. *** *These are the questions behind this year's State of Docs report.* [*You can read the full report here.*](https://stateofdocs.com/) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://stateofdocs.com/blog/the-writing-was-never-the-hard-part-notes-from-the-state-of-docs-panel-with-wtd-nyc.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.