AI works well for one kind of documentation. The kind of documentation no one reads, that is just here to please some manager, or meet some compliance requirement. These are, unfortunately, the most common kind I see, by volume. Usually, they are named something like QQF-FFT-44388-IssueD.doc and they are completely outdated with regard to the thing they document despite having seen several revisions, as evidenced by…
I let it generate README.md files for my projects and they look awesome and they read nice and are theoretically helpful for everyone new. And LLM are really good in reading your docs to help someone. So I make sure to add more concrete examples into them
To those who fired or didn't hire tech writers because of AI
231–240 of 278 posts
Re: To those who fired or didn't hire tech writers because of AI
#232If that was more technical tho, like something more similar to technical writing... I would have had Copilot summarise it for me.
You are correct, the future is collaborative with AI, but not everything will still need to be collaborative...
Technical writing, like manuals and whatnots, that is simply akin to a math problem that, post calculator, has always calculated by calculators - even by people who didn't need them.
It will not be better, there is absolutely loss, it will still happen.
Re: To those who fired or didn't hire tech writers because of AI
#233Earlier quoted context omitted.
What’s the point of confirming? AI can lie and so can humans as well. I believe you but that’s just a gut feeling. I guess the best way to put this is anyone can write what you wrote with AI and claim it wasn’t written by AI.
Prove it.
The decision to stop hiring technical writers usually feels reasonable at the moment it’s made. It does not feel reckless. It feels modern. Words have become cheap, and documentation looks like words. Faced with new tools that can produce fluent text on demand, it is easy to conclude that documentation is finally solved, or at least solved well enough.
That conclusion rests on a misunderstanding so basic it’s hard to see once you’ve stepped over it.
Documentation is not writing. Writing is what remains after something more difficult has already happened. Documentation is the act of deciding what a system actually is, where it breaks, and what a user is allowed to rely on. It is not about describing software at its best, but about constraining the damage it can do at its worst.
This is why generated documentation feels impressive and unsatisfying at the same time. It speaks with confidence, but never with caution. It fills gaps that should remain visible. It smooths over uncertainty instead of marking it. The result reads well and fails quietly.
Technical writers exist to make that failure loud early rather than silent later. Their job is not to explain what engineers already know, but to notice what engineers have stopped seeing. They sit at the fault line between intention and behavior, between what the system was designed to do and what it actually does once released into the world. They ask the kinds of questions that slow teams down and prevent larger failures later.
When that role disappears, nothing dramatic happens. The documentation still exists. In fact, it often looks better than before. But it slowly detaches from reality. Examples become promises. Workarounds become features. Caveats evaporate. Not because anyone chose to remove them, but because no one was responsible for keeping them.
What replaces responsibility is process. Prompts are refined. Review checklists are added. Output is skimmed rather than owned. And because the text sounds finished, it stops being interrogated. Fluency becomes a substitute for truth.
Over time, this produces something more dangerous than bad documentation: believable documentation. The kind that invites trust without earning it. The kind that teaches users how the system ought to work, not how it actually does. By the time the mismatch surfaces, it no longer looks like a documentation problem. It looks like a user problem. Or a support problem. Or a legal problem.
There is a deeper irony here. The organizations that rely most heavily on AI are also the ones that depend most on high-quality documentation. Retrieval pipelines, curated knowledge bases, semantic structure, instruction hierarchies: these systems do not replace technical writing. They consume it. When writers are removed, the context degrades, and the AI built on top of it begins to hallucinate with confidence. This failure is often blamed on the model, but it is really a failure of stewardship.
Responsibility, meanwhile, does not dissolve. When documentation causes harm, the model will not answer for it. The process will not stand trial. Someone will be asked why no one caught it. At that point, “the AI wrote it” will sound less like innovation and more like abdication.
Documentation has always been where software becomes accountable. Interfaces can imply. Marketing can persuade. Documentation must commit. It must say what happens when things go wrong, not just when they go right. That commitment requires judgment, and judgment requires the ability to care about consequences.
This is why the future that works is not one where technical writers are replaced, but one where they are amplified. AI removes the mechanical cost of drafting. It does not remove the need for someone to decide what should be said, what must be warned, and what should remain uncertain. When writers are given tools instead of ultimatums, they move faster not because they write more, but because they spend their time where it matters: deciding what users are allowed to trust.
Technical writers are not a luxury. They are the last line of defense between a system and the stories it tells about itself. Without them, products do not fall silent. They speak freely, confidently, and incorrectly.
Language is now abundant.
Truth is not.
That difference still matters.Re: To those who fired or didn't hire tech writers because of AI
#234Re: To those who fired or didn't hire tech writers because of AI
#235Earlier quoted context omitted.
His other comment in this thread is also a clone of someone else's comment.
And it happened after I wrote that comment. Which means I replied to a bot. I am officially retiring from social media.
And im new to hackernews lol
Re: To those who fired or didn't hire tech writers because of AI
#236Re: To those who fired or didn't hire tech writers because of AI
#237The fired writers should get together start their own publications. AI can’t generate insights far beyond what it’s trained on. Their writing will be a different moat.
> The fired writers should get together start their own publications. What if the next version of AI model gets trained on their work ?
Google returns the best result based on both it's calculations, and click history of what clicks were most successful for a search.
LLM's don't really have that same response partially because it's strength is writing one sentence many different ways. The many different ways to write a sentence doesn't mean it's the best way. If it can write deep sentences, keeping a coherent, connected arc through sentences and stories
LLMs' also generally return the "best" answer as the most "common" one, without weight towards outliers as easily that might be the most true, or the best.
The definition of what is "good" and "correct" can also vary quite a bit, especially with writing.
AI can be configured to look for patterns humans might not see, but we also know humans can see things and scenarios that LLM's aren't trained on and can miss getting to.
As we can tell with AI copy, it all starts to sound the same even if it's new. Real writing ages differently. It can be much more of a finger print. This is an area I'm hoping to learn more about from the talented writers in my life - it seems the better the writer, the more they can see the holes of LLM and also be the best power users of LLMs by their superior ability to use words whether they realize it or not.
Re: To those who fired or didn't hire tech writers because of AI
#238The best tech writers I have worked with don’t merely document the product. They act as stand-ins for actual users and will flag all sorts of usability problems. They are invaluable. The best also know how to start with almost no engineering docs and to extract what they need from 1-1 sit down interviews with engineering SMEs. I don’t see AI doing either of those things well.
AI may never be able to replace the best tech writers, or even pretty good tech writers. But today's AI might do better than the average tech writer. AI might be able to generate reasonably usable, if mediocre, technical documentation based on a halfheartedly updated wiki and the README files and comments scattered in the developers' code base. A lot of projects don't just have poor technical documentation, they have…
AI would do a great job of fixing their writing, but they don't want to use it, because it's not an official part of "the process".
>and comments scattered in the developers' code base
I'm not so sure about this one. Most devs I've worked with don't use comments.
Re: To those who fired or didn't hire tech writers because of AI
#239Yeah. AI might replace tech writers (just like it might replace anyone), but it won't be a GOOD replacement. The companies with the best docs will absolutely still have tech writers, just with some AI assistance. Tech writing seems especially vulnerable to people not really understanding the job (and then devaluing it, because "everybody can write" - which, no, if you'll excuse the slight self-promotion but it saves…
That's fine, though: as long as the AI's output is better than "completely and utterly useless", or even "nonexistent", it'll be an improvement in many places.
Re: To those who fired or didn't hire tech writers because of AI
#240Earlier quoted context omitted.
Low-quality is relative. LLMs' low-quality is most people's above-average. The fact the copy - either way - is likely to go through some sort of copy-by-committee process makes the case for LLMs even stronger (i.e., why waste your time). Not always, but quite often.
No it's not. It's low quality because it's extremely verbose and that wastes time.