Principle
When generation is cheap, the bottleneck moves up the stack — from typing code to choosing what deserves to exist, how it should feel, and what must stay human-owned.
A product engineer optimizes for outcomes in the world: users, revenue, trust, revision speed. A software engineer optimizes for correctness inside the system: APIs, tests, performance. AI-native builders sit at the intersection — and must not confuse the two chairs.
The decision
DEC_002
Product engineer → what / why / for whom
Software engineer → how / safely / for how long
AI-native builder → orchestrates both, owns the seamWhat humans should own
| Own | Share with AI | Delegate to AI |
|---|---|---|
| Problem selection | Discovery synthesis | First-draft research |
| Taste and UX calls | Layout exploration | Boilerplate UI |
| Pricing and scope | Option comparison | Scaffold code |
| Architecture bets | Trade-off writeups | Repetitive implementation |
| What ships this week | Test ideas | Formatter-level edits |
Workflow
- Write the user outcome in one sentence before opening any tool.
- Ask: is today’s risk product or engineering? Pick the chair deliberately.
- Use AI to widen options early and narrow with human commits late.
- Keep a revision trail — what changed after user contact, not just what the model suggested.
Tooling
Cursor, Claude Code, Lovable, v0 — interchangeable for drafts. The mindset does not depend on which one you opened first.
Common mistakes
- Measuring productivity in lines generated instead of decisions clarified.
- Hiding behind “the agent chose it” for product calls that are yours.
- Refusing AI for implementation while also refusing to own product judgment.
Further reading
- Your mesh / footnotes stack — inquiry loop, folio, shipping discipline (see angelguirao.com).