Technology & Automation

Specification-first delivery, where agents do the predictable work and people own the decisions that are expensive to reverse.

What this is

The bottleneck moved. It did not disappear.

We build software with a specification-driven workflow: the behaviour, the interfaces and the acceptance criteria are written down before implementation begins, and coding agents work against that specification rather than against a conversation. Architecture, review and release stay with the engineers accountable for them.

Generating code stopped being the slow part. What still takes judgement is deciding what should exist, how it should be structured, and what must never break — and a model asked to guess at those will produce something that looks finished and is not.

01

A specification is a testable artefact

Written behaviour and acceptance criteria give both the agent and the reviewer the same definition of done.

02

Review is the control, not the prompt

Every change arrives as a diff a person reads. Nothing merges because it was generated confidently.

03

Speed is worth nothing without reversibility

Tests, types and migrations are written first where a mistake would be costly to undo later.

Use cases

When businesses come to us for this.

Rebuilding a system nobody remembers the rules of

Getting from a signed-off brief to a working prototype

Adding test coverage to code that shipped without it

Large refactors that keep being deferred as too risky

Integrations where the contract matters more than the code

What this is

What we actually do here.

Specification and acceptance-criteria authoring
Architecture decision records
Agent-assisted implementation against a spec
Automated test generation and coverage
Typed interface and API contract design
Refactoring and migration planning
Code review workflow and merge policy
Continuous integration and release automation

Technology

Assistants

  • Claude
  • Codex
  • Cursor
  • GitHub Copilot

Orchestration

  • Make
  • n8n
  • GitHub Actions
  • Model Context Protocol

Verification

  • TypeScript
  • Vitest
  • Playwright
  • ESLint

How it runs

A working rhythm, not a process deck.

01

Specify

Behaviour, interfaces and acceptance criteria written down before anything is built.

02

Decide

Architecture and trade-offs recorded as decisions, so later changes know what they are changing.

03

Implement

Agents work through the specification; engineers review every diff before it merges.

04

Verify

Tests, types and CI gate the release rather than a demonstration that it worked once.

What it should achieve

Outcomes worth measuring.

A written specification the team can hold work against

Prototypes early enough to change direction cheaply

Test coverage on the paths that would be expensive to break

Architecture decisions recorded rather than remembered

Questions

The things people ask.

It writes some of it, against a specification, and an engineer reviews every change before it merges. Architecture, review and release decisions stay with people — those are the ones that are expensive to reverse.