Technical writing in the age of AI

At a function not too long ago, my wife’s co-worker asked me, “What do you do?” I responded that I was a technical writer, to which this person responded, “Aren’t you afraid of AI taking your job?”

I waited a few beats as if contemplating the question. Then I smiled.

“No,” I said. “Not in the least.”

In our new age of generated text, there is an assumption that all writing, especially technical writing is on endangered species list. Some people think that computers can provide a deeper understanding of technical material being the computer is also technical in nature. Others believe, that it doesn’t matter. When a simple prompt can produce an article in a matter of seconds, it’s only natural to believe technical writing to be a dead-end job.

Game. Set. Match.

See you at the horse buggy convention.

The role of the technical communicator

Obviously, I don’t believe in any of those arguments. A computer is a machine that cannot innately understand technical things because it is non-sentient. As for generating articles with a prompt, that’s like playing frisbee with landmines.

In a previous article, I mentioned that AI provided no danger to effective writing. While AI may at times “stumble” into effective writing, the reality is that AI-produced writing – writing based on statistics and probability – creates very mediocre writing. This is because the machine has no concept of the audience.

This is compounded with technical writing. With technical writing, the learning journey is just as important as the technical details.

When I first encounter a technical subject such as a programming language for example, I feel like an explorer arriving on a new land. You see, each language is unique. Each language does things in different ways. Oftentimes, some languages repeat patterns of other languages but other times, languages may “echo” instead of repeat.

An “echoing” language “looks” like another language but does things quite differently. In these cases, your personal experience may inhibit your progress.

The Javascript language is a perfect example of this. Developers coming to it from a language like Java or C# get frustrated because Javascript is a prototype-based language yet it looks just like a class-based language. Or take the Dart language, when you designate a method as void, it still returns a value. That’s madness coming from a standard C-based language. The AI won’t understand these issues unless people like me write about them.

As a technical communicator with a firm understanding of my audience, I know where they are coming from. Having stumbled through the jungle myself, I know the pitfalls of my own expectations. Thus, my documentation is written for that journey and those expectations. The machine has no idea and thus, will always lag behind the skilled communicator.

The meaning behind an empty map

Technical writing goes beyond audience expectations. It also teaches the underlying concepts behind an API or framework. The best kind of documentation teaches not just the “nuts and bolts” but also the thinking behind the organization. Once a developer learns that paradigm, it becomes almost trivial for them to learn new features.

While AI can certainly do this, it relies on existing documentation. As a technical communicator, I’m often put into projects with zero documentation.

For example, I wrote a book for the Amazon Sumerian team (a now-defunct browser-based 3D engine). I flew out to Seattle and embedded with the team for a week. The team was introducing a new API for the engine. I needed to teach the API in the book. There were no forum posts. There were no questions on Stack Overflow. There was nothing for an AI to use outside the raw code.

For this project, all I had was the lead engine programmer. I had maybe one hour in the morning to ask questions and maybe – if I could catch him before he left the office for the day – one hour in the afternoon. He was busy, so when I had his attention, I needed to be prepared. This required me to do lots of exploration and testing on my own. From my testing and rapid-fire conversations, I learned the intentions of the API and where the API aspired to go. These insights “weighted” coverage of various topics in the book so the learner could grow and evolve with the API itself.

AI just can’t do that. Besides, I was creating a learning journey off documentation that existed in the mind of the lead programmer. There was nothing to train the AI on. It needed someone like me to present my findings so it could learn and thus, “teach” others.

The nebulous future

It’s hard to say where AI will go in the future. There’s a great video questioning whether it has already “peaked” in terms of utility. This video argues we may have already reached a point of diminishing returns based on the sheer amount of data and expense needed to train these models.

That’s not to say AI isn’t useful. It can do a decent job of revealing connections between data. It can assist in the production process as well as speed up existing tasks. I don’t see AI as the “great replacer”. I set it as an enabler.

So yes, as a technical communicator, I feel my future is secure. People will always need light to illuminate the unknown places in our technological landscape. But even if the tech bros are correct and AI will take over, they’ll still need people like me to explain how to use their machine.