Software development, without letting the work dissolve into chat.
AIR gives a capable AI host a governed project frame for software work: one active task, explicit scope, spec-driven implementation where behavior changes matter, planned verification, evidence boundaries, approvals, and Handoff state that can survive the session.
The host model does the work. AIR governs the project around it.
AIR is not a separate coding agent or autonomous agent layer. In the public prompt-based kit, AIR runs inside the compatible host model's context and shapes how that model frames, executes, reviews, and carries forward the work.
AIR's job
- keep one material task centered
- bind scope, sources, constraints, acceptance criteria, and approval boundaries
- select task-relevant cognitive routes and challenge unsupported assumptions
- require behavior and verification specifications when material coding behavior changes
- surface blockers, evidence posture, review state, and handoff state
- stop when required evidence, input, or approval is missing
Your job
- set the goal and decide the responsibility split
- provide or authorize access to the repository, requirements, standards, and other needed sources
- keep irreversible or sensitive decisions behind the approval boundary you choose
- review the evidence that matters for the stakes
- make the final human decisions that remain yours
From request to verified change.
The exact ceremony is proportional to the work, but the execution order keeps the high-risk decisions ahead of implementation.
Frame the project
Onboarding establishes rigor, ambiguity handling, continuity, project sources, and the working agreement — including what AIR may do independently and what still requires your approval.
Bind one active task
AIR compiles the current task into the sole active Orbit 0 artifact. Other known work can remain queued or deferred without competing for execution authority.
Inspect before changing
The current repository state, relevant contracts, tests, standards, and dependencies become evidence for the active task rather than background assumptions.
Specify behavior and verification
For behavior-bearing changes, AIR defines the intended observable result and the planned checks before generating code, then tests whether those checks are adequate.
Implement inside the bound scope
Code generation or mutation stays inside the active artifact's allowed actions, resource scope, evidence requirements, and approvals. Related-looking work does not become authorized automatically.
Verify with real evidence
Tool output, test logs, repository state, deployment state, or operator results count according to what was actually observed. AIR does not turn an intention to test into a claim that tests passed.
Reconcile and continue
AIR compares the result to the resolved original intent and acceptance criteria, records what remains unresolved, then either closes, revises, queues the next task, or serializes the state for Handoff.
Where the structure earns its overhead.
AIR is deliberately more structured than raw chat. That makes the most sense when losing state, drifting scope, or overstating readiness has a real cost.
Features and refactors
Useful when the implementation must preserve existing contracts, avoid regressions, or satisfy several constraints at once.
Security, migrations, integrations
Useful when tests, standards, external APIs, repository state, approvals, or rollout conditions must remain traceable.
Projects that outlive one session
Useful when decisions, blockers, evidence, and the next active step need to survive context resets or platform changes.
Not every coding question needs a runtime.
For a one-off syntax question, a tiny disposable script, or exploratory code where the cost of being wrong is low and no project state needs to survive, raw chat or a normal coding assistant can be faster. AIR is for the point where project discipline becomes cheaper than reconstruction and drift.
Spec-driven development with AIR
Why AIR qualifies as SDD for software work and where that classification stops.
Read the SDD page →Specification-First Verification
See the behavior specification, verification specification, adequacy gate, and reconciliation loop.
Read the SFV page →Where AIR fits
Compare the system layer with raw chat, SDD harnesses, agentic engineering environments, and agent runtimes.
See the architecture map →Inspect the AIR Kit
The Foundation, governance, Handoff schema, Specialist packages, release catalogs, and distribution-integrity workflow are public.
Open GitHub →The public AIR Kit is prompt-based cooperative behavioral governance. It does not independently guarantee deterministic tool execution, backend enforcement, security, correctness, universal host behavior, or production readiness. Those claims require the corresponding external evidence.