Give the agent a job, context, and constraints.
A useful AI role knows the user, product surface, acceptance criteria, risk, and what output is expected.
Back to Playbook
AI collaboration
AI collaboration model
How I use AI collaborators while keeping judgment human-owned.
01Context
Why AI needs roles.
I do not treat AI as one generic assistant. I treat it as a set of bounded collaborators with different jobs: product manager, system architect, UX engineer, implementer, QA tester. Each role needs context, constraints, expected artifacts, and a clear human review boundary.
The more complete version of the model has eight roles: research analyst, product manager, product designer, system architect, implementation agent, QA and security reviewer, technical writer, and product operator. Those are not job titles for the AI. They are lenses for deciding what kind of artifact is needed and how it should be reviewed.
The important idea is that delegation should increase clarity. If the work is serious, the human still owns the problem framing, taste, tradeoffs, risk acceptance, verification, and final claims. AI can accelerate artifacts; it should not blur accountability.
02Model
The collaboration model as role design.
The model is the part of the article where the idea becomes usable: a sequence of decisions, artifacts, or checks that can guide real product work.
Ask for artifacts, not vibes.
The expected output might be a brief, user story, system map, screen state, code change, test note, or launch blocker list.
Keep human ownership explicit.
AI can draft, inspect, generate, and test. The human owns product judgment, taste, risk acceptance, verification, and final claims.
AI collaboration is shown as bounded roles around one human-owned judgment layer.
- 01Product manager
Structures problems, stories, tradeoffs, priorities, acceptance criteria, and launch questions.
- 02System architect
Shapes architecture, data, APIs, integrations, failure modes, and non-functional constraints.
- 03UX engineer
Turns workflows into screens, components, empty/error states, content hierarchy, and interaction quality.
- 04Implementer + QA tester
Produces small code changes, then exercises happy paths, edge cases, regressions, and residual-risk notes.
Human ownsjudgment · taste · risk · verification · claims
03Core belief
AI is leverage, not authorship.
A model can help generate product artifacts quickly, but authorship of the product claim stays with the person deciding what matters, what is true, and what is safe to ship.
This is why my AI process separates role, task type, scope, non-goals, evidence, and stopping conditions. The model can recommend and implement. It should not silently decide the product purpose, target user, brand standard, release risk, customer message, deployment, or public claim.
04Working method
Context is the quality control system.
The better the product dossier, the better the AI output. Roles and constraints make it easier to review the work because the work has a stated target.
The useful prompt pattern is consistent: load the relevant source-of-truth documents, assign the right role, say whether the task is analysis, design, implementation, or verification, define scope and non-goals, define expected evidence, and ask the AI to surface assumptions and blockers.
05Frontier-product relevance
Delegated work needs governance.
As coding agents and research/product tools become more capable, the bottleneck shifts toward direction-setting, review, eval-like checks, launch criteria, and trust.
06Artifacts
What this leaves behind.
I use artifacts as evidence of thinking. They make product judgment reviewable, reusable, and easier to connect back to the work.
Product manager
Structures problems, stories, tradeoffs, priorities, acceptance criteria, and launch questions.
System architect
Shapes architecture, data, APIs, integrations, failure modes, and non-functional constraints.
UX engineer
Turns workflows into screens, components, empty/error states, content hierarchy, and interaction quality.
Implementer + QA tester
Produces small code changes, then exercises happy paths, edge cases, regressions, and residual-risk notes.