Edward Angert | Blog

Chasing the Meta: Fundamentals, Hype, and Progress

Tue, 02 Jun 2026 00:00:00 GMT

In the early 1900s, New York City built elevated train lines over its major avenues. Like in Chicago and Boston, they were called the “Els.”

They were the future of urban transit, steel and steam carrying passengers above the crowded streets.

By the 1930s, the city was tearing them down as blights, building subways to replace them. While they were perfecting one system, they were already making it obsolete with the next.

Companies were competing to become the standard and building conflicting infrastructure while trying to outpace regulation.

Every ~~time~~ week there’s something new in the AI hype cycle I’m reminded of the Els.

One day, maybe soon, AI will be a part of everyone’s workflow in ways we don’t even question, and many of these think pieces will age about as well as my college-era LiveJournal posts.

This isn’t a post about AI. Not really.

It’s about what we care about and work towards, and how we can explore and incorporate the latest and greatest while still maintaining focus on our core values and mission.

This is a familiar pattern.

Hype-loop Pattern

Some developer friends use an IDE they have a love-hate relationship with. The developers behind it start building features that seem genuinely useful, then abandon them for the next shiny feature before they’re finished.

I’ve been using open-source software for decades and I’ve worked at startups. When they explained this, I understood immediately.

That’s the feeling I’m starting to get about certain AI features and maybe MCP. It’s not that it’s being abandoned, not even that it doesn’t do what it promises. It’s that it’s being built mid-flight toward an airport that’s already being replaced.

We’ve seen this before. In open source, projects announce features in the README that won’t ship for years. Then the project gets abandoned, or absorbed, or the feature ships differently than promised.

Technical writers know this so deeply, it’s nearly canon: never document something as coming soon.

Or as the (Google developer documentation style guide) says:

Avoid documenting future features or products, even in innocuous ways.

Sometimes we spend two weeks documenting a feature that gets abandoned before release. We stay resourceful, take notes, learn from the chase, and know when to pivot. And we keep receipts.

AI is speedrunning technology concepts from the last three decades and companies are changing their names around it. Everyone works for “an AI company” now.

The Land Before Protocol

At Coder, I asked Claude Code to help document the way the Coder codebase handles networking, something that relies on a number of different parts of the codebase.

Claude kept insisting it didn’t need the help:

“Just link me to the docs.”
“I can analyze the codebase directly.”
“Point me to the repository.”

I answered: “You’re in the repo right now.”

And like my five-year-old, it responded “oh yeah, I forgot” with the same confidence that it was right to begin with.

I created a new Git repository, started Claude Code, gave it access to the Coder repo, and took it feature-by-feature:

Let’s take this directory-by-directory and feature-by-feature. Learn about the way networking is handled as a concept, by which files, and what aspects of it users can modify. Create a file called networking.md with detailed notes for yourself. Whenever you learn something new about networking, update the file.

This became shared-docs-kb, a knowledge sidecar of notes, context, and architectural patterns.

The idea was to give Claude Code structured context about the codebase so it could help with documentation work instead of making things up as it went along. I was trying to minimize the amount of information it needed to keep in context and teach it new skills that would make it a contributor’s buddy.

With MCP and skills, what I started as a manual sidecar had become a protocol, and skills helped keep Claude focused.

I was trying to solve a problem with the tools I had: AI needs structured context to be useful for documentation work.

Meanwhile, Claude’s context window keeps expanding and its native tools keep improving.

The ground keeps shifting while I’m building the bridge.

So I tried an MCP

My goal is to make it easier for developers on open source and small tools to draft useful documentation.

I built an MCP server for reformatters, a Python framework for converting weather datasets. It’s not meant to replace technical writers or documentation functions, but it should get people started.

In my last post, I was optimistic about it.

Here’s what actually happened:

Railway deployment wouldn’t bind to the right IP. Crash loops. But that was almost beside the point.
Claude Desktop only supports local stdio connections. I built an HTTP/SSE server for a client that can’t use HTTP. The Railway deployment was solving the wrong problem from the start.
The dataset tools had circular dependencies. They required the main reformatters package to be installed, which defeated the purpose of a separate knowledge repo.
Search tools returned nothing even when the content was right there. Tool registration worked. Retrieval didn’t.

The MCP server runs. The tools are registered. Claude thinks the knowledge base has good content. But the architecture was mismatched from the start: I built a remote-first HTTP server for clients that only work locally over stdio.

I had Claude Code verify the branch and document its findings. Its conclusion: MCP remote access isn’t mature enough for team-wide use. MCP requires infrastructure I don’t have the capacity (or desire) to maintain.

Claude Code eventually reached the Write the Docs-ready conclusion I’ve been arguing for, “we don’t need another repository, we just need better documentation.”

I used to write documentation. I still do, but I used to too.

BJJ Core Mechanics

The style of Brazilian jiu-jitsu has changed since it started getting popular in the US in the early 2000s.

Back then, though the tagline was about smaller practitioners beating stronger opponents, in practice, there was still a focus on heavy pressure. The “gentle art” was a little brutish.

Through the years, the way people “played” evolved, with new techniques catching people off guard and being used to win competitions, then catching on in gyms throughout the world.

That strategy, called “the meta,” becomes the new cool thing for a while, then people get good at countering or defending it, and it usually subsides or gives way to the next thing.

You’re not meant to abandon your entire game to chase only after the cool new thing.

Often, though the specific technique fizzles, some component remains and helps shape the new meta.

Berimbolos, x-guard, heel hook entries. They were all surprising at first, and now they’re just part of the system.

As a featherweight who’s highly proficient at pulling bottom side-control, the buggy choke was a gift. The problem is, pressure can still beat a buggy choke, and the real gift is reapplying the head-and-arm concept in other unexpected ways.

It’s fun to chase the meta, as long as you keep your “why” close at heart (and protect your neck).

Knee cuts, pressure passes, just standing up. They never left, and they still work.

It’s not that the techniques are necessarily fundamental, but that some concepts are.

Fundamental Concepts

MCP and skills might actually stick around, but I think they’re techniques that will get supplanted by more adaptive contexts and maybe a way to micro-train our tools. Things that would work out of the box.

The spiritual core of technical writing hasn’t changed much: know your audience.

Human readers are always the audience. That’s the same whether they’re accessing the content directly or through an AI tool.

That which was best practice before is still best practice now. Write things down, put them somewhere people can find them.

Make documentation a practice, and wherever you are in your practice, remember to keep practicing. Write things down even if they’re not perfect. Show them off even before you think they’re ready. Make it accessible.

I try to write accessible documentation, but who is accessibility for?

There are business cases for digital accessibility. When you write documentation with accessibility in mind, screen readers can navigate it, search engines can index it, and AI tools can parse and summarize it. The same practices that serve a person using a screen reader serve an LLM trying to extract meaning or translate content.

When you make things more accessible, like a curb cut, it helps people even outside the original intention. That’s not a coincidence, it’s fundamentals.

So go ahead, experiment with AI, build that MCP, try a buggy choke, and chase the meta. Just remember why.

AI is coming for my job. Maybe to my job.

Fri, 12 Dec 2025 00:00:00 GMT

While I was working on a pull request for a new Coder feature, there were a few times that Claude Code offered my own documentation or comment on a PR to answer questions I had.

It was a guess I made in a PR about the way a feature might work, and when I asked Claude Code to verify, it referred to the documentation. My documentation.

My job has always been to empower users to get stuff done smoothly and on their own.

Now my audience includes AI.

If humans and AI both rely on good documentation, how do I develop documentation and an information architecture that help both?

How I Use AI

I use Claude and Claude Code both at home and at work. On my phone, my chats with AI probably look a lot like most peoples’:

Is this poison ivy?
Which of these water bottles fit in my car’s cup holder?
What’s this broken part of our toilet called?
Is this rash poison ivy?

Claude Code might look a little different:

Help me turn my settings into dotfiles.
I have a Docusaurus site hosted through GitHub Pages. Let’s develop a plan to migrate it to Astro with Starlight.
When I ask you to help me work on documentation, remember the following…
Help me make a Claude Code plugin that helps you follow my standards for documentation.

For me, the great promise of AI is that it can make sense of piles of information that would take me hours to untangle and map out.

The current hype seems centered around how AI can take over tasks like research, software development, and documentation.

If AI has all the information, can it write the documentation for me?

AI Can Document Things; Humans Are Better at Writing Documentation

For a good example of this, explore DeepWiki, which “provides up-to-date documentation you can talk to, for every repo in the world.” It gives a comprehensive breakdown of a repository, but you won’t get concept, guides, steps, and examples. Right now, AI is excellent at documenting what exists in the way that it exists, but not as good at thinking about what a user will need.

When I write documentation, I take all the information I have from my own notes, from product managers, and the several threads from Slack in which someone said @Edward ☝️. I parse it all, following threads and connecting the dots.

With AI, I paste all the information into a window, tell it what we’re working on and direct the outline of documentation and examples. Claude lays out a plan, and if I’m using Claude Code, we dig deeper into the codebase or Git branch for the context I need.

Context, relationships, and information synthesis all help technical writers make better documentation. Usually we get that from subject matter experts (SME), by exploring codebases, or by being in every Slack channel and engineering standup ever.

If my AI tool has access to all of these, shouldn’t it be able to write the documentation itself?

It tries.

It can make a great outline, but it seems to have trouble navigating what kind of technical documentation to write.

AI is missing—at least for now—that magical blend of curiosity and empathy that helps technical writers anticipate their audience’s needs. It’s good at parsing content that is there, and it tries to imitate abductive reasoning as best as it can. Maybe that’s why it “hallucinates” technical content - it’s trying to guess, very much like I would, and it can get to the right answer, but it needs to be babysat, coaxed, coached, and led.

But while AI agents aren’t great at writing technical documentation (yet), they are a great aid.

Maybe aide is more appropriate. Claude Code is my SME, my always-at-hand assistant, my rubber duck, and regex expert.

How It Started / How It’s Going

I’m sure there will be advancements that feel threatening, and there will be companies that try to eschew a documentation and education function to “have someone else do it,” as there always are.

AI agents are becoming our technical analogues and companions, and the same way that some engineering teams are, technical writers will find ways that they augment and accelerate our work; not supplant us.

What if we can use this to make things better?

At Coder, as part of a larger effort to help other teams implement AI into their workflows, I created a knowledgebase that everyone could use to find answers and contribute documentation. This was before I learned about Model Context Protocol (MCP).

I want to make it easy for subject matter experts to share their knowledge, and for people who need it to find it.

Right now, I’m working on developing an MCP for an open source project that converts weather and climate datasets. As always, my goal is to develop a repeatable strategy. You can follow that repository to see how it goes.

That’s Documentation, and once I get it working, I’m looking forward to hearing about how you implement the concept, whether you learn it here or through a chat with your favorite AI.