How AR Labs engineers software with AI coding agents

AR Labs builds software with AI coding agents, AI agents that write code such as Claude Code or Codex, and treats that as agentic engineering rather than conversation: we design the harness, context, tools, gates, checks and cost around the agents. A person decides what to build and approves the design; agents write the specifications, the tests and the code; scripts check every step for proof; a model from a different vendor reviews the result; and a person merges it. This page is the map for a newcomer: the approach in one place, and where each practice is described in full. Start here, then read the coding pipeline, which follows one change from idea to merge.

The problem the approach answers

An agent asked to "just build it" fills every gap with a plausible guess. It writes code, then writes tests that confirm whatever the code does, then reports success. The tests pass because they share the code's misunderstanding. The longer the session, the worse this gets: the agent's context fills up, early decisions are summarised away, and steps it was told to take quietly fall out.

Our answer starts from a point Matt Pocock makes in his public workshop on a workflow for AI coding: the software engineering fundamentals that work with human teams also work well with AI. We read those fundamentals as small tasks, clear designs, fast feedback and review by someone other than the author. What changes is that an agent will not apply them on its own, so the environment has to.

The approach in five commitments

1. Design before code. Every system has one living design document, decisions recorded one per page, and diagrams at two zoom levels. Larger work starts with a design interview in which the agent questions the person until every decision is settled. See software architecture.
2. A written spec for every task. A campaign plan sets the goal and design for a large piece of work; each task then gets its own spec, written against the code as it stands that day. See spec-driven development.
3. Test-first, with proof. Agents implement red-green-refactor from acceptance scenarios, and every criterion must be proved by a committed test or a captured artefact. See test-driven development and evidence of completion.
4. Independent review and a human merge. A second model, in a fresh context, reviews the diff on four axes; a person reads it and merges. See the code review gate.
5. Rules that matter are enforced by scripts. When a written rule is broken, it becomes a hook (a script run automatically around an agent's action that can block it) or a check in the harness: everything around the model that shapes what an agent does, the agent program, its instructions, skills, hooks, tools and checks. See harness engineering.

How the practices fit together

flowchart TD
  A["Idea"] --> D["Design: interview, DESIGN.md, ADRs, C4"]
  D --> P["Campaign plan (PRP)"]
  P --> S["Vertical slices in a task graph"]
  S --> T["Per-task spec"]
  T --> I["Test-first build in a worktree"]
  I --> E["Evidence for each criterion"]
  E --> R["Cross-model review"]
  R --> M["Person merges"]
  H["Harness: rules, hooks, floors"] -.-> I
  G["Human gates"] -.-> D
  G -.-> M

Stage	What happens	Practice page
Route	Decide whether the work is one task or a campaign of many	The coding pipeline
Design	Interview, design record, decision records, diagrams, design rules for agent code	Software architecture, architecture documentation, design principles
Plan	Campaign plan, then thin end-to-end slices with dependencies	Task graphs with Beads, graph engineering, To Issues
Specify	A spec per task, grounded in a named commit	Spec-driven development
Build	One branch and checkout per task, test-first, search before writing, walkthrough as you go	Worktree isolation, test-driven development, reuse before create, walkthroughs
Verify	Committed proof, cross-model review, a person at the merge	Evidence, review gate, human gates
Run	Attended or unattended, with typed stops and a record	Unattended agent runs, multi-agent orchestration, act or ask
Sustain	Harness, documents, writing, routing, and keeping people able to read the code	Agentic engineering, harness engineering, agent harness anatomy, progressive disclosure, writing rules, model routing, understanding agent-written code
Deliver for clients	Seven phases from first conversation to a system in production, with an evidence gate between them	Client delivery framework

Who decides what

The division of labour is the core of the method. A person owns the outcome, the scope, the design decisions, the acceptance criteria and the merge. Agents own the implementation: how the code is structured, how the tests are written, how the change is refactored. Agents also own facts: an agent looks things up itself and asks a person only about choices. When the person approves a plan, that approval covers each of its steps, so the agent does not ask again at every one (see act or ask).

This separation exists because, when one source both decides what "done" means and writes the code, nothing independent checks that the definition was right. Acceptance criteria written or approved before the agent starts give the tests an author who was not looking at the code.

A worked example

Illustrative example, with generic names. A team wants sessions in a small web app to survive a server restart.

The work is one coherent piece, so it enters as a lone task, tracked as one issue, app-42.3. An agent reads the codebase and writes a spec: the goal, two Gherkin scenarios ("Given a visitor with an unfinished session, When the server restarts, Then they resume where they left off"), the files it expects to change, and the commit it researched against. The design record already holds a decision to use SQLite for persistence, so the spec cites it rather than reopening it.

A person approves the spec. A fresh agent session, on its own branch in its own checkout, writes a failing test for each scenario, makes them pass with the least code, runs every suite the change could affect, starts the app, restarts it, and records the output. Scripted checks refuse to advance the task without a well-formed spec, and review will not start until the tests pass and each criterion has its proof. A different vendor's model reviews the diff against the spec and the design and finds nothing critical. A person reads the pull request, which opens with three plain paragraphs on what was broken, what changed and what to check, and merges it. A last check confirms the reviewed commit is on main before the task closes.

What exists today

The pipeline runs our own development, attended and unattended. The design method, decision records and C4 diagrams are in use on our products, including the Salesbot voice agent. Concurrent dispatch of many coding agents at once is design work, described under the software factory.