Ask a coding agent to “design a scalable API” and watch what happens. Nine times out of ten you’ll get Kubernetes, Kafka, Redis and three microservices — for a product with 100 users and one developer.
It’s not that the agent is wrong about what big systems look like. It’s that it learned the aesthetics of system design from conference talks and engineering blogs, drawn almost entirely from the largest 0.1% of systems on Earth. Netflix writes about Netflix’s problems. Nobody writes a viral post titled “We ran a single Postgres instance and everything was fine.”
So the agent never learned the economics. And the economics are brutal in their simplicity:
100 users at 40 requests per session is 0.28 requests per second. A single application instance has roughly four orders of magnitude of headroom against that. There is no architecture decision to make here — there’s an arithmetic problem, and the arithmetic takes ten seconds.
That’s why I built OAB — Open Architecture Brain. It’s an open-source plugin that gives your coding agent architectural judgment, not just architectural vocabulary.
The bit a generic assistant never produces
Plenty of tools will tell you to keep things simple. That’s just a different flavour of vibes. OAB does something more useful: it computes the capacity envelope, refuses what the numbers don’t justify, and — this is the part I care about most — names the exact measurement that would reverse the refusal.
Here’s a real fragment from a design run for a tiny startup (100 users, £50/month, two developers):
cache— At 0.24 peak reads/second there is no measured read pressure to relieve.
Revisit when: a single query exceeds 10 requests/second at over 50 ms, or database CPU is sustained above 60% for 3 days.
orchestration-platform— Three times the complexity budget and four times the money budget for a system with four orders of magnitude of headroom on one instance.
Revisit when: more than 4 independently deployable services exist and a dedicated operations engineer is on the team.
A rejected component with a revisit threshold isn’t a “no”. It’s a “not yet, and here’s the tripwire”. You can disagree with it, but you have to disagree with a number, which is a far better argument than disagreeing with a mood.
Complexity is arithmetic, not advice
Under the hood, every component costs complexity points, and every team has a budget:
available = 4 + 1.5 × (engineers − 2) + 4 × dedicated_opsTwo developers get 4 points. A managed database costs 1; a self-managed orchestration platform costs 4. Go over budget and the component is rejected by default — an override must name what’s being dropped, or who will operate the excess.
The pricing makes it concrete. At roughly £240 per point per month in engineering attention, self-hosting a database to save £250/month actually costs about £720/month. The managed service is cheaper, and OAB says so with arithmetic rather than preference. It’s a calibrated heuristic, not a law — and the output says that too.
Not anti-complexity. Anti-unjustified complexity.
The obvious failure mode for a tool like this is becoming a machine that says “you don’t need it” to everyone. That tool would be useless — it would just be a different bias.
So the evaluation suite guards both directions. One scenario describes a platform at 50,000 requests per second across three regions, and its assertions require the machinery a small system would be refused: the CDN (against 1.04 PB/month of egress, where 85% offload saves roughly $35,000/month), the event stream, the cache. If OAB refuses Kafka to a system that genuinely needs it, the suite fails.
Two of the five scenarios guard against under-building; three against over-building. There’s even a scenario whose correct answer is “nothing needs to change” and one whose correct answer is “these requirements are inconsistent” — the two answers an eager assistant never gives.
And because a framework can be tuned to produce reassuring prose far more easily than the right structure, assertions run against artifact fields, never against words. Scenarios are perturbed 100× and 0.01× to prove the system responds to magnitude rather than recognising specific numbers.
What it isn’t
It’s not a methodology, and it doesn’t compete with one. Process plugins like superpowers govern how your agent works — TDD, debugging, planning, review. OAB governs one decision inside that flow: what this system actually needs. They compose.
It’s also not finished, and I’d rather say so than let you find out: no MCP server yet, one agent integration, 6 knowledge domains of a planned 18. The roadmap is public, and so is a critique of the project’s own founding brief.
Try it
OAB is free, Apache-2.0, local-first — no hosted service, no accounts, no telemetry.
/plugin marketplace add mhayk/oab
/plugin install oab@oabThen ask /oab:design for something modest and see what it refuses you. If you’d rather look before installing, oab.run walks through the same decision end to end — the brief, the numbers, and what gets rejected.
The highest-value contribution, incidentally, requires no understanding of the codebase at all: architecture knowledge units are templates you copy, fill in and send as a pull request. If you’ve operated a system at any scale, you know something the largest 0.1% never wrote down.
