Developer Relations has traditionally been built around one primary audience:
Developers.
We write docs for them.
We build tutorials for them.
We create SDK examples, maintain GitHub repositories, run communities, and answer implementation questions.
But AI coding assistants are changing the developer journey.
The developer may now ask an AI agent to research a library, understand an API, write an integration, or debug an error.
That means your documentation can become an input to an AI agent before it ever reaches a developer.
The new developer journey
Previously:
Developer → Search → Docs → Code
Now:
Developer
↓
AI Assistant
↓
Docs / GitHub / API Reference
↓
AI interprets information
↓
Code
↓
Developer reviews
The developer is still the user.
But the AI can become the first consumer of your developer experience.
That's why documentation quality matters differently now.
Write documentation that removes guessing
Consider this:
Use our SDK for authentication.
It sounds simple, but it leaves a lot unanswered.
A developer or AI agent still needs to figure out:
Which package?
How do I install it?
Where does the API key go?
Can I use it in the browser?
What happens when authentication fails?
What's the response format?
A better example provides actual implementation context:
const client = new Client({
apiKey: process.env.API_KEY
});
const user = await client.users.get("123");
console.log(user);
Then explain what the code does, what the inputs mean, and what can go wrong.
This helps both audiences.
Examples are part of the API
An API reference without good examples can force developers to guess.
AI agents have the same problem.
If the API is:
client.users.create(options)
showing a complete request is more useful:
const user = await client.users.create({
name: "Alex",
email: "alex@example.com"
});
Then document:
Required fields
Optional fields
Response shape
Validation errors
Authentication requirements
The more important the API, the less you want people guessing.
Don't forget errors
Happy-path documentation gets most of the attention.
But debugging is where developers often spend their time.
This:
Request failed.
doesn't give much context.
This is better:
Authentication failed: API_KEY is missing.
Set API_KEY as an environment variable before
creating the client.
Now the developer knows what happened and what to try next.
An AI agent can also map that error to a much clearer action.
Your README matters more than you think
A README should quickly answer:
What is this?
How do I install it?
How do I use it?
What does it support?
What are its limitations?
Where are the detailed docs?
This isn't about adding keywords for AI.
It's about making your project understandable.
That's useful for humans.
It's useful for AI.
And it's useful for maintainers six months later.
The bigger DevRel shift
I don't think DevRel needs to start writing "AI documentation."
Instead, we should improve developer experiences so the information is:
Clear
Structured
Current
Explicit
Easy to retrieve
Easy to implement
AI agents increase the value of these fundamentals.
The interesting change isn't simply that AI can read documentation.
It's that an AI agent can use that documentation while completing a software task.
Read docs
↓
Choose API
↓
Generate code
↓
Run code
↓
Read error
↓
Search docs
↓
Fix code
Documentation becomes part of the development loop.
Final thought
The developer isn't disappearing from DevRel.
The audience is expanding.
Your documentation may now need to work for the developer and the AI assistant helping them.
So instead of asking:
"How do we write docs for AI?"
I'd ask:
"Is our developer experience clear enough for both humans and machines to use correctly?"
That feels like a much better DevRel question for 2026.
Top comments (0)