AI software engineering

Building software with an AI delivery pipeline.

From product requirements to release: specifications, tests, independent review and clear decisions at each gate.

Kerry Panchoo · October 2026

What it is

An autonomous software organisation

A directed pipeline coordinates many specialist AI agents through structured, deterministic flow. No single agent controls or directs the pipeline.

Each phase uses bounded agents with defined roles, tools, contracts and access.
Agents perform only assigned work and enforce the rules within their remit.
Explicit gates and routing rules advance, return or stop work based on evidence.
Some routing and decision processes use LLM judgement within defined contracts; system rules govern the resulting action.
Deterministic gates check entry to each phase and the handoff from reviewer to inquisitor.

Why it works

Intent stays visible. Requirements connect to specifications, tests, implementation and acceptance.
Proof precedes approval. Tests must detect missing behavior, and results must belong to the current build.
Work is challenged independently. Reviewers check quality; inquisitors challenge the findings and evidence.
Changes have an owned route. Gaps return to specification, tests or code. New ideas become separate tickets.
Completion includes the whole system. Required child work, human acceptance and integration proof precede release.

These controls reduce silent omissions, scope drift and repeated repair. Their value depends on the quality of the requirements, tests and independent examination.

Build profile

Build profile: choose the pipeline

Sets the phases, gates, scoring rubric and code-control strictness for the build.
Exploratory work may use Requirements → Coding → Testing.
Proof of Concept (PoC) may use Requirements → Tests → Coding → IMPL.
More rigorous builds require broader phases, stricter gates and deeper proof.

Explore Sarolta’s destination build types →

Model profile

Model profile: model routing

Model routing lets us combine models from multiple providers for specific tasks—for example, Codex models for reviewers and inquisitors, and Opus, Sonnet or Sol for coding. Each role has its own model and reasoning effort.

Assign a provider, model and reasoning effort to each station or gate.
Route generation, review, inquisitor, remediation and decision roles separately.
Define tools, fallback and budget; record the actual model and effort used.
Model routing changes who performs the work; the build profile still sets its obligations.

Separate responsibilities

Who builds, reviews and decides

Builder

Creates the owned artifact within its approved scope.

Reviewer

Checks the phase rubric and identifies findings for repair and re-review.

Inquisitor

Independently challenges the artifact and the evidence behind approval.

Gate controller

Checks policy, scope, freshness, and prerequisites before advancement.

Human participation follows a clear choice: ARA is enabled by default with an opt-out. In every other phase, human-in-the-loop participation is optional and opt-in. These choices do not remove the required engineering gates.

The delivery flow

From requirements to maintenance

Requirements

Requirements analysis, remediation and review

Agree the product. Resolve gaps. Review the requirements.

Define the product

Users, outcomes, core scope and acceptance criteria.
Mockups, journeys, UI states and responsive behaviour.
Build/model profiles, security contracts, deployment and test obligations.

Check the real system

Validate files, dependencies, coverage and architecture.
Check risks and contradictions against code, tests and history.

Resolve gaps

Use evidence, recorded amendments or supported recommendations.
Unresolved ambiguity blocks progress; extras become separate tickets.
Human input is optional and opt-in.

Generate missing requirements

Repair one draft or compare bounded candidates.
Combine compatible contributions; preserve provenance.
Poor drafts trigger PRD enrichment and regeneration.

Mockups, behaviour, security and proof—defined together.

Review and hand off

PASS, RECOMMEND or BLOCK after independent review.
Recheck changes; advance only accepted, current requirements.

Phase gates

Review Gate: Check clarity, completeness, consistency and acceptance criteria; remediate gaps and re-review.
Inquisitor Gate: Independently challenge requirements, assumptions and review evidence. Unresolved blockers prevent handoff.

Next: the build profile sets the route. A Proof of Concept (PoC) may go straight to test writing or development. More rigorous builds proceed to specification.

Specification

Specification: define the behaviour contract

Turn accepted requirements into a testable behaviour contract.

Write the behaviour contract

Use accepted requirements, analysis and existing system patterns.
Define behaviours, interfaces, constraints, failure cases and numbered acceptance criteria.
Link requirements to tests, proof and permitted file changes.

Develop the draft

Repair one draft or compare bounded candidates against the same requirements.
Combine compatible contributions with provenance; retain success and rejection scenarios.

Generation strategies

Standard · Single generation

Generate one draft; review and repair gaps.

Evolutionary selection strategies

Sequential Multi-Candidate: generate and assess candidates in sequence.
Parallel Multi-Candidate: generate independent candidates concurrently; compare against the same requirements.

Select a coherent draft; retain contribution provenance. Selection still requires review, inquisitor checks and gate approval.

Keep the product intent connected to every obligation.

Review and challenge

Reviewer: check clarity, completeness, feasibility and testability.
Inquisitor: challenge omissions, contradictions and hidden prerequisites independently.
Remediate gaps; repeat affected gates when requirements change.

Gate · Accept the specification

Approve a reviewed, traceable contract with complete obligations.
Return blocking contradictions to SPEC.
Proceed to planning; retain scope and proof.

Phase gates

Pre-gate: Check accepted requirements, build profile and contract inputs.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Challenge completeness, consistency, traceability and testability. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

Planning

Turn the contract into owned work

Split the work. Preserve obligations. Schedule dependencies.

Define the tasks

Split by behaviour, interfaces, files and resource boundaries.
Give each child scope, acceptance criteria, tests, an owner and inherited contracts.

Spec-file sizing and task decomposition

Score functional requirements (FRs) by severity and complexity to size each spec.
Balance critical, major, medium and minor FRs, their interactions and required proof.
Match workload to the coding model’s reasoning, context, tool use and proven performance.
Consider UI complexity, security, dependencies, shared files and integration risk.
Create independently verifiable child specs; retain criteria, dependencies, ownership and parent links.

Check the family

Map every parent obligation to child work.
Resolve conflicting criteria, shared files and hidden or circular dependencies.

Development strategy

Third-party library selection

Compare library fit, maintenance, licence, security and compatibility.
Record versions, trade-offs and dependency obligations.

Third-party tools

Choose tools for building, testing and delivery.
Define access, data boundaries, costs and reproducible setup.

Implementation strategies

Standard sequential — complete tasks in dependency order.
Rolling waves — verify each batch; use findings to refine the next.
Vertical slices — deliver small, end-to-end user behaviours.
Contract-first — agree interfaces, then implement against them.
Parallel agents — isolate independent tasks with clear file ownership.
Test-driven increments — implement one tested behaviour at a time.
Scaffold then fill — build a runnable skeleton, then complete its parts.
Incremental replacement — replace existing components one at a time.

Schedule safely

Verify prerequisites before dependent builds.
Run independent tasks in isolated worktrees; coordinate shared resources.

Plan review and remediation

Review coverage, task boundaries, dependencies, feasibility and verification.
Repair plan defects and review again; unresolved findings block handoff.
Planning can expose missing requirements or spec decisions. Return gaps to their owning phase; update and re-review affected work.

Planning exit

Retain the accepted plan, child specs, coverage map and execution order.
Advance only after plan fixes and upstream gaps are resolved.

Phase gates

Pre-gate: Check the accepted specification, workload scores and model capabilities.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Challenge coverage, decomposition, ownership, dependencies and feasibility. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

RED · Tests

Tests before implementation

Define the proof, then show missing behaviour fails. Building and validating this coverage makes RED the longest phase of the automated pipeline.

Map each FR to its tests

The test matrix derives each FR’s tests from requirements and the build profile.
Map applicable behaviours, scenarios and failure modes to assertions, test files and execution commands; record justified exclusions.
Depending on testing requirements, an FR can result in 9–15+ tests. This is an indicative range, not a fixed count or quota.

Specify and build tests

Create a reviewed Test Spec for each functional requirement.
Cover success, rejection, boundaries, fixtures and assertions.
Build executable tests after Test-Spec review and independent examination.
Test building can expose specification and planning gaps; return them to the owning phase for remediation.

Test generation strategies

Standard: generate one test suite; review and repair.
Sequential Multi-Candidate: generate a test, assess quality and requirement fit, then remediate or regenerate; update and re-review the Test Spec when needed.
Parallel Multi-Candidate: generate independent suites concurrently; compare against the same obligations.

Score and select

Solution score: assess coverage, assertion strength, correctness and reliability.
Remediation score: estimate the difficulty and work needed to fix the suite; lower is easier.
Compare quality with repair effort. Regenerate a poor suite when a fresh solution is easier than debugging it.
Selection still requires independent review and fail-first proof.

Review the proof

Apply standard reviewer and independent inquisitor checks to test specs and generated suites.
Could incorrect code still pass? Check mocks, assertions and determinism.
Re-review remediated specs and plans through their reviewer and inquisitor gates; update affected tests.

Prove RED

Capture profile-required fail-first evidence on the identified pre-build revision.
Failures must expose missing behaviour, not broken fixtures or syntax.

Gate · Accept tests

Require complete coverage across all requirement suites.
Route test defects to RED, specification gaps to SPEC and planning gaps to Planning. Unresolved findings block advancement.

Phase gates

Pre-gate: Check accepted specifications, the plan and requirement-driven test matrix.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Challenge test coverage, assertions, reliability and fail-first proof. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

GREEN · Build

Build and verify the code

Implement accepted scope. Review it. Prove the current result.

GREEN pre-gate · Admit ready work

Deterministically check dependencies, accepted tests and RED evidence, specs, owned files and commands.
Missing prerequisites block implementation.

Build within the contract

Use minimal-pass, contract-preserving or scoped-remediation strategy.
Edit authorised production files; tests remain RED-owned.

Code generation strategies

Standard: generate one implementation; assess and repair.
Sequential Multi-Candidate: assess quality and contract fit, then remediate or regenerate; re-review spec changes.
Parallel Multi-Candidate: generate isolated implementations against the same contract; compare candidates.
Use solution and remediation scores to choose repair or regeneration. Selection still requires review, tests and inquisitor gates.

Handle discovered gaps

GREEN often exposes feature/specification and test gaps. Record evidence and choose a route.
Immediate: fix an item directly affecting the current implementation; repeat affected reviews and tests.
Late Discovery: close a gap needed to fulfil the task’s obligations. Child tickets follow the full process and block parent completion.
Follow-up: record bugs, deficiencies or necessary features outside the task’s scope as separate tickets for later work.

Review and execute

The gate checks code quality, interfaces and applicable security/performance.
Run every required suite; record revision, commands, environment and results.

Gate · Verify evidence

Execution inquisitor checks current runs, active assertions and fixtures.
Next: Late Discovery closes required gaps before IMPL reviews the completed work.
Route code defects to GREEN, test gaps to RED and contract gaps to SPEC.
Refresh affected proof; bound retries and recover from repeated stalls.

Phase gates

Pre-gate: Check dependencies, accepted tests and current RED proof before coding.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Challenge implementation quality, contract alignment and execution evidence. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

Late discovery

Find gaps. Complete the corrections.

Required corrections become child tickets through the same full process.

Examine the whole result

Compare spec, code and tests for missed paths, mismatches and complexity.
Record evidence, affected obligation, owner and source of each gap.

Create owned child work

Give each required correction scope, acceptance criteria and file ownership.
Inherit parent constraints and build profile; keep new features separate.

Complete the full process

Each child follows requirements, SPEC, RED, GREEN, Late Discovery, IMPL, ARA and integration as applicable.
Further required gaps create further children until completion.

Gate · Reconnect proof

Audit child completion and dependencies; rerun affected parent checks.
Block the parent until required children and connected proof are complete.
Record an explicit no-gap result when none are found.

Phase gates

Pre-gate: Check the current implementation, tests and connected requirement evidence.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Challenge gap findings, required child completion and refreshed parent proof. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

IMPL · Implementation review

Review the implementation as a whole

Review alignment

Check that every functional and nonfunctional requirement is implemented and meaningfully tested.
Review architecture, security, performance and code quality against the accepted contract.

Remediate and verify

Return deficiencies for further development or upstream correction; preserve passing tests and rerun affected proof.
The inquisitor independently audits requirements, tests, implementation and evidence.
Repeat review after remediation. Advance to ARA with resolved findings and current proof.

Phase gates

Pre-gate: Check completed GREEN work, required discovery corrections and current proof.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Audit requirement alignment, code, tests and remediation evidence. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

ARA

Alignment, Refinement & Acceptance

Focused human participation is on by default, with an explicit opt-out.

Review the outcome

Exercise real workflows against PRD outcomes and acceptance criteria.
Check usefulness, usability and actual UI behaviour—not screenshots alone.

Gate · Check fidelity

Expose omissions, additions and changed assumptions against agreed intent.
Keep differences visible; do not rewrite intent to fit the result.

Decide and record

Choose acceptance, refinement or a change of direction.
Record evidence, tradeoffs, conditions and any explicit opt-out.
Other phases offer optional, opt-in human participation.

Refine through the pipeline

Approved behaviour changes become a delta specification.
Repeat affected SPEC, RED, GREEN and reviews; refresh invalidated proof.
Recheck the outcome; keep future opportunities separate and bound retries.

Phase gates

Pre-gate: Check the accepted implementation review, resolved findings and current proof.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Challenge outcome fidelity, acceptance evidence and recorded decisions, including any human opt-out. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

Integration & release

Integration and release

Verify the combined system on the revision being released.

Gate · Authorise integration

Implementation inquisitor audits the complete candidate and connected evidence.
Require completed children, acceptance, current proof and visible deferrals.
Outstanding blocking work prevents integration.

Combine and recheck

Merge approved work into the intended baseline; check shared interfaces.
Conflict resolution changes code: refresh affected tests and proof.

Gate · Accept the system

Integration inquisitor challenges regression and combined-system evidence.
Verify exposed contracts in the required environment; route failures to owned repair.

Release the proven artifact

Match source, build and runtime configuration to approved evidence.
Authorise deployment, verify target operation and retain lineage and rollback.
A merge alone does not prove deployment.

Phase gates

Pre-gate: Check accepted work, ARA decisions, dependencies and release inputs.
Review Gate: Assess the work against the phase rubric; check review completion, blocking findings and current evidence before independent audit.
Inquisitor Gate: Challenge combined-system behaviour, regressions and deployment evidence. Unresolved blockers prevent advancement; repairs repeat affected reviews and gates.

Maintenance

Maintain the released system

Turn operating evidence into scoped, reviewed changes.

Observe and reproduce

Use runtime checks, incidents, user reports and dependency changes.
Record release identity, environment, symptoms and reproducible evidence.

Route the correction

Distinguish code defects, test gaps, changed requirements and environment failures.
Create owned tickets with scope and acceptance criteria.

Repeat the discipline

Apply the appropriate requirements, SPEC, RED, GREEN, review and integration route.
Verify affected behaviour and regressions on the next release.

Preserve release control

Keep improvements separate from urgent repairs.
Carry forward decisions, profile requirements and recovery records.
Changed scope or risk requires a recorded decision and refreshed gates.

How advancement works

What happens at a gate

Every phase has a deterministic entry gate. A further deterministic gate runs between its reviewer and inquisitor checks.
Check the prerequisites first: accepted inputs, owned files, completed dependencies and evidence tied to the current revision.
The reviewer assesses the artifact against its phase rubric. Findings identify the location, severity and correction needed.
The inquisitor independently challenges both the artifact and the reviewer’s conclusion. A passing review does not automatically mean permission to advance.
The gate combines those assessments with deterministic policy checks. Missing proof, stale results or unauthorized changes prevent advancement even when the quality score is high.
Blocking findings return to the phase that owns the repair. Repaired artifacts are reviewed again; affected downstream proof is refreshed.
ARA provides focused human acceptance by default, with an explicit opt-out. Human involvement elsewhere is optional and opt-in; record decisions and preserve the required proof.

Product Requirements Document · PRD

Start with a defined product

Define the problem, users, outcomes, core scope, constraints, and acceptance expectations.
Analyze contradictions and missing decisions. Human review of the direction can be opted into.
Record useful extras and process improvements as separate work before they become scope creep.

Drift, deferral & recovery

Handling defects, new scope and deferrals

Block unmet criteria in the active gate rubric. Findings outside the declared rubric remain visible as audit notes or separate follow-up tickets; they cannot silently expand the accepted build.
A deferred ticket keeps the originating finding, evidence, owner, and acceptance conditions.
Keep new features separate. Changes to accepted scope require an explicit decision.
Decision Support advises on routing; Process Recovery diagnoses execution failures. Neither waives proof.
Bound retries and detect stalls. Try again only with changed facts or a changed approach.
Retain logs and artifacts across the pipeline so an overseer can inspect why a task advanced, stalled, changed scope or returned for repair.

Route by the layer that owns the correction
Missing or ambiguous behavior	SPEC
Missing test or faulty assertion	RED
Implementation defect	GREEN
Environment or transport failure	Recovery
Useful additional feature	Separate ticket
Accepted product refinement	Delta spec

Preserve the connected record: requirements, decisions, tickets, tests, reviews, commits, runtime proof, acceptance, and release.

Build what matters next

Bring the product.
Make the delivery dependable.

Sarolta helps teams turn product intent into defined, tested, independently reviewed software.