A specification both people and AI can read

Tools that generate an interface or an entire application from a description are improving incredibly fast. I’ve tried v0, Lovable and Claude Code, and all of them can show you something in a few minutes that used to take days. The problem comes with the second and third iteration. The brief lives in the chat history, every change has to be described again, and the result slowly drifts away from what you wanted.

A source of truth outside the chat

That’s why I treat the specification as a separate file. In a structured format, such as YAML, I describe the entities, screens, roles, rules and the relationships between them. A person can read it, it can be versioned in Git, and a language model reads it just as well.

What it gives you

• Changes happen in one place. You update the specification and regenerate whatever is needed from it.
• Checks before any code is written. You can run a linter over a structured file to catch missing relationships, undefined roles or conflicting rules.
• Different outputs from one brief. The same specification can produce an interface in Vue or in React, or documentation for the client.
• The client understands what they’re approving. A structure is easier to follow than fifty pages of text.

Where the limits are

A specification doesn’t replace decision-making. You still need someone who knows why the application is being built and what it’s supposed to solve. The specification just makes sure that decision doesn’t get lost on its way between people and tools.

Why this matters for smaller teams

When AI handles a large part of the generation, writing code stops being the bottleneck. The precision of the brief becomes the bottleneck instead. A team that can describe exactly what it wants will build more with AI than a team that just writes fast. And a precise brief is work that sits where business, product and engineering meet.