There was a period not that long ago when a substantial portion of my hours at work was updating screenshots. Once a year or so a major UI update would drop, and it meant every article had to be audited for needed changes, screenshots and videos had to be reproduced and edited, articles had to be updated and published. For even smaller changes (the ones R&D figured were so small they didn’t bother to tell you, amiright?)—a relocated button, a dropdown with a new CTA, a new visual language on a modal—I was the one who had to take a new capture, crop it to the right dimensions, et cetera, et cetera.

Nobody would have framed this as a learning experience. If anything, it felt like a pain in the ass; but at least one that meant job security. Someone had to do this work 🤷.

But there were lessons I was learning. Lessons about how to manage my documentation today to make future updates easier. About finding the most efficient way to use your documentation tech stack. About researching and applying best practices, but not being beholden to convention.

Maybe the most important thing was that I was learning that the person who cares enough to notice the wrong screenshot is doing something that matters. That attention to detail is a kind of superpower that not everyone has. That, while that work won’t appear on any dashboard, it can matter to an end user as much as a great call with a CSM or a positive CSAT chat with Support.

I was learning how to be a technical writer.

Now, these craft-centered tasks are handled by script, by CI/CD workflows, or maybe an AI agent that flags outdated image references in pull requests. Which is, by every efficiency metric, a significant improvement. But who misses out on learning what I learned? Don’t younger writers need to put in the work?

Or, am I just like the older folks I’m wont to complain about—acting as though there was some moral imperative in the suffering they had to endure “back in the day”, and therefore everyone else should suffer needlessly now?

The Floor Goes Up

Much of the conversation in technical writing communities lately—Reddit, Write the Docs, newsletters—understandably tends to treat the loss of junior roles as a workforce problem. AI raises the floor. Tasks that used to require a junior writer to perform have now either disappeared or have been absorbed by someone more senior who can complete them in a fraction of the time. Fewer entry-level positions, a harder path into the field. Can’t gainsay any of that—I see it in all kinds of roles these days.

But I think it’s also a craft problem. The tasks that AI handles best are precisely the tasks that used to teach people things. They’re defined, repeatable, and feedback-rich: take this content, apply this format, produce this output. Do it a hundred times. Build a mental model of why the format exists, what breaks it, what the reader actually needs from it. The boring work—the updating-screenshots work—was, in the way of all boring work, a form of practice that enabled the systems thinking and the context for senior-level work. And now we’ve automated the practice.

The craft of technical writing isn’t learned from a style guide. You become competent by doing the work, getting things wrong at a scale where the consequences are manageable, and developing judgment over time—about what a user actually needs, about when to push back on a SME who’s wrong about their own product, about when complexity and specificity matter and when they don’t. That judgment is the hard part. The writing is the easy part.

The Pipeline Problem

This obviously isn’t unique to technical writing. The same conversation is happening in software engineering, where entry-level job postings have dropped sharply. And the explanation—AI lets senior engineers deliver more—closely mirrors what’s happening in technical writing. If one experienced writer with good AI tools can do what three writers once did, the math for junior hiring gets uncomfortable fast. Organizations that embrace this math (or use it to justify radical layoffs)—rarely ask what it implies for the talent pipeline five or six years from now. What happens when your hiring pool doesn’t know the first thing?

And for technical writing, the problem is compounded by something we’ve always struggled with: it was frequently dismissed as not essential. If we can create a GitHub workflow that pushes commits to an LLM, what do we need a technical writer to write release notes for? If we can have an AI agent review our docs and update content to match what appears in the codebase, why do we need someone to manage the CMS?

What’s left is a field that increasingly demands the judgment of someone with years of experience—the deep product knowledge to catch technical inaccuracy, the industry fluency to ask the right questions, the editorial confidence to say “this isn’t ready to document yet”—while reducing the opportunities to develop that judgment organically.

I don’t have an obvious answer to any of this. I think it might require market-level corrections to the way organizations value labor and understand that employee growth has to start at the beginning.

But we—the folks who have been around the block; the ones who are in positions of tenure or seniority—aren’t without influence. We can push our companies to take risks, hire with the promise of creating great, future employees. We have to look out for each other.

If you're thinking about what the AI era means for technical writers, I wrote about one path forward.

Read: Is Content Engineering the New Technical Writing?