Skip to main content
idego

Software delivery at Idego

AI-Native Software Development Lifecycle

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.

Translucent cyan glass loops connected into a continuous sculptural ribbon

What is an AI-Native SDLC?

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.

AI-Native vs AI-Assisted development

Assistants can write tests and review code. The difference is whether the team shares a delivery process that enforces those steps.

How shared process controls differ in AI-assisted and AI-native delivery
AreaAI-assisted developmentAI-native development
Where the process livesMay depend on individual habits and prompts.Versioned standards, specifications and skills live in the repository.
Specification before codeA 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 developmentAssistants can write tests, but test-first work may not be enforced.A failing test precedes each behavior, with a required edge-case matrix.
Automated reviewReview may depend on who asks and which checks they choose.Four reviewers check security, bugs, standards and specs, and maintainability.
Severity and deferralsFindings 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 budgetsRetries may have no shared limit or escalation rule.Two-strikes budgets stop failed loops and produce a gap report for a human.
Human approval pointsApprovals may depend on personal practice.People approve scope, select issues, confirm commits and merge to main.
Agent portabilityInstructions may differ between tools.The same skills run in Cursor, Claude Code and Codex, with parity checked by a gate.
Traceability after mergeLinks between requests, tests and decisions may be incomplete.Issues link to specs, tests, PRs and archived specs that describe the delivered system.

How Idego implements an AI-Native SDLC

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.

  1. Scope

    OutputIssues and milestone

    Agree on a clear, testable scope before delivery starts.

    Required check
    A person approves the issue list and its scope before delivery starts.
    Process details

    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.

    Agent role
    Inspect the codebase, ask focused questions, draft and publish issues.
    Human role
    Answer scope questions and approve the issue list.
  2. Start

    OutputBranch, draft PR and spec

    Turn the selected issue into an implementation-ready specification.

    Required check
    The issue must be well scoped and the specification apply-ready, unless a documented docs/process-only check permits spec:skip.
    Process details

    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.

    Agent role
    Create the branch, specification and draft PR, and apply labels.
    Human role
    Choose the base branch and resolve scope questions.
  3. Implement

    OutputCode, tests and check results

    Build one behavior at a time, with tests and required checks.

    Required check
    All preflight and postflight checks must pass, and the PR checklist must match the completed work.
    Process details

    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.

    Agent role
    Write tests and code, run checks and report results.
    Human role
    Resolve blockers reported by agents.
  4. Finish

    OutputReview report and test plan

    Review the change in parallel and resolve blocking findings.

    Required check
    The report must say DONE, with no unresolved Critical or High findings and an accurate checklist and test plan.
    Process details

    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.

    Agent role
    Review, fix findings, document deferrals and report DONE or NOT DONE.
    Human role
    Read the report and decide how to resolve escalations.
  5. Archive

    OutputUpdated living specifications

    Update the living specifications to match the verified code.

    Required check
    The living specifications must reflect the verified change before the work moves to merge.
    Process details

    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.

    Agent role
    Sync and commit the specification updates under those approval rules.
    Human role
    Retain commit confirmation authority under the project approval rules.
  6. Merge

    OutputHuman-approved merge

    A person approves and merges the completed change.

    Required check
    A human must approve and perform the merge to main after all required checks pass.
    Process details

    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.

    Agent role
    Provide the verified work and report; never merge to main.
    Human role
    Approve and merge to main.

Where AI agents fit into the lifecycle

Agents carry out delivery work and report evidence. People set direction and keep control of the irreversible decisions.

People decide

  • Approve scope and select issues.
  • Choose the base branch and resolve unclear requirements.
  • Confirm commits under the project approval rules.
  • Resolve blockers and escalated findings.
  • Review the final report and merge to main.

Agents execute

  • Explore the repository and prepare issues, specs and draft PRs.
  • Delegate task groups, write tests and implement code.
  • Run quality checks and the four reviews.
  • Fix findings, record deferrals and report results.
  • Archive verified specs and aggregate milestone work on an integration branch.

Specification-Driven Development with agents

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.

  • Proposal: agree on the problem, scope and expected outcome.
  • Design: record the approach and key decisions.
  • Delta specs: describe changed requirements with testable scenarios.
  • Tasks: break the approved change into implementation steps.
  • Implement: use test-first work to satisfy the scenarios.
  • Verify: check the code, tests and each specified scenario.
  • Archive: merge the verified requirements into the living specs.

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.

Quality gates and automated review

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.

Reviewers

  • Security

    Checks security risks and the project security guardrails.

  • Bugs

    Checks correctness, failure paths and edge cases.

  • Standards and specification

    Checks repository rules and every specified scenario.

  • Maintainability

    Challenges unnecessary complexity and code that is hard to change.

Severity

Critical
Must be fixed before the work can be DONE.
High
Must be fixed before the work can be DONE.
Medium
May be deferred only with written rationale in the PR.
Low
May be deferred only with written rationale in the PR.

Enterprise adoption of AI coding agents

The repository contains the rules and evidence your team needs to govern agent work. These controls make the process reviewable and repeatable.

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.

Enforced working rules

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.

Living specs and an audit trail

The repository connects issues, specifications, tests, PRs and archived requirements. Decision records and a domain glossary preserve the reasons behind the work.

Loop limits and telemetry

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.

Portable skills

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.

Human approvals

People approve scope, select issues, confirm commits and merge to main. Agents report blockers and escalations so a person can decide what happens next.

Who is AI-Native SDLC for?

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.

  • Teams commissioning software

    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.

  • Teams adopting coding agents

    Give agents a shared process with enforced tests, reviews and human approvals, instead of relying on each developer to assemble the workflow.

  • Your team after handover

    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.

Questions about AI-Native SDLC

What is an AI-native SDLC?

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.

How is it different from using a coding assistant?

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.

Does the AI merge code on its own?

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.

What happens when the agent gets stuck?

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.

Which AI tools and models do you use?

The process is model-agnostic. The same skills run in Cursor, Claude Code and Codex, and a pipeline gate checks skill parity across them.

How do you keep specs and code in sync?

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.

Can our team run this after handover?

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.

How do you handle security review?

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.

How can a company implement AI across the software development lifecycle?

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.

How do you measure productivity gains from AI coding tools?

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.

What is specification-driven development?

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.

Is an AI-native SDLC suitable for enterprise software development?

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.

Build a process your team can keep

Talk to us about your delivery needs, approval rules and team handover. We can scope the work and show where agents fit.

Talk to Idego