AI-native tearsheet
Structuring Product Teams in the Age of GenAI
Small, senior, cross-functional teams use GenAI as elastic capacity, not as a separate function. The company paves the road for safe agentic work; each team decides how to drive on it.
By Tim Vasil •
1Team shape
The unit of delivery is a small, senior, cross-functional team that owns a product area end to end. Agents extend the team’s capacity; they do not replace its judgment.
- Small and senior. Four to seven people with product, design, and engineering in one room. Fewer junior seats and a higher floor on judgment: agents now absorb the volume work that used to justify headcount.
- One team, one outcome. Each team owns its domain from discovery through operations. No hand-off to a QA or release team, and no separate “AI team” doing product work on the team’s behalf.
- Agents are capacity, not a function. Plan agent work like elastic compute: burst it on well-specified work, budget it visibly, and never let “the agent did it” become a hand-off of accountability.
- The platform is a team. One central team owns the paved road below and is measured on its adoption. Practice spreads through embedded champions and a working guild, not a mandate.
- Roles move up the stack. Engineers orchestrate and verify more than they type. Product managers write specs precise enough for an agent to execute. Designers prototype in working code.
2The paved road: a company-wide AI platform
Product teams should not assemble their own AI stack. Provide common primitives, guardrails, and defaults centrally, then let teams customize their workflows on top.
| Platform construct | Provided centrally |
|---|---|
| Models & interfaces | Approved models; chat, IDE, and API access; model routing where it pays; enterprise data and privacy controls |
| Coding & agent runtime | Interactive coding agents plus asynchronous cloud agents that can run code and tests and open pull requests |
| Context layer | Source, architecture, product docs, tickets, APIs, runbooks, and internal knowledge reachable by agents through repo context, MCP, and other controlled connectors |
| Instructions & skills | Version-controlled AGENTS.md, coding standards, architectural rules, reusable agent skills, and shared prompts and workflows |
| Execution environments | Sandboxed development environments; reproducible builds; scoped network and tool access; ephemeral credentials |
| Verification & evals | CI, automated tests, type and lint checks, security scanning, agent evals, acceptance criteria, and regression suites |
| Identity & permissions | Least-privilege agent identities; explicit tool permissions; protected environments; human approval for consequential actions |
| Observability & governance | Agent and action logs, traceability to a human owner, usage and cost visibility, quality metrics, and auditability |
| Memory & feedback loops | Decisions, post-mortems, and review outcomes written back into the context layer, so agents and new hires inherit what the team learned |
Standardize the primitives and guardrails. Let teams optimize the workflow.
3Autonomy levels
Autonomy is set per workflow, not per team or per tool. The same team may run its maintenance queue at A4 and its production deploys at A3.
- A1AssistAI advises; a human performs the work.
- A2PairHuman and AI work interactively, turn by turn.
- A3DelegateA human defines the outcome; the agent executes independently and returns a result for review.
- A4AutonomousThe agent identifies or receives eligible work, executes it, verifies it, and produces a PR or action. Humans govern exceptions and consequential gates.
- A5Pre-authorized actionThe agent may take bounded production actions within explicit policy. Use selectively.
Autonomy is earned through verification.
Bounded scope + tests and evals + observability + reversibility + low blast radius → greater autonomy
4GenAI across the SDLC
Humans keep intent, judgment, and accountability at every stage. Agents take the volume, and the autonomy they are given rises with how well the stage can be verified.
| SDLC stage | Humans own | Role of GenAI and agents | Typical autonomy | Paved-road tools |
|---|---|---|---|---|
| Discover & understand | Customer empathy, problem selection, judgment | Research; synthesize interviews and support; find patterns; interrogate analytics; generate hypotheses | A1–A2 | Chat and LLM; transcript tools; analytics; search and knowledge connectors |
| Define & specify | Product intent, outcomes, priorities, acceptance criteria | Draft and refine specs; expose ambiguity; enumerate edge cases; convert requirements into structured, agent-executable tasks | A1–A2 | LLM; product docs; ticketing; internal context |
| Design & prototype | UX judgment, taste, user validation | Generate alternatives; prototype UI and flows; create assets; critique designs; build disposable prototypes | A2–A3 | Figma AI; v0 and Lovable-style tools; coding agents |
| Architecture & plan | System boundaries, invariants, NFRs, irreversible decisions | Inspect the codebase; research alternatives; identify dependencies; draft ADRs; decompose work for humans and agents | A2–A3 | Coding agents; repo and docs context; architecture skills; MCP |
| Implement | Technical direction, hard judgment calls, ownership of correctness | Generate implementation; refactor; debug; migrate; execute bounded issues independently; run parallel workstreams | A2–A4 | Cursor, Claude Code, Codex, Copilot; cloud coding agents; sandboxes |
| Test & verify | Risk model, critical behaviors, the acceptance bar | Generate tests; find missing cases; run unit, integration, and E2E suites; fuzz and adversarial testing; diagnose failures | A3–A4 | CI; Playwright; pytest and Jest; coding agents; eval framework |
| Review | Architecture, maintainability, intent, consequential judgment | Automatic first-pass review; correctness, security, and style checks; compare the change against the spec; suggest or apply fixes | A3–A4 | AI code review; CodeQL and SAST; agent skills; repository instructions |
| Integrate & release | Release risk and authorization | Resolve CI failures; write release notes; assess change risk; verify release criteria; prepare the rollout | A3–A4 | GitHub Actions and CI; deployment platform; policy gates |
| Deploy | High-impact production authorization | Execute the validated deployment workflow; monitor the rollout; halt or roll back automatically on predefined conditions | A3–A5 | CI/CD; feature flags; policy-as-code; deployment automation |
| Operate & respond | Incident command, customer impact, consequential decisions | Correlate logs, traces, and events; investigate hypotheses in parallel; identify suspect changes; propose remediation | A2–A4 | Datadog and Sentry; OpenTelemetry; runbooks; production-read MCP and tools |
| Maintain & improve | Prioritization and systemic improvement | Find and fix flaky tests; dependency upgrades; vulnerability remediation; docs drift; repetitive refactors; tech-debt queues | A4 default where verifiable | Autonomous and cloud agents; Renovate and Dependabot; scanners; CI |
5The expected engineering workflow
The default used to be
- Design
- Code
- Review
- Ship
It is increasingly
- Frame
- Decompose
- Delegate
- Parallelize
- Verify
- Integrate
- Ship
A single engineer may simultaneously:
- pair with an agent on an ambiguous architectural problem,
- delegate two well-specified implementation tasks,
- run multiple agents in parallel on independent work,
- let autonomous agents work the maintenance queue,
- and review completed work surfaced by agentic code review.
The scarce resource shifts from code production to intent, decomposition, context, judgment, and verification.
6Expectations for every product team
- Use AI by default where appropriate, not AI for its own sake. Repetitive manual work should prompt the question: could this be delegated or automated?
- Move work up the autonomy ladder. Continually identify workflows that can safely move from Assist to Pair to Delegate to Autonomous.
- AI reviews before humans do. Every substantive change gets automated AI and static review before it consumes scarce human review attention.
- Humans remain accountable. An agent may author all of a change; a human, or an explicitly approved policy, still owns the outcome.
- Create verification before autonomy. If output cannot be independently tested, evaluated, observed, or reversed, do not increase autonomy.
- Make the codebase legible to agents. Clear module boundaries, fast tests, and current docs are now throughput multipliers, not hygiene. Treat
AGENTS.mdand the context layer as product surfaces with owners. - Standardize what repeats. A team-level agent workflow that works should become a reusable platform capability.
- Measure outcomes, not AI usage. Track lead time, throughput, change failure rate, escaped defects, reliability, toil, developer experience, and cost. Not prompts, tokens, or percent of AI-generated code.