Better with Kent

Kent C. Dodds

Solo episodes from Kent C. Dodds on durable skills for people who ship software: judgment, accountability, problem clarity, and what stays valuable as AI takes on more implementation. Kent teaches directly on camera — no guest, one idea at a time. Complements guest interviews on Become a Product Engineer (Chats with Kent). Episode 1 adapts The Last Software Engineer; later episodes cover traps like building the wrong thing faster and skills like making user pain visible. Subscribe for evergreen episodes as the series grows.

Odcinki

  1. Pragmatic Loop Engineering for AI Coding Agents

    6 dni temu ·  Wideo

    Pragmatic Loop Engineering for AI Coding Agents

    Kent shows how he closes agentic loops in real Cursor workflows: manual testing, PR review loops, Cursor Automations, and the stop conditions that keep humans in the right place. (00:00) - Loop engineering before the name (00:11) - Boris on loops (00:33) - Better with Kent (01:01) - What the loop is (02:59) - Tests were already a loop (03:24) - Browser mode and manual testing (05:35) - Human-driven PR looping (06:43) - My first real loop (08:37) - Boundaries and stop conditions (09:37) - Cursor Automations (11:29) - Trading compute for attention (12:24) - Homework (12:52) - Closing Better with Kent — durable skills for people who ship software. Loop engineering sounds new, but Kent has been building toward it through a series of practical workflow improvements: automated test loops, Cursor browser mode, Cursor Cloud Agent manual testing, pull request feedback loops, and finally Cursor Automations. This episode walks through what a useful agentic loop actually needs: a trigger, an act/observe cycle, a stop condition, and a human boundary. Kent shows how he uses agents to mark PRs ready for review, respond to AI reviewer feedback and CI failures, and ping him when the loop has reached its stop condition. The key idea is not removing the human. It is widening the loop so more verification happens before your attention is required. Links Better with KentHow I Build Web Apps in 2026Manual testing example PRManual PR feedback loop exampleFirst informal self-running loop PRFirst formal PR loop example

    14 min
  2. Stop Taking Tickets, Start Applying Jobs Theory

    16 cze ·  Wideo

    Stop Taking Tickets, Start Applying Jobs Theory

    Kent walks Clay Christensen's jobs-to-be-done lens on a food-delivery shared-cart ticket — three questions that turn a solution into a job statement, plus Wayne Allan's Australia flop and Aaron D. Francis on deciphering feature requests. (00:00) - Your backlog is full of solutions (01:27) - Jobs to Be Done (03:12) - Shared cart ticket (04:04) - When it goes wrong — Wayne (06:01) - Three questions before you estimate (06:40) - Question 1 — progress and circumstance (08:56) - Question 2 — what they hire today (10:09) - Question 3 — what would fired look like (11:22) - Aaron on solutions vs jobs (12:54) - The job statement (13:47) - Stack with Kano (14:40) - Big hire vs little hire (17:19) - The habit — what job is this for? (19:27) - Homework (20:12) - Books and close Better with Kent — durable skills for people who ship software. Your backlog is full of proposed solutions. Kent walks a shared cart / group ordering ticket (same food-delivery app as the Kano episode) through Clay Christensen's Jobs to Be Done framework — why the expensive mistake is building the wrong thing, not bad code. Three beats land early: a ticket is not a job, hire/fire/progress language, and the habit "What job is this for?" before the estimate, PRD, or agent prompt. When it goes wrong — Wayne Allan (*Become an Epic Product Engineer*) on building for every person in Australia logging in at once: ~1.2M AUD, zero users. Three questions before you estimate: progress and circumstance, what they hire today (group text, separate orders, Venmo as workaround), and what "fired" looks like. Aaron D. Francis on what users actually want vs the button they asked for. The job statement: *When our team orders lunch together, help us coordinate food and check out once — without a 40-message thread.* After you ship: little hire vs big hire, why metrics alone miss the emotional job, and stacking qualitative signal. Homework: one sentence — what is the job to be done? Links Wayne Allan — The right thing before the thing right (Become an Epic Product Engineer)Aaron D. Francis — Vertical slices, Solo, and empathy (Become an Epic Product Engineer)*Competing Against Luck* (Clay Christensen et al.)HBR — Know Your Customers' "Jobs to Be Done"*Jobs to be Done: Theory to Practice* (Anthony Ulwick)The Last Software Engineer (essay)How to Prioritize Software Tasks (Better with Kent — Kano episode)Better with Kent on kentcdodds.com

    21 min
  3. How an AI Agent Deleted PocketOS Production in 9 Seconds

    12 cze ·  Wideo

    How an AI Agent Deleted PocketOS Production in 9 Seconds

    When an AI coding agent guessed its way through bad permissions and deleted months of PocketOS production data in nine seconds — and what durable skills would have stopped it. (00:00) - Cold open — car rental (01:49) - Today's story (10:29) - Railway recovery (14:57) - Three questions (16:29) - Close Better with Kent — durable skills through story. Episode 3 is a cautionary tale: on April 24, 2026, a Cursor agent working on PocketOS staging found a forgotten Railway API token, guessed it could delete a staging volume safely, and wiped production in nine seconds — along with volume-level backups in the same blast radius. Jer Crane and his co-founders spent days reconstructing customer records while Railway worked recovery. Kent walks the full chain: least privilege, independent tested backups, hard approval boundaries for destructive ops, and why markdown guardrails are not system boundaries. The principles are old; agents just find the holes faster. Creative license for pacing; primary sources linked below. Based on Jer Crane's public account of the PocketOS incident. Links Jer Crane interview (Agents Go Wild)Railway — Your AI wants to nuke your databaseJer Crane — original incident write-up (mirror)Zenity — System prompts are not security controlsBetter with Kent on kentcdodds.com

    16 min
  4. How to Prioritize Software Tasks

    3 cze

    How to Prioritize Software Tasks

    Kent walks the Kano model on a real food-delivery backlog: Must-be, Performance, and Delighter — why GPS was a wow in 2015 and a basic today, and why you cannot delight your way out of broken basics. Chapters 0:00 The backlog fight1:39 What type of feature is this?2:15 Basics (Must-be)3:47 Performance needs5:38 Delighters6:32 GPS lifecycle reveal7:56 Why silence misleads teams10:00 Cannot delight out of broken basics10:36 AI and the junk drawer11:52 Prioritized build order14:25 Homework and closeBetter with Kent — Durable skills for people who ship software. You have five backlog items and everyone wants their feature first. Kent uses a food delivery app example and the Kano model (Must-be, Performance, Delighter) to show what type each feature is — and what to build first. Land three beats: broken confirmation email is a Must-be (fix before anything else), estimated delivery accuracy is Performance (more accurate = more satisfied), surprise discounts and group ordering are Delighters (fun to build, dangerous when basics are broken). The GPS reveal: tracking felt like magic in 2015; today missing GPS means users leave. Why teams get this wrong: silence in support is not proof basics work — most users leave without filing tickets. You cannot delight yourself out of broken basics. AI makes it worse when agents churn exciting Delighters while hygiene features rot. Homework: label five real backlog items, fix broken basics first, ask whether last year's Delighter became today's Must-be. Become an Epic Product Engineer guests cited: Wayne Allan, Sean Roberts, Swizec Teller, Don Norman, Dillon Mulroy, Dax Raad. Links Watch on YouTube

    16 min
  5. What Software Engineers Need in 2026

    29 maj

    What Software Engineers Need in 2026

    Kent maps the durable skills that stay valuable as agents take more implementation: clarity, judgment, empathy, feedback loops, systems thinking, agent fluency, and ownership — with practical homework for each cluster. (00:00) - Intro: Google stat and durable skills (00:20) - Why now (01:08) - Durable skills map (01:25) - Clarity & judgment (03:40) - Wayne Allan: build the right thing first (04:28) - Practice: clarity & judgment (06:01) - User empathy & feedback (07:29) - Practice: empathy & feedback (08:56) - Systems thinking (12:22) - InfoWorld: AI coders need good engineers (18:52) - Agent fluency (20:14) - Practice: agent fluency (21:26) - Ownership (23:03) - Slow down on purpose (27:05) - What to deprioritize (28:04) - Homework Better with Kent — Durable skills for people who ship software. Episode 1 is the map. Agents can implement faster every month; the expensive mistake is building the wrong thing even faster. Kent walks through seven skills that were valuable decades ago and still matter in 2026: problem clarity, domain depth, judgment, empathy, feedback loops, systems thinking (including closing the agent loop), agent fluency, and ownership. Three clusters pair each skill area with concrete practice — stakeholder rooms, wiring daily feedback, building tests and CI so agents can iterate. Kent cites Become an Epic Product Engineer guests (Wayne Allan, Jack Ryan, Aaron Francis, Dillon Mulroy, Swizec Teller, Ruben Casas, and others), reacts to Matt Asay's InfoWorld piece on AI-generated code, and closes with homework you can do this week. Not a tool demo. Not a PM course. Not a framework checklist — just durable skills for people who ship software. Subscribe and comment with topics you want covered. Chats with Kent (Become an Epic Product Engineer) continues with guest interviews; Better with Kent is Kent thinking out loud on camera. Links InfoWorld — AI coders need good software engineers (Matt Asay)The Last Software Engineer (essay)Become an Epic Product Engineer (guest podcast)Better with Kent on kentcdodds.com

    30 min
  6. Introducing Better with Kent

    22 maj

    Introducing Better with Kent

    AI is accelerating change for software engineers. Kent introduces Better with Kent — solo episodes on durable skills, judgment, and knowing what to build — plus Chats with Kent guest interviews on Become an Epic Product Engineer. Better with Kent — Durable skills for people who ship software. The landscape is moving fast. Agents can implement more every month, which means the expensive mistake is building the wrong thing even faster. This series is Kent on camera — no guest — on judgment, accountability, problem clarity, and skills that stay valuable as implementation gets cheaper. Also continuing: Become an Epic Product Engineer with guests who blend technical depth and product judgment. Subscribe on YouTube, Spotify, Apple Podcasts, or wherever you listen. Comment with topics you want covered — Kent live-streams many recordings. Links Better with Kent on kentcdodds.comBecome an Epic Product Engineer (guest podcast)Kent on YouTube

    5 min

Zwiastun

O programie

Solo episodes from Kent C. Dodds on durable skills for people who ship software: judgment, accountability, problem clarity, and what stays valuable as AI takes on more implementation. Kent teaches directly on camera — no guest, one idea at a time. Complements guest interviews on Become a Product Engineer (Chats with Kent). Episode 1 adapts The Last Software Engineer; later episodes cover traps like building the wrong thing faster and skills like making user pain visible. Subscribe for evergreen episodes as the series grows.

Informacje

  • Twórca
    Kent C. Dodds
  • Lata aktywności
    2 tys.
  • Odcinki
    6
  • Klasyfikacja
    Dla wszystkich
  • Prawa autorskie
    © 2026 Kent C. Dodds Tech LLC
  • Witryna programu
    Better with Kent

Możesz również polubić