01Overview
This is how we build. The board reads the plan, works out which tickets can be built side by side, and gives each one to an AI coding session in its own copy of the project. Every change is written test first, reviewed by a second AI from another vendor and proven before a person sees it.
The board
A live page of every ticket, lane and session, and what each is waiting on.
The gate
Runs only the tests a change can reach, and leaves a receipt for that exact change.
The cloud runner
A private server per project that works unattended and asks its questions over WhatsApp.
02The challenge
Every step waited for a developer.
AI models made writing code faster, but a developer still briefed each step, checked each answer and carried the work to the next one. Whatever was decided was lost between one session and the next.
What the client wanted to achieve
Less human time
People are asked only for decisions.
Nothing unproven merges
A change merges only with passing proof for that exact change.
More work in parallel
Every safe ticket runs at once, the critical path first.
Works on any codebase
It attaches to a new project without rewriting the tool.
How it worked before
- Instructions written again for every task
- Each answer checked by hand before the next step
- Decisions lost between sessions
03How we built it
- 01
A map of the work
It began as one screen of tickets and what blocks them, opening a workspace for each.
- 02
Proof before any merge
A local test gate that leaves a receipt bound to the exact change.
- 03
A second AI reviews
Reviews became structured findings judged by a model from another vendor, and a free slot starts the next ticket by itself.
- 04
Lanes that deliver alone
One command runs a whole line of tickets and delivers it once.
- 05
One tool, any project
It moved into its own home and learned to attach to any codebase from one settings file.
- 06
Plans by the critical path
It learns each project’s structure and plans the heaviest chain of work first.
- 07
Running without a laptop
Its own cloud server, an account that cannot merge on its own, and questions sent to people on their phones.
04How it works
Step 01Plan
Read the backlogTickets, blockers and priorities.Pick what runs firstThe heaviest chain first, in parallel lanes.Step 02Build
Test firstA failing test, then the code that passes it.Isolated lanesEach lane in its own copy, with its own data.Step 03Review
A second vendorAnother AI reviews the exact change, and every finding must point to real code.Step 04Prove and merge
Combined and provenFinished lanes merged into one change and tested.People on demandAnything that needs a person reaches them on their phone.
Before a person sees a change
- A new test that fails, then passes
- The existing tests the change can reach
- A review by a second vendor, bound to the exact change
- Every review finding grounded in the code
- One final run of everything the change touches
- A change to a guardrail still needs a person’s word
05The outcome
We build with it every day. A backlog becomes tested, reviewed code ready to merge, and people step in only for the decisions that are theirs to make.
| Before | After |
|---|---|
| A developer briefing every step | Tickets that carry their own plan and rules |
| Answers checked by hand, one at a time | Tests run on every change before a person looks |
| One reviewer, or none | A second AI from another vendor reviews every change |
| Decisions lost between sessions | The project’s history on the board, for every next ticket |
06Key figures
Week 3 counts its first three days.
07Technology
What the system runs on, for the technical reader.
- AI
- Claude CodeOpenAI Codex
- Cloud
- AWSWhatsApp for questionsA daily email summary
- Code and CI
- Node.jsGitHub Issues and pull requestsGitHub ActionsIsolated working copiesVitest
08What comes next
Next, a whole batch of tickets delivered from its own server with nobody watching, its one real question asked over WhatsApp.
09About
About the client
Our own technology. We built the project board for our own delivery, and we develop it with the board itself, test first and reviewed twice.
About MYBB
MYBB builds systems around how a business already works. We diagnose it with MYBB ROIQ, build the system, launch it with the team and keep running and improving it.