It is a Tuesday morning at a regional health system. The Chief Medical Officer has just approved a behavioral-health pilot. They need a patient-intake service that captures consent, demographics, and a depression-screening questionnaire — tenant-scoped to the pilot clinics, role-based for clinicians and front-desk staff, with audit trails for compliance. Three vendors have quoted four months. The internal team has quoted six.
By Wednesday lunchtime, an enterprise architect has done the following on a laptop:
- Sketched the bounded context — intake owns submissions and consent, integrates with the existing EHR via events, leaves clinical documentation to the EHR
- Described the domain to an AI agent in plain language: entities, roles, tenant model, regulated fields, audit requirements
- Reviewed roughly 240 lines of generated Carrier source: a service, an auth jwt, three model declarations, four named type contracts, two healthcare.questionnaire instruments, six action workflows, eight thin routes, and a tenant-aware policy block
- Run carrier fmt, carrier check, and carrier build --target node — all green on the first pass
- Run carrier openapi > openapi.json — the API contract is ready for the integration team
- Run carrier migrate generate — schema migrations ready for DBA review
- Inspected .carrier/manifest.json to confirm tenant scoping, role protection, and PII annotations on regulated fields
By Thursday morning, the integration team is generating clients from OpenAPI. By Friday, the service is deployed to a sandbox and the clinical team is testing the questionnaires through the UI. By the following Tuesday, the pilot is running with real patients.
This is not a story about replacing engineers. It is a story about replacing the parts of engineering that should never have been done by hand.
Conventional stacks could not produce this outcome. The plumbing alone — routing, validation, persistence, authentication, OpenAPI, migrations, policy — would have consumed weeks. The AI-generated code in those stacks would have arrived in three different shapes from three different runs, and each would have needed careful manual reconciliation before it could ship. The supposed speed advantage of generation would have evaporated in the cleanup.
Carrier produced a single shape because it has only a few shapes. The architect never wrote a controller, a validator, a serializer, or an OpenAPI annotation. They wrote what only a human can write: a description of the business — its entities, its rules, its boundaries, its obligations. The compiler — and the agent operating within its rails — produced everything else.
This is what the rest of the book is about. The story above is not aspirational. It is what becomes possible when enterprise architecture and domain knowledge are brought to life in a language whose constructs match what architects actually care about.
Part One
Why Carrier
The case for domain-native enterprise services
❦