Daniel Miessler argues that written intent should guide AI development more strongly than the code an agent happens to produce. His October 23 essay, Writing Is Closer to Thought Than Code, makes the case through an Ideal State Artifact, or ISA: a living document connecting desired outcomes to tests.

He positions the essay against Matt Pocock’s code-centered approach. Miessler quotes Pocock saying, “The code, not the spec, should be the center of your universe.” The competing concern is that an early implementation can quietly turn accidental choices into permanent requirements.

What the document contains

  • Ideal state. Prose describing the experience or outcome being sought. Miessler allows anything from a few paragraphs to thousands of words of exploration.
  • Constraints. Boundaries and things the project should avoid.
  • Decisions. Dated changes with reasons, including discoveries made while building.
  • Ideal State Criteria. Small, testable statements of what must be true, each paired with a check. These criteria guide both implementation and evaluation.

Miessler describes two feedback loops. Writing changes the author’s understanding of the goal. Building reveals omissions or mistakes in the writing. Both kinds of discovery return to the same document.

Put a check beside each requirement

His checking sequence starts with ordinary code assertions. Where those are insufficient, a fast model answers targeted questions. A stronger model can then score an output against a rubric or compare alternatives. Cheap checks run first, and a failed assertion stops that run before model-based evaluation.

This makes the proposed artifact more specific than an aspirational product description. It pairs each intended outcome with evidence that would support calling it complete.

The essay’s yoga-studio example illustrates the risk. An agent creates a booking app with a login wall, an awkward mobile calendar, and capacity for 20 people in a 12-person room. Teams can then document and test those choices simply because they already exist. A written target would let them judge the app against the intended booking experience.

Keep intent and operational truth distinct

A document can define what should happen. Running software, tests, and observations show what does happen. Calling either one the only source of truth obscures the job of the other.

The strongest practical proposal is the connection between intent, dated decisions, and explicit checks. Miessler also acknowledges that a living spec could serve this role. His objection is to documents written once, separated from tests, and abandoned as implementation proceeds.

His broader claim is that human involvement increasingly becomes an anti-pattern as AI execution improves. That goes beyond what these examples demonstrate. A clear requirement can still be implemented incorrectly, and a model judge can approve the wrong result.

Caveat: this is a workflow argument with illustrative examples, rather than a measured comparison of development methods or a reliability study of autonomous execution.

Keep the written goal current, make its criteria executable where possible, and investigate disagreements between the document and the running system. Better articulation reduces one source of error; verification still has to catch the rest.