Writing Technical Blogs After AI

Technical blogs used to have a simple and important job: preserve knowledge.

Someone spent a weekend fighting a build system, a database migration, a new framework, a strange production failure, or a barely documented API. Then they wrote down what they learned so the next person could suffer a little less. This was a generous act. It made the internet more useful. It helped engineers move faster. It turned private debugging pain into public infrastructure.

That kind of writing still matters. But it is no longer scarce in the same way.

AI has made procedural technical writing much easier to produce. A decent model can explain a library, summarize documentation, generate a tutorial, compare tools, write sample code, and turn scattered notes into a polished post. The result is not that technical blogging is dead. The result is that the baseline has moved.

If a blog post only preserves information, it now competes with systems that can generate information on demand.

So I want to restart this blog with a different purpose:

In the AI era, the most valuable technical writing preserves understanding, not just knowledge.

That distinction is going to guide what I write here.

Knowledge Is Easier To Generate

Knowledge-preserving writing answers questions like:

• How do I set up this tool?
• What does this API do?
• How do I build a small example?
• What are the steps to fix this common error?
• What changed between version A and version B?

These are useful questions. They are also increasingly well served by AI, documentation search, generated examples, and conversational assistants.

The problem is not that AI answers them perfectly. It often does not. It can hallucinate, flatten important context, ignore edge cases, or produce code that looks more confident than correct. But for many routine questions, AI is now good enough to change the reader’s expectations.

Readers no longer need every blog post to be a static answer. They can ask for the answer themselves.

What they still need is help knowing how to think.

Understanding Is Still Scarce

Understanding-preserving writing answers a different class of question:

• What is the right mental model?
• Why does this abstraction exist?
• Where does the simple explanation break?
• What tradeoffs matter in practice?
• What should I pay attention to, and what can I safely ignore?
• How did building with this change my taste?
• What does this tool make easier, and what does it make more dangerous?

These questions are harder to generate from surface-level knowledge because they require judgment. They require contact with reality: building, debugging, designing, evaluating, and being surprised.

Good technical writing has always done this. The difference is that now this part is the main event.

In a world full of instantly generated explanations, the valuable post is not the one that says “here is how to use agents.” It is the one that says:

• Here is what agents change about software.
• Here is a failure mode I did not expect.
• Here is why the demo is misleading.
• Here is the product boundary that suddenly feels different.
• Here is the engineering habit I had to unlearn.

That is the kind of writing I want to do.

AI Changes The Shape Of Software Work

The most interesting thing about AI is not that it can write text or code. The more interesting thing is that it changes the relationship between people and software.

Traditional software is mostly deterministic. A user expresses intent by clicking, typing, configuring, or calling an API. The software follows predefined paths. The product designer decides the possible actions ahead of time. The engineer encodes the behavior. The user operates inside that surface area.

AI products are different. They can interpret vague intent. They can generate intermediate plans. They can use tools. They can adapt their response to context. They can act as collaborators instead of only instruments.

This does not make them magical. It makes them strange.

An AI agent is not just a script with a chat box. It sits somewhere between interface, runtime, teammate, and automation. That makes old categories feel unstable. Product design, software architecture, engineering process, testing, observability, trust, and user education all need adjustment.

Some questions become newly important:

• What should the human decide, and what should the agent decide?
• When should an agent ask for permission?
• What makes an AI workflow inspectable?
• How do we test behavior that is useful but not exactly repeatable?
• What does good taste look like when output quality is probabilistic?
• How do teams preserve understanding when agents produce more code than humans can comfortably review?

These are not just implementation details. They are design questions, engineering questions, and cultural questions at the same time.

That is the terrain I want this blog to explore.

The Problem With AI Content

There is an awkward truth here: AI makes it easier to create the kind of writing that looks useful before it is actually useful.

A generated technical post can have the shape of expertise. It can include a crisp introduction, clean bullet points, code snippets, caveats, and a confident conclusion. It can sound reasonable without carrying much lived experience.

That creates a new burden for writers.

If I publish something now, I should be able to answer: why does this need to exist as a human-written piece?

Not because humans are automatically better. They are not. Not because every sentence must be handcrafted. Tools are tools, and using AI in the writing process can be valuable. The reason must be that the post contains judgment, synthesis, experience, or framing that would be hard to recover from a generic prompt.

The post should make the reader’s understanding sharper.

That is a higher bar, but it is also a more interesting one.

What This Blog Will Try To Do

This blog will focus on AI, agents, AI-native products, and the changing practice of software engineering.

I expect the posts to fall into a few patterns.

Mental Models

Posts that explain a concept in a way that changes how it feels to work with it. For example: what makes an agent different from a workflow, why context is not just input length, or why evaluation is becoming part of product design rather than only model development.

Field Notes

Posts from building, testing, or using real systems. These should be specific. What worked? What failed? What surprised me? What did I change my mind about?

Product Analysis

AI products are full of new interaction patterns. Some are powerful. Some are confusing. Some hide complexity well. Some hide it dangerously. I want to study those patterns with the seriousness we usually reserve for architecture.

Engineering Practice

AI changes how code is written, reviewed, tested, and maintained. The interesting question is not “can AI write code?” The interesting question is how a good engineering organization changes when code generation becomes cheap but understanding remains expensive.

Open Questions

Some posts should not pretend to be finished. AI is moving quickly, and many of the most important questions are unsettled. A good open question, clearly framed, can be more useful than a premature answer.

The Standard I Want To Hold

I want each post to do at least one of these things:

• Give the reader a clearer mental model.
• Name a tradeoff that is easy to miss.
• Connect product behavior to technical architecture.
• Turn a personal experiment into reusable judgment.
• Challenge a popular but shallow explanation.
• Make an uncertain area easier to reason about.

If a post cannot do one of those things, maybe it should stay in my notes.

A Better Reason To Blog

The old reason to blog was often: I learned something, so I will write it down.

That is still good.

But the better reason now might be: I am trying to understand something important, and writing is how I will make that understanding precise enough to share.

That is the spirit I want here. Less content production. More public thinking. Less tutorial farming. More durable mental models. Less pretending the future is obvious. More careful attention to what is actually changing.

AI has made knowledge easier to generate.

It has not made understanding easy.

That is why technical writing still matters. And that is where I want to begin.