I think that question is coming for a lot of docs teams. The same version of it is coming for QA: if engineers can work with agents to test their own changes, what does a dedicated QA team own?
A quick aside: this is a little off-topic, but if your team uses Cursor Enterprise, I thought you’d want to know.
Eligible Cursor Enterprise customers can get Kilo Enterprise free for the rest of their paid Cursor contract, up to 12 months. Bring your whole team and choose from 500+ models.
Apply for the Cursor Exodus offer by November 30, 2026.
As we delegate more of the tactical work to agents, our responsibility moves up a level: defining what good looks like and building the systems that can produce it.
Two weeks ago in Budapest, I gave a talk about how software engineering is changing. One of my arguments was that engineers should own more of what it takes to ship something useful: the code, the first version of the design, the tests, the documentation, and the customer issues that follow.
Watch my Budapest talk on YouTube.
If an engineer is becoming a manager of agents, they need to be a cross-functional manager of agents. That creates an opportunity to keep context together and reduce the handoffs required to deliver value to a customer.
That has implications well beyond engineering. Technical writers and QA specialists also get to operate at a higher level of abstraction. They can design the systems in which the work happens, oversee the tactical specifics, and improve how the next piece of work gets done.
Everyone is a manager now. That includes people whose careers have been built around being excellent individual contributors. Documentation makes the shift especially clear.
Technical writers need to own how the docs fit together
A technical writer can spend a lot of time collecting facts from engineers. What changed? How does it work? What permissions does it need? What happens when it fails?
The engineer already has much of that context. With agents, they have more help turning it into usable documentation. I think the day-to-day documentation of a feature should increasingly be part of the engineer’s work to ship it.
That leaves a substantial responsibility for the docs team: making sure all of those individual contributions add up to something a user can actually understand.
Twenty accurate feature pages can still make for a confusing documentation experience. Each page can describe its own feature perfectly well while leaving the user unable to figure out where to start, which approach to choose, or how the pieces fit together.
That is where technical writers get to spend more of their attention now.
They get to actually drive the information architecture. What belongs in a tutorial? What belongs in reference material? How do we organize around the things customers are trying to accomplish? Which concepts need to be explained once and reused throughout the docs.
They need to own the bigger resources that span individual features: the getting-started experience, the explanation of how the product works, the guide that helps a customer choose between several approaches.
This is not a problem- it’s an opportunity! Imagine what the team could do with a plethora of individual contributors who could tackle the day-to-day tasks so that the team could work on the next-level, more strategic projects.
Build the primitives that people and agents can use
In this new world, technical writing teams shift their focus to building the primitives that let people and agents produce good documentation within that structure.
“Engineers should write their own docs” is an incomplete operating model. Where should they put them? What should they include? What terminology should they use? How do they know whether they’ve done a good job?
A docs team can answer those questions in ways that are reusable by both people and agents:
Templates for common types of pages
Clear conventions for prerequisites, examples, and troubleshooting
Contribution instructions an agent can follow
Checks that catch broken links or invalid examples before they reach a customer
Together, these are the beginnings of a documentation factory: the context, instructions, tools, and checks that turn a product change into documentation a customer can use. Technical writers need to design how that factory works.
Imagine an engineer shipping a new integration. They should be able to document the setup steps, required permissions, configuration options, and known limitations as part of the change.
The technical writer’s job becomes making that contribution fit into a coherent whole. Perhaps the existing integration template is missing something every new integration needs. Perhaps the product has accumulated three authentication methods and customers need help choosing between them. Perhaps the setup instructions are accurate, but assume knowledge a new customer won’t have.
Each of those problems calls for the judgment of someone who understands how people learn and use the product. Fixing them can improve the experience across many features.
This is the shift I want docs teams to make: focus on the architecture and the big-picture resources. Build the primitives other people can work on. Put responsibility for the day-to-day facts with the people changing those facts.
Put expertise where it changes the outcome
That also changes what deserves review. A new concept that affects the whole product may need a technical writer involved from the beginning. A routine addition to an established reference page should have a straightforward path to publication. The docs team needs to decide where its attention will make the most difference.
Otherwise, having engineers generate drafts just creates a larger editing queue. Every change still waits for the same small team, only now that team has more text to review.
There also needs to be a way to see whether the system is working:
Where are customers getting lost?
Which questions keep showing up in support despite having a documentation page?
Can someone complete the getting-started flow without already knowing the product?
Page count tells us very little about those things.
The docs team needs a feedback loop:
observe where customers struggle
identify what the production process missed
improve the instructions, structure, or checks so the next contribution is better
They need to build the system.
QA needs to shape how the whole product gets tested
QA faces a similar change.
If engineers are responsible for testing their features, QA needs to help build the conditions under which they can do that well
Reliable test environments
Useful test data
Reusable ways to exercise common workflows
Clear expectations about what needs to be verified before something ships
QA also brings a perspective that can be hard to get from inside a single change. What happens when two individually correct features interact? What happens to an existing customer’s data during an upgrade? Which failure would be most expensive for a customer, and are we testing it?
Writing more tests with agents doesn’t automatically answer those questions. QA needs to define what success looks like, decide which failures are unacceptable, and build checks that reveal whether the work meets that standard.
As with docs, the goal is for that expertise to improve work across the product. A QA team can still do exploratory testing and become deeply involved in consequential changes. Its role needs to extend beyond being the queue every engineer hands work to before release.
Give docs and QA the authority to change the workflow
For leaders, this requires changing what we ask these teams to deliver. We can’t tell technical writers to build a better documentation system while evaluating them solely on how many feature pages they personally write. We can’t ask QA to improve how everyone tests while keeping them responsible for manually signing off on every change.
They need authority and time to change the workflow itself. Their contribution should include how effectively the system produces useful, reliable work and how much it improves as they learn.
Everyone is a manager now
I’ve said it before, and I’ll say it again. This is the broader change that docs and QA make visible. When agents can do more of the technical work we used to delegate to individual contributors, more of our work becomes designing the system where that work gets done.
That requires the judgment we associate with good management: give the work a clear purpose, provide the right context, define success, set boundaries, and evaluate the result. Then use what you learn to improve the system.
The guardrails need to leave room for innovation, too. A documentation system can require accurate examples and consistent terminology while leaving room to try a better way of explaining a difficult concept. A QA system can define the risks a release must address while encouraging new ways to discover failures. People need to know which constraints are essential and where they have room to experiment.
Operating at a higher level of abstraction still means paying attention to the specifics. Technical writers need to read what gets published and understand whether customers can use it. QA needs to investigate failures and challenge whether passing checks reflect a working product. Those specifics tell us where the factory needs to change.
For technical writers, the opportunity is to own how useful documentation gets produced across the product. For QA, it is to own the systems that help everyone deliver and demonstrate quality.
Everyone is a manager now. Building the systems, defining success, and exercising judgment about the work are becoming part of the job.