When Plain Text Becomes Code

I'm sure software engineers are noticing all kinds of changes in the way we work. Recently, the biggest shift for me has been how I get ideas out of my head and into something that actually runs.

I used to start a new project by writing a simplified version of the core pieces in code. Almost all the time these days, I’m not starting with code. I’m starting with plain text,notes, fragments, half-formed thoughts. Sometimes in a doc, sometimes in chat, sometimes just a scratchpad. Then, without much ceremony, that text turns into something more structured, then more precise, and eventually some piece of working code. Most of the time, I’m not even the one writing that code anymore.

Because of that, I find myself worrying a lot less about whether an idea is fully thought through. I can just write it down and see what happens.

There’s a common line people repeat in some form or another about working with coding automation:

If you are working with a coding robot, your work will eventually become an incredibly precise description of what you want. And that’s called code.

That feels true. But I remember colleagues using that line years ago to argue the opposite of what we’re seeing now: that we wouldn’t really get automated coding systems, because you’d still have to do the hard work of writing a precise specification, and that is programming. I think they were right about one part,you can’t automate the thinking. But they were wrong about what it means to specify something well enough to try it. You don’t need a fully precise, complete specification up front. You just need something clear enough that an agent (or human) can take a first pass and produce a result you can react to. The rest of the precision can be filled in iteratively.

What’s changed isn’t that code suddenly became a description. It always was. The real shift is how fast and how easily you can move between levels of abstraction. A rough description can be turned into a partial implementation, inspected, and refined, then turned into something more complete, in minutes. If a plain text description is clear enough that an agent can reliably turn it into a working system, then that description is already functioning as code, just at a different level. You don’t have to translate it all the way into a traditional programming language up front for it to be useful, the text in the middle is already doing real work.

The Messy Middle

We used to pretend there were clean steps: talk about an idea, write requirements, implement code. Now it feels more continuous. You start with a vague idea, write a paragraph, turn it into a list, clean it up a bit, add some structure, and at some point it’s specific enough that an agent can turn it into something that runs. You can stop anywhere along that path and still get useful results.

The obvious answer is “AI got better,” but that’s not quite the right way to think about it. What actually changed is that agents are now good enough at dealing with ambiguity. They don’t need perfectly structured input or a fully specified API. They can take something messy and incomplete and still produce something reasonable, and they can do it consistently enough that you start to trust the process.

That shifts where you put the effort. Instead of forcing structure up front, you can defer it. You can stay in plain text longer, and only make things precise when you need to.

For example:

## Scheduling Goals
- Short jobs should start quickly
- Long jobs should keep the system busy
- GPU workloads should be prioritized when available

This is just a description of intent. But in practice, it’s often enough. An agent can take that, fill in the gaps, ask questions if needed, and turn it into something executable. If it’s wrong, you fix the text and try again.

Text Starts Acting Like Code

At some point, you notice something slightly uncomfortable. If you keep refining that text, making it clearer, more explicit, less ambiguous, it starts to behave exactly like code. Not because it looks like code, but because it produces predictable results when an agent interprets it.

That was always true in principle. What’s new is how early in the process it becomes useful. You can get behavior from a description long before it’s thought through, then tighten it and try again. The more precise the description, the more reliable the outcome, and if the agent is consistent enough, that description is effectively executable.

Why Markdown Shows Up Here (as an Informal IR)

You could say “Markdown is becoming the new IR,” and that’s not totally wrong, but it’s also not really about Markdown specifically. It just happens to be a natural fit for this way of working. Humans can read it easily, agents can interpret it, and existing tools and programs can process it without much effort. It’s simple, flexible, and already everywhere.

In practice, that means you end up with one (or a few) well-organized text file, usually in Markdown, that describe what you want in a way that’s easy to read, easy to modify, and structured enough to be useful. Headings, sections, and lists give just enough shape to the content without locking you into a rigid format.

If you squint a bit, those files are doing the job of an intermediate representation. They sit between the initial idea and the final implementation, and they’re specific enough that agents can reliably turn them into code or other artifacts. You can revise them, reorganize them, add detail, or remove things, and each change flows through to what the system actually does. They end up acting as a shared layer between humans, agents, code, and even build systems,not because they were designed that way, but because they’re good enough at all of those roles.

Reproducibility Matters

The reason this works is that agents are getting more reproducible. If you give the same input, you increasingly get the same (or very similar) output, or at least something within a tight enough range that small edits to the text reliably move the result in the direction you expect.  At that point, you don’t need much more. For a lot of problems, a few well-structured text files are enough. They capture the intent, act as the intermediate form, and are sufficient to reliably produce a working implementation when paired with an agent. Because the representation is simple,just plain text,you can iterate quickly, and small changes reliably produce the changes you expect. That’s a very different starting point than traditional software workflows.

So Are We Just Writing Code Again?

In a strict sense, yes. If you push far enough, the text becomes precise. Every case is covered, every constraint is spelled out, every behavior is defined (or more likely, you trust that the agent can fill in the gaps closely enough to what you intend). At that point, you’ve recreated code, just in a different syntax. But the process of getting there is different, because you don’t have to commit to that level of precision up front. You can move toward it gradually, only when it’s needed. If coding agents turn your work into an increasingly precise description, we're in only a slightly different place than we thought we would be: still writing descriptions, just at a different level of abstraction. The difference now is that you don’t have to finish the description before you can run it.