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
- ≈88,000
- lines of application codeplus ≈24,500 of contracts, tools, simulator and documentation, and ≈113,000 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.
One change, traced end to end
Day 19: eleven new requirements while the work was running.
How one of them travelled from the owner’s message to a checked result. Every step is in the project’s records.
- The request
Point 4 of the owner’s message: «bulk sending of driver acts in the API and the library».
- Recorded once
Row 26 of the change ledger, written the same day. Before: one act per call. After: a batch of acts in one call, each act behaving exactly as if it were sent alone — the same operation id, the same protection against sending twice, the same send rule. The row names the three parts it touches: the operations contract, the binding service and the library.
- Contracts first
The replan wrote the phase’s shared contracts that day: a new batch call with a result for every act. Every ticket of the phase reads them before it starts.
- Built
One build ticket, rated hard (concurrency, uniqueness, sending twice, rate limits): up to 50 acts in one call. The driver app got continuous scanning and one «send all» button.
- Checked by another company’s model
The check measured «a batch of 20 in ≤ 3 s» from the button to the last act — and found that the builder had measured only the work on the phone.
- Proved, not argued
The repair wrote a repeatable test: 1.66 s of work on the phone, plus the server’s mandatory 5-second check of a document seen for the first time — 6.7 s in all. Under 3 s was impossible without weakening that check, so the repair changed no code and handed the choice back as a business decision.
- Recorded — and left to the owner
The target was not changed for the owner. An interim reading was recorded as taken on his behalf, not by him: the 3-second target counts the phone’s batch work, and the first-time document check is measured apart. The end-to-end wait — about 6.7 s — is on the owner’s list of open questions: keep it, check documents while scanning, or shorten the check. Nothing was built for either option.
The other ten requirements went the same way: a ledger row each (rows 23–33), the contracts of the next phase, then build, check and repair.
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 articlesWhy do several AIs work on the same job?
Because one AI does not catch its own blind spots. In CodeHero one model builds and, by default, a model from a different company checks; problems go back for repair and are checked again. 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
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