Tag: Tech writing profession

After a particularly tiring vibe coding session with Claude, I shared some of the resulting grumpiness in a few posts to the Write the Docs slack. I’ll confess. I’m probably not AI’s (as the term is currently bandied about) biggest fan. But I’m not a hater. I’m just, well, disappointed with it. It’s just not living up to its purported potential (a.k.a. hype, these days).

I’d been writing code (i.e. prompting Claude to write code for me, a.k.a. vibe coding) and Claude’s code was getting buggier and buggier. I’ve seen that happen before after it’s written a lot of code. It acts like it’s tired, but I think it’s due to having too many things to keep track of in the conversation, so it loses its place (I’m not an AI psychologist…yet).

In any case, I was beginning to wonder if it would have been faster to just start typing my own code (it wouldn’t), but I wanted to see how it played out. Eventually, after Claude had gotten stuck, again, I was troubleshooting in parallel and suggested a fix. Lo and behold, Claude agreed (as always). With that experience still fresh in my head, I went to the Write the Docs slack to see how others were faring in their AI journeys.

Thinking of past bubbles

In one post, I compared current AI hype to the hype I recall when PCs (as in IBM PC) came out in the early 80s. They promised the moon and in microscopically fine print, mentioned that “some assembly was required.” Sometimes some C, as well. (If you know, you know.)

In the 80s, it’s not that PCs weren’t amazing pieces of technology that could fit on your desk and still have room for your phone and desk blotter. Remember, this was a time when computer hardware had to have its own air-conditioned office. It’s that they lacked the “killer app” (the application that solves a high-value problem for a large audience), until Lotus 1-2-3 & Multiplan, two of the first spreadsheet apps), came out and ran on the PC.

Those killer apps transformed the PC from a geeky novelty to an absolute necessity. They enabled regular people to see the value that these machines could provide. Fast-forward to today, that’s how AI seems to be positioned: A novel (to most non-AI researchers and developers) technology waiting for its “killer app.” Just like the PC could do anything, but nobody cared until it did something useful. It’s hard to tell what AI’s killer app will be until we see it. If I knew what it was, I wouldn’t be here writing another blog post; I’d be working on AI’s killer app!

Continue reading “I’m not an AI hater. Really!”

After six months of diving into AI tools, I’m still figuring out how to work with them without compromising my professional integrity. The old boundaries between my words and borrowed words don’t map cleanly onto AI assistance. When AI helps craft my prose, am I still the author? When my students use GPTs (a generative, pre-trained transformer, built on a large-language model, or LLM and more commonly known as an AI chat tool) to generate sophisticated responses, how do I know if they actually understand the material? The underlying tension in both contexts is the same: Where does human skill end and tool dependency begin?

I’ve been wrestling with this question through direct experience, using AI tools in my own writing and as I prepare to teach students about AI applications in technical writing scenarios. The uncertainty isn’t comfortable, but it’s productive. It’s forcing a clarity about professional standards that I previously took for granted.

The attribution gap

Traditional models for crediting intellectual work assume clear human sources. Plagiarism involves stealing and passing off ideas or words as one’s own without crediting the source. That creates a property line between what’s “my work” and what isn’t. The property line is fuzzy, but it’s recognized.

Work-for-hire contracts handle using another’s writing by transferring ownership. I might write the words, but my employer becomes “the writer” through legal assignment. Editorial assistance operates on a continuum: the greater the influence of dictionaries, grammar checkers, or human editors on the final product, the more they should be credited.

Search engines provide access to enormous amounts of knowledge while making attribution relatively straightforward. This makes it easy to build on others’ genius, and cite the sources to avoid plagiarism, while maintaining a clear distinction between your words and those of others.

But what’s a GPT in this context?

• Is it a sophisticated grammar checker? Definitely.
• Is it a mechanical editor? It can be.
• Is it your personal writer-for-hire? It could be.
• Is it a source of original content? Unclear.
• Is it an industrial-strength plagiarism machine? That’s still a topic of heated discussion.

AI doesn’t fit into existing categories while somehow fitting into all of them. The academic press is still debating this. Stances range from “do what makes sense” to “no way, no how” depending on the field and editorial board. Most of my academic papers were guided by ACM and IEEE standards, so the ACM’s more flexible approach feels familiar and reasonable while maintaining academic transparency.

The competence question

As a writer, the integrity question centers on authorship: “Am I still the writer if AI helps structure my arguments?” As an instructor, it’s about learning: “Do my students understand the material if they’re using AI to generate responses?”

Continue reading “Finding the line between AI assistance and AI dependence”

It’s been a while since I’ve contributed to my blog. The truth be told, I’ve been busy.

The day after my birthday, 2023, was when I found out that, along with 12,000 of my now former coworkers, I no longer had a job with Google.

I remember the feeling when I got the news (by email, of course). I felt like when I was learning to fly, and the instructor cut off the engine mid-flight. One minute you’re looking out the window, checking off the waypoints to your destination. The next, you’re looking for where you’re going to land. Because you weren’t going to be flying for much longer.

For the non-pilots reading this, most light airplanes keep flying after an engine failure. They just don’t stay at the same altitude for very long.

Learning to fly taught me that in those situations, the longer you ignore the reality of the situation, the shorter your list of options becomes. So, if they’re laying off thousands of people in my industry and, as we’d see in the months that followed, this would be just the beginning, I concluded that this was the end of my professional career as I had come to know it.

I was now gliding.

However, that’s a story for another post (or two).

A soft landing

The good news is (as it is for the pilots who are prepared for the possibility of an engine failure), my wife and I have landed safely and we’re doing fine.

My post-career landing was softened by an opportunity to teach an API documentation course at the University of Washington’s Professional and Continuing Education school. I just wrapped up the third term, last week, and it’s been a lot of fun.

However, the past two years have brought seismic shifts to technical writing, particularly in API documentation. Large language model tools have reshaped how we approach documentation creation, analysis, and maintenance. As practitioners, we’re all grappling with the same fundamental questions:

• How do we adapt our established practices?
• What assumptions about our craft need revisiting?

Enter AI and the curriculum challenge

Large language model (LLM) tools have taken the world by storm in the past two years. API documentation hasn’t been immune to their influence. As such, I’ve been working on an update to my API documentation course to integrate AI technologies to keep the curriculum current.

The challenge isn’t just adding AI tools to the syllabus. It’s understanding how these tools change the fundamental nature of documentation work. What skills remain essential? What new competencies do we need to develop? How do we teach both the power and limitations of AI-assisted documentation?

As I update the API documentation course, I’ve been putting different AI tools to the test, with some rather interesting results.

Continue reading “Looking back to look ahead”