Building Whoobe with AI: what we measured, what went wrong, what we do not claim

Whoobe is a self-hosted platform for content, data and integrations. It was built by one senior architect working with an AI assistant. This post says how that worked, with numbers you can check, and where it went wrong. It is one project, so treat it as a case, not as a proof.

The bet

The usual way to use AI in software is to let it write code faster. Our bet was different: the assistant types, a person decides. The person fixes the structure first (the data model, the contracts between parts, what must never leave the server) and the assistant works inside those limits. We wrote about the idea in Using AI as a structural co-pilot. This post is about what came out of it.

What we measured

Figure	Value	Where it comes from
Time	77 days (2/3 hrs per day) from the first commit of the current repository (1 August 2026) to 17 October 2026, 674 commits	git log
Size	about 110,000 lines in about 730 source files	TypeScript, Vue and JavaScript tracked in the repository, without tests, documentation and generated output; counted on 17 October 2026
Automated tests	2,033	API 1,359, security unit 276, core 295, SDK 59, browser 30, workspace isolation 14; the test summary of 14 October. A further 46 integration tests run on a disposable database
Findings	59 recorded, every High fixed	the public findings register; some Medium and Low items are still open or accepted, each with a reason and a date

Lines of code say little about quality. We give them only to show the scale. The tests say more, but only about what they cover: the register lists what they do not (no load test, no SQL fuzzing of every endpoint, no outside audit).

Where the decisions were human

The data model is data. Classes are stored as data and objects as JSONB in PostgreSQL, checked at runtime with Zod. A change to a class never runs ALTER TABLE. The price is that filtering happens in the application: thousands of objects fit comfortably, millions are not the target.

Credentials stay on the server. Third-party credentials are encrypted with AES-256-GCM and removed from every response before it reaches the browser, so DevTools and browser extensions never see them.

Events, but no engine. A change to a record stores an event in the same database transaction. A worker delivers it, signed and retried, to whatever engine the operator runs. We chose not to build a workflow engine, because durable execution, retries and a run log are a product of their own. The cost is two products to operate and two places to look when something fails.

One workspace per organisation. Isolation is a separate stack with its own database and storage, not a column in a shared table. Fourteen tests start two stacks and check that the credentials and data of one do not work in the other. That is evidence for those cases, not a general proof.

Where the machine was wrong or incomplete

Fast code has defects. These were found by tests and by review, not by the step that wrote the code:

• Stored XSS through rich text (finding F-045) was found only after browser tests were added. The unit and API tests had passed.
• A documentation review found that function permissions were never enforced and that a push-provider key was served by a public route (F-058 and F-059), in features that were already working.
• An import script built page nodes without the default fields the editor expects, and the editor crashed on open. Every node now gets the full default shape first.
• Tests drift. Two security tests no longer matched the code after a redesign and failed for that reason, not because of a defect.

Generation is cheap. Verification is the work, and it did not get cheaper.

What we do not claim

• One project and one architect: this does not show that the method works for a team, or for someone else.
• No outside audit or certification. The evidence is our own, and the register says what is not covered.
• Known gaps remain: no single sign-on for staff, no audit log of administrative actions, no full Content-Security-Policy on the admin applications.
• The numbers change with every commit. Read the dates.

What we would tell a team

1. Write the contracts first. Schemas, route lists and permissions come before the code that uses them.
2. Make the tests guard the structure. A route-drift test fails when a route appears without a rule; it does not trust anyone's memory.
3. Review by reading. Writing the documentation found problems that the tests did not.
4. Keep a register of findings, with a status and a date, and publish it.

The code is MIT. The decisions, the threat model and the findings are in the repository, so you can judge the result by reading them.