CodeHero A real project, from its own records
A gateway to a national goods-movement system.
A business described what it needed. In 25 days, AI agents in CodeHero planned, built, checked and repaired a distributed system: a management server, independent gateways to a government API, a driver app and libraries for business systems. Every number on this page comes from the project’s own records.
The country, the authority and its API are not named: every country calls these documents and systems by its own names. No server address, key, account or customer record is shown.
At a glance
- 25
- days23 September – 17 October 2026
- 252
- tickets94 build · 32 independent check · 89 repair
- ≈113,000
- lines of product codeand ≈113,000 lines of tests
- 919
- test files241 specifications · 1,571 contract files
- 39
- acceptance scenarioseach with the level it was proved at
- 43
- requirementswritten with the owner before the work
- 33
- owner decisionsrecorded as the work went on
- 2
- AI companiesone builds, the other checks
- 8+
- platform upgradesduring the project — the work resumed after each one without losing progress
What the owner needed
Before a vehicle with goods leaves, the business must issue an electronic transport document to the tax authority and have it confirmed. A business has several systems that create these documents, many vehicles and drivers on the road.
The owner needed one service that accepts documents from any business system in one shape, sends them to the authority without ever losing or duplicating one, keeps every organisation’s keys and credentials apart, lets a driver scan a QR code and see whether the load may leave, and runs on several servers that install, update and recover in a controlled way.
What it is made of
The topology by role. The delivered layout: one management server and three gateway servers.
- API — writes every document durably before it answers
- Queue — one gateway owns each document
- Worker — sends within each account’s budget
How one document travels
- A business system sends it
to any gateway, in one format, with its organisation’s key.
- The gateway writes it first
then answers — under 100 ms for 95% of documents in the load test.
- One gateway owns it
the worker sends it within the account’s budget, never twice.
- The authority answers
nothing counts as sent until the authority’s status confirms it.
- The driver scans the QR code
the app shows whether the load may leave.
- Every step is counted
statistics and service levels at the management server.
How the work was organised
The owner and the planner wrote the requirements and contracts first. The plan was reviewed in 23 rounds and by a second AI before any build. Each phase ended with a re-plan that read what was really built.
- Phase 1
Two local gateways and the contracts
- Phase 2
Administrator sign-in, organisations, keys, configuration, queue and ownership
- Phase 3
The authority’s test environment and the client contract
- Phase 4
Telemetry, service levels, the management screens
- Phase 5
Installers, deployment, retention, virtual machines
- Phase 6
A repair round, the final topology, documentation, the security test
- Phase 8
The owner’s new scope: QR rule, driver keys and app, retention, backups, REST documentation, Java library
- Phase 9
Eleven new requirements from the owner in one message
- Phase 10
The approved test plan with the authority and the final acceptance
A conditional phase (automatic fail-over) was planned but not activated.
Build, independent check, repair
- Build94 tickets
Anthropic models, mostly senior with balanced reasoning
- Independent check32 tickets
OpenAI models — a different company; the checker never edits product code
- Repair89 tickets
one ticket per finding, at most three cycles before the owner decides
- Check againuntil it passes
the same checker re-runs the business rules from input to output
17 peer reviews gave a second opinion on plans and designs; 12 re-plans planned each next phase from what was really built.
Security: tested like an attacker would, on the installed servers
The project’s own active security test, run on a four-server staging cluster (one management server, three gateways).
- Cross-tenant access
- Sign-in, sessions, throttling
- The permission matrix
- Cross-site requests
- Injection and path traversal
- Server-side requests
- Hostile answers from the authority
- Replay
- Queue abuse
- Secret exposure
- Transport: TLS 1.2/1.3 only, HSTS
- The database
- Host settings
- 38
- security fixtures passed
- 18
- active network probes passed
- 20
- host checks passed
- 24
- credential refusals confirmed
- 328
- access checks after the fix — 0 failures
One medium finding was found, fixed and tested again. Open findings: 0 critical, 0 high, 0 medium.
The security ticket and its check run on two different AI companies, the checker at a high reasoning setting. This is the project’s own test — not an external certification.
Speed: measured under load
15 minutes at 10 documents and 10 live status reads per second, with a 60-second double peak, on a gateway with 2 virtual CPUs and 3.8 GB of memory.
- 9,600
- documents accepted — 0 timeouts, 0 lost
- 6 s
- to recover after the peak
- 88,184
- calls to the authority’s simulator — each matched one-to-one by the test oracle
- 1 of 3
- gateways switched off: only its sending budget moved to the other two; its documents waited for it, then it rejoined
A later performance test of the whole product was measured again by the other AI company; what it found was repaired in three cycles and measured once more.
The figures hold on the declared test hardware; the production sizing is the owner’s. A document with more than about 30,000 events cannot be read live, because the authority limits the size of an answer.
For engineers
The guarantees, and how each one was proved
What the system promises, the mechanism behind it, and the evidence that it holds — all from the project’s contracts and acceptance register.
| Guarantee | How it works | How it was proved |
|---|---|---|
| Accepted means durable | The gateway commits the document’s receipt to its database before it answers. | The API process was killed before and after the commit; nothing answered was lost. |
| One request, one operation | Requests carry an identity; a repeat returns the first result instead of a new operation. | 10 identical requests at the same moment: one created the operation, nine returned it. |
| Never sent twice | Each document has exactly one owner gateway; a send that may have happened is reconciled with the authority before any retry. | A worker was killed right after a possible send; reconciliation found the true state and did not resend. |
| Ownership moves safely | A handover writes a newer binding; the old owner is fenced and its late writes are refused. | Forced handovers and a late return of the old owner on the three-gateway servers. |
| Shared budgets hold | Each account’s rate towards the authority is split into per-gateway shares by the management server. | Under load the budget was never exceeded (two controlled refusals, nothing lost). With one gateway switched off, only its share of the budget moved to the others; the documents it already owned were not taken over: they waited for it and were sent exactly once when it came back. |
| Configuration cannot be forged | The management server signs configuration snapshots; gateways verify them; keys rotate with an overlap window. | Test vectors for the signatures, the key rotation and the refusals. |
| Telemetry counts once | Events are stored by identity; late data creates a new revision of a statistic and keeps the old one. | The same batch sent three times stored each event once; out-of-order and late events produced correct revisions. |
| Sent means confirmed | A document counts as sent only when the authority’s own status says so. | A business error inside a successful HTTP answer is reported as a rejection, never as success. |
| Updates without loss | Drain, update, roll back; an interrupted install resumes; two operating-system versions. | Update and rollback of management and gateways on both versions, from the screens and by the runbooks. |
| Data is accounted for | A data register lists every column of both databases with its personal-data category; retention purges by rule; audit records are append-only. | The runtime database user cannot change or delete audit rows; the database is not reachable from outside. |
Eight versioned contracts — the single source every ticket used
CT01Gateway API (OpenAPI 3.1)1.14.0CT02Ownership, handover, fencing1.3.0CT03Queue schema, send safety, shared limiter, reconciliation, canonical JSONCT04Control plane: signed snapshots, keys, per-node shares, telemetry2.15.0CT05Metrics, availability, exports1.2.0CT06Release manifest2.1.1CT07Client conformance1.6.0CT08Management API1.28.0
Eight topology drills, run by the operators’ runbooks
D1Management server stopped — the gateways keep workingD2A gateway fails while a call to the authority is in flightD3Owner mismatch between gatewaysD4Maintenance: drain, update, returnD5Manual handover and a late return of the old ownerD6Pressure: queue, disk, databaseD7Shared budgets across gatewaysD8A real browser from another origin
The engineering record it left behind
- 41
- architecture decisions (ADRs)
- 12
- operations runbooks: install, deploy, update and rollback, backup and recovery, retention, certificates, topology …
- 8
- user guides
- 2
- languages for every message (one catalogue each)
- 1
- acceptance manifest with a checksum for every released file
How the evidence is kept honest
- A result against a mock or the simulator is never recorded as a result against the authority.
- The load generator is open-loop: it does not slow down when the system does.
- A test oracle matches every call to the authority one-to-one (88,184 ↔ 88,184).
- The checker belongs to another AI company and never edits product code.
- Each scenario keeps its proof level; a gap is written as blocked or not run, with its reason.
Complexity: what was built
| Part | Lines | |
|---|---|---|
| Gateway — Node.js | 18,320 | |
| Management API — PHP | 30,688 | |
| Management screens — Vue | 9,756 | |
| Management worker — Node.js | 3,221 | |
| Java library for business systems | 12,125 | |
| Driver app — PWA | 5,185 | |
| Simulator of the authority (tests only) | 2,480 | |
| Installers and updates | 6,390 | |
| Contracts: schemas, SQL, test vectors | 8,191 | |
| Developer tools | 7,990 | |
| Reference client | 2,249 | |
| Documentation | 5,851 | |
| Tests | 113,117 |
By language
- JavaScript143,849
- PHP33,098
- Shell13,128
- Java11,995
- Vue8,636
- Python6,338
- SQL4,427
- XSD3,913
Changes while the work went on
33 decisions of the owner are recorded in the change ledger. Each is written once and reaches every ticket it touches — the ones still to come and the ones already running.
- Who may create organisations, devices and keys
- Object-level permissions for device keys
- What an organisation may still do when it is inactive
- A confirmation rule for the whole application
- Log privacy: what access logs keep
- Backup retention and off-host backups
- One message with eleven new requirements on day 19: a driver API, a library that activates with one file, bulk sending, continuous QR scanning, a bilingual app, a public page, three ways to activate a driver …
CodeHero itself was upgraded at least eight times during the project: the tickets paused, the platform was upgraded, the work resumed without losing progress.
What was proved, and where
Each acceptance scenario keeps the level it was proved at. A test against the simulator is never reported as a test against the authority.
- 2 Installed four-server staging
- 4 The authority’s test environment
- 15 Production-shaped virtual machines
- 14 Locally, with the simulator
- 3 Waiting for the customer’s own client
- 1 Conditional, not activated
The AI work, in numbers
- 459 h
- of agent sessions (several ran in parallel)
- ≈72,500
- tool calls
- 12.8 bn
- tokens processed — 98% re-read from cache; counted at the cache price ≈1.35 bn
- 47 M
- tokens written by the models
- ≈25
- decisions only the owner could make — about one a day
After the first day’s specification, the owner was asked only for business decisions: choices, approvals of test windows, accepted limits. The agents wrote every ticket’s instructions themselves and sent each other 228 messages. Anthropic models did the planning, building and repair work (203 tickets, counting the first planning ticket, which ran on the project’s default provider); OpenAI models the independent checks and peer reviews (49 tickets). The project ran on subscriptions, so no cost per project is given.
Status and limits
- Release 0.8.0 is installed on a production-shaped test cluster: one management server and three gateways.
- On 17 October 2026 the final acceptance check was running.
- Not done yet: the production sizing (the owner’s), and the customer’s own client on staging (three scenarios).
- By design there is no automatic fail-over: a document waits for the gateway that owns it.
Numbers from the project’s records, read on 17 October 2026. They describe this run; they are not a promise of time or cost for another project.
Bring a project like this.
A real business problem, the owner’s decisions, and a factory that builds, checks and keeps the record.
Questions people ask
All the articlesAm I tied to one AI company?
No. CodeHero works with many AI companies at once and with models on your own hardware. You can change company or model at any time — the project, its rules and its history stay. Read the article
Do my passwords and keys reach the AI company?
Not the ones you store as secrets (eight characters or longer): your application uses them, but their values are not sent to the AI service. A password typed into a chat message or shown in a screenshot cannot be recognised — store every password as a secret. Read the article
Why do several AIs work on the same job?
Because one AI does not catch its own blind spots. In CodeHero one model builds and a model from a different company checks; problems go back for repair and are checked again. Read the article
How does CodeHero compare with other AI coding tools?
It is a different kind of thing. Coding tools help a person who writes code. CodeHero does the whole job — asks, plans, builds, checks, hosts and maintains — for the person who knows the business. Read the article
If CodeHero writes the code, what is my role?
You become the advisor: you decide the business rules, approve the plan and accept the result. CodeHero is the developer that asks, builds, checks and maintains. Read the article
How does the AI keep its memory on long jobs?
With memory folding: when the AI has finished with a long result it keeps a short note of what matters and puts the rest away — it can open it again at any time. So it works much longer without losing the thread. Read the article
How does the AI avoid forgetting or getting confused on a big project?
The factory gives it structure: smart tickets with one clear job each, a change ledger of every decision, a map of the code and search by meaning. The AI reads what it needs instead of guessing — which also saves a lot of cost. Read the article
Why do you call it a factory and not a tool?
Because it runs the whole production line on its own — planning, building, independent checking, repair, delivery and maintenance — with stations, rules and records, like a factory. A tool waits for a person to use it. Read the article
How can this change the world of applications?
When the person who knows the work can get software made, checked, hosted and maintained without a development team, software can be made for every business and every need — not only for those that can afford a team. Read the article
What does CodeHero mean for developers?
Less repetitive work and fewer late nights. The factory takes the routine building, checking and fixing; developers decide the architecture, review what matters and handle the hard problems. Read the article
Why does CodeHero host the applications too?
Because building and running belong together. The application runs where it was built, with its domain, secure connection, backups and recovery — and every later change returns to the same factory. No separate hosting panel to learn. Read the article
What technology do the applications use?
Always open, widely used technologies — PHP and MySQL first, and others such as Node, Python or .NET when the job needs them. Your application is never locked into a proprietary platform. Read the article
Why use AI subscriptions instead of paying per use?
Because in our own measurements, for heavy daily work, a subscription has cost up to about 40 times less than paying per use for the same work. CodeHero runs the subscription AI tools (Claude Code, Codex, Grok Build) as workers in the factory. Read the article
What happens to the knowledge about my project?
It is built up and kept inside your installation: decisions, rules, changes and their reasons, next to the code. A new person or a new AI continues from there — the knowledge does not leave with them. Read the article
Can small local AI models do real work?
Inside the factory, yes — more than on their own. Small, clear tickets, a checklist for finishing, tool help and a stronger model that checks the result let small models on your own hardware do much of the building. Read the article