You’ve probably felt it: the quiet frustration of explaining exactly what you want to an AI, only to get something that’s 80% right but 20% off. You tweak the prompt. It changes something else. You add a constraint. It forgets the first one. The loop is exhausting, and the result is never quite yours.
There’s a better way. It’s not a smarter prompt or a bigger model. It’s a single file—a specification written in KDL—that tells an AI agent exactly what to build. Change the spec, and the agent rebuilds the entire application from scratch, deterministically. Every time.
You don’t write code anymore. You edit a spec. The AI builds the rest.
This is the Mimeng principle in action: emotion first, logic second. The emotion here is the allure of absolute control—the dream of dreaming a system into existence simply by tweaking its blueprint. The logic is that declarative specs, like KDL, strip away the probabilistic noise of LLMs and give you a deterministic contract. The agent follows the spec. No hallucinations. No drift.
Let me be blunt: Code becomes a disposable, auto-generated byproduct. The real asset is the human-readable specification.
I saw this firsthand with the Surface project (github.com/etoxin/surface). The creator wanted an app spec format that could near-deterministically output an application via an AI agent. Change the spec, and the LLM could rebuild the whole application with that one change. Human-readable, agent-executable.
Think about what that means for version control. If the spec is the source of truth, and the code is regenerated from it, what is the point of tracking every single line of generated code? The commit history becomes a history of spec changes. The diffs become meaningful. The noise of a thousand auto-generated files disappears.
Traditional software engineering is built on the assumption that code is the artifact. But if code is just a compilation of a spec, then the real work is in specifying. This is a paradigm shift that will make most of today’s refactoring, debugging, and merge conflicts look like medieval alchemy.
The most important file in your next project won’t be a .py or .js file. It will be a .kdl file.
Now, the skeptic in you is asking: ‘But LLMs are probabilistic. How can you get deterministic output from a random process?’ The answer is the spec. By constraining the agent with a declarative format, you turn a probabilistic model into a deterministic compiler. The agent’s job is not to invent—it’s to follow the blueprint. The creativity is in the spec, not the code.
This is the twist: the very thing that makes AI unreliable—its stochastic nature—is neutralized by the very thing that makes specs boring—their rigidity. The tension creates a new kind of tool: one that gives you the power of generative AI without the chaos.
If you’re a developer, you have two choices: keep wrestling with prompts and hoping for the best, or start writing specs and watching the code pour out exactly as you intended. The future of software isn’t coding. It’s specifying.
Pick a side. I have.
FAQ
Q: How is this different from simply using a prompt with an LLM?
A: Prompts are vague and probabilistic. A spec is a structured, deterministic contract. The agent follows the spec exactly, regenerating the entire app from scratch when the spec changes. No hallucinations, no drift.
Q: What practical steps do I need to take to start using this approach?
A: Start by learning KDL (kdl.dev) and look at the Surface project on GitHub. Write a spec for a small app, then feed it to an AI agent that can generate code from it. Experiment with changing the spec and rebuilding.
Q: Does this mean I'll never need to debug code again?
A: No, but you'll debug the spec instead. The generated code is a direct reflection of the spec. If the code is wrong, the spec is wrong. That's a smaller, more precise debugging surface.