Content Engineering Is Here ... To Stay

Reflections on the world’s best content conference - CAKE

---

At CAKE conference 2026, AI agents showed up as a measurable second audience for technical documentation, while human readers grew too. Content engineering means automating the predictable writing, keeping the reporting and editing for humans, and teaching the judgment Aristotle called phronesis.

---

In February, AI agents made up 3% of the traffic to Box’s developer docs.

By July, they made up 58%.

Ian Freeman shared that number at CAKE conf in Kraków this month. Those agents read documentation so they can turn it into working code.

The next day, Anastasiya Biaroza showed her own analytics. Nearly half the readers of her developer docs are now agents.

Freeman also pointed out that human traffic to Box’s docs went up over the same months. The people are still reading, but a second audience has arrived alongside them.

Machines aren’t replacing writers. Content for humans isn’t going away. The audience just got bigger.

I’ve made some version of this prediction at conferences for four years. Writing was turning into something else, and I never quite knew what to call it. By 2024, the name I kept coming back to was content engineering.

Each year, I could point to job titles and hunches, but this year, I see more and more people using the term content engineering to describe what they are doing in the workplace.

Mainly ... managing the back end of AI writing systems and validating outputs. Tech writing is becoming less and less about “generating” text directly to users.

(Is it a coincidence? I’m getting a slew of tech writing job posts in my email this week ... and just saw one from Anthropic for a Content Engineer.)

This is one of my main takeaways from the world’s best content conference ... CAKE.

Hello, content engineering

The prediction started in Kraków, too ... with CAKE’s predecessor, Soap!.

At Soap! in 2022, I argued that new technologies would kill off writers but not creators. The people who last would be the ones who shape information.

It was a bit tongue in cheek, because I call those writers, too.

A year later, back at Soap!, I stopped calling what I teach “writing” and started calling it content and information development.

AI could already generate text, but deciding what a situation needed and how to put the content together was still a human job.

At ConVEx in 2024 (the best content conference in the US), I still hadn’t settled on a name: “I don’t know what to call it ... but it’s not tech writing.”

That was also the year “content engineer” started showing up in job titles more and more.

The work itself is much older than the title, though. Robert Glushko was doing document engineering in the early 1980s. By 2018, Mike Atherton and Carrie Hane’s Designing Connected Content had split the field into content engineering and content operations, and Joe Gollner had moved from calling himself a content strategist to a content engineer.

Rahel Anne Bailie’s uneven history of content strategy traces the whole lineage ... and I’ll come back to it in a future post.

By ConVEx 2025, the conversation had moved to purpose. I came home convinced that AI can imitate a goal but can’t supply one, and supplying it falls to the people who design the content.

That fall at CAKE, the argument turned to structure. The same semantic markup that makes content accessible to a screen reader makes it processable by a machine.

Every one of those posts described a shift I could feel but couldn’t quite measure.

Now I’m starting to see some numbers.

Enjoying CAKE … in the front row!

Drafts are cheap now

The first thing to go is the writing you could have predicted.

Freeman’s team figured this out quickly. Reference docs now come straight from the API specs, and tutorials complete themselves. That frees the writers to build structure, and for making the docs actually move developers toward signing up.

But cheap drafts create a new problem ... there are a lot more of them.

According to Justin Gagne, AI writing skips two roles, the reporter who finds things out and the editor who decides what’s worth saying. If you hand everyone a writer, the drafts multiply, but the reporting and the editing don’t happen on their own.

That’s where the human work has gone, and most practitioners already know it.

Małgorzata Lis surveyed 61 technical writers and IT professionals for her thesis and presentation, and they told her the same thing. AI is useful, but they don’t trust anything it produces until a person has checked it.

So here’s my working definition of content engineering. Content engineers:

• Design the process that makes the drafts

• Find out what the drafts need to say

• Check what comes out

It’s still writing work, but it relies on a paradigm change that sees content and information (or writing) as a system of people, processes, and technology.

This is a paradigm that has been around for decades, but is becoming a cornerstone of the tech writing field.

The machines want what editors always wanted

So, yeah ... agents are going to read your docs. The fundamentals, though, aren’t changing. They just become more important (and less forgiving when things aren’t quite right).

In her presentation, Biaroza’s analytics showed three things agents reward:

• A real claim up front

• Structure that means something

• Nothing padded

Here’s an example.

A page that opens with “Welcome to our file management guide” makes an agent wade through a paragraph before it finds anything usable.

A page that opens with “Upload a file with a POST request to /files” gives it something to act on in the first line.

Headings that name tasks (”Upload a file”) help. Headings that name themes (”Getting started”) don’t.

And the intro paragraph that exists only so the page doesn’t look thin is just noise to a machine.

Any editor would have marked up those same pages twenty years ago.

A human reader forgives a padded intro and scrolls past it, but an agent has to process every word of it, and each word takes up space in the context window and costs inference.

So the skill that matters is knowing, page by page, which standard applies where. Presenters at CAKE mostly called this judgment.

But there’s an older word from rhetoric that I keep coming back to.

Aristotle called it phronesis, the practical wisdom to make a sound call in a particular situation where no rule strictly applies. Today we’d call those situations probabilistic.

I saw it all over CAKE.

Freeman’s team had to decide which docs were safe to generate and which needed a person. Lis’s respondents check AI output because they can’t yet say in advance when it will be wrong.

Agentic workflows run on that kind of judgment, and so far only people supply it.

Can you teach judgment?

So ... if AI takes over the predictable writing, where does the next generation learn to make these judgment calls?

This is becoming the core problem in technical writing ... and it’s only going to get more important.

Junior writers used to build judgment on exactly the work that’s being automated. They wrote the reference page, got it marked up, and wrote the next one better. Take away the reference page and you take away the practice.

I’d rather not protect the busywork. I’d rather have people practice the judgment directly.

Conference participants building their own local markdown knowledge base.

That’s what I tried in the workshop I ran at CAKE. Before anyone built a single note, I asked the room whether they had a taxonomy for their knowledge written down anywhere.

One hand went up.

So that’s where we started.

Everyone pointed their AI assistant at a folder of their own documents and asked what domains it saw.

The real work was figuring out which of those domains were actually useful for the person’s knowledge project.

The taxonomies that came back didn’t look like mine. This is a probabilistic task ... a rhetorical one. The answer will always be contextual.

One person organized by product feature, and others by user characteristics. None of them was wrong. Each one answered three questions only that person could answer:

• Who reads this folder?

• How do they find things in it?

• How fast does it change?

An AI can propose folders all day. Deciding which ones match how you actually think about your material is phronesis at a small scale, and you get better at it by doing it.

The agents will keep reading, and so will the people. Both need someone who has practiced making the important calls.

Soon, I’ll walk through the full workshop step by step for paid subscribers, from the first folder to the taxonomy to your first AI-ready note, so you can build one yourself.