My Slack Feedback Now Ships Itself

At-a-Glance

• Verdict: Watch fully
• Core thesis: Claude Sonnet 4 (Fable) enables a fully automated feedback-to-PR pipeline where Slack feedback is ingested, structured, batch-fixed by AI, and merged overnight without human input—shipping features while you sleep.
• Why it matters: This is a working end-to-end AI agent factory for product development: feedback collection → structured processing → batch PR generation → automated merge. It demonstrates both the leap in model capability (Sonnet 4) and a repeatable workflow for AI-assisted shipping.
• Best use: Study the toolchain (RiffRaff + Slack MCP + Cursor + Compound Engineering) and batch-review pattern; assess for Ken's agent ops, product dev velocity, and AI GTM workflows.

Executive Summary

The speaker (building Quora v2 at Avery) describes a production workflow where Claude Sonnet 4 ('Fable') autonomously converts Slack feedback into shipped code. The system runs twice daily: a scheduled Cloud Cowork task scrapes a Slack alpha channel, classifies feedback (text, screenshots, RiffRaff recordings), downloads attachments, and structures everything into YAML/markdown. A separate Cursor agent (using the 'LFG flow' from Compound Engineering) then batch-processes all items in a single PR branch, fixes what it can, leaves notes for human-required decisions, and consults a strategy doc.

The speaker manually reviews via a /polish preview server but emphasizes the batch paradigm: 17 feedback items → 1 PR to review, not 17 separate PRs. The workflow's climax occurred when he set the system to auto-merge if CI passes, woke up to shipped features and positive user feedback, and realized he had been asleep during deployment. He credits Sonnet 4 as the model that made tasks that 'wanted to work suddenly start working,' calling it 'my favorite model ever' and 'a big shift.'

Key infrastructure: RiffRaff (open-source React wrapper that records DOM clicks, voice, network requests, errors as a shareable zip—'richer than video'), Slack MCP for message fetching, Compound Engineering's LFG flow (which includes a 'compound step' that prevents repeat mistakes), and Cursor for the agent execution. The system is not yet fully automated (manual Cursor invocation, manual review), but the speaker plans to close those gaps and integrate learnings into Compound Engineering.

This is a concrete, shipped example of an AI product-development factory: structured ingestion, batch reasoning, overnight merge. The speaker solicits feedback and acknowledges it's 'what works for me,' not gospel, but the velocity gain—features shipping while asleep—represents a new paradigm for solo/small-team product work.

Key Takeaways

• Claim: Claude Sonnet 4 ('Fable') represents a capability step-change that enabled previously failing tasks to work reliably in this workflow. | Evidence: Speaker twice emphasizes 'stuff that I wanted to work suddenly started working,' calls it 'my favorite model ever,' and 'feels like a big shift.' The entire overnight auto-merge success is attributed to Fable's ability to batch-fix 17 items in one PR without human steering. | Caveat: No A/B comparison with prior models (e.g., Opus 3.5) or explicit failure cases shared; the claim is experiential/anecdotal. Run time is 'sometimes two, three, four hours,' so speed is not the gain—correctness and autonomy are. | Implication: For Ken: Sonnet 4 may be the threshold model for end-to-end agent workflows in product development. Worth benchmarking against Opus 3.5 and o1 for batch reasoning + code generation + decision-making under a strategy doc. | Timestamp: 00:00–00:30, 07:20–07:46 (repeated thesis)
• Claim: Batch feedback processing (many items → one PR) is operationally superior to per-item PRs because review overhead scales linearly with PR count, not item count. | Evidence: Speaker contrasts '17 items found in Slack' with 'imagine you have to review 17 pull requests—it's a lot of work.' The LFG flow consolidates fixes into a single branch, making review 'manageable.' | Caveat: This assumes the AI can correctly batch-resolve items without introducing cross-item conflicts or regressions. No mention of how conflicts/dependencies are handled if fixes interact. | Implication: For Ken: Agent systems should bias toward batch operations when context windows and reasoning allow. Single-PR-per-batch reduces review tax and CI overhead, but requires model capability + good strategy docs to avoid tangled changes. | Timestamp: 05:30–06:00
• Claim: RiffRaff (open-source React wrapper) captures richer feedback than video by recording DOM clicks, voice, network requests, and errors as a shareable zip file. | Evidence: Speaker built RiffRaff; it wraps a React app, adds a recording button, saves a zip with interaction traces. 'Rich information, better than a video.' Users share zips to Slack; the agent downloads and analyzes them. | Caveat: Only works for React apps. No mention of performance overhead, privacy/data concerns, or how non-React feedback is handled. Also unclear if the model can parse/reason over all the captured data (e.g., network request payloads). | Implication: For Ken: RiffRaff is a reusable pattern for structured feedback capture in web apps. Consider similar instrumentation for Ken's agent/UI products if user feedback is a bottleneck. The structured zip likely feeds better prompts than unstructured Loom videos. | Timestamp: 02:20–03:10
• Claim: The Compound Engineering 'compound step' prevents the agent from repeating past mistakes across iterations. | Evidence: Speaker notes 'if it makes a mistake, it will also not make the same mistake the next time' due to the compound step in the LFG flow. Implies some form of error logging or memory across runs. | Caveat: No detail on how the compound step works (e.g., is it a vector store of errors? a YAML of anti-patterns? a fine-tuned classifier?). Also unclear if it generalizes across projects or is Quora-specific. | Implication: For Ken: Agent memory/anti-pattern databases are critical for production AI systems. If Compound Engineering's compound step is robust, it's worth evaluating for Ken's agent ops. Persistent learning loops separate toys from tools. | Timestamp: 06:15–06:30
• Claim: The speaker achieved the 'magic moment' of waking up to shipped features after setting the system to auto-merge if CI passes, with positive user feedback arriving before he reviewed the changes. | Evidence: Speaker: 'Last night I kicked it off, said if everything looks good and CI is green, merge it. This morning I woke up and Brandon said whoa, the design looks good... I was sleeping and I was doing that. So that's the dream.' | Caveat: This is a best-case anecdote. No mention of rollback mechanisms, monitoring, or what happens if CI is green but the feature regresses in production. Also, speaker is solo/small-team (Avery internal alpha), so risk tolerance is higher than in a customer-facing production app. | Implication: For Ken: Overnight auto-merge is feasible for alpha/internal tools with good CI + model trust, but requires guardrails (feature flags, rollback, monitoring) for broader deployment. The psychological unlock—delegating the final merge—is as important as the technical capability. | Timestamp: 06:30–07:10
• Claim: The workflow is not yet fully automated: the speaker manually invokes Cursor with the LFG flow command and manually reviews PRs via /polish. | Evidence: Speaker: 'What I do, still manually, but I could automate this, I should probably automate this... I just go to cursor and I use the cloud and say LFG flow...' and 'I check out the branch, take the videos... use /polish.' | Caveat: Manual steps are bottlenecks but also safety valves. Full automation (scheduled Cursor runs + auto-review) is technically possible but not yet implemented, likely due to trust/risk. No mention of how /polish integrates or whether it's an Avery internal tool. | Implication: For Ken: The gap between 'semi-automated' and 'fully automated' is often human trust, not capability. This workflow is ~80% there; the last 20% (auto-invoke, auto-review, auto-merge) requires robust CI, monitoring, and risk appetite. Worth modeling the ROI of full automation vs. the cost of occasional bad merges. | Timestamp: 04:00–04:30, 05:00–05:30

Detailed Brief

System Architecture: Feedback Ingestion and Structuring

• Claims: A scheduled Cloud Cowork task runs twice daily (morning and evening) to scrape a Slack alpha channel for feedback.; The task uses Slack MCP to fetch messages, classifies feedback types (text, screenshots, RiffRaff zips, video), checks if items are already resolved (via checkmarks/eyes reactions), and downloads attachments.; Output is structured as YAML and markdown files tracking reported vs. unreported items, what works, what doesn't.; RiffRaff zips (DOM clicks, voice, network, errors) are downloaded and analyzed via a separate skill in the agent.
• Evidence: Speaker shows Slack channel with Brandon's feedback, eyes emoji (reviewing), checkmarks (done).; Shows 'Alpha Feedback Polls' skill in Cloud Cowork loading messages, classifying, downloading.; YAML and markdown files visible in demo, tracking state.; RiffRaff is open-source, wraps React apps, records interaction traces as zips shared to Slack.
• Caveats: No detail on how Slack MCP is configured or whether it's rate-limited.; No mention of how the agent handles ambiguous feedback (e.g., user complaints without clear repro steps).; RiffRaff only works for React apps; other frameworks would need different instrumentation.; No discussion of privacy/security for captured network requests or voice recordings.
• Implications: This is a reusable pattern for any team using Slack for alpha feedback. The structured YAML/markdown intermediary allows non-LLM code to query state.; RiffRaff's structured feedback likely produces better prompts for code-generation models than unstructured Loom videos.; Slack MCP + scheduled tasks can turn any Slack channel into a structured queue for agent workflows.; For Ken: Consider whether similar feedback capture (structured, multi-modal, persistent) would improve agent product development velocity.

Batch Processing and PR Generation via Cursor + LFG Flow

• Claims: After feedback is structured, the speaker manually invokes Cursor with a 'LFG flow' command, pointing it at the PR branch created by the ingestion task.; The LFG flow (from Compound Engineering) batch-processes all items in the YAML, fixes what it can, leaves notes for items requiring human decisions, and consults a strategy doc.; The output is a single PR containing all fixes, with a video walkthrough showing each change.; The speaker reviews the PR by checking out the branch and using /polish (a preview server showing before/after UI).; The batch approach reduces review overhead: 17 items → 1 PR, not 17 PRs.
• Evidence: Speaker shows Cursor command: 'LFG flow for each of the every items in the pull request. Let's work in this PR branch too. Fix all the items, leave notes for the ones that need human input, but look at the strategy, makes a decision if you think you can make a decision.'; Video walkthrough embedded in PR shows UI changes frame-by-frame.; Speaker: 'Imagine you have to review 17 pull requests. It's a lot of work. And with Fable, it's very good at doing that.'; /polish gives side-by-side app preview for manual QA.
• Caveats: Manual invocation is a bottleneck; speaker acknowledges 'I should probably automate this.'; No detail on how the strategy doc is structured or how the agent decides when to 'make a decision' vs. leave a note.; No mention of how cross-item conflicts are resolved if fixes interact (e.g., two feedback items touch the same component).; Run time is 'two, three, four hours,' so this isn't real-time; it's overnight-batch velocity, not interactive velocity.
• Implications: Batch reasoning + strategy docs are the unlock for autonomous code generation at scale. Single PR + batch review is far more efficient than per-item PRs.; Video walkthroughs (likely generated by an agent summarizing diffs?) are a UX innovation for PR review; consider for Ken's agent outputs.; For Ken: The LFG flow (part of Compound Engineering, which speaker plans to open-source more) is worth investigating as a reusable pattern for agent-driven code changes.; The manual Cursor invocation step is the remaining automation gap; scheduled Cursor runs or CI-triggered agent flows would close it.

Overnight Auto-Merge and the 'Magic Moment'

• Claims: The speaker set the system to auto-merge the PR if CI passes, went to sleep, and woke up to shipped features with positive user feedback.; This is described as 'the magic moment' and 'the dream'—features shipping while the developer sleeps.; The Compound Engineering 'compound step' prevents repeat mistakes across iterations, improving reliability over time.
• Evidence: Speaker: 'Last night I kicked it off and I just said, okay, if everything looks good and the CI is green, merge it. This morning I woke up and Brandon said, whoa, the design looks good... I was sleeping and I was doing that.'; Speaker: 'If it makes a mistake, it will also not make the same mistake the next time' due to compound step.
• Caveats: This is an alpha product with a small internal user base (Avery team), so risk tolerance is higher than in customer-facing production.; No mention of rollback mechanisms, monitoring, or production incident response if the auto-merge introduces a bug.; CI being green doesn't guarantee semantic correctness; the agent could introduce logic bugs that pass tests.; The 'compound step' mechanism is not explained—unclear if it's a vector store, YAML anti-pattern list, or something else.
• Implications: Overnight auto-merge is feasible for alpha/internal tools with strong CI, but requires additional guardrails (feature flags, monitoring, rollback) for production.; The psychological unlock—trusting the agent to merge without human approval—is as important as the technical capability. This requires earned trust via prior successful runs.; For Ken: Agent-driven CI/CD pipelines can shift development from 'write code during work hours' to 'review and merge overnight results.' This changes the tempo of product work.; The compound step (error memory) is critical for reliability. Without it, agents repeat mistakes and erode trust. Ken should investigate how Compound Engineering implements this.

Toolchain Components and Open Questions

• Claims: RiffRaff: Open-source React wrapper for structured feedback capture (DOM, voice, network, errors as zips).; Slack MCP: Used to fetch messages from Slack channels.; Cloud Cowork: Scheduled task runner for the ingestion flow.; Cursor: IDE/agent interface for invoking the LFG flow.; Compound Engineering: Framework providing the LFG flow and compound step; speaker plans to integrate learnings and make it more robust.; /polish: Preview server for side-by-side app review (unclear if Avery internal or public tool).; Strategy doc: Consulted by the agent for decision-making (content and structure not shown).
• Evidence: Speaker shows RiffRaff UI with recording button, explains it's open-source and wraps React apps.; Shows Slack MCP being used in Cloud Cowork task.; Shows Cursor command invoking LFG flow.; Mentions 'LFG flow is from compound engineering. Go check it out. It's in cursor, it's wherever you want.'; Shows /polish side-by-side preview in demo.; Mentions 'look at the strategy, makes a decision if you think you can make a decision' in Cursor command.
• Caveats: No links or documentation provided for RiffRaff, Compound Engineering, or Cloud Cowork.; No detail on how the strategy doc is authored or what it contains.; /polish is mentioned but not explained; unclear if it's publicly available.; No discussion of costs (API usage, compute) for running multi-hour agent tasks twice daily.
• Implications: This is a multi-tool pipeline, not a single product. Replicating it requires integrating several components, some of which (Compound Engineering, /polish) may not be publicly documented yet.; For Ken: Each component (feedback capture, task scheduler, agent framework, preview server) is modular and could be swapped. The architecture pattern is more valuable than the specific tools.; RiffRaff is worth investigating as a feedback UX pattern; structured feedback likely improves agent success rates.; The strategy doc is a critical but underspecified piece. Without seeing its structure, it's unclear how much domain knowledge must be encoded vs. inferred by the model.

Notable Concepts & Terms

• Fable (Claude Sonnet 4): Anthropic's latest model, which the speaker credits as the breakthrough enabling this workflow. Described as 'favorite model ever' and 'a big shift' in capability for autonomous multi-step reasoning and code generation.
• RiffRaff: Open-source React wrapper that records DOM interactions, voice, network requests, and errors as shareable zip files. Used for structured feedback capture; 'richer than video' according to speaker.
• LFG Flow: Agent workflow from Compound Engineering that batch-processes feedback items, fixes code, leaves notes for human input, and consults a strategy doc. Core of the autonomous PR generation step.
• Compound Step: Feature of Compound Engineering's LFG flow that prevents the agent from repeating past mistakes across iterations. Mechanism not explained, but implies some form of persistent error memory.
• Slack MCP: MCP (Model Context Protocol) integration for Slack, used to fetch messages and attachments from Slack channels for agent processing.
• Cloud Cowork: Scheduled task runner used to orchestrate the feedback ingestion pipeline (fetch Slack messages, classify, download attachments, structure as YAML/markdown).
• Batch Feedback Processing: Pattern of consolidating multiple feedback items into a single PR rather than one PR per item. Reduces review overhead; relies on model's ability to reason across items without introducing conflicts.
• /polish: Preview server tool that provides side-by-side before/after views of the app for manual QA. Unclear if Avery internal or public; used for PR review.
• Strategy Doc: Document consulted by the agent during the LFG flow to make decisions about fixes. Content and structure not shown, but critical for agent autonomy.
• Quora v2: The product being built—a full-inbox version of Quora (the speaker's project at Avery). Used as the test case for this workflow.

Operator Notes / Why Ken Should Care

• This is a shipped, production example of an end-to-end AI product-development factory: feedback → structured ingestion → batch reasoning → overnight merge. Not a demo or concept—it's what the speaker uses daily.
• The workflow demonstrates how Sonnet 4's improved reasoning enables tasks that previously required human-in-the-loop (batch multi-item fixes, strategy-doc-guided decisions) to run autonomously.
• Key insight: Batch operations (many items → one PR) are operationally superior to per-item PRs when review overhead is the bottleneck. Requires model capability + good strategy docs.
• RiffRaff (structured feedback capture) is a reusable UX pattern for any web app. Structured feedback likely improves agent success rates vs. unstructured video/text.
• The 'compound step' (preventing repeat mistakes) is under-explained but critical. Agent memory/anti-pattern databases are the difference between toys and tools. Worth investigating Compound Engineering's implementation.
• The speaker has not yet automated the Cursor invocation or PR review steps, so there's still a manual gate. Full automation (scheduled Cursor runs, auto-merge) is technically feasible but requires trust/risk tolerance.
• Overnight auto-merge worked in an alpha context with small user base. Scaling to production would require feature flags, monitoring, rollback mechanisms, and likely staged rollouts.
• This workflow shifts product development from 'write code during work hours' to 'review overnight results.' The tempo change is significant: features ship while you sleep, but you need robust CI + monitoring.
• For Ken's agent ops: Consider whether batch feedback processing, structured feedback capture (RiffRaff-like), and overnight agent runs could improve velocity for Ken's products. The toolchain (Slack MCP, Cloud Cowork, Cursor, Compound Engineering) is modular and could be adapted.
• The speaker is the creator of RiffRaff and involved with Compound Engineering, so this is a founder/builder sharing a personal workflow, not a sales pitch. Credibility is high for technical details but low for generalizability claims.
• No discussion of costs (API usage, compute for multi-hour runs twice daily). Worth modeling economics if replicating at scale.
• No discussion of failure modes: What happens if the agent misinterprets feedback? Introduces regressions? Merges broken code? The 'magic moment' anecdote is a best-case outcome; median/worst-case not shown.

Watch Map

• 00:00: Intro: Speaker loves Claude Sonnet 4 (Fable), calls it a big shift. Setting up the demo of Quora v2 and the feedback-to-ship workflow.
• 00:30: Shows Slack alpha channel with feedback (screenshots, RiffRaff zips, eyes/checkmarks). Explains twice-daily scheduled task.
• 01:30: Explains the Cloud Cowork task: fetches Slack messages via MCP, classifies feedback, downloads attachments, structures as YAML/markdown.
• 02:20: RiffRaff demo: React wrapper that records DOM clicks, voice, network requests, errors. Shares zips to Slack. 'Richer than video.'
• 03:30: Shows YAML/markdown output of ingestion task. Explains manual Cursor invocation of LFG flow to batch-fix items.
• 04:30: Cursor command: 'LFG flow for each item, fix all, leave notes for human input, consult strategy doc.'
• 05:00: Shows video walkthrough embedded in PR, demonstrating all fixes. Explains batch review advantage (1 PR not 17).
• 06:00: Explains manual review via /polish (side-by-side preview). Mentions Compound Engineering's compound step prevents repeat mistakes.
• 06:30: 'Magic moment': Set to auto-merge if CI green, went to sleep, woke up to shipped features and positive feedback from Brandon. 'That's the dream.'
• 07:20: Outro: Solicits feedback, plans to integrate learnings into Compound Engineering. Repeats love for Sonnet 4 ('favorite model ever').

Source/Metadata

• Title: My Slack Feedback Now Ships Itself
• Transcript words: 2311
• Duration seconds: 466
• Timestamp note: Timestamps unavailable in transcript; watch_map entries are estimated from typical 7-8 minute video structure and speaker's narrative flow.