talk-maple-ai-native-devcon-welcome-spec-reviewer

name	talk-maple-ai-native-devcon-welcome-spec-reviewer
description	Use when the user asks about the AI Native DevCon talk "Welcome to AI Native DevCon" featuring Shachar from Buzz (hosted by Simon Maple, Head of DevRel at Tessl) — including questions about why code review is still a bottleneck in 2026, the Spec Reviewer agent architecture, splitting planner vs verifier agents, sub-agent delegation for requirements verification, context window explosion, why giving the agent the base branch beats the diff, ephemeral sandboxes with AWS Agent Core, context engineering for complex agentic tasks, or how to find product gaps the big coding agents overlook.
metadata	{"generated-by":"talk-to-skill","source":"user-pasted-transcript","generated-at":"2026-06-01T00:00:00.000Z"}

Welcome to AI Native DevCon — Building a Spec Reviewer Agent

Shachar, a product manager at Buzz (Tel Aviv), walks through the six-month journey of building "Spec Reviewer" — an agent that verifies whether shipped features actually match their specs. The talk is a hands-on case study in context engineering: why a single coding agent can't reliably verify multi-requirement specs, how splitting into planner + verifier (and then into per-requirement sub-agents) helps, why grounding the agent in the base branch (not the diff) reduces hallucinated requirements, and why ephemeral sandboxes matter when the agent must visit arbitrary customer URLs. The closing message: look for the cracks the big coding agents overlook and build there.

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. The bulk of the talk is delivered by Shachar (the presenter); Simon Maple is named in the event metadata as host but does not have labelled lines in the body. Q&A questions come from unnamed audience members. Prefer phrasing like "the speaker said..." or "an audience member asked..." unless the transcript clearly names someone (e.g. the speaker says "My name is Shachar"). Do not invent attributions.
6. Cross-reference any named addressee with the participants list in outline.md before attributing. Note: the transcript contains speech-to-text artifacts (e.g. "Tessla" likely = Tessl, "vehic" likely = "veteran", "Asian sessions" likely = "agent sessions", "Father. Doc" is a garbled audience-member intro). Quote these verbatim but you may flag them as transcription artifacts.

How to help with this talk

Apply the speaker's approach to current work

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

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (planner/verifier split, sub-agent delegation, base-branch grounding, scoping, ephemeral sandbox).
2. Read the corresponding range of transcript.md for the speaker's exact wording.
3. Anchor your suggestion in a verbatim quote of how the speaker articulates the approach. Then walk through applying it step-by-step to the user's case.
4. If the approach genuinely doesn't fit the user's situation, say so. Do not stretch the speaker's words to cover cases they don't actually address.

Surface this talk proactively when relevant

When the user's current work touches on themes the speaker addressed (context engineering for agents, agents that skip requirements, planner/verifier patterns, agent sandboxing, finding product gaps vs the big AI labs) — even if the user hasn't asked about the talk:

1. Briefly note: "Shachar made a related point in his AI Native DevCon talk on Spec Reviewer..."
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 the speaker covered:

1. Look up the term in outline.md → "Terminology glossary".
2. Read the speaker's explanation in transcript.md.
3. Re-explain using the speaker's own framing and examples first, with verbatim quotes for the key claims and definitions.
4. You may add modern context or extensions afterwards — but mark them clearly as "not from the talk" so the user can tell which parts are the speaker's and which are yours.

Factual Q&A about the talk

For any question about what the speaker said, did, or argued:

1. Read outline.md first to find the relevant section(s).
2. Read the matching range of transcript.md.
3. Answer using verbatim quotes from transcript.md. Do not paraphrase the speaker's words while presenting them as a quote.
4. Cite line numbers so the user can verify.
5. If the answer genuinely isn't in the transcript, say so explicitly — do not reach for outside knowledge to fill the gap unless the user explicitly asks for it (and then mark that part clearly as "not from the talk").

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.