How we build

Most of the code in FlowFinds is written by agents. That is not a slogan about the future of engineering; it is a description of the working day, and it only functions because the things an agent is bad at — knowing when it is finished, remembering what was decided, being honest about a red test — have been moved out of the agent’s judgement and into machinery that does not have an opinion.

The cycle has five stages. Each one ends at a gate that a person or a script must pass before the next begins.

1. Objective

Nothing starts from a chat message alone. Before non-trivial work begins, five things are written down: the outcome, the scope, the reference the result will be compared against, the condition under which it is done, and any blocking assumption. That block is committed to the repository rather than held in a conversation, because the agent that finishes the work is frequently not the agent that started it.

Ambiguity is resolved at this stage or not at all. One focused question is asked when two readings of the objective would produce materially different products; otherwise the agent gathers evidence and proceeds without asking for routine approval. The failure mode this prevents is the expensive one: a correct implementation of the wrong objective, discovered at acceptance.

2. Architecture, and the state that outlives the session

Context windows end. Repositories do not. So the durable state of the project lives in files with fixed jobs: a directory of intent, acceptance criteria, decisions, known gaps and verification evidence; a roadmap file that is the ordered step queue; a metrics file that is the scoreboard; and a handoff directory holding live inter-agent state. An agent picking up work reads those files. It does not reconstruct the project by reading old conversations.

Two architectural rules do most of the work of keeping a multi-agent codebase coherent. Contract changes route through a single controller, and each concern gets exactly one resolver — never two code paths that could disagree. And parts of the product that the owner has accepted are explicitly locked: the surface is declared frozen in the repository’s agent instructions, with a rollback archive and its SHA-256 recorded, so that a lock can be verified rather than trusted. Opening a lock requires an exact, case-sensitive unlock phrase from the owner in the same request; nothing about the phrasing of a nearby instruction, or a previous turn, is treated as permission. The lock re-engages immediately afterwards.

Generated artefacts are never hand-edited. Where a surface is ported between repositories by a script, the canonical source is edited and the script re-run; editing the generated copy is treated as a defect even when the result looks right.

3. Autonomous execution

The execution shape is chosen per task rather than applied uniformly. A targeted fix gets one owner and a narrow verification. An uncertain problem gets two or three independent read-only investigations racing competing hypotheses, stopped the moment the evidence is decisive. Wide mechanical work gets shared rules, a pilot of two or three units, and only then a fan-out across separate worktrees with disjoint file ownership — never two writers in the same files. Long builds, test suites and research run in the background while independent work continues, so that human waiting is not the limiting factor.

Inside execution the loop is closed without a human in it: edit, run the targeted check, read the failure, fix, re-run, continue. For anything with a rendered surface the loop includes a real browser — open the reference, open the local build, compare, interact, find the discrepancy, fix, repeat. Reading the code is not accepted as a substitute for observing the behaviour when the behaviour can be observed.

4. Verification: deterministic gates

There is one command that decides whether a change is green. Builders loop on it and are not permitted to hand off red. Nobody negotiates with it, and it is not weakened to manufacture a pass; a check that is inconvenient is either correct and must be satisfied, or wrong and must be fixed as its own piece of work.

The gate is where our particular failures have been turned into permanent constraints:

• Every mechanically-checkable review finding becomes a gate check as part of its fix. A defect found once is a bug; the same defect found twice is a missing check. The fix is not accepted without the check that would have caught it.
• Load-bearing checks are mutation-tested. Before anyone is allowed to lean on a check, it must be proven able to fail — the code it guards is deliberately broken and the check must go red. An assertion that has never failed is not evidence.
• Accepted surfaces are verified at fixed viewports. Locked screens are re-verified at 1440×900 and 390×844, with the adversarial cases scripted rather than eyeballed — for the dashboard checklist, thirty rows simulated, the correct element proven to be the only scroller, the last row proven to clear the fixed dock, and horizontal document overflow proven absent.
• Product claims are separated from company claims by rule. One signal never carries two meanings, and statements about us are not permitted inside artefacts that describe the product.

Benchmark runs are the same machinery pointed at the model instead of the code. The suite is fixed before the runs, the inputs are hashed, and the recorded runs — passed and failed — are what the research section reads at build time. No page on this site types a score by hand. The methodology is published, and so is the procedure for running it against us.

5. Acceptance: review by exception

Intelligent reviewers are not used to establish facts a script can establish. Review is allocated by risk: low-risk changes are gated deterministically and reviewed only where judgement is genuinely required; medium risk adds one focused reviewer; high risk adds specialist review and an integration gate. Copy, and anything composing what the product reveals or claims, is treated as medium risk regardless of how small the diff is, because the damage from a wrong sentence is not proportional to its length.

Reviewers do not return opinions. A finding is structured — issue, severity, evidence, reproduction, confidence, required fix — and only verified, high-confidence findings are routed to a builder. A speculative finding is not repaired; unverified review noise costs as much as a defect and is measured as such.

The last reviewer is given the original objective, the acceptance criteria, the final diff, compressed verification evidence and the unresolved risks, and is asked for blind spots rather than a repeat of the earlier passes. Ship state is then confirmed by listing what is actually on disk, not by believing a report that says it was written.

The loop that changes the loop

Corrections are classified rather than accumulated: instance-specific ones are fixed and forgotten, deterministic ones become a check or a hook, and generalisable ones become a candidate rule. The agent instruction files are never auto-appended to by a lesson. A proposed rule is a candidate edit; it runs against a suite of evaluations built from real past tasks — targeted fixes, ambiguous objectives, hard debugging, previous scope misunderstandings, previous false review findings — and it is promoted only if the harness measurably improves. If it is faster but misses more requirements, it is rejected. Without that, an instruction file becomes accumulated trauma: long, revered and untested.

The same evaluations run whenever the instruction files, the agent definitions, the routing or the review policy change, because the organisation that writes the software is itself software and gets tested like it.

Why this is on a public page

Because the discipline that makes a benchmark trustworthy and the discipline that makes an agent-written codebase trustworthy are the same discipline, and it is fair for a customer to check whether we practise it. The mission explains what the gates are enforcing; the research section is what they produce; careers is where to say you want to work this way.