manifesto
What fabrig holds to be true about making software with agents. Disagree freely: most of it is a setting.
1
Agents write more code in a day than a team can read in a year. Writing no longer limits software. Trust does: knowing that what landed is what was checked, and that what was checked was worth checking. Everything below follows from that.
2
If a step has one right answer, it’s a procedure. A procedure is faster, repeatable, testable and costs no tokens. A model is woken only where something has to be decided: making a change, repairing a failure, reviewing, resolving a conflict. Every step moved to code stops depending on a model’s good day.
3
Instructions are useful, and agents mostly follow them. Mostly isn’t a guarantee. What must hold belongs in authority, not in a prompt: agents aren’t asked to leave the merge alone, they’re given no merge tool. Know which of your rules are enforced and which are followed, and never confuse the two.
When the outcome of a write can’t be known, the work waits for a person. A guess is the worst answer an unattended system can give.
4
You can’t build reliable software at scale with agents on top of flaky CI and badly engineered code. Agents don’t clean up a mess, they extend it, and faster than anyone can keep up. Without strict discipline they drift, and slop accumulates.
fabrig is built for reliable, quality software at scale, with minimal or zero human intervention. It makes that possible. It can’t teach anyone how to do it. A fast car doesn’t make a driver, and a crash isn’t the car’s fault. Good software design is still a human responsibility, though models are getting close.
5
What matters is what your code and process guarantee: tests that mean something, builds that repeat, gates that tell the truth, design that’s written down. These are well-known engineering practices, and none of them depends on a language or a programming model. fabrig’s own answer, a strict subset of Rust under deterministic simulation, is one answer. Yours is your pick.
6
One person in a chat approving every change is a valid way to use fabrig. So are goals that land on their own overnight. Neither is the grown-up version of the other. Start where your repository is, and turn the dial as it earns it.
7
You shouldn’t have to learn a product’s vocabulary to tell it what you want. Say how you work, and it should ask what it needs, propose how it will run that, and say plainly what it can’t do. Most software will end up configured this way.
The result has to stay ordinary: versioned settings you can read, compare and restore, never a hidden state an assistant manages.
8
No one will read what agents write at this rate, and pretending otherwise is theatre. People should decide goals, designs and plans. Code gets tests, simulation, gates, verification after landing, and continuous review by agents: for debt today, then for security and whatever else matters to you. Judge the outcomes, in numbers, in public.
9
When building was expensive, you took what existed. When building is cheap, a dependency’s remaining costs dominate: fit, control, churn. Not-invented-here used to be a vice. With generated code it’s a legitimate choice: build what you need, exactly how you need it, and keep control of it. Be honest about the exceptions. Don’t write your own cryptography.
10
Your limit is tokens, not machines: hardware can follow the work. So make every token count. Offload to code whatever doesn’t need a model. Give the strongest model to the decisions that deserve it. Measure what a verified change costs, and keep that number where whoever pays can see it.
11
Claims are cheap in this field. fabrig is built with its own prototype, its numbers come from its own log, and its source and design are in the open. Where it’s unfinished or unproven, it says so.
Teams that already hold a strict engineering bar and want far more from it. And anyone prepared to build that bar first, at a lower setting of the dial.
It isn’t for anyone hoping agents will rescue a codebase nobody is willing to own.
