Make your web app agent-ready with WebMCP - product-minded engineering with Sarah Drasner

If more of your users are going to show up through an agent, this episode is for you. Kent talks with Sarah Drasner - Distinguished Engineer at Google, area tech lead for AI and the web ecosystem in Chrome - about giving agents a real interface to your product instead of brittle DOM scraping.They cover WebMCP and semantic tooling, untrusted content hints and layered defenses against prompt injection, the accessibility upside of agents, how Google is moving from "adopt agents" to levels of autonomy, and why system design is now a skill everyone needs early.(00:00) - Meet Sarah Drasner, Distinguished Engineer on Chrome (03:21) - WebMCP and fixing the web platform (06:04) - Semantic tooling instead of brittle DOM scraping (06:58) - Agents and accessibility (09:57) - Untrusted content and prompt injection (12:38) - Product decisions inside the WebMCP spec (14:38) - You're not building it alone (15:37) - Levels of autonomy and software factories (17:45) - Measuring agentic changes against a control (19:22) - Finding the right problems to solve (21:41) - Prototyping with agents and adversarial reports (26:29) - Your comprehension can't be delegated (28:14) - System design is the durable skill (31:15) - The trust diamond: agents act for people (33:32) - Homework: nuance, the user, and WebMCP (34:39) - Kent on agents that never sleep (37:32) - Where to follow Sarah Sarah Drasner is a Distinguished Engineer at Google working in Chrome on AI and the web ecosystem, and she spends a lot of her time deep in WebMCP. Before that she led web, Android, iOS, observability, and reliability across Google's core infrastructure.The through-line is that agents are not just random bots - they are often an extension of a person trying to get an outcome. WebMCP lets your site expose structured tools for coarse-grained functionality, which is more token efficient than scraping and safer because you can mark content as untrusted, read-only, or consequential. But no single protection is enough: like accessibility and security on the web, you need layered approaches.They also talk about product decisions inside the spec itself (like keeping state across page navigations with continuation tokens), working with the people around you instead of doing it alone, measuring agentic changes against a control at Google, prototyping with agents and adversarial reports, why your comprehension can't be delegated, and why system design matters much earlier in your career now that you're making decisions with an agent in the planning loop.Homework: keep nuance open, put the user first (even when an agent is acting for them), and go check out WebMCP.HomeworkKeep nuance open: don't reach for one Boolean answer - plan for layered protections, because no single solution covers every case.Put the user first, including when an agent is acting on their behalf. Ask when they want a signal and when that signal gets tiring.Check out the WebMCP spec, hand it to your agent, and ask how your product can take advantage of it.ResourcesWebMCP specWebMCP on GitHub (explainer, issues, proposals)Chrome DevTools MCP (DevTools for agents)NotebookLMSarah's websiteSarah on XSarah on BlueskySarah on GitHubGuest: Sarah DrasnerCompany: GoogleGitHub: @sdras𝕏: @sarah_edoHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

If AI handed you back hours of implementation time and you're not sure where to spend it, this episode is for you. Kent talks with Jay Parikh - Executive Vice President of CoreAI at Microsoft - about putting that time into customers, ideas, and outcomes instead of more output.They cover where the line between engineer and product manager is (and isn't), why small teams win the learning loop, activity metrics vs outcome metrics, tracking focus time and toil, capacity planning at GitHub scale, and why Copilot Fusion means you shouldn't have to pick a model.(00:00) - Meet Jay Parikh and Microsoft CoreAI (01:16) - Where software engineers fit now (03:33) - Spend saved time on outcomes and customers (05:12) - Product engineer vs product manager (06:47) - Small teams, faster learning loops (08:30) - Capacity planning at GitHub scale (11:41) - Activity metrics vs outcome metrics (14:38) - Tracking focus time and toil (15:44) - Copilot Fusion: stop picking models (18:32) - Agents that manage the project (19:00) - Homework: raise your ambition, measure outcomes Jay Parikh leads CoreAI at Microsoft, the organization building the tools, platform, and infrastructure for AI-native developers, including GitHub. Kent caught up with him the day of his GitHub Universe keynote.The through-line is outcomes over output. When agents take on more of the implementation and verification, Jay wants that time to go into ideation, creation, collaboration, and "picking right" - and then into checking whether the feature actually moved the business. The line between software engineer and product manager is situational, not fixed, but getting closer to the customer is all upside for engineers.They talk about small teams that traverse a faster learning loop than competitors, why activity metrics (lines of code, PR counts) were useful for getting people moving but aren't the goal, dividing PR velocity by incident rate, measuring focus time vs unfocused time and toil across CoreAI, capacity planning when volume per person keeps climbing, and Copilot Fusion and Copilot projects: express your intent and budget, and let the system orchestrate the models and agents.Homework: whatever level of ambition you have, raise it. Then define explicit outcome metrics (leading and lagging) and wire them into your dashboards and your agents.HomeworkWhatever level of ambition you have with these tools, raise it: try something bigger, bolder, and faster than you think you're ready for.Try different tools and different ways of doing the work to find the edge.Define explicit outcome metrics for what you're building, and know which are leading and which are lagging.Wire those outcome metrics into your dashboards and your agents so the whole learning loop runs faster.ResourcesGitHub Universe 2026: Evolving every layer of the stack (Jay Parikh)Copilot Fusion docsCopilot projects docsJay on GitHubJay on LinkedInGuest: Jay ParikhCompany: MicrosoftGitHub: @jayparikhHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer

If you jump straight to implementation before you can explain the user journey, this episode is for you. Kent talks with Drew Hoskins - author of The Product-Minded Engineer, Senior Staff engineer at Stripe - about the otter metaphor, avoiding the Cthulhu effect in user interviews, and reviewing systems instead of diffs.They cover Facebook product-hybrid archetypes, Temporal and Stripe loops, the rule of three for generalization, and homework: sketch one feature's journey and hunt for plot holes.(00:00) - Meet Drew Hoskins (00:33) - The Product-Minded Engineer (03:21) - Stripe and developer products (06:11) - From compilers to product hybrid (08:34) - Facebook archetypes and career turn (10:57) - Temporal PM, then back to Stripe (13:51) - Sketch the user journey (16:13) - Balancing systems and users (21:05) - Fire-and-forget codegen risks (25:00) - Avoiding the Cthulhu effect (30:43) - Puzzle approach to empathy (33:28) - Rule of three (39:43) - Review systems, not only diffs (46:03) - Homework: sketch one journey Drew Hoskins (he also goes by Andrew) is the author of The Product-Minded Engineer. He started as a compiler engineer at Microsoft, built deep systems at Facebook and Oculus, founded Workflow Engine at Stripe, spent two years as a PM at Temporal, then returned to Stripe engineering after the book shipped - living the product-hybrid path he writes about.The through-line is product-minded engineering as a career shape, not a side hobby. At Facebook, Kent Beck's staff archetypes named "product hybrid" as a real mode. Drew doubled down instead of managing. The otter metaphor from the book frames engineers who play across product and systems. User interviews go wrong when you summon the Cthulhu effect - leading people into agreeing with your idea. Sketching the journey (discovery, understanding, usability, safe usability) exposes plot holes before you ship.They talk balancing systems thinking with user empathy, reviewing systems not diffs as agents write more code, deferred trust and conditional approvals, and the rule of three for when to generalize.Homework: take a feature you are working on, sketch its user journey in detail, and look for plot holes - how users find it, how they understand what it means, where the story breaks.HomeworkPick a feature you are working on.Sketch the user journey in detail (discovery, understanding, usability / safe usability).Look for plot holes: how does the user find it, understand what it means, and get through without getting stuck?ResourcesThe Product-Minded Engineer (O'Reilly)The Product-Minded Engineer (Substack)Drew on LinkedInTemporalStripeGuest: Drew HoskinsCompany: StripeHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

If you only get asked about feasibility, this episode is for you. Kent talks with Sam Julien - Director of Product at CopilotKit, author of Agentic GraphRAG - about moving past ticket-taking, collaborative product-engineering dialogue, and frameworks that help you push back with vocabulary.They cover leverage / neutral / overhead triage, Kagan's four big risks, communicating intent with AI agents, and why engineers need product models even when they have a PM.(00:00) - Meet Sam Julien (01:26) - Dev to DevRel to product (03:37) - Product, design, and engineering overlap (06:00) - Durable skills as agents write code (12:01) - Get closer to customers (15:34) - Building a product-minded engineering team (18:46) - When technical work was the whole job (25:28) - Talk through the problem first (33:26) - Sales-driven development and gatekeeping (36:26) - Beyond feasibility (39:35) - LNO, RICE, and friends (42:42) - Continuous discovery and agents (46:44) - Communicating intent to AI (51:27) - Homework: triage your backlog Sam Julien went from self-taught web developer to developer relations to product. He is Director of Product at CopilotKit (generative UI across front ends, Slack, Teams) and author of the O'Reilly book Agentic GraphRAG.The through-line is product-minded engineering as a durable skill. Implementation-only careers are getting thinner as agents take more code work. Sam's article on building a product-minded engineering team name-drops jobs-to-be-done, Kagan's four big risks, continuous delivery, LNO (leverage / neutral / overhead), DHM, RICE, and North Star - and he lands on LNO as especially practical for backlog triage.Leverage work: small effort, outsized outcome. Neutral: necessary, so scope it. Overhead: automate or drop - often a fit for AI. Engineers need these models so they can push back with shared vocabulary, especially when the PM is checked out. Feasibility alone is not enough; value, usability, and business viability belong in the dialogue.They also talk collaborative product-engineering conversations, gatekeeping sales-driven development, and communicating intent clearly when agents execute.Homework: spend ten minutes on your backlog and apply at least one triage framework (LNO or similar). Extra credit: watch something recent from Teresa Torres.HomeworkOpen your backlog once this week.Spend about ten minutes sorting items with a triage lens (LNO - leverage, neutral, overhead - or another framework from the episode).For each item, ask why you are doing it, what the effort is, and what the value or impact is.ResourcesSam JulienBuilding a Product-Minded Engineering TeamCopilotKitSam on XSam on GitHubSam on LinkedInAgentic GraphRAG (O'Reilly)Guest: Sam JulienCompany: CopilotKitGitHub: @samjulien𝕏: @samjulienHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

If you ship features and never hear what users actually said, this episode is for you. Kent talks with Ben Vinegar - co-founder of Modem, formerly founding engineer and VPE at Sentry - about aggregating feedback, eliminating adoption barriers, and keeping human judgment in the loop as AI speeds up shipping.They cover FreshBooks-era product engineering, Modem's approach to capturing feedback across Slack, Discord, GitHub, and support tools, and why five real conversations beat a median LLM opinion.(00:00) - Meet Ben Vinegar (01:29) - Career startup guy (03:48) - What Modem is for (06:59) - Building products for builders (12:58) - Aggregating feedback at scale (15:26) - FreshBooks and early product loops (21:34) - Onboarding and getting users unstuck (25:06) - Emerging technology at Sentry (27:59) - Buy a laundromat - go deep on users (33:56) - Support culture and intentionality (39:35) - Human connection in the feedback loop (42:27) - Hunk and accelerating taste with AI (45:12) - Human judgment vs median products (49:43) - Homework: five people talking Ben Vinegar calls himself a career startup guy - early at FreshBooks, Disqus, and Sentry (first five people through ~400 employees), then head of product engineering, VPE, and VP of emerging technology. He founded Modem (modem.dev) to give product engineers faster access to what users are saying so they can iterate.The through-line is closed-loop feedback. Successful products Ben has worked on followed make-a-change, get-it-in-front-of-users, adjust, repeat. Modem aggregates signals from Slack Connect, Discord, GitHub issues, Intercom, Zendesk, and similar channels so teams are not hunting screenshots in five tools.They talk adoption barriers, FreshBooks' support culture, and why human judgment still differentiates when agents can ship median products. Ben's Hunk terminal diff tool story shows taste accelerating with AI: he built what he needed as a "norm core" Mac user who wanted agents running while he closed the laptop. Extreme product bets rarely come from averaged LLM taste.Homework from Ben, sharpened by Kent: get five people to try your software - and talk with them about their experience using it.HomeworkPick something you shipped (or are about to ship).Get five people to try it.Talk with those five people about their experience using your software - not just whether they clicked install.ResourcesModemBen VinegarBen on XBen on BlueskyBen on GitHubBen on LinkedInHunkGuest: Ben VinegarCompany: ModemGitHub: @benvinegar𝕏: @bentlegenHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

If your backlog is full of tickets and zero customer contact, this episode is for you. Kent talks with Teresa Torres - product discovery coach, author of Continuous Discovery Habits, and host of Just Now Possible - about why engineers belong in discovery, what "just now possible" really means, and how curiosity beats solution advocacy.They cover opportunity solution trees, confirmation bias in decision-making, the Mom Test trap of pitching your solution, and homework that starts with one real conversation (or observing one).(00:00) - Meet Teresa Torres (02:03) - Just now possible (04:14) - Why coding agents are not enough (08:07) - Engineers in the data model conversation (15:10) - Continuous discovery habits (19:01) - Prove the null hypothesis (21:22) - Where engineers should show up more (24:06) - Solving your own problem (27:27) - AI unlocks software for one (30:04) - The Mom Test trap (33:26) - Opportunity solution trees (39:19) - Confirmation bias vs status quo (42:07) - Informed opinion vs preference (43:16) - Start with curiosity (46:01) - Homework: talk to a customer Teresa Torres has spent about twenty years coaching product teams to make better decisions about what to build. She is a maker at heart: product discovery exists so makers ship useful things instead of crickets.The through-line is engineer involvement. Marty Cagan's line sticks: engineers know best what is just now possible. Teresa's Google Maps API story makes it concrete - a PM would never have invented map pins for customer connection without an engineer who saw the new API and understood the business. AI accelerates that dynamic. Her podcast Just Now Possible interviews teams building AI products for that reason. Coding agents write a lot of code; they do not replace judgment about scalability, security, maintainability, or a data model that will survive the next iteration.They dig into continuous discovery habits: weekly customer contact, opportunity solution trees that separate outcomes from solutions, and the confirmation-bias trap of comparing every idea only to the status quo. The Mom Test warning is sharp - showing someone your solution teaches you whether they are polite, not whether the problem is real.When leadership wants ticket-takers, Teresa's answer is not "quit immediately." Start with genuine curiosity: "I'm curious, can you tell me more?" Opinionated why-questions create defensiveness. Informed opinions matter after you have customer context - personal preference dressed up as technical expertise usually misses the mark.Homework: talk to someone who matches your customer segment (even casually over coffee) and ask about the last time they experienced the problem your product exists to solve. Or sit in on interviews your PM, designer, researcher, sales, or support teams already run.HomeworkIdentify who uses your product (or who has the problem it solves) and find one person in your network who matches that segment.Have a casual conversation (coffee, LinkedIn second-degree, whatever fits) and ask: tell me about the last time you experienced [the problem your product solves]. Learn about them as a human - not about your product.If customer contact is blocked, ask to observe an interview your PM, designer, researcher, sales, or support team is already running.ResourcesProduct TalkProduct Discovery BasicsContinuous Discovery HabitsJust Now Possible podcastTeresa on BlueskyTeresa on LinkedInTeresa on XGuest: Teresa TorresCompany: Product Talk𝕏: @ttorresHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

If you still build for an audience of one and get defensive when users "use it wrong," this episode is for you. Kent talks with Mark Techson - staff developer relations engineer on Angular at Google - about empathy as a career differentiator, listening without defense, and why knowing what to build still beats vibe-coding forever.They cover internal tools as real products, a fitness-app failure that forced better questions, Google Developer Experts as a feedback loop, durable expertise in the AI era, and why attention is the scarce resource when anyone can ship.Mark Techson (legal name Mark Thompson) has spent about twenty years building software - teaching, senior engineering roles, a fitness startup, American Express fraud tooling, healthcare exchange apps, and now staff DevRel on Angular at Google. The views in this episode are his own; he notes he works for a major frontier-model provider.The through-line is empathy. Mark's number-one product-engineering skill is putting yourself in the end user's seat before you ship. Engineers who only implement tickets miss the concert of perspectives PMs, EMs, and builders bring when everyone aims at the best user experience. He compares great teams to a film set where talent still suggests a shoulder turn that makes the scene land.Listening without defense is the mechanism. Feedback means either you built it wrong or they cannot see how it works - both are actionable. Mark's hard lesson was a fitness app he built for himself: even his wife chose another app. Surveys flipped his assumption from "customize everything" to "just tell me what to do." At Google he leans on Angular GDEs and a simple reply to angry comments: tell me more.They also talk AI. Expertise is not going out of style - Mark uses a guitar-tuner analogy: auto-tune does not erase your ear. Knowing what to build, who to build for, and how to orchestrate agents matters more as code gets cheaper. Kent adds that human attention stays finite even if tokens get cheap. Mark closes against the "you're left behind" narrative: you do not have to live on the bleeding edge, but ignoring AI is the only wrong move.Homework: write a prompt for the first basic version of a product you have been postponing, run it in any AI tool, and notice what you failed to specify.HomeworkPick a product idea you have postponed for lack of time or skill.Write a prompt that describes only the first basic version - not the million-dollar finished product.Run that prompt in any AI coding tool, then list what was missing from your prompt and iterate toward that first version.ResourcesMark TechsonMark on XMark on GitHubMark on LinkedInAngularGoogle Developer ExpertsGuest: Mark TechsonCompany: GoogleGitHub: @MarkTechson𝕏: @MarkTechsonHost: Kent C. DoddsWebsite: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerMark's views are his own. He notes he works for a major frontier-model provider (Google).

If execution got cheap and you still wait for someone to tell you what to build, this episode is for you. Kent talks with Joyce Er about five years owning features on VS Code, the jump to product at Cerebras, and why trust is the metric that tells you the work is working. They cover daily stand-ups that roast your feature in public, friction logs as taste practice, dogfooding when you cannot be the user, qualifying customers instead of taking every check, and why a sales book belongs on a product engineer's shelf. (00:00) - Meet Joyce Er (01:18) - A dinner-plate AI chip (02:47) - Engineering as we knew it shrunk (04:38) - Ownership on the VS Code team (07:33) - Why ownership matters more with AI (10:23) - Keep a friction log (12:18) - Judgment from lived experience (15:33) - Invalidate old priors (17:41) - VS Code's daily stand-up roast (20:35) - When you cannot dogfood (22:52) - Getting partner teams to help (29:30) - Curiosity and time-boxing AI (32:20) - Selling inference to coding tools (34:00) - Qualify the right customer (38:47) - Trust as the success metric (40:11) - Homework: friction log and a sales book Joyce Er spent five years as a software engineer on VS Code at Microsoft, with a front-row seat to GitHub Copilot and the shift from typing code to owning the why. About a year before this conversation she moved into product at Cerebras, the company behind dinner-plate wafer-scale chips for ultra-fast AI inference. The views in this episode are her own. A major theme is ownership. On VS Code, every engineer owned the end-to-end definition of what shipped, not just the implementation. That only works with trust, dogfooding, and rituals that force you to defend the experience. Joyce describes a daily stand-up where you get five minutes to walk the feature, then the team roasts padding, consistency, and whether it belongs in the product. The lighter version is a bug bash. If people inside the company will not use the feature, that is a signal. They also talk about how you grow judgment when nobody assigns the work. Joyce's first practice is a friction log: five minutes at the end of the day listing paper cuts in any software you used. Her more controversial homework is to read a sales book - she recommends The Qualified Sales Leader - so you understand how business value actually closes, especially when the product is not a credit-card checkout. Trust, she says, is the end-to-end metric: if customers and teammates trust you, you are doing the job. Homework: keep a daily friction log, and read a book about sales. Homework Spend five minutes at the end of each day writing a friction log of paper cuts in software you used.Read a sales book - Joyce recommends The Qualified Sales Leader - and notice how value gets sold at your company.Use those notes the next time you decide what is worth building. Resources Joyce Er on XJoyce on GitHubJoyce on LinkedInCerebrasVisual Studio CodeThe Qualified Sales Leader by John McMahon Guest: Joyce Er Company: CerebrasGitHub: @joyceerhl𝕏: @joyceerhl Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer The views expressed by Joyce Er are her own and do not necessarily represent those of her employer.

If you ship a feature and never click through it yourself, this episode is for you. Kent talks with Rita Kozlov, VP of Product for Cloudflare's developer platform, about the line between product managers and product engineers, why ownership still matters when prototypes look real, and how far upstream an engineer should insert themselves. They cover holding the pager vs throwing away a prototype, sitting in customer calls until someone will not click the button, primitives vs paved paths, and what to do when your PM is running a feature factory. (00:00) - Meet Rita Kozlov (01:36) - Engineering taste in a PM role (04:05) - Where PM and product engineer blur (07:53) - You are not holding the pager (09:48) - What AI changed on both sides (13:40) - Sit in the user's seat (17:04) - The art of the possible (18:53) - Trade-offs and why not both (23:22) - Primitives vs paved cow paths (26:43) - Insert yourself upstream (29:40) - When the PM is a feature factory (33:17) - Deep-stack work still reaches users (37:58) - Homework: go use the product Rita Kozlov is VP of Product for Cloudflare's developer platform - Workers, KV, Pages, and the rest of the stack Kent uses constantly. She started as a software engineer, and that background shows up in the details: taste for developer experience, intuition for patterns that do not sit right, and a refusal to treat implementation as someone else's problem. A major theme is how AI blurred the PM and engineer line. Prototypes are worth a million words, and they create a temptation to ship the facade. Rita's reminder to her product team: you are not the one holding the pager. Accountability is not about having someone to call at 2 a.m. It is about living with the code for the next two years. Product engineers close that gap by translating implementation trade-offs, filling the holes a PRD will never list, and sitting in the user's seat - including the customer call where nobody clicks the button. They also get into Cloudflare-shaped product judgment: most doors swing both ways if you wait; early customers are worth delaying a launch for; primitives can serve many jobs, and sometimes you still pave a cow path. Rita wants PMs to define the problem, not the solution. Engineers should get closer to customers, challenge a feature-factory PM with why, and remember that even work deep in the stack - cache, TTL, the interface between systems - is user experience. Homework is basic on purpose: go use the product, including the feature you just shipped, and push it before you throw it over the fence. Homework Use the product you work on this week - not as a demo path, as a real user.After you ship a feature, try it in the different modalities and push the limits before you hand it off.Write down what you found that you would have missed from the ticket alone. Resources Rita KozlovRita on XRita on BlueskyRita on GitHubRita on LinkedInCloudflare WorkersCloudflare Guest: Rita Kozlov Company: CloudflareGitHub: @rita3ko𝕏: @ritakozlov Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer

If you are merging beautiful AI PRs without being able to say why the change exists, this episode is for you. Kent talks with Erin Fox about treating every feature like a new product, asking why before you write code, and rebuilding the trust contract that agents quietly broke. They cover circling back to metrics, using community Slack as a feedback loop, telling a stakeholder story that is not just a migration estimate, and going slower with agents so they do not rewrite your patterns. (00:00) - Meet Erin Fox (01:40) - A new feature is a new product (05:03) - Finding the why before you build (07:36) - AI PRs broke the trust contract (10:57) - Metrics, research, and circling back (14:25) - Community Slack as a feedback loop (16:17) - Tell the story stakeholders can hear (20:49) - Communications skills as an engineering edge (24:12) - Ask your boss their goals (27:22) - Go slower with your agents (37:50) - Homework: ask why on every PR Erin Fox is a full-stack engineer who has shipped a React Native MLS soccer app, creator-focused email tools, and plenty of features that felt like launching a product each time. In this conversation, she and Kent dig into what that framing changes: you do not just implement a ticket. You figure out the date, the why, and whether the real fix is a new feature or a two-hour margin change. A major theme is trust. Erin used to assume a teammate's PR already had the why baked in. AI-generated PRs look great and pass tests, but the why is often missing. Her red flag is simple: if you cannot explain why this change is needed, do not treat passing tests as permission. That same question belongs in the PR template, in stakeholder conversations, and in how you brief an agent - because "fix this bug" will happily change a million things. They also get practical about feedback loops. Look at the metrics you instrumented. Lurk in community Slack, including accessibility channels, until user pain is not abstract. Then tell the story in language stakeholders care about: not "this migration takes a quarter," but what it unlocks. Erin's communications master's degree shows up here. She asks her manager what their goals are this quarter and treats that as the job. Homework is small on purpose: on every PR you open or review, write why this change matters. Homework On the next PR you open, add a Why section that a teammate could understand without the ticket.On the next PR you review, ask why this change is needed - especially if it looks AI-generated.If you cannot answer why, stop and find out before you merge. Resources Erin Fox on XErin on BlueskyErin on GitHubErin on LinkedInKit Guest: Erin Fox GitHub: @erinfox𝕏: @erinfoox Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer