AI can write code. The question is whether it writes code you would trust with your clients' data. These are real artefacts from a real build — unedited, produced autonomously. Judge the evidence.
Every snippet on this page was produced during a governed autonomous build. No human wrote any of it. No human edited any of it afterward. What you see below is exactly what the build produced — security models, data integrity guarantees, specialist analysis, component manifests, and graceful degradation patterns.
Five artefacts. Five aspects of governance. Each one a behaviour that traditional AI code generation does not exhibit.
The build produced a threat model before writing the first route handler. Security is not a follow-up ticket — it is the starting constraint.
| Threat | Layer | Mitigation |
|---|---|---|
| Cross-tenant data leak | Database | RLS on every table; tenant_id checked per-row against unforgeable JWT claim |
| PII exfiltration via SQL injection | Database | Plaintext never in main schema; only SECURITY DEFINER functions touch encrypted vault |
| Audit log tampering | Database | UPDATE/DELETE physically revoked from all roles incl. service_role; SHA-256 hash chain |
| JWT forgery | Auth | RS256 signature verification; tenant and role are JWT claims, not app state |
| Overbilling via mutated rate cards | Database | Append-only (REVOKE UPDATE/DELETE); DATERANGE overlap constraint |
What this means: The builder enumerated attack surfaces, identified the correct mitigation layer for each, and implemented the mitigations structurally — at the database privilege level, not in application code. A bolted-on security review would not produce this. A governed build treats the threat model as a first-class design input.
The build produced a data ontology that explains — in plain English — why certain records can never be edited. This is the paragraph it wrote about time entries.
Every unit of work logged by a team member. A row is created once and never modified. Immutability: UPDATE and DELETE are revoked from both `authenticated` and `anon` roles at the privilege layer. No application code path can modify a time entry after creation. Corrections are made by logging a new entry with a negative or corrective note — the ledger is append-only by design. This mirrors double-entry accounting: there is no erasure, only new facts. A partner reading this can trust that the hours billed to an invoice reflect an unedited record of what was logged at the time.
What this means: The builder understood the business context — PE engagement billing — and chose an append-only pattern enforced at the database layer, not by convention. It then explained the guarantee in language a non-technical partner could verify. Code that explains its own integrity constraints is code that can be audited.
Orch has 8 specialist lenses built in — Security Architect, Scale Architect, Data Architect, Integration Engineer, and more. Each one analyses what is being built during construction. We show two examples here.
[Scale Architect] One thing worth noting: the invoice
detail page is the only client-fetched portal page — all
others are server-rendered. This is intentional. Invoice
PDFs may be generated client-side for print fidelity, and
the data is already scoped by the portal token. But if
portal traffic scales, this is the first candidate for
edge caching — the invoice data is immutable once issued.
What this means: The build does not just produce code. It produces analysis. Specialist perspectives — security, scale, data architecture — examine each component as it is constructed. The builder explains its own decisions, flags trade-offs, and identifies future optimisation paths. This is the difference between code generation and governed construction.
Each ticket in the build produces a manifest of the files it created, with descriptions. This is a real excerpt from one ticket's output.
| File | Description |
|---|---|
src/app/api/v1/invoices/route.ts |
Invoice list + create endpoint with rate-aware line generation |
src/app/api/v1/invoices/[invoiceId]/route.ts |
Single invoice GET/PATCH with status transition validation |
src/app/api/v1/invoices/[invoiceId]/send/route.ts |
Send invoice via Resend; updates status to sent |
src/app/api/v1/invoices/generate/route.ts |
Auto-generate invoice from unbilled time entries for a date range |
src/components/invoices/InvoiceDetail.tsx |
Full invoice view with line editor, print preview, status actions |
src/components/invoices/InvoiceList.tsx |
Filterable invoice table with status badges and total roll-up |
src/lib/invoicing/generate.ts |
Business logic: groups time entries by rate card, computes line totals |
What this means: The build maintains a complete audit trail of what it created and why. Every file has a documented purpose. This is not a post-hoc README — it is produced in real time as part of the construction process. A new engineer (or a new build iteration) can read the manifest and understand the system without reverse-engineering it.
The build designed every external integration to degrade silently when unconfigured. No key, no crash. The feature simply does not activate.
| Integration | Gate Variable | What It Unlocks |
|---|---|---|
| Google Calendar | GOOGLE_CLIENT_ID + SECRET |
OAuth calendar sync for engagement stakeholders |
| Microsoft 365 | MS365_CLIENT_ID + SECRET |
Entra-authenticated calendar sync |
| Stripe | STRIPE_SECRET_KEY |
Invoice mirroring with auto_advance=false |
| Resend | RESEND_API_KEY |
Transactional email (invoice notifications, alerts) |
| AI Extraction | ANTHROPIC_API_KEY or AI_GATEWAY |
Transcript analysis with human-in-the-loop review |
What this means: The builder designed for the real world — where not every API key is available on day one. Each integration has an isConfigured() gate that returns a no-op stub when credentials are absent. The application runs cleanly with zero integrations or all five. This is a production engineering decision, not a corner case — and the builder made it autonomously.
Five artefacts. One pattern: the builder does not just write code — it produces governed systems with security constraints, data integrity guarantees, specialist analysis, documented manifests, and production-grade degradation paths.
This is what governed autonomous coding means. Not AI that writes faster. AI that builds with the discipline of a senior engineering team — threat models before routes, append-only ledgers before UIs, graceful degradation before feature flags.
The artefacts are the evidence. The code is the proof.