One Architect + Claude + MCP = A Full Engineering Squad: The Operating Model I'd Install at Your Company

Here is the uncomfortable math most engineering leaders haven't run yet: a large share of a product team's payroll goes to translation work — turning decided architecture into typed code, writing the CRUD nobody argues about, keeping three layers consistent with each other. That work is now automatable to a degree that changes staffing math. This post is the exact operating model I use — one architect directing Claude through MCP — and what installing it inside a company looks like.

The operating model

My setup has three layers. At the top, me: owning the data contracts, the trust boundaries, and the review. In the middle, Claude — not as a chat window, but as Claude Code running against the real repository with a maintained CLAUDE.md covering the conventions, the architecture, and the things it must never do. At the bottom, MCP servers that give the model governed hands: Postgres for real schema and data, Playwright for driving and verifying the actual UI, filesystem and Git for the codebase itself.

The result is that a single instruction — "add cursor-based pagination to the orders API and update every consumer" — executes across database, backend, frontend, and tests in one coordinated pass, with the model reading real schema over MCP instead of hallucinating it, and verifying its own work in a real browser before I review.

What this replaces — and what it doesn't

• Replaced: the mechanical middle of feature work — scaffolding, wiring, consistency maintenance, test boilerplate, migration chores. This was most of the payroll.
• Amplified: the architect. Decisions land in production the same day they are made, because there is no handoff chain to traverse.
• Not replaced: judgment. Someone still decides what the schema is, where the trust boundary sits, and whether the generated diff is actually correct. That someone is the hire that matters now.

Installing this at a company: the 30-day version

This is what I would do in my first month inside a team that hasn't operationalized AI yet:

• Week 1 — write the constitution. A CLAUDE.md per repo: architecture, conventions, forbidden patterns, verify commands. This single file is the difference between an AI that helps and an AI that vandalizes.
• Week 2 — wire MCP to the real systems. Read-only Postgres first, then the design system, then the browser. Governed access beats copy-pasted context by an order of magnitude.
• Week 3 — pick the worst recurring chore (migrations, test backfill, dependency upgrades) and automate it end-to-end as a proof.
• Week 4 — measure. Cycle time on the automated lane versus the manual lane, in front of the team. Adoption follows evidence, not mandates.

Companies do not have an AI-model problem — every vendor sells the same models. They have an operating model problem. The winners are the ones with an architect who has already run this system in production, on their own products, with their own money on the line.

I have. Every product on this site was built under exactly this model, and the Claude Code efficiency roadmap documents the playbook lesson by lesson.