A lot has changed since I last wrote about AI and technical writing here. We have continued to see the accelerated use of AI in business writing, and technical writing is no exception. Traditional technical communications tasks now might take minutes instead of hours. And many organizations—especially in the technology space—are seeing opportunities to contract their communications staffs. After all, when you can just plug your AI into GitHub, why pay for a technical writer?

Need more convincing? Last year, after more than 70 years in operation, the Society for Technical Communications closed shop. The STC was where I went for training webinars, salary data, job opportunities, and more. It was the largest and longest-running professional organization for technical writers.

Sounds bleak. But with some agility and growth, technical writers can still find opportunities to continue being indispensable to their employers. That growth area? Content engineering.

Let me explain what I mean—and how I ended up here without really planning to.

The Writing Part Is Getting Easier

Here’s the uncomfortable truth: LLMs and AI workflows are increasingly more competent at completing the work associated with traditional technical writing. Review specs, get context from engineering, generate user-facing content—that was the job. And it’s table stakes for AI development tools.

A first draft of a how-to article? AI can produce one in two minutes. A structured changelog from a set of Jira tickets? Automated. A review pass for consistency and clarity? There are tools for that too. The core craft of translating technical complexity into plain prose—the thing many of us trained for—is becoming less and less of a differentiator in the job market.

Yes: good, branded, audience-informed writing still matters. But the time it takes to produce it has collapsed. Your time is spent verifying rather than generating. When time-to-output collapses, organizations ask a reasonable question: do we need as many people doing this? Do we need anybody doing this?

For a lot of technical writers used to the old ways of doing things… the answers are getting uncomfortable.

So What Is Content Engineering?

If traditional technical writing is about creating content, content engineering is about building the system that content lives in.

Here’s a useful framework: as a Content Strategist, the Technical Writer defined the “who, what, and why”—who is this for, what do they need, why are we creating it. The Content Engineer also answers the “how”:

  • How will this content be structured so it’s reusable?
  • How will it be stored and delivered at scale?
  • How can we automate the content creation and distribution pipeline that moves a rough brief to a published article to an AI-powered search result?

Content engineering brings content creation, IT, and product development into one role.

How I Got Here (Without Meaning To)

I didn’t set out to become a Content Engineer. For most of my career I was a Technical Writer in the traditional sense—researching, writing, editing, publishing. But I kept running into problems that writing alone couldn’t solve. And being a team of one meant owning those problems and their solutions.

When my team needed specific designs and behaviors on our knowledge base, I started learning HTML, CSS, and JavaScript to build and maintain the UI ourselves, without paying a third party or requesting internal engineering resources. When the knowledge base needed consistency at scale, I learned Handlebars templating to create reusable .hbs templates across the CMS. When we migrated documentation platforms entirely, I wrote Python scripts to call both platforms’ APIs and migrate the content programmatically. I built out new Liquid syntax templates from scratch for the new system. After we implemented AI-powered search, I wrote a script to sync our community content into the knowledge base so the AI could draw on a richer, more context-aware pool of answers.

None of this was in my job description. I was just finding ways around the roadblocks between me and our organization’s content goals.

Now, as the roles of content creator, platform administrator, and product developer are collapsing into one role, I’m blessed to be in a position where I can point to the work I’ve already done to show that I can continue bringing value—and with the help of new technology, new forms of value—to my organization.

The Pattern

What I described isn’t a unique career path. Technical writers—facing the same pressures and the same problems—have always done some of these things: calling APIs, wiring tools together, writing scripts, managing platform templates, building automation workflows.

The difference between a technical writer who gets squeezed out and one who doesn’t often comes down to their agility and their willingness to make the shift from content creator to content systems owner.

That shift means building on the skills that made you a good technical writer—clear thinking, strong communication, understanding your audience—and adding the technical skills to manage and extend the platforms where those skills have value. Things like knowing how a CMS actually works, not just how to click through it. Being comfortable using AI to write small scripts to automate repetitive tasks. Understanding enough about APIs to pull data in and push content out. Structuring content so AI tools can actually use it. Managing the prompts and workflows that make AI work for you instead of in place of you.

Why This Matters Right Now

AI tools have made content production faster, but they’ve also made it messier: inconsistent outputs, content scattered across platforms, no single owner of how everything connects. Organizations are generating more content—for internal and external consumption—than ever, and fewer people know how to manage it coherently.

Sales and Customer Success needs easy access to all the content that can help their customers and prospects understand your product. Support needs great content to provide context to your AI chatbot. Your Product team needs your articles to appear in your in-app federated search results.

If you’re a technical writer who’s been quietly building these skills—learning to code a little, wrangling your CMS, writing automations—you may already be doing this work. You just might not be calling it that.

To stay relevant and to remain an asset to your organization, you have to start positioning yourself as more than just a technical writer or technical communicator.

Welcome—whether we like it or not—to the AI era, fellow Content Engineers.

Want to talk about content engineering, technical writing, or how AI is changing the game? Get in touch.