Sarah Deaton

Last week, I wrote the words “reader as actor” about 200 times in PR reviews.

For my recent Write the Docs talk, I needed a docs site that felt real enough to demo against.

I recently gave a talk at Write the Docs about three git commands I’d been avoiding for most of my career, or in two cases didn’t know existed at all.

Most of how I’ve customized Claude Code so far has been on the side that changes what it knows or does: CLAUDE.md for project conventions, path-scoped rules for specific instructions, skills for specialized behaviors, hooks for guardrails.

In my first week writing documentation for Claude Code, I realized I’d been using a Swiss Army knife with only the main blade, unaware of what else it could do.

TL;DR: Traditional tool calling eats away at an agent’s context window.

I saw a screenshot of this email about AI-assisted coding and agency, and it sparked a lot of thoughts for me.

A few days ago, I posted about using the Claude Agent SDK to play the Wikipedia game as a way to think about docs navigation using an LLM.

I’ve been wondering for a while how to test or verify information architecture when I can’t actually sit down with users and watch them navigate the docs.

Seven months ago, I was skeptical of AI.

My roles prior to developer education were in site reliability and infrastructure.

The most recent team I joined had a set of docs but had never had a dedicated technical writer.

In Part 1, I looked into why MCP exists: it’s guardrails for LLMs to use APIs without screwing up.

You’ve probably seen the headlines: “AI shortcuts are already making kids lazy“”“ChatGPT Use Linked to Cognitive Decline”“Using ChatGPT for work?

I wrote this post because I found myself struggling with a very specific question: Why MCP when we already have APIs and so many ways to communicate programmatically?

I love incidents.