Structure Intent

Structure Intent: A Manifesto

Structured intent: the bridge between what we mean and what machines build.

Version 0.2 · 7 November 2026 · structureintent.com

The claim

For seventy years, the program has been the main artifact of software. A person held an intention in their head, translated it by hand into a programming language, and the code became the record of what the system was supposed to do. The intention itself was rarely written down. When it was, it drifted away from the code within weeks.

That arrangement made sense when only humans could write code. It no longer does. AI systems now write code in traditional languages faster than people can, and increasingly better. When translating an intention into an implementation becomes cheap, the value is no longer in the translation. The value is in the intention.

Sean Grove of OpenAI put it in one sentence: code is a lossy projection of intent. In the same 2025 talk, he named the valuable artifact structured intent. This manifesto takes up his term and proposes a discipline around it.

Every implementation discards the reasons behind it: why this limit, why this order, which behaviors are promises and which are accidents. Code preserves what a machine does. Structured intent preserves why it should do it.

Definition. Structured intent is a versioned, machine-checkable and human-governed representation of a system’s purpose, guarantees, constraints, priorities and origins, independent of any particular implementation. It must be precise enough for machines to build from, verify against and carry across technologies, and readable by the people who own it.

Gaps have always been software’s core problem. Requirements drifted from code, documentation drifted from behavior, and the business drifted from engineering. Each era tried to bridge these gaps with a document or a process, and the bridges kept failing because nothing kept them honest. Structured intent is the first bridge that machines can check from both sides. It bridges:

  • meaning and implementation: what we want, and what gets built
  • people and machines: human judgment, and AI action
  • old technology and new: code lifted from one language, lowered into another
  • research and code: findings about what’s missing, turned into something buildable
  • promise and proof: what was meant, and what is actually enforced
  • today and what comes next: a habit built while we still read the code, for systems we may not be able to follow

Intent is the source of truth. Code is one of its renderings.

The lineage

Each major advance in programming has disciplined something that was previously left to chance.

  • Structured programming (1960s–70s) disciplined control. Edsger Dijkstra’s case against unrestricted goto replaced tangled jumps with sequence, selection and iteration, so a program’s flow could be reasoned about.
  • Object-oriented programming (1980s–90s) disciplined state. It bundled data with the behavior allowed to change it, so systems could be organized around things.
  • Structured intent (2020s–) disciplines purpose. It organizes software around what the system is for: its goals, the promises it keeps, the lines it must never cross, and how it trades one goal against another.

Each step raised the level at which people think, without removing the levels below. Structured programming did not abolish machine code, and object orientation did not abolish control flow. Structured intent does not abolish programming languages either. It moves them down a layer, where compilers and AI agents produce and check them, and it puts human attention where it now matters most.

The object-oriented vocabulary offers a useful, if loose, correspondence:

Object-oriented Intent-oriented
Class Intent: goal, constraints, priorities
Object instance Binding: one realization in Rust, Python or another technology
Encapsulation Implementation hidden behind the intent
Interface Contract, plus the evidence of how strongly it is enforced
Inheritance Refinement: a narrower intent that provably keeps every guarantee of its parent
Polymorphism One intent, many bindings

Inheritance was famously fragile, because a subclass could quietly break what its parent promised. Refinement can be checked.

The trend

Structured intent is not a prediction. The field is already moving toward it from several directions at once, mostly without a shared name.

  • Natural language as programming. In 2025, Andrej Karpathy described “Software 3.0”: large language models as a new kind of computer, programmed in English. He also pointed to a growing category of code that mixes English with conventional programming.
  • Specifications as the new code. At the 2025 AI Engineer World’s Fair, Sean Grove of OpenAI argued that specifications, rather than prompts or code, are becoming the basic unit of programming, and that the most valuable skill is communicating intent precisely. He named the valuable artifact structured intent.
  • Spec-driven development goes mainstream. In 2025, AWS (Kiro, July) and GitHub (Spec Kit, September) shipped tools for writing structured specifications that AI agents implement, and Tessl offers a framework of its own. A January 2026 paper formalized the most extreme form, spec-as-source, in which the specification is the only artifact people edit and code is regenerated from it.
  • Machine translation between languages. DARPA’s TRACTOR program funds automated translation of legacy C into safe Rust, with teams including Intel using AI models checked by testing. Research systems such as Syzygy and SPECTRA extract specifications from source code along the way, and VERT and Heimdall check equivalence formally.
  • Machines that write specifications. Tools such as SpecGen and AutoSpec now produce formal specifications from code, with an AI and a verifier working in a loop. Newer work measures whether a specification is complete, not only whether it verifies, and finds that passing the verifier alone overstates quality.
  • Intent formalization as a grand challenge. In March 2026, Shuvendu Lahiri of Microsoft Research argued that turning informal intent into checkable formal specifications is the challenge that will decide whether AI makes software more reliable or merely more abundant. He calls the distance between what a user means and what a program does the intent gap.
  • Intent engineering enters the vocabulary. Through 2026, writers and practitioners including Daniel Miessler, Nate Jones and Vincent Koc began describing intent engineering as the successor to prompt engineering: saying what should be done rather than how.

Each of these supplies part of structured intent, and older disciplines supply more. Requirements engineering has long recorded rationale, priorities and traceability. Design by contract and formal methods make guarantees checkable. Model-driven engineering separates platform-independent models from their implementations.

What none of them does is combine all of these properties in one portable artifact. That artifact can be authored, recovered from existing code, merged, and lowered into many technologies, while recording who decided what and how strongly each promise is kept. That combination is what structured intent proposes.

Why now, and not in 2001

The obvious objection is Model-Driven Architecture. Launched by the Object Management Group in 2001, it promised platform-independent models that would be transformed into platform-specific code. It never became mainstream. Its models had to be built by hand, they were rigid, and the transformation machinery was costly to maintain.

AI changes the economics in both directions. Lifting intent from existing code becomes practical. Lowering one intent into several technologies becomes cheap. Keeping intent and implementations reconciled becomes increasingly automatable. None of this is solved yet, but for the first time the costs are moving in the right direction.

Principles

  1. Intent is the source of truth. People write and own intent. Code in any language is a rendering of it, regenerated when the intent changes.
  2. Correct means three things. Validity: does the intent say what people actually want? Quality: is the intent sound, complete and precise? Conformance: does the implementation satisfy the intent? A verifier can check conformance and much of quality. Only people can establish validity. A system can perfectly implement the wrong intention.
  3. Intent is structured, not prose. Goals, preconditions, guarantees, prohibitions and examples are separate parts with separate meanings. Ambiguity is a defect to find and remove.
  4. Intent includes priorities. Real requirements conflict. A structured intent says how to trade them off, for example correctness over speed or privacy over convenience. A specification without priorities is only a list of rules.
  5. Intent records its origin and its authority. Every clause says where it came from and who has the authority to decide it: an explicit decision, an inference from existing code, or a behavior inherited by accident. Telling promises apart from accidents is part of the intent.
  6. Intent evolves, and admits what it doesn’t know. Every change records what was added, what was withdrawn and why, and which implementations match which version. Open questions, assumptions and hypotheses are part of the intent, not gaps in it.
  7. Intent is bound, not translated. One intent can be realized in many technologies through bindings. A binding maps each part of the intent to the strongest mechanism that technology offers.
  8. Evidence is explicit. In every binding, each clause states how its guarantee was established (proven, type-checked, tested, checked at runtime or assumed), over what scope, and under what assumptions. A proof is only as strong as its assumptions, and a broad test suite can cover ground a narrow proof does not.
  9. Intent measures itself. A structured intent reports its own quality against a defined scope: sound (true of the system), complete (it rejects wrong behavior) and precise (it allows only one reasonable reading). Machines can then search toward better intent the way they search toward passing tests.
  10. People judge; machines do the labor. AI drafts, lifts, binds, checks and repairs. People decide what the system should do, and rule on the places where the machine finds the code and the intent in disagreement.

Anatomy of an intent

Here is a single structured intent, as an illustration. The notation is a sketch, not a standard. What matters is the parts. (A full, runnable version is in examples/transfer-funds.)

intent TransferFunds                         version 3
  goal:      move amount from A to B
  requires:  amount > 0, A.balance >= amount
  ensures:   total balance unchanged
             A debited, B credited, exactly once
  never:     negative balance, partial transfer
  priority:  correctness > latency > throughput
  examples:  ok(100, A:500 -> A:400, B:+100)
             reject(600, A:500)
  origin:    lifted from legacy/ledger.c:212
             "exactly once" = intended (decided by ledger owner)
             rounding to cents = accidental -> flagged
  open:      behavior for cross-currency transfers (unresolved)
  evidence:  rust:   ensures = tested (10k generated cases)
                     proof harness written, not yet run
                     (assumes single ledger writer)
                     never = type-checked
             python: ensures = tested (10k generated cases)
                     never = runtime check
  quality:   sound; rejects 12 of 14 seeded faults
  • goal, requires, ensures and never form the contract. Formal methods have expressed these for decades.
  • priority says how conflicts between goals are resolved.
  • examples tie the meaning to concrete cases, and they become tests.
  • origin separates promises from accidents and names who decided.
  • version and open record how the intent changes and what it doesn’t yet know.
  • evidence reports, binding by binding, how each clause is enforced and under what assumptions.
  • quality reports how good the intent itself is, measured against something concrete: here, how many deliberately broken versions of the code it rejects.

Today’s specification languages already have the first four. The rest are what make intent structured.

Three ways in, one way out

There are three roads to structured intent. All three end in the same artifact, and all three leave it the same way: by lowering it into an implementation.

Author it (new systems). For a new system, people write the structured intent first: goals, guarantees, prohibitions, priorities and examples, before any code exists. Every clause starts as an explicit decision.

Lift it (from one existing system). Most of the world’s software is existing code with no written intent. Lifting recovers that intent in three stages:

  1. Extract candidate clauses from the code, its tests, production logs, documentation, tickets and the people who know the system.
  2. Tighten them with an AI-and-verifier loop until they are sound, complete and precise.
  3. Rule on each flagged clause: intended, accidental or a bug.

Without the ruling, a lift only describes what the system does. The ruling turns that description into intent: what the system should do. Lifting from C separates intent from undefined behavior, overflow quirks and inherited bugs. Lifting from Python supplies what the code never stated: types, ownership, numeric limits, and which exceptions are part of the contract. Where sources disagree, such as code against tests or documentation against logs, the disagreement is exactly what a person should rule on.

Merge it (from several systems). Lift from several codebases, for example products that each solved part of the same problem, and combine their features into one intent. Overlapping features become one clause. Contradictions become explicit rulings about which behavior wins. Gaps become open questions. The result describes a system that no single codebase contained, before any of its code is written.

Lower it. Whichever road led in, a binding turns intent into an implementation. Structured intent is a portable layer between technologies, much as a compiler’s intermediate representation sits between many source languages and many machines. A Rust binding can carry much of the intent into the compiler itself:

  • single ownership becomes the borrow checker
  • “an order cannot ship before it is paid” becomes typestate, where each stage is its own type
  • “never null” becomes an Option type with exhaustive matching
  • invariants become contracts checked by tools such as Kani

A Python binding carries less, and says so honestly. It enforces the same clauses with tests and runtime checks.

Lifting and lowering through one intent turns the hardest problem in migration, proving that old code and new code are equivalent, into two smaller problems: checking each one against the intent. The intent outlives every implementation, and the next technology needs only a new binding.

Author it, lift it or merge it. Then lower it.

What structured intent is not

  • Not prompting. A prompt is a one-time request. A structured intent is a lasting artifact that is versioned and can be checked.
  • Not documentation. Documentation describes code and drifts away from it. Intent is what code is generated from and verified against.
  • Not the end of programming. Programming languages remain, as bindings. Engineers who understand them remain essential, because someone has to design bindings and judge evidence.
  • Not a product. Structured intent is a philosophy and a discipline. Many tools will implement it, in many notations, and no one owns it.
  • Not a claim that machines understand us. It is the opposite: an admission that intent has to be made explicit, precisely because neither people nor machines can be trusted to infer it.

Where human value moves

When acting becomes cheap, value moves upstream. Building software runs in a loop: research, plan, act, learn. AI now does nearly all of the acting and a growing share of the rest. What stays human is judgment.

Stage What happens Who does the work Where people still matter
Research Survey what exists and what’s possible: markets, patents, papers, existing systems AI gathers at scale Choosing the questions; recognizing the open space
Plan Decide what the system should do People, assisted by AI Priorities, prohibitions and rulings, which no amount of research settles
Act Build, test and deploy AI Designing bindings; deciding how much evidence is enough
Learn Compare actual behavior with the intent and feed the gaps back AI measures, people interpret Deciding whether the code is wrong or the intent was

How the dynamics shift

  • A wrong plan costs more than before. When building is nearly free, AI will build the wrong thing quickly and well. The price of a mistake moves from the code to the intent.
  • The bottleneck moves from typing to judgment. Teams no longer wait on implementation. They wait on decisions.
  • Decisions come faster. Faster iteration means more decisions per day, so the quality of judgment becomes the limit on progress.
  • Expertise shifts from how to what and why. Knowing a language’s syntax matters less. Knowing what a system must guarantee, and why, matters more.

The critical skills

  1. Asking the right question. Research is only as good as the question that starts it.
  2. Recognizing the open space. Seeing what is missing, unsolved or newly possible, and having the taste to tell a real opportunity from noise.
  3. Ranking priorities. Saying what to give up when goals conflict.
  4. Ruling on intent. Deciding whether a behavior is a promise, an accident or a bug.
  5. Judging evidence. Knowing when tested is enough and when proven is required.
  6. Stating intent precisely. Writing it down so that neither a person nor a machine can misread it.
  7. Learning fast. The skill underneath all the others, covered below.

Structured intent is the deliverable

In this world, the most valuable thing a person produces is neither code nor a prompt. It is structured intent: research and judgment captured in a form machines can act on and verify. Code can be regenerated at will. A good intent cannot be regenerated without the judgment that made it. Structured intent is where human value is kept, and it is the deliverable a professional should be measured by.

Learning fast enough to judge well

Good judgment depends on understanding, and every field now moves faster than anyone can keep up with. The scarce human ability is learning quickly enough to judge well: getting up to speed on a new domain, technology or market in days rather than years.

AI is also the best tool for this. It can explain, summarize, quiz and argue the other side. The people who thrive will use AI as much to learn as to build. That closes the loop: AI speeds up learning, learning sharpens judgment, judgment produces better intent, and better intent lets AI build the right thing.

Machines act. People judge. Structured intent is where judgment is kept.

Why this matters beyond software

The more capable the system that builds, the less we can rely on it guessing what we meant. Today, an AI that misreads intent produces a bug that a person can find and fix. A far more capable system working at a scale and speed no reviewer can follow would turn the same misreading into outcomes no one chose.

Software is the first place this discipline can be built and tested, because code can be checked by machines. If structured intent works there, the same structure becomes a candidate discipline for handing purpose to powerful systems in general:

  • Priorities say what to give up when goals conflict, rather than leaving the system to decide.
  • Prohibitions draw lines that hold even when crossing them would serve the goal.
  • Origins keep a record of which human decision stands behind each clause.
  • Evidence separates what is guaranteed from what is only hoped for.

The same idea already appears in AI alignment work, where labs publish written specifications of how their models should behave. Structured intent asks that such specifications be held to engineering standards: structured, checkable, versioned, and honest about how strongly each part is enforced.

No one knows when, or whether, AI systems will surpass human intelligence across the board. What can be said now is that the habit of making intent explicit is easier to build while people still read and write the code. It should be in place before it is needed, not after.

Structure intent now, while we still write the code.

SI: structured intent for superintelligence.

An invitation

This is version 0.2 of a living document. Two companion documents will follow: one setting out the technical foundations, and one working through a full example from legacy code to verified implementations. It will change as the field changes, and it is meant to be argued with.

If you build spec-driven tools, translators, verifiers or agents, treat intent as its own layer: give it structure, record where it came from, report its evidence and measure its quality. If you lead engineering teams, ask this of every system you own: where is its intent written down, and how would we know if the code stopped honoring it?

Structured intent bridges the gap.

How to cite

jaynryan. Structure Intent: A Manifesto, version 0.2, 7 November 2026. structureintent.com.

This manifesto is shared under the Creative Commons Attribution 4.0 license (CC BY 4.0). You may share and adapt it, with credit.

Sources

Research

Talks

Programs and industry announcements

Practitioner commentary