Turbo AI PM
Kits / workflow

Coding assistant / IDE copilot

Generates, completes, or reviews code. Work top to bottom, or jump to the decision in front of you — each one links to the metrics, tool, and playbook that answer it.

The riskCode that passes a benchmark but fails in your codebase.
Take it to your PRD, Notion, or launch review.

The chain

What has to be true at each layer for this product to create value. The hypotheses between layers are yours to hold — and to check after launch.

Model / SystemIs the AI behaving correctly?
Q-08 Pass@K↔ B-07P-01 Latency (p50 / p95 / p99)↔ C-01C-01 Cost per Inference↔ P-01
If suggestions compile, pass tests, and arrive at typing speed, developers accept them.
Product / UserIs the user accomplishing the task?
B-07 Acceptance Rate↔ B-06B-06 Human Override / Edit Rate↔ B-07B-01 Adoption Rate↔ B-04
If accepted code survives review, cycle time drops without raising defect rates.
BusinessIs the product creating meaningful value?
Cycle time · defect and revert rate · engineering hours

↔ marks each metric's shadow metric — the one to watch alongside it so the number can't improve while the product gets worse.

01

Before you build

Should this be AI at all — and which capability fits?

Before scoping a model, check that the problem has a pattern to learn, data you can reach at decision time, and a cost of being wrong you can live with. If a rule would get most of the value, the rule is the better product.

For Coding assistantThe test for a coding assistant: is the work pattern-heavy (boilerplate, tests, conversions) rather than novel design? Pattern-heavy work is where suggestions get accepted.
Check whether this needs AI →
Evidence, business implication, deeper reading
Evidence you need: Examples of the decision being made today, where the data lives and whether it is available at decision time, and an honest estimate of what a wrong answer costs.
Business implication: Choosing AI for a problem rules could solve buys you cost, latency, and a maintenance burden with no extra value.

Check whether the unit economics can work

Estimate cost per completed task against the value of that task before building — margins are set by architecture, not tuning.

MetricsC-02 Cost per Resolved Task↔ B-02C-01 Cost per Inference↔ P-01
Estimate ROI & unit economics →
Evidence, business implication, deeper reading
Evidence you need: Volume estimate, token estimate per task, model pricing, and the human cost (or revenue) per task.
Business implication: A feature that works but destroys gross margin is a failed product.

Make the case to build it

Ask for one specific decision by a specific date: the problem in their units, why AI and not rules, the expected value with its assumptions visible, the risk said out loud, and the checkpoint you will report back at.

MetricsB-07 Acceptance Rate↔ B-06
Build the business case →Make the case & defend the work →
Evidence, business implication, deeper reading
Evidence you need: The baseline (what today costs and achieves), a value range with the two assumptions that move it most, cost per completed task vs. the human cost, the rules-vs-model comparison, and the top failure modes with their mitigations.
Business implication: A named checkpoint turns a bet into a staged decision — much easier to approve than an open-ended one. For this product: Cycle time · defect and revert rate · engineering hours.

Define what the model may do, must never do, and needs to know

Write the operating envelope before anyone writes a prompt: context the model sees, unforgivables, and what happens when it fails.

For Coding assistantDefine repo context access, languages in scope, and what it must never touch (secrets, prod config).
Write the AI PRD →
Evidence, business implication, deeper reading
Evidence you need: Agreed context spec, a written list of unforgivables, and a fallback for each failure mode.
Business implication: Scope decided here drives both cost and risk for the life of the feature.
02

Evaluate

Choose what to measure

Pick one metric per layer and a shadow metric for each, so no number can improve while the product gets worse.

MetricsQ-08 Pass@K↔ B-07B-06 Human Override / Edit Rate↔ B-07B-07 Acceptance Rate↔ B-06Q-07 BLEU / ROUGE↔ B-06P-01 Latency (p50 / p95 / p99)↔ C-01C-01 Cost per Inference↔ P-01
Calculate any of 38 metrics →
Evidence, business implication, deeper reading
Evidence you need: The starter metrics below, each paired with the metric that catches it being gamed.
Business implication: The layer-3 metric is the one leadership will ask about — name it now. For this product: Cycle time · defect and revert rate · engineering hours.

Establish a baseline worth beating

A number means nothing without a comparison. The simple heuristic and the incumbent are the two baselines that get skipped.

For Coding assistantNo suggestion at all: cycle time and defect rate for comparable changes.
MetricsQ-08 Pass@K↔ B-07B-07 Acceptance Rate↔ B-06
Evidence, business implication, deeper reading
Evidence you need: Zero-rule, heuristic, and incumbent scores on the same eval set, measured the same way.
Business implication: If a heuristic gets 80% of the value, the model has to justify its extra cost.

Design an evaluation you can trust

Representative data, a scoring method that matches the task, and a holdout nobody tunes against.

MetricsQ-08 Pass@K↔ B-07P-01 Latency (p50 / p95 / p99)↔ C-01C-01 Cost per Inference↔ P-01
Evidence, business implication, deeper reading
Evidence you need: A golden set with an owner and a size target, slices defined up front, and a judge calibrated against humans.
Business implication: A weak eval means you ship blind and cannot explain failures afterward.
03

Ship

Decide whether it is ready to ship

The bar depends on blast radius and reversibility, not on the accuracy number alone.

For Coding assistantGreen for suggestions in the editor; amber for anything that commits or merges on its own.
MetricsQ-08 Pass@K↔ B-07P-01 Latency (p50 / p95 / p99)↔ C-01
Decide go / no-go →Make the case & defend the work →
Evidence, business implication, deeper reading
Evidence you need: Your quadrant, the threshold for it, the eval result against the baseline, a working fallback, and the numbers you promised at the funding checkpoint.
Business implication: A documented bar turns post-launch blame into post-launch learning.

Design what users see when it is wrong

Every AI flow needs a designed failure state: specific copy, a way to recover, and a human path.

For Coding assistantEasy reject, and one-click revert when an applied suggestion breaks something.
Design for non-determinism →
Evidence, business implication, deeper reading
Evidence you need: Fallback copy for timeouts, low confidence, out-of-scope requests, and refusals.
Business implication: Users forgive visible, recoverable failures; they abandon silent ones.
04

In production

Set up monitoring that separates "the model changed" from "the world changed"

Alert on breakage, review drift daily, review quality weekly, review business impact monthly.

MetricsQ-08 Pass@K↔ B-07P-01 Latency (p50 / p95 / p99)↔ C-01C-01 Cost per Inference↔ P-01
Evidence, business implication, deeper reading
Evidence you need: Error and latency alerts, input-mix and confidence drift, slice quality, and the layer-3 metric on a monthly cadence.
Business implication: Degradation you catch in a week costs far less than one you find in a quarterly review.

Turn production signal into a better next version

Design what each interaction captures and where it goes — implicit, explicit, and outcome signal feeding the eval set.

For Coding assistantRejected and reverted suggestions show where the model misreads your codebase.
MetricsB-07 Acceptance Rate↔ B-06B-06 Human Override / Edit Rate↔ B-07
Evidence, business implication, deeper reading
Evidence you need: A named owner for the signal pipeline and a path from user action to golden set.
Business implication: The flywheel is the only part of an AI feature that compounds over time.
!

Something looks wrong

Start from what you're seeing. Each symptom points to its most likely cause and the metrics that confirm it.

High acceptance, more reverts
Accepted-but-wrong code getting through review.
CheckB-07 Acceptance Rate↔ B-06B-06 Human Override / Edit Rate↔ B-07
Suggestions arrive too late to use
Latency above typing speed — developers have moved on.
CheckP-01 Latency (p50 / p95 / p99)↔ C-01Investigate →
Benchmark Pass@K is high, developers are unimpressed
Benchmark problems do not look like your repository.
CheckQ-08 Pass@K↔ B-07Investigate →

Other kits

RAG / knowledge assistant Agents & multi-step pipelines Copilot / drafting tool Customer-facing chatbot / support Classifier / triage & moderation