Context
A consumer brand wanted a data-intensive web app from a blank repo. The team that would inherit the codebase is small. The team building it is also small. The architecture had to serve both, while doing the bulk of the work with coding agents.
Problem
"Build it for agents" sounds like a tagline. In practice it forces real choices: which framework, which database, which level of abstraction. Pick wrong and the agents either hallucinate around your domain or generate slop that senior engineers spend their week cleaning up.
What we tried first
First sketch had a Postgres-heavy domain layer with clever generic abstractions. It tested well in a notebook. It was uncomfortable for the agents. They wrote against it confidently and wrong. The abstractions weren't the problem; they were one layer too deep for the agent to keep in its head.
What we shipped
Next.js, Bun, Postgres on AWS, Terraformed infra. Strict TypeScript. A flatter domain layer with explicit naming. Sentry from day one. Structured logs piped to CloudWatch with dashboards humans actually open. A Cursor rules and planning template system tuned to the project's domain language. CI runs strict linting, type checking, unit tests, integration tests, and end-to-end tests on every push, so both humans and agents know in minutes if anything broke.
Outcome
Production app shipped on the schedule the client needed. Roughly 90% of the code generated by agents under senior review. Codebase reads cleanly to the team that will inherit it; conventions documented in the same repo as the code. Acceptance rate on agent output climbed past the Code Corp average once domain rules were dialed in.
What we got wrong
Initial Cursor rules were generic, copied from internal templates. The agents took shortcuts that made sense in general and made no sense in this domain. Once we rewrote the rules in the project's own language, with examples drawn from the repo, acceptance rate jumped. Bring rules to the project. Don't bring the project to your rules.