Standards as code
Readiness, completion, testing, security, review, coding and orchestration standards share one canonical index. A unit test fails CI if a standard is added or removed without an index update.
Software delivery at Idego
Six stages. Shared checks. Human approval.
Agents implement, test and review. People approve scope and merge to main. The specifications, checks and process live in your project repository.

An AI-native SDLC is a software delivery process designed for agents to execute and people to govern. Specifications, tests, review rules and approvals are versioned in the project repository.
AI assistance helps people with individual tasks. An AI-native process connects those tasks through shared, enforced checks, with a clear record of what changed, what passed and who approved it.
Assistants can write tests and review code. The difference is whether the team shares a delivery process that enforces those steps.
| Area | AI-assisted development | AI-native development |
|---|---|---|
| Where the process lives | May depend on individual habits and prompts. | Versioned standards, specifications and skills live in the repository. |
| Specification before code | A specification may be optional or kept outside the workflow. | An apply-ready specification is required before code, with a documented docs/process-only exception. |
| Test-first development | Assistants can write tests, but test-first work may not be enforced. | A failing test precedes each behavior, with a required edge-case matrix. |
| Automated review | Review may depend on who asks and which checks they choose. | Four reviewers check security, bugs, standards and specs, and maintainability. |
| Severity and deferrals | Findings may lack shared severity rules or a deferral record. | Critical and High must be fixed. Medium and Low deferrals need written rationale in the PR. |
| Loop budgets | Retries may have no shared limit or escalation rule. | Two-strikes budgets stop failed loops and produce a gap report for a human. |
| Human approval points | Approvals may depend on personal practice. | People approve scope, select issues, confirm commits and merge to main. |
| Agent portability | Instructions may differ between tools. | The same skills run in Cursor, Claude Code and Codex, with parity checked by a gate. |
| Traceability after merge | Links between requests, tests and decisions may be incomplete. | Issues link to specs, tests, PRs and archived specs that describe the delivered system. |
In plain terms: every change goes through six stages, and it cannot move to the next stage until its checks pass. Each stage ends with a blocking check. Single-issue delivery (/deliver-issue) runs Start through Archive. Milestone delivery (/deliver-milestone) runs issues in parallel batches, each in an isolated worktree, combines their PRs on an integration branch and opens a draft umbrella PR to main. A human performs the final merge to main.
OutputIssues and milestone
Agree on a clear, testable scope before delivery starts.
A focused interview and repository exploration turn an idea into end-to-end feature slices, each sized for one PR, with testable acceptance criteria and dependencies. For three or more issues, a milestone records execution order; a read-only audit can also produce a prioritized, labeled improvement milestone.
OutputBranch, draft PR and spec
Turn the selected issue into an implementation-ready specification.
One issue gets a gh-<n> branch and a draft PR with Closes #<n>; unclear scope is clarified and rewritten, with decision records and glossary entries. The agent prepares an OpenSpec proposal, design, scenarios and tasks before code, or records a docs/process-only applicability decision as spec:skip.
OutputCode, tests and check results
Build one behavior at a time, with tests and required checks.
Preflight checks cover readiness, spec validity, architecture boundaries, security and documentation before one subagent per task group follows test-first development: failing test, minimal code, refactor. The edge-case matrix covers empty, invalid, boundary, precedence, inheritance, isolation and asymmetry cases; postflight runs lint, type checks, unit and integration tests, a production build and every spec scenario.
OutputReview report and test plan
Review the change in parallel and resolve blocking findings.
Full verification and four parallel reviewers produce findings with severity levels; Critical and High must be fixed, while Medium and Low deferrals need written rationale in the PR. Review stops after at most two waves, with unresolved Critical or High findings reported as NOT DONE and escalated to a person.
OutputUpdated living specifications
Update the living specifications to match the verified code.
For changes that require a specification, the agent merges the change specs into the living specification library. It commits the updated specs so they describe the system as built.
OutputHuman-approved merge
A person approves and merges the completed change.
A human reviews the completed work and merges to main. Aggregating issue PRs into an integration branch is a separate step and does not authorize an agent to merge to main.
Agents carry out delivery work and report evidence. People set direction and keep control of the irreversible decisions.
Every non-trivial change starts with a specification that is ready to implement before code begins. Its scenarios define what the tests and final verification must prove.
OpenSpec keeps the change artifacts in the repository. Decision records explain choices, the glossary defines domain terms, and archived specs describe the current system.
A documented applicability check may permit spec:skip for docs/process-only work. It does not exempt code changes or allow agents to skip required checks.
Definition of Ready checks whether work can start. Definition of Done checks whether it is complete. Test-first development, the edge-case matrix and passing checks are required before delivery can proceed.
Checks security risks and the project security guardrails.
Checks correctness, failure paths and edge cases.
Checks repository rules and every specified scenario.
Challenges unnecessary complexity and code that is hard to change.
The repository contains the rules and evidence your team needs to govern agent work. These controls make the process reviewable and repeatable.
Readiness, completion, testing, security, review, coding and orchestration standards share one canonical index. A unit test fails CI if a standard is added or removed without an index update.
Test-first work and the edge-case matrix are mandatory. Agents reuse UI primitives from the design-system registry; hand-rolled UI primitives are not permitted. PR labels and Conventional Commits are required; CI enforces gh-<n> branch names.
The repository connects issues, specifications, tests, PRs and archived requirements. Decision records and a domain glossary preserve the reasons behind the work.
Review waves, failing-test retries and verification reruns have a two-strikes budget. A second failure stops the loop with BLOCKED and a gap report. Each phase report includes a Loops: line with waves, attempts, dispatches and deferrals.
The same skills run in Cursor, Claude Code and Codex. A skill-parity gate checks that their behavior stays aligned; the process does not depend on a particular model.
People approve scope, select issues, confirm commits and merge to main. Agents report blockers and escalations so a person can decide what happens next.
We work with engineering teams in the UK and across Europe. For organizations that want agent-led delivery with clear control, and a process their own team can keep running.
Get a project repository with specifications, delivery rules and agent skills from day one. Review reports show what passed and what still needs a decision.
Give agents a shared process with enforced tests, reviews and human approvals, instead of relying on each developer to assemble the workflow.
Keep the same pipeline in your repository. Follow each issue through its specification, tests, PR and archived requirements, then use that process for the next change.
It is a software delivery process that agents execute and people govern. The repository holds the specifications, standards, skills and quality checks, along with reports and approval records.
A coding assistant can help write, test and review code. AI-native delivery makes those activities part of a shared, enforced process with specs before code, review rules, retry limits and human approvals.
Agents never merge to main. For a milestone, they can aggregate issue PRs into an integration branch and open a draft umbrella PR. A human approves and performs the final merge to main.
Automated loops stop after a second failure with BLOCKED and a gap report for a person to resolve. Reviews allow at most two waves; unresolved Critical or High findings then mean NOT DONE and human escalation.
The process is model-agnostic. The same skills run in Cursor, Claude Code and Codex, and a pipeline gate checks skill parity across them.
An apply-ready OpenSpec change precedes code, and verification checks every scenario. After verification, Archive merges the change specs into the living requirements library. Only a documented docs/process-only applicability check permits spec:skip.
Yes. The process, standards, specifications and agent skills stay in the project repository. Your team can run the same pipeline and trace decisions and results for each delivered change.
A security baseline is a preflight requirement. A dedicated security reviewer joins the bug, standards and spec, and maintainability reviewers. Critical and High findings must be fixed; Medium and Low deferrals need written rationale in the PR.
Start with the process, not the tool. Put specifications, tests and review rules in the repository, so every agent and engineer works to the same checks. Give agents clear limits, keep people approving scope and merges, and pilot the process on a real project. Once it works, hand it over to the team that will run it every day.
Measure delivery outcomes, not impressions. Record a baseline of lead time for changes, deployment frequency, change failure rate and review time, then compare after adoption. Self-reports can mislead: in a 2025 METR study, experienced developers were 19% slower with AI tools on the tasks studied, yet believed they had been 20% faster.
Specification-driven development means agreeing what a change must do before any code is written. A short specification records the problem, scope, design decisions and the scenarios that tests must prove. With AI coding agents, the specification is the instruction the agent works from and the contract that tests and reviews check. At Idego, specifications live in the repository with OpenSpec.
Yes, when governance is built into the process rather than added later. Enterprises need standards defined as code, enforced working rules, specifications that stay in sync with the system and an audit trail of what changed and who approved it. Agents never merge to main on their own, so people keep control of every release.
Talk to us about your delivery needs, approval rules and team handover. We can scope the work and show where agents fit.