talk-dubnov-merge-rate-ai-adoption

name	talk-dubnov-merge-rate-ai-adoption
description	Use when the user asks about Tammuz Dubnov's talk "When Our PM Started Writing Code: What Merge Rate Taught Us About AI Adoption" — including questions about what "AI-native" means, harness engineering, merge rate as an AI-adoption metric, non-technical contributors (PMs, designers) opening pull requests, PR fatigue, the ~74% merge rate / ~84% zero-dev-touch numbers from Autonomy AI, why Uber/Microsoft's AI spend isn't translating to velocity, Shopify as a positive example, Calamarous Coding, feature-flag-driven developer autonomy, or applying his framework to the user's own engineering org.
metadata	{"generated-by":"talk-to-skill","source":"file:user-provided-transcript","generated-at":"2026-06-02T00:00:00.000Z"}

When Our PM Started Writing Code: What Merge Rate Taught Us About AI Adoption — Tammuz Dubnov

Tammuz Dubnov (Founder & CTO, Autonomy AI) argues that "AI-native" doesn't mean giving developers more tokens — it means collapsing the handover so the person who cares and has authority is also the person who can do the work, with agents executing. The bottleneck has moved from code generation to review, coordination, and architectural alignment. Merge rate — and specifically the share of non-technical contributors' PRs that land in production without dev touches — is the signal that tells you whether your org is actually becoming AI-native or just burning LLM budget.

Bundle files

This skill depends on two files that should be present in the same bundle:

• outline.md — a structured index of the talk's sections, named frameworks/concepts, a terminology glossary, and line-range pointers into the transcript.
• transcript.md — the full speech-to-text transcript of the talk (line-numbered). Note: the transcript has no per-speaker labels in the Q&A, and speech-to-text artefacts are present (see grounding rule 5).

If either file is missing, tell the user before attempting to answer.

Grounding rules — MUST follow when answering

1. Before answering any specific question, read outline.md to locate the relevant section, then read that section of transcript.md.
2. When attributing words, quote verbatim from transcript.md. Never put quotation marks around paraphrased content.
3. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer positions from outside knowledge.
4. Cite by transcript line range whenever possible.
5. Speaker attribution is unreliable for this transcript — the source has no per-speaker labels, and the speech-to-text is noticeably garbled in places (e.g. "animated" appears to be "AI native", "harness" is sometimes "harness" and sometimes mistranscribed, "Calamarous Coding" / "clamorous college" / "climate astrology" all refer to the same concept Tammuz names but doesn't fully explain). Prefer phrasing like "Tammuz said..." for the main talk body (since he is the sole speaker for that portion) and "an audience member asked..." for the Q&A. Do not invent attributions for Q&A questioners.
6. Cross-reference any named addressee (e.g. "Uber", "Microsoft", "Shopify") with the transcript before attributing a claim.

Common workflow — apply to every use case below

All use-case sections below follow these shared steps first:

1. Navigate: Read outline.md to locate the relevant section(s), then read the matching range of transcript.md.
2. Quote verbatim: Anchor all claims in direct quotes from transcript.md. Do not paraphrase Tammuz's words while presenting them as a quote.
3. Cite lines: Include transcript line numbers so the user can verify.
4. Respect limits: If the answer isn't in the transcript, say so explicitly. Do not infer from outside knowledge.

How to help with this talk

Apply the speaker's approach to current work

When the user asks "how would Tammuz tackle ?" or wants the talk's framework applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (AI-native = collapsed handover; harness engineering; merge-rate measurement; feature-flag-led developer autonomy).
2. Anchor your suggestion in a verbatim quote of how Tammuz articulates the framework. Then walk through applying it step-by-step to the user's case.
3. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch Tammuz's words to cover cases he doesn't actually address (e.g. he explicitly says "I'm not going to talk about it in this talk" about Calamarous Coding methodology details).

Audit the user's situation against the speaker's framework

When the user asks to "audit", "score", "review", "grade", "check", or "gap-analyse" their AI adoption against Tammuz's framework:

1. Use outline.md → "Named frameworks / concepts" to locate the measurement dimensions: (a) PR count by non-technical contributor, (b) merge rate of those PRs (~74% benchmark), (c) zero-dev-touch rate of merged PRs (~84% benchmark), plus harness principles (agent onboards itself, product-level language, long sessions, self-checking, learns across users).
2. Walk the user through every dimension in order. If they haven't described their state for a dimension, ask before scoring.
3. For each dimension, give a clear verdict (covered / partial / missing) grounded in Tammuz's criteria, with verbatim quotes for what "good" looks like.
4. If a dimension doesn't apply, say so explicitly. Tammuz's numbers are from Autonomy AI's customer base — he doesn't claim they're industry-wide.
5. Summarise gaps at the end with verbatim quotes anchoring what to do about them.

Draft an artifact following the speaker's specification

When the user asks to "draft", "generate", or "produce" something Tammuz described — most commonly a measurement dashboard, a PR risk/size labelling scheme, or a harness-principles checklist:

1. Locate the specification in outline.md → "Named frameworks / concepts" or the relevant transcript section, and capture every constraint Tammuz mentioned.
2. Before producing, quote verbatim Tammuz's prescription so the user can see what the draft is grounded in.
3. Produce a draft that follows his specification faithfully. Match his terminology and his benchmark numbers (74% merge rate, 84% zero-dev-touch).
4. Mark any additions you make beyond Tammuz's explicit prescription as [not from talk — added as a starting placeholder].
5. If the artifact needs elements he didn't address (e.g. a specific CI tool), ask the user rather than inventing.

Factual Q&A about the talk

For any question about what Tammuz said, did, or argued:

• The Q&A is short (5 minutes) and several questions were partial — don't overreach.
• Tammuz explicitly defers details on Calamarous Coding ("I'm not going to talk about it in this talk because there's not enough time").

Surface this talk proactively when relevant

When the user's current work touches themes Tammuz addressed — AI spend justification, PR fatigue, non-technical contributors shipping code, the "AI-native" buzzword, harness engineering, or measuring AI adoption ROI:

1. Briefly note: "Tammuz Dubnov made a related point in his talk on merge rate and AI adoption..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting the quote to the user's situation.
4. Do not over-cite. If the connection feels strained, stay quiet.

Teach / explain concepts from the talk

When the user wants to understand a concept Tammuz covered (AI-native, harness, merge rate, zero-dev-touch rate, Calamarous Coding, the PM→engineer authority collapse):

1. Look up the term in outline.md → "Terminology glossary".
2. Re-explain using his framing first, with verbatim quotes for the key definitions. Be aware several terms are speech-to-text-garbled in the source (see grounding rule 5) — quote what's actually in the transcript and note the likely intended word in brackets if needed.
3. You may add modern context afterwards — but mark it as "not from the talk" so the user can tell which parts are Tammuz's and which are yours.

Key quotes

quotes.md contains pre-extracted verbatim highlights from this talk, organised by theme. When formulating answers, check quotes.md first for strong citable evidence before searching the full transcript.md.