Teaching technical writing

February 20, 2026February 21, 2026

Teaching AI in Tech Writing: One Year In

A year of working with AI feels like five years of regular thinking. Is that true for you too, or is that just me?

I’ve spent the past year integrating AI into my API documentation course.

Feb 2024: Start experimenting with use cases
April 2024: Teach the last non-AI version of the course
July 2024: Formal lesson planning updates
Sept 2024: First AI-enhanced term
Dec 2024: Reflect and revise
Feb 2025: Prep for next iteration

So, the AI component of API documentation has been swirling around in my head for at least a year now. Here’s what that year of experimentation revealed.

Three categories of AI in technical writing

Last summer, I drafted three categories for thinking about AI interaction in technical writing:

AI supporting content creation and management – Tools that help you write, edit, organize, and maintain documentation
AI generating and publishing content – Tools that create documentation with minimal human intervention
AI reading your content – How AI tools consume and use your documentation in other contexts

I’ve tested all three in the course. Here’s what I’m learning about each.

Category 1: AI supporting content

Students in the last term were encouraged to experiment with their AI assistant throughout the course. They discovered where it helped and where it didn’t—sometimes intentionally, sometimes by accident.

For next term, I’m making this discovery more structured. Students will systematically test their AI tool on specific tasks: outlining topics, reviewing their drafts, explaining concepts they’re documenting, generating test cases for code examples.

The challenge: AI still has no user guide. AI tools don’t document their own limitations. Students need to test them systematically on specific tasks to discover where they help and where they fail. That’s what we’ll work on next term.

Category 2: AI generating content

I’m still skeptical about unmonitored AI content generation. I’m watching my opinion on this closely because I suspect I’ll need to reconsider it soon. For now, I don’t think AI is ready for write access to the repo.

January 7, 2026February 21, 2026

Reflections on my first AI-enhanced API documentation course

Now that the last quarter has ended and the holidays are behind us, I finally have a chance to reflect on the API documentation course I taught last fall. Last summer, I integrated AI tools into the course that I’d taught for two years. What I discovered: when students can generate content faster with AI tools, your evaluation process needs to keep pace, or you won’t catch problems until students have already repeated them multiple times. I suspect this applies to any course where instructors encourage AI use without rethinking their feedback loops.

I encouraged students to use AI tools and they did. They were generating content faster than in previous course iterations. What I didn’t anticipate: they hadn’t completely installed the linting tools that were part of the authoring system. Their use of AI tools let them produce assignment after assignment without applying the linting tools that should have caught basic errors. In one module with three assignments, more than two-thirds of students submitted work with style violations, such as lines exceeding 100 characters, missing blank lines around headings. Their local linters should have flagged these immediately, but their linters weren’t installed or weren’t working correctly, and I didn’t discover this until after they’d submitted all three assignments with the same problems repeated.

In previous iterations of the course without AI tools, students generated content slowly enough that I’d evaluate early assignments and catch tool issues before they could compound. Adding AI tools to the mix changed the velocity assumptions. Because of the additional AI-related curriculum, I grouped these three writing assignments into a single module. By the time I evaluated that module and saw one error, it had already been repeated three times—per student.

July 28, 2025February 21, 2026

Teaching technical writing in an AI world

A lot has changed in tech writing during the past two years when it comes to LLM tools (a.k.a. AI). That time frame coincides with my tenure teaching API documentation and watching how my students adapt to these tools has given me some insight into how our profession is evolving.

More to the point, it’s forced me to develop a systematic approach to AI integration for my next course.

The challenge: Teaching moving targets

When I started teaching API documentation in spring 2024, LLM tools felt like the “Apple II” stage of PC evolution. Interesting, but not quite ready for serious work. My students were “cautiously skeptical,” and treated AI as a curiosity rather than a necessity.

Some students used LLM tools to help create rough drafts while others wanted to avoid the AI tools to get a more hands-on experience.

That changed rapidly. By the third course, students weren’t asking whether to use AI, they were asking how to use it effectively. The industry had moved very quickly, and my students needed practical frameworks, not philosophical debates, to confront this new reality.

What I learned from watching students evolve

Rather than ban AI tools, I decided to lean into them and watch what happened. I asked students to describe if, and how, they used AI tools in their assignments. This gave them a record for their portfolio presentations, but it also created an informal longitudinal study of AI application in technical writing education. Here’s a summary of what I observed:

July 22, 2025February 21, 2026

Do-it-yourself (with a friend) portfolio

Everyone tells aspiring tech writers to find an open-source software (OSS) project to create content for a portfolio. Unfortunately, while popular advice, I haven’t heard that to be very successful.

Rather than leave you hunting for those elusive OSS opportunities, I’ll describe how the portfolio project I use in my API documentation course works. This approach might be more accessible and achievable for building the portfolio content that you need.

The course portfolio project works because it addresses two critical elements often missing from solo projects: collaboration and accountability. Both are essential skills for technical writers, and both significantly improve your chances of producing something portfolio-worthy.

How to run your own portfolio project

Here’s how our portfolio projects work, as adapted for self-directed learning:

May 14, 2018February 21, 2026

Tech comm education and the job market

One of the many informative experiences I had at this year’s WriteTheDocs 2018 conference was my chat with employers/recruiters at the Job Fair. My primary goal was to learn what they looked for in their technical communication interns and entry level recruits, so I could bring that back to school. What I learned was not surprising, having only recently left industry for academia, but it was a wake-up call.

Recruiters want people (even their interns) who have experience and they want current and relevant experience.

I agree, that’s a bit of a Dog bites man story. Of course they do. All other things being equal, having current and relevant experience is almost always better than not. I suspect it is because the assumption is that with it, the person will become a productive team member sooner than later. What I think is often overlooked is how other idiosyncratic aspects of the specific job might have a greater influence in the time to productivity, such as the onboarding support (discussed in Sarah Day’s talk at this year’s conference), but that’s not something that I, as an educator, have much control over (unless you’re hiring me to consult on the process, of course).

What an intern needs

One of the things I have to keep in mind when reviewing my notes is that I was at a software documentation conference and the companies I talked to were software companies with open-source software products to document. In that context, it was natural that they were looking for writers with experience in their product domains: open-source tool experience (Git, GitHub, Markdown, etc.) They also looked for a passion for documentation—as evidenced by experience in such tools (e.g. documenting an open-source project in GitHub). I don’t know how many of these observations transfer to looking for writers in other industries.

Continue reading “Tech comm education and the job market”

July 20, 2017February 21, 2026

Still catching up…

Photo of stacks of archived patient files — Archived paper patient files from one of the clinics I visited this summer.

It seems as though I’ve been “catching up” since I started as an assistant professor, and I’m not sure I’ve gotten any better, but I keep trying.

Summer break is just weeks from turning into the Fall semester where I’ll dive into my second year as an Assistant Professor. While I’m looking forward to it, I really need two more months of summer to catch up.

As I get used to academia, I’m finding the term Summer break to be a bit misleading. While it’s a break in the academic year, I’ve been too busy to consider it much of a break. Granted, I’ve been having fun, and it’s nice that work is fun.

Summer started off with a trip to Honduras, where I was able to conduct some site visits and contextual inquiries in how limited-resource health clinics manage their records. After two weeks of visiting five different clinics in Honduras, I came back with enough research to complete a conference paper, start a journal article, apply for a grant, and get an internship for one of our TC students…and that was all before the spring semester had officially ended.

After returning, of course, I had to actually produce the papers for which I’d collected the data and prepare for the conference presentation that I’ll be making next week with two professors from my department at the IEEE ProComm 2017 conference in Madison, WI.

One happy coincidence I had this summer was to meet some super technical writers from the Denver-Boulder (Colorado) area at a Write-the-Docs meetup. As luck would have it, their meeting and my travel managed to coincide last night in Broomfield, CO and I got to meet some of the tech writers that, until last night, only knew through email and the WTD forum.

But, busy is good. I’m looking forward to next week’s conference and, of course, the semester that starts just a few weeks after that.