DevRel's New Job: Match AI Patterns to Outcomes

The tutorial I would have written for this is "How to create a WordPress draft with the REST API." I never wrote it. Claude Code already knew the endpoints.

What I wrote instead was a pipeline. At Postman, a blog post used to move through people: someone drafted, someone copyedited, someone found a header image, someone staged it, someone checked the calendar. Now an agent team takes a draft, copyedits it, generates the header image, stages it, schedules it against the publication calendar, and measures how it does afterward. Anyone in the company can submit through Slack. I covered the mechanics in the post on building the pipeline, so I won't repeat them here.

The pipeline as it runs today. The header image step is the one that loops: the orchestrator regenerates until the rubric passes.

What I want you to notice is what that pipeline needed. At no step did it need a tutorial on the product. It needed someone to know which AI patterns to apply: atomic skills, an orchestrator that checks the work before moving on, a rubric the image has to pass. That knowledge is the job now. I think it's the whole job.

Why feature tutorials stopped being the job

A feature tutorial teaches a human to use a surface area. Agents don't need that. Point one at a CLI and it reads --help. Hand it an OpenAPI spec or an MCP server and it has the full tool list in seconds, more completely than any developer who skimmed your docs on a Tuesday.

So the bottleneck moved. Developers used to ask how a feature works. Now they ask how to get an outcome, and the answer isn't a feature. It's a combination of your product and a way of working with an agent that didn't exist two years ago.

That shift doesn't make your product less important. It changes what a developer advocate is for. If your team still measures itself by how many how-to posts shipped last quarter, you're producing the one thing the reader's agent already has.

The new way to get work done

One developer with an agent, a set of skills and some automation can now do what used to take a team or a week. I don't mean that as hype. I watched it happen to my own publishing workflow, and I'm one person with a day job.

DevRel's job is to show developers that route to an outcome at a scale they couldn't reach by hand. That means knowing the patterns well enough to say which one fits which problem, and knowing your product well enough to say where it plugs in.

Write the outcome, not the feature

The unit of content changes. Here is the old one, a step from a feature tutorial:

## Step 3: Create a draft
Send a POST request to /wp/v2/posts with a title, content, and a status
of "draft". Include your application password in the Authorization header.

An agent can do this without you. Here is the replacement, a skill written around the job-to-be-done:

---
name: publish-post
description: Take a finished draft to a scheduled, staged post. Use when someone submits a draft or asks to publish, stage, or schedule a post.
---
 
# Outcome
A post that is copyedited, has a header image that passes the rubric,
is staged as a draft, and is scheduled in the next open calendar slot.
 
# Order
1. Copyedit against the style guide and report the score.
2. Generate the header image. Score it against the rubric and
   regenerate until every item passes.
3. Stage the draft with all SEO fields filled.
4. Schedule it. Monday to Thursday only, no holidays, never two posts
   on the same day.
 
# Gotchas
- Never name customers from the product updates channel.
- If staging returns a draft ID but no image, the upload failed.
  Retry before scheduling.
 
# Done when
The Slack thread contains the draft link, the scheduled date, and the
copyedit score.

Look at what it leaves out. It never says how to call WordPress. It says what done looks like, what order matters, and what has bitten me before. The agent supplies the rest.

That "Gotchas" section is where an advocate earns the job. Those lines come from having run the workflow and watched it fail.

Pair the skill with a goal, a loop, or beads

A skill tells an agent how to reach an outcome. Automation runs it without you standing there. Claude Code and Codex both have a /goal command that keeps the agent working until a condition you wrote is met. I wrote about why that changes how you build, but the short version is that the done-condition has to be something a verifier can check:

/goal The draft at blog-output/mcp-support.md is staged and scheduled,
the header image scores 12 of 12 on the rubric, and the Slack thread
shows the draft link and date

For work that recurs, /loop runs a prompt on an interval:

/loop 1d /measure-posts report page views and referral sources for
posts published this week

For work too big for one session, Beads gives the agent a task list that survives between sessions, with dependencies. Say you ship an SDK major version and you want every sample app migrated:

bd create "Upgrade sample-app-1 to SDK v3" -p 1
bd create "Upgrade sample-app-2 to SDK v3" -p 1
bd create "Publish migration guide once all samples pass" -p 2
bd dep add <guide-id> <sample-1-id>
bd dep add <guide-id> <sample-2-id>
bd ready

bd ready returns the unblocked work, highest priority first, so a fresh session picks up where the last one stopped. Forty sample apps instead of two is the same list. That's the part that wasn't practical before. A single advocate can give every customer a migration path that runs while they sleep.

Three outcomes I've built this way

AXRank measures how well an agent can use your product's surface area. The pattern is the agent as the user: give a frontier agent a real job against your CLI, API or MCP server, and record where it gets stuck. A tutorial can't tell you that. Watching the agent fail can.

LiftOff teaches APIs by doing. I write a lesson in markdown, and an agent generates validators against the Postman API from that lesson, so a learner's work gets checked in real time. The lesson author never writes validation code. The pattern is generating the test from the teaching material.

My Camino Guide generates the itinerary and the interface from an interactive conversation with the pilgrim. The UI is dynamic, so it takes the shape of what that person asked for. I didn't build screens for every possible Camino. I built the conversation and let the interface follow.

None of these is a tutorial. Each one is an outcome with an AI pattern that gets you there.

Where DevRel judgment still matters

The agent knows your surface area. It doesn't know which outcome is worth chasing, or that the odd way someone combined two of your features is the best use of your product. Finding those is the part of the job I'd protect. When I see a developer use something in a way we never planned, I read it as a sign the product's primitives are sound enough to compose. It's also the best product feedback I know of.

What I'm still unsure about

Skills rot. When your product changes, a skill that encodes the old gotchas quietly sends agents down the wrong path, and that might be worse than stale docs because nobody reads it. I don't have a good answer yet, other than running the skill against the product on a schedule and treating a failure as a bug.

I also don't think tutorials die entirely. Humans still learn concepts from good writing, and I'd still write one for an idea that isn't in any spec. I just wouldn't write one for a feature.

The metric I'd use instead of page views is time to outcome. How long does it take a developer, and their agent, to get from the problem to the result, and how much effort did it cost?

If you want more of this, subscribe at quintonwall.com and follow me on YouTube at @seeqcode.