How Markdown became the new programming language

Do you remember Terminator 3: Rise of the Machines? Beyond Kristanna and Arnold making an entrance, what stayed with me was all that sophisticated technology. Machines taking over the world seemed to require some pretty impressive hardware.

It's 2026, and the machines in my working day can already read a project, write code and run commands. What tells them what to do? A bunch of Markdown files.

Rise of the Markdown. Somehow, I don't think that title would have sold as many tickets.

I certainly didn't expect those files to become such a big part of my job.

Two years ago, I was already using AI every day. I asked questions, pasted code into chat windows and accepted autocomplete suggestions. But I still opened the files, wrote the Swift and fixed the build.

Today, much of my work starts differently. I describe a feature, let an agent implement it, then read, test and question the result. I still care about the code. I just spend more time writing the instructions that produce it.

The file I keep coming back to is AGENTS.md.

The README started giving orders

For years, Markdown explained software after someone built it. Installation instructions. API documentation. The README we promised ourselves we would update later.

Now those same files can influence what gets built in the first place.

AGENTS.md gives coding agents a place to find project context, build commands and conventions. The Agent Skills format puts reusable instructions in a SKILL.md file, alongside any scripts or references a task needs.

By 2026, this is a very practical use for a format I once associated mostly with GitHub READMEs. A Markdown document can describe the project. Another can explain how to perform a task. A third can record the plan before the agent touches the code.

These files don't execute themselves. The agent reads them and turns their instructions into actions. That makes the quality of the writing matter in a way ordinary documentation rarely did.

Consider the difference between asking an agent to “improve the editor” and giving it this:

Both editing views share the same Markdown source. Changing how the document looks must never change its text. Preserve selection offsets and undo history. Run the editor tests before calling the task complete.

That paragraph describes constraints, names failure conditions and defines a check. It gives the agent something concrete to work with, and gives me something concrete to review.

Why this slightly awkward format?

Markdown was designed for readable text that could become HTML, not for directing machines. Yet its original appeal fits this new job surprisingly well.

A heading separates the goal from the constraints. A code block preserves the exact command. A link points to the design decision behind a rule. You can read it all in a terminal without needing the app that created it.

And it is still a file. Put it in Git and you can see who changed an instruction, discuss the change and recover the previous version.

I find that more useful than another clever prompt sitting somewhere in my chat history.

Files also give agents a place to recover context. A new session can read the decisions from the last one, provided the relevant documents are actually loaded. It isn't magical memory. Somebody still has to keep those notes accurate.

Writing becomes part of engineering

Calling Markdown a programming language is a stretch in the literal sense. There is no compiler checking whether “keep this simple” means the same thing to me and to the model.

That's exactly where the work gets interesting.

A vague specification leaves room for plausible mistakes. An outdated instruction can send several sessions down the same wrong path. A good plan makes those assumptions visible before they become hundreds of lines of code.

I've started treating these documents with more care: fewer vague requests, clearer constraints, explicit checks. The generated code still needs review and testing. Writing a convincing plan doesn't make its implementation correct.

Why I built Markify

Spending more time in Markdown also made me want a better place to read it.

An agent's long report is easier to think about as a document than as another wall of terminal output. The same goes for the specification I'm about to hand back to it.

That's part of why I build Markify, a free native Markdown editor for macOS 26. I can write on a rendered page, then press ⌘/ to see the Markdown underneath. Both views work on the same text, and the saved file stays ordinary Markdown that an agent or another editor can use.

For me, that is the useful middle ground: a comfortable page to think on, and a plain file to keep.

The rise of the machines has been less cinematic than I expected. In my working day, it looks like an agent waiting for me to explain what I mean.

Increasingly, I explain it in Markdown.

Which file gets more of your attention now: the implementation, or the instructions behind it?