The 9 Stages of AI‑Assisted Software Development
From autocomplete to autonomous production systems. Where does your team sit?
01
02
03
04
05
06
07
08
09
Every engineering team adopting AI tools follows the same trajectory. The specifics vary — different languages, stacks, org structures — but the pattern is remarkably consistent. There are nine distinct stages between “developer with an autocomplete tool” and “self-maintaining production system that adjusts its operations for the environment it serves.”
Most teams are at Stage 2 or 3. Getting to Stage 5 requires designing for it. Getting beyond Stage 5 requires building for it. None of the later stages happen by accident.
Stages 1–3
The developer and the assistant
Where most teams are today. The AI helps — but the developer owns every decision, every review, every integration.
01
Autocomplete
A faster keyboard, not a different workflow
Developer does
- Writes code manually
- Reviews AI suggestions line by line
- Full cognitive load stays with the developer
AI does
- Completes lines and functions from context
- Developer and AI work at the same level — same task, same pace
Automated: nothing
02
Prompted Changes
Output grows. Review burden grows with it.
Developer does
- Describes what needs changing
- Reviews all output — still owns every line
- Writes fewer lines, but review burden grows
AI does
- Rewrites functions, files, components on instruction
- Output volume increases significantly
Automated: nothing
03
Collaborative Loop
The ceiling is the developer’s attention bandwidth
Developer does
- Prompts brief, reviews PRD, approves approach
- Tests and debugs with AI — conversational back-and-forth
- Still deeply involved in every decision
AI does
- Drafts PRDs, generates implementation
- Iterates on feedback across multiple rounds
This is where most “vibe coders” operate. LLM-controlled TDD, brute-force retry loops, and conversational debugging. It works — until it doesn’t. The productivity gain is real but linear: one developer, one conversation, one task. The ceiling is the developer’s attention.
Automated: some development. Review stays manual.
Stages 4–6
Building the infrastructure
The transition from Stage 3 to Stage 4 is the largest single leap — from ad hoc prompting to a designed, repeatable process. Something has to be built.
04
Partial Pipeline
Some steps are automated. The gaps are where things break.
Developer does
- Configures pipeline steps manually
- Monitors output, intervenes on failures
- Fills gaps between automated phases
AI does
- Executes specific phases: code gen, tests, basic review
- Phase transitions are manual or fragile
Automated: code generation, test execution. Manual: review, integration, deployment.
05
Full Pipeline, Fixed Configuration
Every step scripted. Every transition enforced. Every output reviewed.
Developer does
- Writes specs, reviews pipeline output
- Makes architectural decisions
- Pipeline handles everything else
AI does
- Full TDD cycle: spec → red tests → green → review → remediation
- Quality gates between every phase
- Deterministic orchestration — scripts control, LLMs execute
~50%
Tests are harder than code
Half of pipeline remediation cycles are triggered by test quality, not implementation quality. Writing tests that verify behavior rather than implementation is the hardest part.
≠
Retry loops are not pipelines
A generate-fail-retry loop is not a pipeline. A designed pipeline adds adversarial review gates, scoring, stall detection, and circuit breakers. The difference is structural.
Pre-built pipelines
At this stage, pipelines are pre-configured — different gate thresholds, review depth, model selection, and retry limits for each context. The system defaults to the appropriate pipeline; users can request new ones, but most work runs through what’s already there. Includes pipelines for non-software artifacts like documentation and training materials.
PoC
MVP
Team
Org
SaaS
Mission-Critical
3–4×
net output increase
Per-task, the pipeline is slower — but devs run 4–6 tasks at once
Review gates, adversarial checks, and remediation loops add hours to each task. That sounds like a problem — until you compare it to a world where devs handle one or two tasks and context-switch constantly. The pipeline builds overnight. Net delivery is 3–4× higher, not lower.
Automated: everything except spec authoring and architectural decisions.
Deep dive: Stage 5 →
Why deterministic orchestration matters
At Stage 5+, a critical choice: who controls the workflow?
- LLM-directed (path of least resistance) — unbounded retries, step skipping, context loss, self-review blind spots
- Deterministic (scripts enforce sequence, LLMs execute steps) — reproducible, auditable, decisions from state files not model judgment
06
Spec-Driven Pipeline Synthesis
The system builds the pipeline from the specification.
Developer does
- Provides specifications or intent
- Reviews generated pipeline configuration
- Selects pipeline type — PoC gets minimal gates, production gets full adversarial review
AI does
- Reads spec, generates complete pipeline — stages, agents, gates, retry logic
- Generates pipelines on demand for new artifact types
- Makes non-software outputs possible without manual pipeline building
Beyond software
The system generates customised pipelines for any task, giving it the ability to produce any digital artifact — not just software. A single PRD now triggers specs across multiple domains. At Stage 5 you’d rely on pre-built pipelines. At Stage 6, the system generates new ones as needed:
PRD: “Add patient intake to the portal”
↓ generates specs for:
Intake form + API
Software specs → code, tests, deploy
Staff training materials
Tutorial videos, walkthroughs, quizzes
Patient-facing docs
Help pages, FAQ, onboarding emails
Compliance & ops
Audit logging, monitoring, runbooks
Each output is produced by its own pipeline — with validation, review, and quality gates appropriate to that artifact type. They stay consistent because they’re all derived from the same PRD.
Automated: pipeline generation, configuration, execution. Manual: specifications, architectural review.
Deep dive: Stage 6 →
A different kind of capability
Stages 1–6 are about production — building things faster, more reliably, at scale. Stages 7–9 are about awareness — what the system knows about itself, the organization it serves, and the world around it. These aren’t levels you unlock in sequence. They’re capabilities that become effective when the production infrastructure is mature enough to act on what the system learns.
At these stages, “software” is just one output. The same pipeline discipline applies to documentation, training materials, marketing, monitoring — everything the organization produces digitally.
Stage 7
Knows itself
What it built, what failed, what was learned. Manager Agents own each major feature.
Stage 8
Knows who it serves
Policies, regulations, domain conventions. Manager Agents apply institutional context automatically.
Stage 9
Acts on the world
Manager Agents don’t wait for specs — they originate work from goals, signals, and constraints.
Stages 7–9
Expanding awareness
Stages 1–6 describe production maturity — building things faster, more reliably, at scale. Stages 7–9 describe something different: an expanding sphere of awareness. The innermost ring is the system itself — what it built, what failed, what was learned. The next ring is the organization it serves — policies, standards, regulations, institutional knowledge. The outermost ring is the environment around it — technology shifts, regulatory changes, user behavior, ecosystem health. At each ring, the system can govern more — because stewards can only govern what the system can see.
07
Self-Awareness
The system stops treating each pipeline run as isolated. It accumulates governed knowledge and maintains a truthful picture of what it actually is.
Developer does
- Governs knowledge — promotion rules, contradiction resolution, what retires
- Sets approval thresholds for autonomous changes
- Reviews and approves Manager Agent proposals
- Defines self-reference boundaries — what the system can modify about itself
AI does
- Accumulates structured knowledge across every run: specs, deficiency records, test outcomes, remediation history, model performance
- Maintains the current-state system descriptor — as-built reality, continuously updated, separate from PRDs and design specs
- Classifies all knowledge by type: intent, constraint, design, reality, outcome, procedural, runtime, data, security
- A formal reasoning layer (logic engine, not LLM) governs policy applicability, contradiction handling, and escalation
- Manager Agents introduced — reactive but informed. They know production history, not just current health signals
The defining capability — Knowledge Synthesis
PoC pipeline
Build fast, minimal gates
→
Iterate
Tickets, bugs, edge cases
→
Knowledge
Specs, contracts, test suites
→
Synthesized MVP
Built from everything learned
At Stage 7, we fully embrace what earlier stages implied: code is a disposable artifact. A proof-of-concept (PoC) accumulates knowledge over weeks of iteration — every deficiency, edge case, security finding, behavioral contract. The system synthesizes this into a new spec set and produces a clean codebase with all hard-won knowledge baked in from day one. The organization’s investment is not in the code. It is in the spec history, the deficiency records, and the behavioral contracts. The code is a rendered artifact — the latest expression of accumulated knowledge. When technology changes, the code is regenerated. Nothing learned is lost.
Automated: knowledge accumulation, feature health monitoring, Knowledge Synthesis. Manual: knowledge governance, synthesis approval.
Deep dive: Stage 7 →
08
Organizational Awareness
The knowledge already exists — in wikis, runbooks, Slack threads, Terraform repos, compliance files. Stage 8 builds the machinery to find it, synthesize it, and apply it automatically.
Developer does
- Connects knowledge sources — wikis, runbooks, compliance files, infrastructure repos
- Resolves policy conflicts and exception approvals
- Reviews escalations when regulatory implications are uncertain
AI does
- Discovers, synthesizes, and applies org knowledge automatically during artifact production
- Infers applicable policies — “Toronto hospital” implies PHIPA, Ontario regs, audit logging, data residency — without the developer writing any of it
- Treats security as a parallel reasoning domain — trust boundaries, threat models, supply-chain risk — not just a validator step
- Evaluates impact with institutional context: regulatory consequences, policy compliance, cross-system effects
- Refuses to produce artifacts when compliance cannot be verified — escalates rather than guesses
- Manager Agents expand: detect regulatory changes affecting their feature, monitor for institutional drift
The defining capability — automatic policy inference
Feature brief
“Patient intake form — Toronto hospital”
→
Policy inference
→ PHIPA patient data requirements
→ Ontario healthcare regulations
→ Org audit logging standards
→ Data residency constraints
Developer wrote none of this
→
Correct spec
Institutionally correct before a line of code is written
The system also refuses
If compliance can’t be verified — policy conflict, uncertain regulatory implications, missing validation — the system escalates to a human rather than produce an artifact it can’t stand behind.
Automated: compliance application, cross-system consistency, policy enforcement. Manual: knowledge curation, policy decisions.
Deep dive: Stage 8 →
09
Proactive Origination
Manager Agents reach full maturity. They monitor four signal domains, anticipate needs, originate work from goals, and coordinate across the entire artifact dependency graph.
Developer does
- Sets goals and strategic intent
- Governs budget, risk, scope, and approval thresholds
- Approves or rejects proposals — including those originating from goals or user conversations
- Governance design is now the most consequential activity — the system self-organizes toward whatever configuration the constraints make stable
AI does
- Monitors four signal domains: operational (crashes, latency, errors), artifact integrity (stale docs, inconsistent diagrams), environmental (regulatory updates, dependency CVEs, API changes), and human (bug reports, feature requests, user conversations)
- Converts user natural-language ideas into structured proposals — “It would be nice if this exported to Excel” becomes a spec candidate
- Originates work from goals: goal → inferred specs → pipelines → artifacts — without a developer writing a single ticket
- Coordinates via the artifact dependency graph — a change in one artifact cascades to docs, SDKs, diagrams, monitoring rules, runbooks, each handled by the responsible Manager Agent
- Every proposal feeds back into Stage 7 knowledge — the cycle is continuous
The defining capability — goal-directed origination
Four signal domains
● Operational — latency spike, validator failure
● Artifact integrity — stale docs, broken tutorial
● Environmental — CVE published, regulation updated
● Human — “can the form auto-fill insurance data?”
→
Manager Agents assess
Auth Agent
Intake Agent
Reports Agent
→
Proposed work
“Patch 3 affected modules, update audit logs, regenerate docs”
✓ Approve
Reject
The complete steward workflow: signals → analysis → impact evaluation → proposal → spec → Stage 6 pipeline → artifact update → back into Stage 7 knowledge. The cycle is continuous. Every proposal requires human approval before execution.
Goal: “Improve patient onboarding”
Redesigned intake workflows
Updated patient documentation
Compliance changes
Staff training materials
Monitoring dashboards
All inferred from the goal. All coordinated across Manager Agents. All governed.
Automated: signal monitoring, impact assessment, pipeline triggering, cross-agent coordination. Manual: goal setting, budget governance, approval.
Deep dive: Stage 9 — Proactive Origination →
Why build this
Emergent properties of a mature system
Nothing learned is ever lost
Developer leaves? Knowledge stays. System rebuilt? Everything from v1 carries forward. Every pipeline run, review, and incident adds to the knowledge.
The system proposes, humans approve
Dependency has a security advisory? Stewards draft the upgrade, update docs, and flag it for review — before anyone files a ticket.
Institutional knowledge is applied, not scattered
Regulatory rules, domain conventions, org policies — applied to every artifact automatically. Not buried in wikis nobody reads.
Goals produce artifacts
“Improve patient onboarding” → workflows, documentation, compliance, training, dashboards. All inferred. All coordinated. All governed.
Code — and every other digital artifact — becomes a rendered expression of accumulated knowledge. The developer’s role transforms: from writing code, to directing pipelines, to governing an ecosystem of agents that maintain everything the organization depends on.
Continue the series
Deep dives into each stage, the full whitepaper, and comparison guides.
// Next Step
Ready to design your team’s next stage?
Whether you’re at Stage 3 or scaling an existing pipeline, we can help you design the architecture for your next level.
Complimentary 30-minute technical assessment. No commitments.