There is someone you know — maybe you — who has been carrying a vision of a system that should exist.
It might be a tool that would solve a real problem in their company, the kind of problem that everyone complains about and nobody fixes because the people with the authority to fix it don’t know how, and the people who know how have other priorities. It might be a product they think about on weekends, the kind of idea that has stayed coherent in their head for years, growing more detailed the longer they live with it. It might be the next chapter of a career they’ve already had, where they’ve stopped writing code themselves but still have stronger intuitions about what should be built than most of the engineers they work with.
What these people share is vision and the absence of one specific skill: typing the code. They have spent years, sometimes decades, developing judgment about what makes a good system and what makes a bad one. They can describe the problem precisely. They can name the people who feel the pain. They can articulate the constraints. They cannot — or will not, or no longer choose to — sit down and write the implementation themselves.
For most of software’s history, that meant the vision didn’t get built. You either learned to type the code, or you found someone who could and convinced them to spend their career on your idea, or you let the vision stay in your head.
That is no longer the only set of choices.
Table of contents
What just changed
The first wave of AI-assisted development promised to make coders faster, and by that measure it succeeded. A working engineer with a capable AI assistant produces working code at a multiple of their previous rate. That story is well-told.
The second wave of the same change is less told and more interesting: the relationship between describing what should be built and getting it built has collapsed. The skill that used to be load-bearing — translating a vision into typed code — is no longer the bottleneck. What is load-bearing now is the clarity of the description.
Concretely: a careful, structured, defensible specification of what a system should be — written by someone who has the vision but not the typing skills — can now produce working code. Not perfect code, not finished code, not code you could ship without anyone else looking at it. But the kind of working draft that used to require an engineer’s full week of effort, now produced from a document that the vision-bearer wrote themselves.
This is not “no-code” in the buzzword sense. The systems being produced this way are real software, with real architectures, real edge cases, real maintenance costs. What changed is not that software stopped requiring craft. It’s that the craft of typing and the craft of reasoning about what to build have decoupled. People who had only the second now have a path to the first that doesn’t go through learning to be the first.
What hasn’t changed
This is the part that is easy to undersell, and undersells the methodology if it’s missing.
The thinking is still the work. AI assistants can produce code from a description, but they cannot produce a description from nothing. They cannot decide which problem is worth solving. They cannot choose which users to serve when serving all of them is impossible. They cannot weigh a long-term cost against a short-term win and tell you which trade your context calls for. They cannot tell you what the system should not do, which is often the most important constraint in the design.
These are judgments. They live in the vision-bearer’s head, often built up over years. The AI assistant has none of them, and acquires them only when they are written down — clearly, structured, in the language the AI reads as direction.
So the thing the vision-bearer has to do has not gotten easier. It has gotten more important. The implementation handoff used to be the bottleneck, which meant the careful articulation of vision was a luxury — most projects didn’t get that far before running aground on the typing. Now the typing is no longer the gate. The careful articulation is.
This is good news, mostly. It means people who already have the careful articulation skill — domain experts, senior architects who no longer code, founders, designers, product leaders, subject-matter experts in regulated industries — can now do the work they were always good at, and have the work translate into running software. It is also, honestly, harder than it sounds. Articulating a vision precisely enough that an AI can implement it is its own discipline, and most people who’ve been carrying visions in their head have not had occasion to develop it.
That discipline has a name.
The methodology
Intent-First Development is the practice that turns vision into the kind of documentation an AI can build from — and a human can defend, revise, and hand off.
It is not a process framework. It does not replace sprint planning, testing, or anything else a development team does. It is the discipline of capturing what a system should be, and why, in a structured form that holds up under examination.
The methodology rests on a single inversion:
The documentation corpus is the design. Code is its executable expression.
In conventional practice, the design lives in heads and conversations; documentation, when written, captures fragments after the fact; code is the design’s only durable form. In Intent-First Development, the relationship reverses. The durable form of the design is the documentation — the explanations, the recorded decisions, the captured assumptions and risks. The code follows from that. When the documentation and the code disagree, the documentation is what was decided; the code is just what was last typed.
This sounds technical. It is, if you read it as a software-engineering claim. But it has a different reading for the vision-bearer who isn’t a coder: the artifact you can produce — the documentation — is now the executable form of the system. You don’t have to translate it into code yourself. You produce the corpus that someone else, or something else, can implement from. The corpus is your deliverable. It is the form of the work that you, specifically, are equipped to produce.
What makes the methodology work — what makes it more than “write more docs” — is the structure it imposes on what gets captured.
Reasoning is captured where it’s relevant. There is no “intent document” sitting off to the side. Intent — the chain of reasoning that explains why the system is this shape and not another shape — lives wherever the topic is relevant. It lives in the explanation of a feature. It lives in the record of a choice that was made among alternatives. It lives in the captured assumption that explains why a constraint is being treated as fixed. The methodology calls these documents by specific names with specific shapes, but the principle is simpler than the names: if you reasoned your way to this, capture the reasoning where the topic is.
Decisions become artifacts. When a vision-bearer makes a choice — and most projects involve dozens of these choices, even if the bearer doesn’t realize they’re choices — the methodology asks for the choice to be recorded with its scenario, its alternatives, its recommendation, and the reason for the path taken. Not as bureaucracy. As a record of design that an implementer can read, an AI can act on, and the bearer themselves can return to in six months when they’re trying to remember why a particular thing is the way it is.
Documentation precedes code, at the altitude where the design is genuinely understood. This is the rule that prevents the methodology from collapsing into a documentation sprint. The vision-bearer does not have to know the architecture on day one; almost nobody does. They have to capture what they do know — the vision, the problem, the audience, the success measure — and let the lower-altitude designs follow when they earn the right to follow. Premature commitment to detail is the most expensive mistake in this kind of work, and the methodology has explicit machinery for preventing it.
The corpus is maintained alongside the code. When implementation reveals that something needs to change — and it will — the documentation is updated as the first step, not as the wrap-up. This is the discipline that prevents the corpus from becoming a museum exhibit. Vision-bearers who hand off documentation and never look at it again will find the system drifting from their intent within months. Vision-bearers who keep the corpus current — themselves, or with help — will find the system holding to its shape across years.
Who this is for
The methodology is for anyone who can articulate clearly what should be built and why — whether or not they can also write the implementation.
That includes engineers. Senior engineers and architects who have moved from typing to designing, and who want their designs to translate into running systems without three months of meetings, are exactly the audience that has the vocabulary to adopt this fastest. They will find the methodology native to how they already think.
It also includes people whose path into software has been different. Domain experts who have lived a problem from the inside and know exactly what would solve it. Founders who can describe a product but have stopped trying to build it themselves. Product leaders whose specifications have always been better than the implementations they got back. Subject-matter experts in regulated industries — medicine, finance, law — whose tacit knowledge has historically been the bottleneck in software that serves their domains. Designers who can describe a system end-to-end and have always wanted that description to be the system, not just an input to one.
Most of these people have been told, implicitly, that their vision needed to be filtered through someone else’s typing before it could become real. That filter has thinned. The methodology is the discipline that lets vision pass through it cleanly.
It is not for people who want software but don’t want to do the design work. The methodology does not let you skip the thinking; it amplifies the value of the thinking you do. A vision-bearer who can’t articulate the problem, can’t name the audience, can’t decide between alternatives, can’t say what the system won’t do — they will not produce a corpus that an AI can build from, regardless of methodology. The methodology helps people who can do this work but have lacked the path to translate it into shipped software. It does not manufacture the underlying judgment.
What it costs
A methodology is honest only when it names what it costs.
The thinking is still hard. Articulating a vision precisely enough to produce working software requires more clarity than most casual descriptions carry. The methodology gives you structure for that clarity, but it cannot supply the clarity itself. The first attempt at a vision document is usually shorter than the bearer expected, because most of what they thought they knew turns out to require more articulation than they’d done.
Decisions you didn’t know you were making become visible. When the methodology asks you to record a decision among alternatives, it surfaces choices you’d been making implicitly. That is the methodology working as intended, but it is uncomfortable — it can feel like the methodology is creating work, when in fact it is exposing work you were already doing without acknowledging.
Technical judgment still matters somewhere. The methodology does not eliminate the need for someone, eventually, to think carefully about whether the architecture will scale, whether the data model is sound, whether the security boundaries are right. It can help the vision-bearer get further into that work without engineering help — sometimes much further — but at some altitude, real engineering judgment has to enter, either through the bearer’s own learning or through a partnership with someone who has it. The methodology does not pretend otherwise. It does, however, keep the vision-bearer in the driver’s seat far longer than the conventional path would.
The corpus has to be maintained. A documentation corpus that drifts from the system it describes becomes worse than no corpus at all. Vision-bearers who hand off and disengage will see the corpus rot. Those who treat it as a living artifact — updating it as reality teaches them new things — will see it hold up.
The honest framing: this methodology gives you a path from vision to running software that does not require you to become a typist. It does not give you a path that does not require you to think clearly. The thinking is still the work. The methodology makes the thinking add up to a system.
What this is not
A few things the methodology is sometimes confused with:
- It is not “no-code” in the buzzword sense. The systems produced this way are real software with real engineering concerns. The methodology gives the vision-bearer a path to those systems; it does not pretend the systems’ engineering doesn’t exist.
- It is not a replacement for engineers. Engineers benefit from the methodology too — possibly more than non-engineers, because they have the vocabulary to apply it fastest. The point is not that engineers are unnecessary; it’s that the gate to building software has moved from typing to thinking, and that gate is open to anyone who can do the thinking.
- It is not tied to any specific AI tool or vendor. The methodology is tool-agnostic. Any AI assistant capable of reading documentation as direction can implement from a corpus shaped this way. Specific tools come and go; the corpus outlasts them.
Where to start
The first step is small.
Pick one piece of the vision you’ve been carrying. Not the whole thing — the next visible piece. The feature you’d build first if you were starting tomorrow. The capability that would prove the rest of it is worth doing.
Write a single document that captures it. Not in code. Not in a chat with an AI. In a structured document that names: the problem, the people who feel the problem, the constraint that shapes the answer, the choice you’re making among alternatives, and the reason you’re making that choice and not another.
Then hand the document to an AI and ask it to produce a working draft. Read what comes back. Notice where the AI got something right that you hadn’t thought to specify, and where it got something wrong because you hadn’t yet articulated the constraint that ruled the wrong answer out. Update the document.
That cycle — articulate, generate, read, refine — is the methodology in its smallest form. Everything else (the structure, the artifact types, the registers of decisions and assumptions and risks) is scaffolding for doing that cycle at scale, across many features, across many decisions, across many sessions, without losing the thread.
But the cycle itself is the thing. The first time you complete it on a real piece of vision you’ve been carrying, you will know whether the methodology is for you. And then we’d love to hear how it went.
A short list of what is true
If the case for this methodology had to be reduced to a list of operational claims that hold up under examination, this is the list:
- The skill of typing code has decoupled from the work of designing systems. People who have one but not the other now have a path to building software they didn’t have before.
- The thinking is still the work. AI assistants can produce code from a description but cannot produce a description from nothing. The careful articulation of vision is now the load-bearing skill, not a luxury.
- The documentation corpus is the design. Code is its executable expression. The vision-bearer’s deliverable is the corpus.
- Reasoning is captured where it’s relevant. There is no separate “intent document” because intent is what gives every document its weight.
- Decisions are first-class artifacts. The choices a vision-bearer makes become a record that an implementer can read, an AI can act on, and the bearer can return to.
- Documentation precedes code at the altitude where the design is genuinely understood. Lower altitudes earn their place as higher altitudes stabilize.
- The methodology is for anyone who can articulate clearly what should be built — whether or not they will be the one writing the implementation.
That is what makes Intent-First Development tick — and why now, more than at any previous point in software’s history, it is open to anyone who carries a vision worth building.
Frequently Asked Questions
How much technical knowledge do I actually need? Will a developer have to translate my vision anyway?
Less than you think, but more than most people assume they need. Writing a vision document — the problem, the audience, the success measure, what the system explicitly isn’t — requires no technical knowledge. Writing a capability map — what the system can do, in business terms — requires domain knowledge, not technical knowledge. Architecture and component design require technical judgment, and most non-technical vision-bearers will need a partner for those descents. What the methodology changes is where that partnership begins: instead of handing off a vague brief and receiving an architecture back, you hand off a documented vision and capability map, and the technical partner’s job is closing the gap from 30K to 10K, not translating “here’s what I want” into something buildable. The partnership is still real. It starts later and from a stronger foundation.
If I hand the corpus to a developer, how do I know the implementation reflects my intent and not theirs?
The corpus is the anchor. When you hand off documented intent — a vision that names the problem and audience, a capability map in your business vocabulary, recorded decisions with your rationale — you have a basis for reviewing what comes back. A developer implementing from that can produce work you can evaluate against it. “Does this implementation serve the documented intent?” is a question with a checkable answer. Without the corpus, you have no reference — you can only say “that’s not what I pictured,” which does not produce a correction. The corpus converts your intent from something that lives in your head into something that survives the handoff.
What’s the realistic timeline from vision document to working software?
It depends on what “working software” means and how much of the technical design work you’re contributing versus outsourcing. A single well-defined feature — documented vision, capability map, design decision record — can produce a working proof of concept from an AI assistant in an afternoon. A production-grade system with real infrastructure, security review, and thorough testing takes whatever it takes. What gets faster is the iteration cycle: “describe what I want → get something I didn’t mean → describe what I really meant → repeat.” That cycle, which typically costs three to five iterations, often collapses to one or two when intent is documented rather than improvised in chat.
What does failure look like? When does this approach not work?
The methodology fails when the documentation is aspirational rather than honest. A vision document that describes the product the vision-bearer wants to have built rather than the problem being solved produces implementation that satisfies the document but misses the actual need. The discipline the methodology demands — naming constraints, ruling out alternatives, writing what the system explicitly won’t do — is where most non-technical adopters underinvest, not because they can’t do it, but because those conversations are uncomfortable. The other failure mode is maintenance: a corpus that is produced and never updated becomes a museum exhibit within months, and implementation drifts away from it silently.
Is this just ADRs and design docs with new vocabulary?
ADRs and design docs are artifacts for engineers, written by engineers, read by engineers. IFD’s documentation corpus is written by whoever holds the intent — including people who are not engineers — in a structure designed to be legible to both AI assistants and non-technical stakeholders. The difference is not vocabulary; it’s authorship and direction. A vision document’s first question is “what problem is being solved, for whom” — a question that requires domain expertise, not technical expertise. The technical artifacts (architecture docs, component designs) are still produced by people with technical knowledge. The methodology gives non-technical vision-bearers a defined role and a defined deliverable up to the point where technical expertise is genuinely required.