Agentic SDLC - Agents build the software. Engineers own it.

We rebuilt how we deliver around AI agents. They write, test and document most of the code; our engineers set the direction, check the evidence and make every call that needs judgement. Each stage hands the next a written record (intent, spec, plan, change, review, release), so you can always see who asked for what, what was built, and who approved it.

StylizedImage

Intent

Every engagement starts from the result, not a backlog. We write down what should change, for whom, and how we will both know it worked.

That short intent document is what everything after it is built and judged against.

Human gate: you sign off the intent before anything is built.

What this stage leaves behind

  • The result, in writing
  • How we will know it worked
  • Who it serves
  • Constraints and risks
  • What is out of scope
StylizedImage

Specify

Agents turn the intent into a draft specification and design in one pass, instead of rounds of hand-offs, applying our standards and yours as they go.

People then do what agents should not: weigh trade-offs, question the brief, and change what needs changing.

Human gate: our engineers and designers review the specification with you and approve it.

What this stage leaves behind

  • Specification
  • Interface and flow design
  • Architecture decisions
  • Your standards and ours, applied
  • An approved spec
StylizedImage

Build

Code is no longer the slow part. Engineers work from the approved plan and run several agent sessions in parallel, each on its own isolated branch.

The time that used to go into typing goes into steering, checking and deciding.

Human gate: an engineer steers every session and owns every change it produces.

What this stage leaves behind

  • A written plan first. Every piece of work begins as a plan the next step can read.
  • Engineers as orchestrators. Our people direct, correct and combine agent work rather than typing every line.
  • Shared project knowledge. Conventions and decisions are written down once and followed by every session.
  • Progress you can see. Each step is a reviewable change, not a status update.
StylizedImage

Verify

Agents get the same feedback loops an engineer would: they run the tests, use the product in a browser and check their own work against the spec before a person looks at it.

So human review is spent where it counts: does this do what we agreed, and what could it break?

Human gate: a reviewer checks the change for intent and risk, not typos.

What this stage leaves behind

  • Automated tests
  • Checks in a real browser
  • Checked against the spec
  • Security and accessibility checks
  • Review findings
StylizedImage

Release

Every change arrives with the evidence that it works and a plain list of what it leaves out. A person reads both and decides whether it ships.

Each release can be traced back through review, plan and spec to the intent you signed.

Human gate: a person approves every release.

What this stage leaves behind

  • Evidence it works
  • Checks every change must pass
  • Release approval
  • Release notes
  • A way back
StylizedImage

Improve

Once it is live, what production tells us becomes the next intent: a regression, a slow page, a request from your users.

The loop starts again, with the same written record behind it, so nothing depends on someone remembering why a decision was made.

Human gate: you agree which signals become the next piece of work.

What this stage leaves behind

  • Monitoring
  • Incidents turned into intents
  • Change history
  • Ongoing support
  • The next result

What changes

Code is no longer the slow part.

When agents can write a working change in minutes, the hard work moves to either side of it: being clear about what to build, and being sure it is right.

Where the time goesThe usual way: Typing codeAgentic: Deciding what to build, and checking that it works
The starting pointThe usual way: A backlog of ticketsAgentic: A written intent and an approved specification
Who writes the codeThe usual way: Engineers, line by lineAgentic: Agents, steered by engineers
Hand-offsThe usual way: Rounds between design, build and QAAgentic: One loop that carries its context forward
DocumentationThe usual way: Written afterwards, if at allAgentic: Written first, and read by every agent session
ReviewThe usual way: Line by line, for typosAgentic: For intent and risk, with the evidence attached
Knowing whyThe usual way: In someone’s headAgentic: In the record: intent, spec, plan, change

Who does what

Agents do the work.
People own the decisions.

You

Own the result.

  • Agree the intent and how we will know it worked
  • Approve the specification
  • Decide what ships, and what comes next

Our engineers

Own every change.

  • Turn the intent into a plan agents can follow
  • Run and steer several agent sessions at once
  • Review for intent and risk, and approve each release

Agents

Do the building.

  • Draft specs, write code, tests and docs
  • Run the tests and use the product in a browser
  • Report what they did, and what they left out

Never

  • Merge their own work
  • Decide scope
  • Work outside the limits we set

What agents are given

Good output starts with good context.

An agent knows only what it is shown. Most of our engineering effort goes into what it is shown, and into the checks it runs against.

01

The intent and the spec

What the result is, how we will know it worked, and the acceptance criteria every change is checked against.

02

Written conventions

How the project is built, written down once, so every session follows the same rules without being told again.

03

Decision records

Why the architecture is the way it is, so an agent does not undo a decision it cannot see.

04

Feedback loops

Tests, type checks and a real browser, so an agent can see its own mistakes before a person has to.

05

An isolated workspace

Each session works on its own branch, so parallel work does not collide and every change arrives on its own.

06

Repeatable procedures

Skills for the jobs we do often, such as capturing screenshots or verifying a release, done the same way every time.

Guardrails

Fast, inside limits we set.

Accountable

A named engineer owns every change an agent makes, from the intent to the release.

Bounded access

Agents can read, change and run only what the task needs.

Every change is a pull request

Nothing reaches the main branch without a reviewable change that a person merges.

Evidence attached

Changes say how they were checked: tests, browser runs, screenshots.

Limits said up front

What a change does not do is written down, not found later.

A way back

Small changes, release notes and history make any step reversible.

Built this way

We run our own products on it.

Vritta, our log pipeline, is built with this loop. The figures are from its repository at the end of September 2026.

Commits co-written with an agent
357 / 423
Issues with acceptance criteria
63 / 64
Pull requests merged by a person
67
Architecture decision records
4

The paper trail

One change,
start to finish.

One Vritta feature, followed through the loop. Agents wrote most of it. Every record says who produced it and who signed it off. Excerpts are lightly edited.

Intent

Issue #120

Show where each field of an event came from

Other consoles can mark a field as parsed, but cannot point to the rule that set it. Every attribute of an event should link to that rule, so an analyst can check it.
  • Written by the product owner

Specify

Design doc §3 · acceptance criteria

What done means, before any code

  • Every field has a provenance mark; parsed fields highlight their span in the raw record.
  • Value actions open Search with the right query.
  • Previous and next follow the search the user came from.
  • Tests for the provenance endpoint; lint, typecheck and build pass.
  • Drafted by an agent
  • Approved by an engineer

Build

Pull request #129 · 4 commits, 22 files

Small steps, each one reviewable

  • Explain a spec run: which rule set each attribute, from which fields
  • Say where each attribute of an event came from
  • Rebuild the event page around where each attribute came from
  • Document the event page and provenance
  • Written by agents
  • Steered by an engineer

Verify

Pull request #129 · Verified

Evidence, not “it works on my machine”

  • The pipeline and control-plane test suites pass, with lint and typecheck.
  • A real proxy-log event returns 16 origins, each pointing to a line of its spec.
  • A browser script opened every tab and followed “next”, with no page errors.
  • Screenshots checked in light and dark.
  • Run by the agent
  • Read by an engineer

Release

Merged · closes #120

What it does not do, said up front

The pull request names what it leaves out, so nobody finds out later:

“Map this” opens the spec editor, but does not pre-fill a mapping yet. That comes with the spec workbench (#121).
  • Approved and merged by a person

Improve

Issue #121

The gap becomes the next intent

Spec workbench: live diff, testers and assertions over real records.
  • Prioritised by the product owner

A great product starts with a conversation.

Bring your idea, your challenge, or your curiosity. We'll bring the team to make it happen.