Product engineer

Специализация продукт-инженера: один человек с AI делает продукт целиком, где AI — рычаг. Что осваиваешь, статьи специализации и карта всех специализаций.

There's a question that used to be solved only by team size: how one person can build a whole product — from the user's problem to shipping and the outcome metric. AI takes on the volume of work; a methodology keeps the result coherent. Their sum is the product engineer.

One person builds the product

Previously, to get a product to users you needed a backend engineer, a frontend engineer, a tester, someone for infrastructure. Every seam between them is where the product drifts apart: the contract is understood differently, the data doesn't line up, the release stalls.

The product engineer closes those seams inside one head. The typing of code they delegate to AI (which has "been through" backend and frontend) — but the engineering foundation stays theirs: a product engineer is a full-stack engineer who has been through backend and frontend and understands what happens under the hood. AI took typing off their plate, but not understanding: without it you can neither hand the agent a contract nor accept its result. The person's job is to lead the product: understand the problem, equip and direct the agent, accept the result, get it to the user, and measure the outcome. That's the product-engineering layer — on top of the technical specializations, not instead of them.

This is an engineer, not a manager. A product manager decides what to build and hands it off. A product engineer decides what — and ships it to the user themselves, with AI as leverage. The role takes engineering judgment at every step: the contract for the agent, accepting its code, behavior under load. Without a backend/frontend foundation it doesn't work — you get a manager who can't verify what the agent did.

One body of knowledge in two forms

Every piece of the methodology exists twice:

  • The article — for you. You read it here to understand the subject: why it matters, what the forks are, how to make a decision.
  • The rule — for your AI agent. The same subject as an executable rule the agent applies on every PR.

Read it yourself — you understand what the agent does; give it to the agent — it holds the rule while you think about the product.

A layer on top of the technical craft

The product engineer leans on the technical specializations but doesn't re-learn them — that's AI's job. They're about how it's built; the product engineer is about what and why.

Technical layerWhat it coversWho leads
BackendContracts, data, DDD, brokers, APIsAI + the program
FrontendComponents, state, forms, accessibilityAI + Frontend · Mobile
E2EEnd-to-end scenarios, PlaywrightAI + E2E

These technical programs are the foundation the product engineer already has: they went through them to understand the agent. What's delegated is the typing of code, not the understanding — you direct and verify as an engineer.

The program: the full AI-native cycle

Seven phases — how one person with AI ships a product from idea to metrics. Open the full program →

1. Who the product engineer isthe role and the work cycle: from problem to metric, how it differs from a developer and a PM

2. How AI workshow models work · hallucinations · tokens and cost · context · tool calling · agents

3. Working with agentsthe session loop · understanding a codebase · feature development · finding and fixing bugs · review and testing · configuring agents · Skills · MCP · Memory Bank

4. Start with the problemproblem, not solution · talking to users · the outcome metric · the smallest valuable slice

5. Contract and tooling for AIa language for AI · slice → contract

6. Build and verifyreviewing AI code · executable rules vs SonarQube · accepting the AI's result

7. Ownership and outcomeownership from idea to user · AI as leverage · shipping and metrics as one person · a methodology for AI

Next