When the old webmasters and information architects became user experience designers — and some split off into content design and content strategy — it was fine. The lineage held. The people doing the work still had some connection to where it began and why the specialization happened. And because you'd worked across those areas before, you could flex back into one when a job needed it.
With how we build websites now, most of that isn't possible. Design has less voice inside product and delivery orgs than ever; it gets treated like a feature shop. Content roles have had to fight for headcount the whole way. And now, with LLM chatbots proliferating, it's both a great and a terrible time to specialize in content.
I went looking into a theory: that the shortage of content roles — despite how much more content we now generate synthetically — comes from a failure upstream in the org chart to understand where content work belongs. Said plainly, the work still exists. It just gets conflated with other parts of the engineering stack and disappears into them.
I’ve been circling this for a while, first around context engineering as a systems problem, and later around context as the terrain these systems enter. This is adjacent to those posts, but it is not quite the same argument.
The thing I keep coming back to is that nobody really owns the response experience.
The chatbot’s tone, the interface chrome, whether the words feel vaguely on brand — those are all part of it, sure. I mean the end-to-end experience of asking a system for something and getting back a response shaped by sources, instructions, memory, retrieval, tooling, escalation, and whatever the system thinks it is allowed to do next.
The response is where the product becomes legible. When it works, the system seems useful. When it fails, the user has to absorb the missing context, the bad assumption, the weak retrieval, the confident nonsense, or the apology that still costs another attempt to fix.
This is where “skill issue” is both true and not really fair.
It reminds me of a coin-op claw machine. Sure, some people can learn the machine. They can read the claw, time the drop, know which prizes are actually gettable. If most people are feeding money into a machine that mostly produces bad grabs, weird randomness, and almost-wins, “get better at it” is not a serious product answer.
LLMs make this more annoying because the retry is part of the business model. If a service fails, you can often get a refund or ask someone to fix it, or return it and get something else. For all those tokens you're maxing, you just to feel dissatified and like any gambler, believe that next time will be better.
I'm thinking of a response engineer who lives in product. Someone concerned with the end-to-end response experience, not just the words on the screen. Someone who can think in information architecture, editorial judgment, schemas, topics, documentation, prompt systems, evals, and agent behavior without getting so far into the weeds that they can’t say plainly what is happening and what needs to be done to improve the downstream experience for users.
Why product? The crude version is “give product its own engineer,” but that isn’t quite it. Product already sits at the collision point between user needs, business goals, technical constraints, and delivery pressure. A response engineer belongs there because the response experience is not owned by any single layer of the stack. It is shaped by retrieval, instructions, schemas, memory, tooling, policy, documentation, interface choices, and all the product decisions that determine what the system is allowed to do.
A hybrid role helps because the response problem rarely presents itself as one kind of problem. It might look like retrieval to engineering, a broken interaction to design, a problem of meaning or emphasis to content, a recurring failure pattern to support, and a trust or retention issue to product. A response engineer needs enough fluency across those perspectives to see how they connect, and enough proximity to the system to turn that understanding into changes that improve what users actually experience. These people exist without a natural home, but these skills are especially crucial in this AI agent-shaped present.
Designers are more technical than they're often given credit for and this work is scattered across engineering, product, design, support, docs, and whatever people think prompt engineering is this week. You don’t need to be a full-stack developer to improve the outcomes of agent tools; you need editorial fluency, systems fluency, and enough technical judgment to know where the work needs to happen and how (and when) to ask the right questions. For the cost of a single FTE you were going to hire anyway, orgs could start to itemize the mess and make sense of it.