What AI-first development means
Using an assistant to write code does not change the development process by itself. The team still has to decide what behavior it wants, state the constraints, review the implementation and check the result.
AI-first development adapts that loop to a concrete reality: a growing part of implementation is produced by agents that do not retain stable product memory. Context, intent and evidence therefore have to exist outside each session and travel with the work.
The unit of work is no longer only a diff. It includes the reason for the change, the contract it must satisfy, the resulting code and the proof captured during verification.
This guide is one chapter of a wider operating problem. When agents produce most of the implementation, the scarce skill moves to running the loop around them, and the guide to building software with AI agents covers that full picture. What follows is the AI-first slice: which artifacts the loop needs and how they stay connected.
The framework artifacts
An AI-first workflow needs a small set of connected parts:
- Product evidence: observations, data or conversations that establish a need.
- Decision: the selected option, rejected alternatives and their rationale.
- Specification: expected behavior, constraints and acceptance criteria.
- Code context: affected components, dependencies, interfaces and invariants.
- Execution: tasks and changes produced by people or agents.
- Verification: tests, logs, screenshots or other proof tied to the contract version.
The value is not document volume. It is the ability to follow the links: from a line of code to the decision that authorized it, and from a criterion to the evidence that shows whether it is satisfied.
These artifacts are where the knowledge sits, and that placement is the whole argument. A separate piece puts it side by side with Waterfall, Agile and DevOps, which each answered the same question differently, and works out what the difference costs a team.
The operating loop
Define
The team turns a need into a testable contract. Before execution, it separates facts from hypotheses, records open decisions and writes criteria that distinguish a correct result from a plausible one.
Spec-driven development covers this part in more detail.
Prepare context
The task receives only relevant context: repository rules, affected architecture, interfaces, current decisions and necessary examples. More context is not always better; it needs provenance and a current version.
Execute
The agent implements against the contract. If it discovers a new constraint or needs to change a shared interface, that information returns to the contract instead of remaining inside the agent conversation.
Verify
The output is checked with reproducible evidence. A message saying “tests pass” is status; the run, logs and criteria version form the proof. The guide to verifying AI-generated code develops this distinction.
Learn
The result updates product knowledge. A hypothesis may be confirmed or rejected, a decision may change, and a specification may become stale. The system should show those revisions without erasing provenance.
Why speed alone does not compound
Teams adopting agents usually see output jump first and maintenance stall later. The arc is common enough to predict. Projects become unsustainable, not because the generated code is wrong but because nobody can reconstruct why it is the way it is. Measured over months instead of sessions, part of the productivity gain turns out to be an illusion: the hours saved writing code come back as hours spent reverse-engineering intent before every change.
The framework exists to keep the saved time saved. Each stage of the loop leaves an artifact behind, so the next change starts from a contract and a trail instead of from archaeology. That is the whole trade: a small tax on every task in exchange for never paying the reconstruction bill.
Adopting it in an existing repository
Nothing here requires a greenfield project. The framework grows one feature at a time.
- Pick the next change you were going to make anyway.
- Write the smallest contract that makes it checkable, with the behavior, the constraints and the criteria that would prove it done. If the codebase has no specs at all, start with the seams you touch, not with a documentation sprint.
- Record the decision when you choose an approach. One paragraph, including the alternatives you rejected.
- Close with the evidence attached, whether that is a test run, a log or a screenshot.
After a handful of cycles the team has a small connected trail and a measured sense of the overhead. That is the point where scaling the practice becomes an informed decision instead of an act of faith.
What adoption costs, and who it is for
The framework does not require a particular team size. A single founder running the loop alone and a ten-person team running it together are doing the same five things: define, prepare context, execute, verify, learn. The difference is who authors each artifact and how many people need to agree on it before it moves forward. A factory of one makes the same case from the other direction: the loop does not get lighter because nobody else is watching, it gets lighter because there is nobody to negotiate the contract with.
The real cost is a tax on every task, not a training program or a headcount you add. Writing the contract and recording the decision take minutes the first time. What they buy back is the hour an agent would otherwise spend re-deriving intent from a diff and a commit message, and that trade repeats every time the work resumes after a break. Controlling AI costs covers the same trade on the token side: a stuck agent looping on a badly scoped task burns far more than the criteria that would have caught it early would have cost to write.
Where the trail lives is a separate question from who pays for it. The framework does not specify a storage layer, only that decisions, reasons and dead ends have to travel outside the chat. Product memory develops what specifically gets forgotten when nothing holds that layer, and context window management explains why no amount of window size makes this optional: compaction eats the session’s own record of what happened, no matter how large the window started out.
Architecture and patterns
The framework does not mandate one architecture. A small product may keep context inside a monolith. A system with several sources and models may separate ingestion, storage and retrieval. A high-risk domain may require human review before execution or release.
The choice depends on volume, data sensitivity, latency, the cost of an incorrect output and the team’s operational capacity. The comparison of architecture patterns for AI systems explains those trade-offs.
Context injection
Context injection gives an agent the rules and artifacts it needs at execution time. It is not a matter of pasting all documentation into a prompt. It selects context for the task and retains the provenance of each item.
A useful implementation answers these questions:
- Which rule or decision does this task need?
- Where did it come from and when was it updated?
- What happens when two sources conflict?
- How is a constraint discovered during execution recorded?
Responsible use
The same trail that supports maintenance also supports AI governance. Teams should record data sources and model versions, restrict access to sensitive information, evaluate domain-relevant bias and define who approves high-impact decisions. Security review belongs inside the same loop rather than after it, and securing AI-generated code covers the tooling side of that check.
Before automating a decision, the team should be able to state who it affects, which data it uses, how an output is reviewed and which mechanism can stop or correct the system. These questions belong in the contract rather than a later review.
What the framework does not solve
The method does not turn a hypothesis into evidence, guarantee that a specification is correct or remove the need for human judgment. It also cannot compensate for a repository without clear boundaries or a test suite that does not observe important behavior.
Its job is narrower: keep the reason, decision, execution and verification connected so a team can review and change the product without reconstructing its history during every iteration.
Frequently asked questions
What is AI-first development?
It is an approach where context, intent and evidence are first-class artifacts alongside code. The goal is not to generate more output; it is to maintain a contract that people and agents can execute and verify.
How is it different from using an AI coding tool?
A tool accelerates an implementation session. A framework organizes the full loop: how a decision is made, which context an agent receives, how its output is validated and how learning returns to the product.
Is AI-first development the same as spec-driven development?
No. Spec-driven development is the define stage of this loop, the discipline of turning intent into a testable contract before execution. AI-first development covers the full cycle around it, including how context reaches the agent, how output is verified and how what the team learns feeds back into product knowledge.
What does a team need to start?
A small testable contract, repository rules, a way to provide task-specific context and reproducible evidence at completion. Additional complexity is justified only after those basic parts work.
How much overhead does the framework add per task?
The time to write a small contract, record one decision paragraph, and attach evidence when the task closes, not a separate process layered on top of the work. The tax is paid up front and in small units; the alternative is paying a larger, unscheduled bill later, in the session where someone has to reconstruct why the code does what it does.
Does this work for a solo developer, or only for teams?
It scales down to one person. The four artifacts stay the same, only the number of people authoring and reading them changes. A factory of one argues the loop matters more for a single founder, not less, since there is nobody else around to remember the reasons if they are not written down.