My technical writing predictions for 2025

For the first time since I started this blog, I’m writing some predictions on software technical writing for next year. Not because I think they’ll be accurate—they never are—but because the exercise reveals what we’re concerned about and what we hope to tackle. Predictions are to-do lists in disguise: they highlight challenges we’re determined to overcome. Plus, they’re fun to write. So here are my predictions for 2025, knowing I’ll enjoy being proven wrong.

2025 will not be the Year of Technical Writing

The main worry of technical writers in 2024 was the fear of losing our jobs to AI, budget cuts, or both. The job market shrunk in the second half of the year, only to see shy signs of recovery in the last quarter of the year. The prevailing vibe is bearish: in tech writing communities, many are considering switching careers. It felt like the End of Tech Writing at times, perhaps because we’re a romantic bunch and like to brood over our fate in our spare time.

No year has ever been the year of technical writing, and 2025 won’t be the exception. We’ll continue to feel cornered and defend our craft against mounting odds, shunned by a tech sector whose knowledge of documentation rarely goes beyond README files and FAQs. Advocacy will be more necessary than ever, especially with AI usage going mainstream for huge swathes of society as AI services become more embedded, accessible, and cheaper.

We’re in this fight together with what I call “peripheral professionals”, that is, humanists and artists that bridge the gap between the dry backends of software and humanity. Since the inception of LLMs, tech’s periphery, which was considered a noble crossroad before, has come under attack, with artists, support agents, writers, and others losing their jobs or fearing to lose it, the value of their skills questioned by owners of inscrutable business logic.

In a recovering job market, landing a job will require AI augmentation

The good news is that the job market is going to recover as those owners of code progressively realize the limitations that are inherent to replacing the folks at the periphery with numb language models, something they’re already noticing when it comes to coding tasks. After a stint of degrowth that has felt way too long, companies will seek to grow again in a more sustainable fashion, a trend that will carry the need for better documentation with it.

The catch is that life in the periphery of tech will require AI augmentation and training. If past job offers emphasized API documentation and coding skills, in 2025 tech writers will have to be proficient operators of AI tools, both for writing in docs-as-code environments as for becoming coding associates, able to execute docs infrastructure and toolchain work. When done well, job interviews will ask writers to be able to use AI in writing tests in efficient, innovative ways.

If I’ve learned something this year is that the LLM-powered writing and coding isn’t going away. Technical writers will need to focus more on content strategy, information architecture, and tooling, and less on writing; at the same time, they’ll be expected to know how to use tools like Cursor’s composer mode to set up entire documentation sets in little time, and then iterate. As I explained in What’s a docs engineer, writers will continue specializing in two separate strains.

Right now, some of us are to technical writers what software developers at Pixar were to classic animators in the early 90s: in the future, creating docs experiences will require knowledge of tools that we’re still developing, but the essence of the craft will still be the same. As computer graphics didn’t kill animation, so AI augmented writing won’t kill technical writing. For that, though, you must be able to embrace the idea of being a transhuman writer:

If a tool is better at something, wouldn’t you give it to qualified operators if you were running a business? Picture chainsaws vs. hatchets or cars vs. rickshaws. The key here is what makes someone a qualified operator of an AI based tool. To answer that, one must first accept that AI can enhance our abilities.

The rise of docs-as-data… and the unexpected return of manuals

The idea of writing for LLMs is easy to ridicule because LLMs need to be proficient readers of human-made materials in order to do their job; they don’t need to be spoon fed content in some flavor of SGML. If you write well for humans, you’re writing well for machines. What seems to matter, though, is how you package content for AI consumption. LLMs favor Markdown and plain text, structural primers such as llms.txt, as well as metadata (for example, frontmatter).

Much in the same way we create API documentation in OpenAPI so that both humans and machines can consume it, we’ll be working hard to provide AI agents with easy to consume versions of our docs, sometimes enriched with additional metadata. While a standard doesn’t exist yet (and may never do), we’ll see some clever solutions to package docs in text pellets that LLMs equipped with larger context windows will be able to swallow without effort.

This is a game changer for developer documentation in particular, but it’ll extend to user documentation as well. Picture a developer inserting a docs cartridge into his AI powered code editor: the presentation layer is going to be largely irrelevant, the docs powering the answers of locally executed LLMs to aid developers in their coding quests. In a multi-channel content strategy, LLM-tailored output is going to be an additional, incredibly relevant channel.

The delicious irony of packaging all docs together for LLMs is that we’ll be essentially publishing… books. My hope for 2025 and beyond is to see a resurgence of manuals, in the sense of highly structured, well maintained sets of documentation that are treated as a product for the sake of better multi-channel consumption, including AIs. The moment you package docs together, you’re producing a versioned deliverable instead of an incomplete stream of docs.

Docs development kits (DDK) and becoming hybrid architects

In docs-as-code contexts, documentation will call for specialized tools or features that can ease docs generation, authoring, and editing. Some will take the form of IDE add-ons, others will look like SDKs for automating docs generation and maintenance by leveraging LLMs in codebases. I think we’re not far from reference docs generation happening as a step of CI/CD pipelines, chaining calls to local or remote LLMs to update documentation in single sweeps.

The advent of DDKs will be a big opportunity for technical writers. We should be there, owning the process, overseeing the configuration and fine-tuning of those tools. It could be as simple as creating a dotfile for an LLM friendly style guide. In other cases, we might have to learn to create some glue code in Python. It doesn’t really matter, given the potential reward. As I said elsewhere:

The potential of AI content in certain scenarios, such as integration docs or code samples, is huge. Figure out where AI should interface in your information architecture and let the LLMs roam within the boundaries that you build for them. Shepherd AIs.

All attempts at connecting deterministic docs linting with LLM-powered editing seem to have largely flunked in 2024. I expect things to improve next year, perhaps with docs-focused models trained on style guides. With training and execution costs hopefully plummeting, we might even be able to train specialized models for different tasks, such as editing, code sample generation, and so on. We’ll be training their own minions to help us maintain consistency and coverage.

DDKs may come in different shapes, from features in existing docs SaaS to standalone SDKs featuring docs helper functions, but the essence behind its usage will be the same, that of developing documentation programmatically under the supervision of human editors. This implies merging the mindset of a content strategist with that of a software architect. Rather than being passive recipients of AI tools, tech writers will step into a more architectural role, actively shaping how tools are implemented and integrated into documentation systems.

The predictions I’m leaving out

I haven’t written anything here about docs observability because I think it’s already feasible and only requires a different mindset around docs. Similarly, I haven’t added a prediction on the geopolitics of tech writing and the language we’ll use in tech writing (as I did in my predictions for 2049) because I think it’s a bit premature to talk about that; I don’t expect dramatic changes in 2025, but we can’t ignore that technical writing doesn’t happen in a bubble.

In the end, our current concerns about AI and automation are pushing us to rethink not just how we write documentation, but how we architect information systems that can serve both human readers and machine consumers. The tools I’m predicting today aren’t just solutions to our present challenges; they’re the blueprints for a future where technical writing transcends its traditional boundaries. The question isn’t whether we’ll adapt, but whether we’ll own the adaption itself.