Founding Lead Playbook: Running Product, Architect & Engineering with AI Agents + 2 Humans

There are a lot of shallow "10x with AI" threads out there. This isn't one of them. This is the actual operating model I use to run product, architecture, and backend engineering as a single person, with one human collaborator (a frontend developer) and an AI coding agent doing the heavy lifting on everything else.

The premise: a stakeholder hands me a one-sentence goal. From there, I own product definition, system design, and technical execution end to end. I have exactly one other human in the loop. Everything else — backend, migrations, tests, infra scripts — runs through an AI coding agent that I direct, review, and gate.

The honest answer to "does this scale" is: yes, but only if you restructure how you work, not just what tools you use. Bolting an AI agent onto a traditional PM → architect → engineer pipeline doesn't collapse the timeline — it just moves the bottleneck to your own attention. Here's the actual playbook, including the parts that broke before I fixed them.

In a multi-person team, a lot of calendar time goes to reconciling context between people — PRD reviews, architecture alignment, ticket grooming. Collapse those roles into one person and that coordination latency mostly disappears. What doesn't disappear, and what people underestimate, is the judgment load: you still have to make every product call, every architectural tradeoff, and every "is this actually correct" review — just faster and back-to-back.

You still own the architecture, the product vision, and the final quality gate. The agent owns boilerplate, migration scripts, test scaffolding, and the first draft of business logic. The frontend developer owns UI/UX and interaction — and should never be blocked waiting on you.

The single biggest failure mode in this model is context-switching mid-thought — writing code while you're still deciding what the feature even is. Treat each phase as a distinct mode with a distinct output artifact, and don't move to the next phase until the current one has a concrete deliverable.

Phase 1 — Product definition: decouple "what" from "how".

When a vague goal lands (e.g. "we need a multi-tenant billing aggregator"), resist opening the editor. First pass is product framing:

"Analyze this objective. Strip vanity features. What are the 3 core user flows that define the MVP? What are the day-one edge cases we can't defer?"

Treat the agent's output as a first draft, not a spec — it will over-scope and hallucinate requirements that sound plausible but weren't asked for. Your job is subtractive: cut it down to a backlog of user stories you'd actually defend to a stakeholder.

Phase 2 — System design: harden the schema and the contract before any code exists.

The artifacts that matter here are the data schema and the API contract — not diagrams for their own sake. A concrete prompt:

"Design a PostgreSQL schema for these user stories. Every tenant-owned table needs an explicit

tenant_id

foreign key, not just an implicit assumption of isolation. Generate the migration. Then produce an OpenAPI 3.0 spec for the endpoints, and flag which mutating endpoints need idempotency keys."

One correction worth making explicit: Postgres Row-Level Security (CREATE POLICY

) is a real and valid tenant-isolation mechanism, but it's not the only one, and for most application-layer multi-tenancy, filtering by an indexed tenant_id

column at the service layer — never trusting the client for that value, always deriving it from an authenticated token — is simpler to reason about and test than RLS policies that live outside your application code and are easy to forget to enable on a new table. Pick one mechanism deliberately and apply it uniformly; the actual bug that bites teams isn't "which mechanism," it's the one table someone forgot to scope.

Once you approve the schema and contract, that OpenAPI document becomes the single source of truth for both the backend implementation and the frontend integration. Nobody should be inferring the contract from someone else's code.

Phase 3 — Execution: agentic implementation against a locked contract.

With the contract locked, point the agent at it directly:

"Implement the endpoints in

billing-openapi.yaml

. Write integration tests alongside the implementation, not after. Mock the third-party payment gateway. Every soft-deletable entity must be excluded from lookups by default — verify this with a test, not a comment."

Watch it iterate — writing routes, wiring the data layer, running its own tests until they pass. Your job shifts to review: does the generated code actually implement the invariant you asked for, or does it look right at a glance and fall apart under a concurrent-write or soft-delete edge case? This is the phase where unverified trust in agent output causes the most expensive bugs — see Trap 1 below.

Phase 4 — The frontend handshake: never let the human be the bottleneck.

While the agent works the backend, your frontend developer should never be idle waiting for a real server to exist. The fix is a fast fake:

The frontend developer builds against a fake that behaves exactly like the real API's shape will, in parallel with backend implementation — not after it.

Phase 5 — Defense-in-depth review before merge.

When both the backend implementation and the frontend PR are ready, run a deliberately adversarial pass — not a rubber stamp:

"Audit the newly merged routes for SQL injection risk, unhandled promise rejections, N+1 query patterns, and any endpoint that filters a mutation by ID alone without also checking an ownership/tenant claim."

Then do a manual read of the frontend PR, boot the real stack (not just unit tests — actually exercise the flow), and run an integration smoke test end to end. Automated audits catch pattern-matchable classes of bug; they do not catch "this endpoint is logically correct but violates an invariant the codebase depends on elsewhere." That still needs a human who knows the codebase.

This looks smooth described linearly. In practice there are three specific failure modes that will bite you if you don't build explicit countermeasures for them.

An AI coding agent will produce large amounts of syntactically correct, plausible-looking code very quickly. It has no felt sense of how painful a given shortcut will be to live with in six months, and — more dangerously — it will happily generate code that looks like it respects an invariant (soft-delete, tenant scoping, transactional atomicity) without actually doing so, because the surface pattern is right even when the substance isn't.

Concrete example of the failure shape: a lookup helper that appears to respect soft-delete because it uses the same repository method as everywhere else, but a nearby "quick fix" swaps in a raw UPDATE

/increment

call that bypasses the ORM's default filtering entirely. Nothing fails at compile time. Nothing fails in a shallow unit test that mocks the repository. It fails in production, quietly, against a real row that should have been excluded.

Mitigations that actually work:

UPDATE

/increment

/raw-query calls that skip the ORM's default scoping — list every one and justify each." This catches the class of bug that a generic code-quality pass misses, because the code isn't badly written — it's precisely wrong in a way that only matters if you know the invariant it's supposed to uphold.Jumping between product framing, system design, and low-level debugging every twenty minutes measurably degrades decision quality — you start making sloppy tradeoffs by mid-afternoon because your brain is still half in the previous mode. The fix isn't willpower, it's scheduling:

Protect the boundaries. Don't let a "quick architecture question" bleed into an execution block, and don't context-switch back to design mid-implementation just because something looks solvable in five minutes — write it down and come back to it in the next design block.

An AI-assisted backend can move several times faster than a human doing frontend implementation and design iteration. If you push that raw velocity downstream unfiltered, your frontend collaborator ends up perpetually behind, context-switching on every drip-fed change, and reasonably start to feel steamrolled.

Mitigations:

These are the actual system-prompt shapes I keep reusing, generalized so they're useful regardless of stack.

Architecture-mode system prompt:

You are acting as a principal-level solution architect for cloud-native systems.
Optimize for security, cost, and long-term maintainability over cleverness.

Rules:
1. Prefer a relational database with explicit foreign keys and indexes over
   schemaless flexibility, unless there's a specific reason not to.
2. Every tenant-owned or user-owned resource needs an explicit, indexed
   ownership column, checked at the service layer — never trust client input
   for it, always derive it from an authenticated context.
3. Favor a modular monolith over microservices until there's a concrete,
   measured scaling reason to split — don't design for hypothetical scale.
4. APIs should be stateless; sessions/identity travel in signed tokens, not
   server-side session state.
5. Mutating endpoints that could plausibly be retried (payments, anything
   with side effects) need idempotency keys.

Output structured markdown — schema tables, OpenAPI fragments. No filler prose.

Pre-merge review prompt:

Review this diff as a pedantic, security-focused reviewer. Check specifically for:
- Injection risk or any raw query that bypasses the ORM's default scoping
  (soft-delete filters, tenant/owner filters).
- Missing error handling, unhandled promise rejections.
- N+1 query patterns in data fetches.
- Any delete/update filtered by ID alone, without an ownership or tenant check.
- Hardcoded secrets or config values.
- Any comparison of a secret value (API key, token, signature) using a
  non-constant-time equality check.

For each finding: exact location, severity, and a corrected code block.

This way of working is genuinely faster — you're not waiting on a meeting to change a column, or a QA cycle to verify a basic endpoint. But the speed is entirely conditional on one thing: your review discipline scaling with your output. An AI coding agent will write code as fast as you can specify it. It will not tell you when the specification itself is wrong, and it will not notice when its own output looks correct but violates an invariant it was never told mattered.

Your value in this model isn't typing speed — it never really was. It's how precisely you can define the problem, how much of the actual invariant-space of the system you can hold in your head during review, and how well you can keep a human collaborator unblocked while the machine does the parts that don't need taste.

Wear one hat at a time. Trust but verify, every time, especially when the code looks fine.