Side project · Running log
Building Bluecliff
Bluecliff is a side project, an app to assess the security of the suppliers and partners a company depends on. This page is about how I build it, more than about the app.
I have three reasons for it: a problem I met in my audit work, technology I want to learn, and a way of working I want to test. The engineering team is made of AI agents, and I'm the only human on it. There's no funding and little spare time, so it has to stay cheap in money and in attention.
This is the log, newest first. Numbers come from GitHub and Linear. The failures stay in.
Product
A problem I met in my audit work, and an app to try a better way of handling it.
Now: Proof of concept. The first screen works on a private preview.
Technology
Recent technology, such as decision models, used for real. Building with it is the fastest way I know to understand it.
Now: Lessons will be shared here. Bluecliff's own design stays private.
Agent team
An engineering team made of AI agents on frontier models, run in Claude Code, with me as the only human.
Now: Three feature owners, plus QA, DevOps and an Orchestrator.
Timeline
October 2026
- Day 4
· Day 4
Agent team · Reflection
The sweet spot between rules and freedom
Prose rules were too weak and the lane guard too strong. What held was a few machine checks at the edges and room to decide inside them.
Read the reflection - Day 4
· Day 4
Agent team · Reflection
Agents need their own way to talk
My agents coordinate the way people do, through tickets and comments, once an hour. Why that is the bottleneck, what exists, and what a tool built for agents would need.
Read the reflection Show 5 log entriesHide 5 log entries12 Oct to 13 Oct
- Day 4
· Day 4
Agent team
A failure nobody noticed
The second model's security review had stopped running the day before. Only 25 of 105 security requests ever ran, and the agents kept asking for it without noticing.
Agent team
From a pipeline to owners
Three full-stack builders now each own a slice of the product and write their own tests. QA runs the whole flow once a day instead of gating each change. The role guard now catches honest mistakes and no longer tries to be a sandbox.
- Day 3
· Day 3
Agent team
A guard that kept growing
A hook keeps each agent in its lane by reading the shell commands it runs. Every review round found a new way around it. It grew to 2,433 lines, and most of the night went to fixing it.
Agent team
The review budget runs out
The second model reviewing every change posted 396 reviews on its first day, against a target of 40. Its weekly quota went in one day. It now reviews only high-risk changes, with a cap on rounds.
Agent team
First night with six roles
29 pull requests merged while I slept, and requests between roles were picked up within the hour. One question left waiting for me held four pull requests for four hours.
- Day 2
· Day 2
Agent team · Chapter
An org chart made of agents
From an empty repository to six agent roles with steps, lanes and gates in two days, and where I became the bottleneck.
Read the chapter Show 4 log entriesHide 4 log entries10 Oct to 11 Oct
- Day 2
· Day 2
Agent team
Seven roles, written down
Each role owns a step and has files it never touches. The document describing it took 16 review rounds and 55 findings before it merged.
Agent team
CI stops for two and a half hours
Every CI job failed from early afternoon because of a billing block on the GitHub account. CI moved to my own servers the same day, where about 50 runs soon queued for two slots.
Agent team
Agents merge their own work
Once CI and review pass, agents merge. They need a go-ahead from me for four things only: money, secrets, customer data, and anything that weakens a gate.
- Day 1
· Day 1
Agent team
Foundations before a product
The repository started generic, with a base any project could sit on: rules for the agents, a security baseline, and a review by a different model on every change. Then four roles, with Linear as the one place where work is planned and handed off.