Writing Technical Blogs After AI

I have been thinking about restarting this blog, and the awkward part is that AI can now write a lot of the posts I used to admire.

Not perfectly. Not reliably. But well enough to change the feeling of the thing.

A tutorial, a setup guide, a “here is what this API does” post: those used to feel like durable contributions to the internet. Someone lost a weekend to a build system, a database migration, a strange production failure, or a barely documented library. Then they wrote down the path out so the next person would not lose the same weekend.

I still love that kind of writing. It is generous. It turns private debugging pain into public infrastructure.

I just do not think it is enough anymore.

The Answer Got Cheaper

AI has made the ordinary answer easier to generate.

If I want a first explanation of a library, I can ask for one. If I want a comparison between two tools, I can get a reasonable draft. If I want an example project, a migration checklist, a debugging path, or a gloss over some documentation, a model can usually produce something useful enough to begin with.

That does not mean the answer is always correct. It can hallucinate. It can miss a version change. It can explain the happy path while the real problem lives in the edge case. Anyone who has used these tools seriously knows the danger of code that looks more confident than it deserves.

But the baseline has moved.

The reader no longer needs every blog post to be a static answer. A lot of answers are now conversational. They can be regenerated, narrowed, expanded, corrected, or translated into the reader’s local context.

So the uncomfortable question for me is not “can I write a useful explanation?”

The question is: why should this explanation exist as a blog post?

Knowledge Versus Understanding

The distinction I keep coming back to is knowledge versus understanding.

Knowledge is the answer: the command to run, the option to set, the shape of the API, the order of the migration steps. That kind of writing is still useful, but it is no longer rare in the same way.

Understanding is different. It is knowing why the abstraction exists, where the simple explanation breaks, which part of the tool deserves suspicion, and what changed in your own taste after using it for real.

That kind of writing has to pass through contact with reality.

It comes from building the thing, watching it fail, being surprised by the wrong part, and noticing the small mismatch between the official story and the actual workflow. It is the difference between “here is how to use agents” and “here is where the agent demo lied to me.” It is the difference between “here is how to evaluate a model” and “here is why the metric improved while the product got worse.”

This is the part I still want from human technical writing.

Not because humans are automatically better. We are not. Not because every sentence has to be typed without tools. That would be a strange standard. The point is that the post should contain something harder to recover from a generic prompt: judgment, friction, a private map of what mattered after the clean explanation stopped being enough.

What AI Content Gets Wrong

AI makes it easy to create writing that looks useful before it is actually useful.

The shape is familiar now: crisp introduction, tidy bullets, a few caveats, a confident ending. The post has the outline of expertise. It may even be correct. But sometimes it carries no scar tissue. Nothing in it suggests that a real person had to choose between bad options, misunderstood the problem at first, or changed their mind after seeing the system behave.

That is the writing I want to avoid here.

If I publish something now, I want to be able to answer a simple question: what did writing this make clearer?

Some posts may still be practical. Some may start from a small experiment, a product detail, a failed assumption, or a question I cannot quite settle. But if a post is only an answer, it probably belongs in my notes. If it changes how I understand the work, then maybe it is worth publishing.

The Blog I Want

I expect this blog to keep circling AI, agents, AI-native products, model evaluation, and software practice. But I do not want it to become a tutorial farm with nicer typography.

For me, a post has to do one real thing. It can sharpen a mental model, name a tradeoff I almost missed, connect a product behavior to the architecture underneath it, or turn a personal experiment into reusable judgment. It does not have to be grand. It just has to leave the question clearer than it found it.

That is a higher bar than “I learned something, so I will write it down.”

It is also a more interesting reason to write.

The old reason to blog was often preservation: I figured this out, so I will save it somewhere public.

That still matters. But the better reason now is precision: I am trying to understand something important, and writing is how I make that understanding sharp enough to share.

AI has made knowledge easier to generate.

It has not made understanding easy.

That is still a good reason to write.