Your agent opened the PR. Now you're refreshing CI and arguing with bots. Kent shows the ship-pr skill that closes that loop - mark ready, fix CI, triage review, Discord handoff - so you spend attention on risk, not chores. 00:00 - Still reading the code? 01:18 - "I read the code" kicked off a war 01:51 - I do read the code sometimes 02:31 - You're the PR babysitter 03:33 - I turned the loop into a skill 04:14 - Discord handoff is the product 04:33 - When it won't auto-merge 05:25 - Inside the ship-pr skill 06:16 - The ship-pr loop 06:28 - Merge mode (low risk only) 07:09 - How far this scales 07:49 - The factory spectrum 08:58 - Don't ship blind 09:43 - 92 times before it was a skill 10:20 - Homework: ship a PR 11:03 - Sign-off Better with Kent - durable skills for people who ship software. "I read the code" kicked off a war. Kent's take: it's a spectrum based on risk. The afternoon killer is not reading - it's babysitting CI, Bugbot, and "please fix that" loops after the agent already implemented the feature. This episode is the concrete payoff after loop-engineering: real Discord handoffs from Kody (including a medium-risk PR that stayed unmerged on purpose), the ship-pr skill file, merge mode for genuinely low-risk changes, and the 92-times lesson before formalizing a skill. Homework: tighten your ship loop. On a simple change, let the agent merge and verify - if your team is good with that. Links * Watch on YouTube ( https://www.youtube.com/watch?v=lfSnYGdtbqE&list=PLV5CVI1eNcJhP4nrJt85L7PxHjebFpDfY ) * kcd-skills / ship-pr ( https://github.com/kentcdodds/kcd-skills/tree/main/skills/ship-pr ) * kody#709 - medium-risk handoff (no auto-merge) ( https://github.com/kentcdodds/kody/pull/709 ) * kody#628 - bots + merge by kody-bot ( https://github.com/kentcdodds/kody/pull/628 ) * Mitchell Hashimoto - "I read the code" ( https://x.com/mitchellh/status/2072738025344565262 ) * Kent's reply on the spectrum ( https://x.com/kentcdodds/status/2075242713692467442 ) * I Was Doing Loop Engineering Before It Had a Name ( https://www.youtube.com/watch?v=jCZKiHrUNT4&list=PLV5CVI1eNcJhP4nrJt85L7PxHjebFpDfY ) * Better with Kent ( https://kentcdodds.com/better ) Better with Kent Episode 13 July 30, 2026 ★ Episode details: https://share.transistor.fm/s/b8fc5642 ★ Additional episodes: https://kentcdodds.com/better

Agent PRs are too big to read line by line. Kent shows a visual system recap in the PR description - classify what changed as composes, extends, or adds - so you review the architecture first, then the code that matters. 00:00 - Still reviewing git diffs? 00:25 - Spectrum: not every line, not zero review 00:43 - Review the system, not just the diff 00:51 - Steve's visual recap (Builder.io) 01:17 - Why I rolled my own 02:30 - System recap + PR #662 (adds) 05:08 - PR #686 (composes — low risk) 05:54 - Primitives playground callback 06:57 - Install kcd-skills visual-recap 07:35 - Homework + close Better with Kent - durable skills for people who ship software. Coding agents ship more code faster, and the review surface explodes. Some people say you have to read every line. Others say never look at the diff. The real answer is a spectrum - and the durable skill is reviewing how the system is changing, not only the syntax. Kent walks through a visual recap approach inspired by Steve at Builder.io, then shows his own kcd-skills version that needs no account, no deploy, and no inference token. The agent that worked the PR writes a system recap block; GitHub renders the mermaid. Live demos: PR #662 adding an MCP client-servers primitive (high risk) vs PR #686 composing onboarding (low risk). Same domain, different review questions. Homework: map your primitives, run visual recap on your next non-trivial PR, and decide whether you are reviewing an add, an extend, or a compose before you open the diff. Links * kcd-skills / visual-recap ( https://github.com/kentcdodds/kcd-skills/tree/main/skills/visual-recap ) * PR #662 - adds mcp-client-servers ( https://github.com/kentcdodds/kody/pull/662 ) * PR #686 - composes onboarding ( https://github.com/kentcdodds/kody/pull/686 ) * Slides deck ( https://kcd-slides-bwk-visual-recap.pages.dev/ ) * Design Primitives Agents Can Actually Use ( https://www.youtube.com/watch?v=kbmv3HIuKyk ) * Better with Kent ( https://kentcdodds.com/better ) Better with Kent Episode 12 July 28, 2026 ★ Episode details: https://share.transistor.fm/s/cd9a47b5 ★ Additional episodes: https://kentcdodds.com/better

Want the system from this episode? Check out Kody at https://heykody.dev/ Kent replays a real publish night — one Cursor conversation where the agent drove Notion, Canva, Kit, Transistor, Bluesky, and LinkedIn through Kody packages, with every secret kept out of the agent's reach. 00:00 - Stop copy-pasting between your agent and your services 01:25 - What we're learning today 01:49 - The real publish-night conversation 02:52 - Search: how the agent discovers capabilities 04:12 - The Notion pipeline board 04:42 - Execute: conversation id and memory context 05:50 - Agent-written code without exposing secrets 08:25 - Kody packages: a registry for your agent 09:43 - Token-efficient queries in a dynamic worker 11:53 - No package? Use the OpenAPI spec (Canva) 14:24 - Interruptions: publish date and square artwork 17:04 - Default square designs for every episode 18:15 - YouTube is live: Kit early-access broadcast 19:37 - Launch posts on LinkedIn and Bluesky 20:48 - I use this for everything 22:22 - Homework: wire your services once Better with Kent — durable skills for people who ship software. If you're still copy-pasting context between services and your agent, you're missing the real unlock: wiring those services in once so the agent can compose them. Kent walks through an actual episode publish night, one Cursor conversation at a time — search to discover capabilities, execute to run agent-written code in a fast isolated worker, saved packages instead of raw fetch calls, and OpenAPI bindings when no package exists yet. Along the way: how Kody's memory context and conversation id keep token usage down, how secret templates make it impossible for the agent to ever see a bearer token, mid-task interruptions the agent absorbs without losing the thread, and the Kit, Transistor, Bluesky, and LinkedIn steps that end with a published episode. Links * Watch on YouTube ( https://www.youtube.com/watch?v=u2PzSPD-wVI&list=PLV5CVI1eNcJhP4nrJt85L7PxHjebFpDfY ) * Kody ( https://heykody.dev/ ) * Kody on GitHub ( https://github.com/kentcdodds/kody ) * The chat walkthrough from this episode ( https://kcd-slides-bwk-publish-with-kody-packages.pages.dev/ ) * Your Coding Agent Needs Better Primitives (the episode being published) ( https://www.youtube.com/watch?v=kbmv3HIuKyk ) * Better with Kent ( https://kentcdodds.com/better ) Better with Kent Episode 15 July 23, 2026 ★ Episode details: https://share.transistor.fm/s/6d9c14fb ★ Additional episodes: https://kentcdodds.com/better

One orchestrator prompt, six platform swaps, and a real production cutover on kentcdodds.com — the workflow, the review loop, the perf scare, and where the agents were wrong. 00:00 - One prompt, 40,000 lines 00:44 - The site and why migrate 06:38 - PR #813 — 483 files 07:09 - Kickoff prompt anatomy 11:35 - Orchestrate with subagents 16:13 - Steering + scope expansion 21:33 - Three-layer review 23:22 - Kody closes the loop 25:24 - The performance scare 30:22 - Merge and cutover 33:51 - Cleanup waves 37:44 - Was 40k lines worth it? 39:40 - Homework: try orchestration Kent walks through how AI agents moved kentcdodds.com from fly.io to Cloudflare Workers — database, ORM, images, email, MDX pipeline, and more — from a single orchestrator prompt plus steering, subagent swarms, three-layer review, and Kody closing every loop. Includes the performance scare that almost killed the migration, the post-cutover cleanup waves, and an honest rollup of four agent-driven PRs (about 40,000 lines changed). Links * PR #813 — migration ( https://github.com/kentcdodds/kentcdodds.com/pull/813 ) * Slides deck ( https://kcd-slides-bwk-one-prompt-migration.pages.dev/ ) * kentcdodds.com ( https://kentcdodds.com ) Better with Kent Episode 11 July 21, 2026 ★ Episode details: https://share.transistor.fm/s/90349326 ★ Additional episodes: https://kentcdodds.com/better

If your coding agent keeps producing garbage, better prompting may not fix it. Kent shows how intentional system primitives make agents more reliable, efficient, composable, and auditable. 00:00 - Bad agent output starts in the system 00:37 - We are all tech leads now 01:28 - What is a primitive? 04:57 - Four moves: create, combine, delete, expand 06:01 - Create: role-based access control 07:59 - Combine: downshift and Kody packages 10:37 - Delete: Instagram and Kody email 12:22 - Expand: packages subscribe to events 13:51 - Why good primitives work 14:43 - Homework for your agent 15:32 - Keep evolving the system Better with Kent — durable skills for people who ship software. If your coding agent keeps producing garbage, the model may not be the problem. Agents are only as effective as the system they work in: the UI components, APIs, data entities, platform tools, workflows, and trust boundaries they can reliably use. Kent explains four moves for improving that system: create missing primitives, combine overlapping ones, delete rigid or unused ones, and expand the primitives that should cover more. The examples come from real product work — Kody's role-based access control and event subscriptions, PayPal's three combobox implementations becoming downshift, and Instagram winning by deleting most of Burbn. The payoff is a smaller action space with less guessing, fewer brittle workarounds, and behavior you can actually audit. The episode closes with homework you can run in your own codebase today: ask your agent which primitives you should create, combine, delete, or expand. Links * Better with Kent ( https://kentcdodds.com/better ) * Kody ( https://heykody.dev/ ) * downshift ( https://github.com/downshift-js/downshift ) * I built my own OpenClaw ( https://www.youtube.com/watch?v=TnztlHzhYvk ) Better with Kent Episode 10 July 15, 2026 ★ Episode details: https://share.transistor.fm/s/fefe75df ★ Additional episodes: https://kentcdodds.com/better

https://kentcdodds.com/live

AI made it easy to launch another app. Michael Shimeles argues the opportunity is not more software - it is better taste, care, and empathy for the person using it. This clip comes from Kent's full conversation with Michael about product judgment, simplicity, and building useful software in the AI era. Full episode: https://www.epicproduct.engineer/taste-simplicity-and-ai-era-product-judgment-with-michael-shimeles~x7p8l

Kent reacts to Dax's question on X — why no framework dethroned React — and connects it to Jobs Theory, network effects, and why framework choice matters less when agents write the code. Chapters * 00:00 — Why did nobody dethrone React? * 00:24 — Dax's question on X * 00:49 — React is the last UI library (2020) * 02:47 — Functional first, then social and emotional * 03:36 — What made React functionally better * 06:43 — Network effects and "nobody got fired for choosing React" * 07:38 — Why framework choice matters less with agents * 09:27 — Jobs Theory: apply this to everything you ship * 11:14 — Wrap-up Better with Kent — durable skills for people who ship software. Every few years the internet declares the framework wars over — usually with React as the loser. Svelte was going to win. Then Solid. Vue had its moment. Angular never left. And somehow, after a decade of "React is dead" takes, React is still the default for an absurd amount of real product work. Kent's take: React won functionally first (state sync, composition, drop-in UI focus), then socially and emotionally once it hit critical mass. Challengers can still be "better" on paper — but once agents can use any capable stack, the throne fight stops mattering the way it used to. Links * Dax (@thdxr) — why no framework dethroned React ( https://x.com/thdxr/status/2069933148767400094 ) * Kent (2020) — React is the last UI library anyone needs to learn ( https://x.com/kentcdodds/status/1297276093951483904 ) * Better with Kent — Practical Jobs Theory ( https://www.youtube.com/watch?v=vAzvoOkA70c&list=PLV5CVI1eNcJhP4nrJt85L7PxHjebFpDfY ) * Watch on YouTube ( https://www.youtube.com/watch?v=mxRjJPoWBE4&list=PLV5CVI1eNcJhP4nrJt85L7PxHjebFpDfY ) * Better with Kent ( https://kentcdodds.com/better ) * React ( https://react.dev/ ) * Become an Epic Product Engineer ( https://www.epicproduct.engineer/ ) Better with Kent Episode 9 July 9, 2026 ★ Episode details: https://share.transistor.fm/s/3a85855d ★ Additional episodes: https://kentcdodds.com/better

https://kentcdodds.com/live

Kent reacts to Zach Lloyd's Warp memo on "factory engineers" — where the software-factory vision is right, where it misses product context, and why factory work still comes back to users. Better with Kent — durable skills for people who ship software. Warp CEO Zach Lloyd told his team they are now factory engineers, not product engineers. Kent reads the memo aloud and pressure-tests the framing: automated development, cloud software factories, agent workflows, and the metrics that can game you if you forget what users are paying for. He agrees with a lot of the direction — build the system agents work in, measure throughput, tighten the loop — but pushes back on anything that treats the product as optional. Internal tools still have users. Factory efficiency only matters when the right work goes in. And yes, the memo's last word is still product. If you're trying to make sense of agentic engineering without losing product judgment, this is the durable-skills read-through. Links * Better with Kent ( https://kentcdodds.com/better ) * Warp — We are now factory engineers, not product engineers ( https://www.warp.dev/blog/we-are-now-factory-engineers-not-product-engineers ) * Warp software factory (build.warp.dev) ( https://build.warp.dev/ ) * Become an Epic Product Engineer ( https://www.epicproduct.engineer/ ) Better with Kent Episode 8 July 7, 2026 ★ Episode details: https://share.transistor.fm/s/ad178f92 ★ Additional episodes: https://kentcdodds.com/better

Kent walks through a real bot/crawler flood against kentcdodds.com, how agentic tooling helped diagnose and mitigate the outage, and what he changed so anonymous traffic is cheaper next time. Better with Kent — durable skills for people who ship software. Kent got a Sentry alert that kentcdodds.com was down. A bot or crawler flood had pushed his single Fly.io machine past its request limit, and the expensive parts of his dynamic blog pages made anonymous traffic hit harder than it should have. This episode walks through the incident response: asking a Cursor agent to investigate with repo context, Kody, Fly CLI access, Cloudflare context, and Grafana evidence; restarting and scaling the machine; blocking junk routes before they hit the origin; and identifying a DigitalOcean host driving a scripted high-concurrency crawl flood. The durable lesson is not "let AI run production." It is that agents become useful during incidents when they have the right context, observability, tools, and boundaries. The same agent that can read code can also connect symptoms to logs, infrastructure, and follow-up fixes. Links * Better with Kent ( https://kentcdodds.com/better ) * Sentry ( https://sentry.io/ ) * Fly.io ( https://fly.io/ ) * Cloudflare ( https://www.cloudflare.com/ ) * Grafana ( https://grafana.com/ ) Better with Kent Episode 7 July 2, 2026 ★ Episode details: https://share.transistor.fm/s/7ad2b507 ★ Additional episodes: https://kentcdodds.com/better

Kent shows how Kody gives the coding agent he already uses search, execute, and saved packages so exploratory workflows can become durable personal automation. 00:00 - Kody handled the demo 00:41 - Why personal agents have not stuck 02:21 - Search and execute 04:31 - Kitchen glare walkthrough 06:47 - Turning one action into a package 08:48 - Scheduling deterministic workflows 10:24 - What I use Kody for today 13:25 - Connectors, capabilities, and packages 15:04 - Code Mode and MCP 16:59 - Augmenting existing software 18:24 - Integrations, OAuth, and secrets 20:53 - What should Kody become? Better with Kent — durable skills for people who ship software. Kent walks through Kody, the thin runtime layer that lets the coding agent he already uses discover capabilities, execute sandboxed code, and save useful workflows as packages. Instead of maintaining a separate personal assistant brain, Kody gives Cursor, Codex, Claude Code, and similar agents a way to connect to personal APIs, home automation, jobs, integrations, secrets, and reusable package exports. The episode uses an office-chaos cold open and a kitchen glare walkthrough to show the progression from one-off prompt, to executable code, to saved package, to scheduled workflow. Links * Kody ( https://github.com/kentcdodds/kody ) * Better with Kent ( https://kentcdodds.com/better ) Better with Kent Episode 6 June 30, 2026 ★ Episode details: https://share.transistor.fm/s/e2720533 ★ Additional episodes: https://kentcdodds.com/better

https://kentcdodds.com/live

https://kentcdodds.com/live

https://kentcdodds.com/live

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. Chapters: 0:00 Loop engineering before the name 0:11 Boris on loops 0:33 Better with Kent 1:01 What the loop is 2:59 Tests were already a loop 3:24 Browser mode and manual testing 5:35 Human-driven PR looping 6:43 My first real loop 8:37 Boundaries and stop conditions 9:37 Cursor Automations 11:29 Trading compute for attention 12:24 Homework 12:52 Closing Resources: Better with Kent: https://kentcdodds.com/better How I Build Web Apps in 2026: https://slides.com/kentcdodds/web-apps-in-2026#/5/2 Manual testing example PR: https://github.com/kentcdodds/kody/pull/550 Manual PR feedback loop example: https://github.com/kentcdodds/kentcdodds.com/pull/581 First informal self-running loop PR: https://github.com/kentcdodds/kody/pull/280 First formal PR loop example: https://github.com/kentcdodds/kody/pull/155

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 uses a shared cart / group ordering ticket (same food-delivery app as the Kano episode) and Clay Christensen's Jobs to Be Done framework to show why the expensive mistake is building the wrong thing — not bad code. Land three beats: ticket ≠ job, hire/fire/progress, and the habit "What job is this for?" before the estimate, PRD, or agent prompt. Wayne Allan (Become an Epic Product Engineer) on building for every person in Australia logging in at once — ~1.2M AUD, zero users. Walk three questions: progress and circumstance, what they hire today (group text, separate orders, Venmo as workaround), and what "fired" looks like. Aaron Francis on what users actually want vs the button they asked for. 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, metrics limits, qualitative signal. Homework: one sentence for your next ticket. Books in description: *Competing Against Luck* (Christensen et al.) · *Jobs to be Done: Theory to Practice* (Ulwick). Better with Kent Episode 4 June 12, 2026 ★ Episode details: https://share.transistor.fm/s/6ea8bbee ★ Additional episodes: https://kentcdodds.com/better

Is sentience computable? Grady Booch on Church-Turing and why software is far from a computable mind. This clip comes from Kent's full conversation with Grady about architecture, LLMs, and what stays uniquely human in engineering. Full episode: https://www.epicproduct.engineer/software-architecture-human-judgment-and-ais-limits-with-grady-booch~e3ly9

Grady Booch wants you to read MacPaint and the Linux kernel. Curiosity across domains builds judgment. This clip comes from Kent's full conversation with Grady about architecture, judgment, and learning from systems built under different constraints. Full episode: https://www.epicproduct.engineer/software-architecture-human-judgment-and-ais-limits-with-grady-booch~e3ly9

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) ( https://www.youtube.com/watch?v=Z-Lh1NYN7lE ) * Railway — Your AI wants to nuke your database ( https://blog.railway.com/p/your-ai-wants-to-nuke-your-database ) * Jer Crane — original incident write-up (mirror) ( https://www.pixelsham.com/2026/04/27/jer-crane-an-ai-agent-just-destroyed-our-production-data-it-confessed-in-writing/ ) * Zenity — System prompts are not security controls ( https://zenity.io/blog/current-events/ai-agent-database-deletion-pocketos ) * Better with Kent on kentcdodds.com ( https://kentcdodds.com/better ) Better with Kent Episode 3 June 12, 2026 ★ Episode details: https://share.transistor.fm/s/346e3014 ★ Additional episodes: https://kentcdodds.com/better

https://www.epicproduct.engineer/events/product-engineering-workshop-2026-07 You're invited to join me for the Epic Product Engineer Workshop!

Architecture is where change hurts. Grady Booch on significant design and LLMs as one subsystem. This clip comes from Kent's full conversation with Grady about software architecture, human judgment, and AI's limits. Full episode: https://www.epicproduct.engineer/software-architecture-human-judgment-and-ais-limits-with-grady-booch~e3ly9

Kent talks with Grady Booch about what software engineering still means in the age of AI agents, why implementation is only one part of the work, and why human judgment remains central to building durable systems. They discuss software architecture, the limits of large language models, computable minds, product engineering across different risk and complexity levels, and the kind of curiosity that helps engineers grow beyond a narrow slice of the field. 00:00 - Introduction to Product Engineering 01:00 - Grady Booch background 06:47 - The Last Software Engineer 09:00 - Will the software industry end? 10:04 - Consciousness and the computable mind 20:13 - What is software engineering? 27:45 - Software architecture and agents 35:30 - The ceiling for LLMs on implementation 39:33 - Durable skills and human judgment 41:39 - Curiosity beyond your domain 45:47 - Homework: read foreign source code Grady brings a rare long-view perspective to the AI and software engineering conversation: early computing, Rational Software, UML, IBM Research, NASA work, software architecture, and current research into computing and the human experience. That background gives this episode a useful tension. Kent and Grady do not agree on every framing, especially around whether the software development industry could eventually "end," but they find common ground around judgment, curiosity, and the responsibility engineers have for what they build. A major theme is that implementation is not the whole of software engineering. Grady breaks the work into a broader journey from imagination to executable artifacts, with computer science, algorithms, architecture, organizational forces, economics, risk, and ethics all shaping the result. Agents and LLMs can help with some of that work, but Grady argues they remain unreliable narrators: useful, fast, and sometimes impressive, while still needing experienced humans who can smell when the work is going off the rails. The episode closes with a practical challenge for engineers: broaden your judgment by studying systems and ideas outside your usual domain. Read unfamiliar source code. Read books outside your lane. Build the curiosity that gives your technical decisions more context. Homework * Read the source code for a system that is completely foreign to your usual work. * Use historical or open source systems like MacPaint, MediaWiki, or the Linux kernel to study different constraints and architectures. * Read a book outside your domain, such as The Sciences of the Artificial, Systemantics, or The Society of Mind. Resources * Grady Booch ( https://booch.com/computing/about.html ) * Computing: The Human Experience ( https://booch.com/computing/ ) * The Last Software Engineer ( https://kentcdodds.com/talks/the-last-software-engineer ) * The End of History and the Last Man ( https://www.penguin.co.uk/books/13399/the-end-of-history-and-the-last-man/9780241960240.html ) * Anil Seth: Why AI is unlikely to become conscious ( https://www.ted.com/talks/anil_seth_why_ai_is_unlikely_to_become_conscious ) * Kluge ( http://klugethebook.com/kluge/book.html ) * The Society of Mind ( https://www.simonandschuster.com/books/Society-Of-Mind/Marvin-Minsky/9780671657130 ) * World Models ( https://worldmodels.github.io/ ) * Global Workspace Theory ( http://cogweb.ucla.edu/CogSci/GWorkspace.html ) * A Robust Layered Control System for a Mobile Robot ( https://people.csail.mit.edu/brooks/papers/AIM-864.pdf ) * I Am a Strange Loop ( https://www.hachettebookgroup.com/titles/douglas-r-hofstadter/i-am-a-strange-loop/9780465030798/ ) * The C++ Programming Language ( https://stroustrup.com/1st.html ) * D3 ( https://d3js.org/ ) * Victorian Engineering Connections ( https://thebrunelmuseum.com/engineering-connections/ ) * Computer History Museum Software History Center ( https://computerhistory.org/software-history-center/ ) * MacPaint and QuickDraw Source Code ( https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/ ) * MediaWiki Source Code ( https://www.mediawiki.org/wiki/Source_code ) * Linux Kernel Archives ( https://kernel.org/ ) * The Sciences of the Artificial ( https://mitpress.mit.edu/9780262354752/the-sciences-of-the-artificial/ ) * Systemantics ( https://archive.org/details/systemantics00john ) Guest: Grady Booch * Company: Computing: The Human Experience ( https://booch.com/computing/ ) * GitHub: @gradybooch ( https://github.com/gradybooch ) * 𝕏: @grady_booch ( https://x.com/grady_booch ) Host: Kent C. Dodds * Website: kentcdodds.com ( https://kentcdodds.com/ ) * 𝕏: @kentcdodds ( https://x.com/kentcdodds ) * GitHub: @kentcdodds ( https://github.com/kentcdodds ) * YouTube: Kent C. Dodds ( https://www.youtube.com/channel/UCz-BYvuntVRt_VpfR6FKXJw ) * Podcast: epicproduct.engineer ( https://epicproduct.engineer ) See on Epic Product Engineer ( https://www.epicproduct.engineer/software-architecture-human-judgment-and-ais-limits-with-grady-booch~e3ly9 ) Become an Epic Product Engineer...

Swizec Teller explains why product engineers should obsess over the user's new superpower instead of the internal puzzle of the implementation. The code matters, but only because of what it unlocks for the person on the other side. This clip comes from Kent's full conversation with Swizec about user outcomes, workflow design, and better product instincts. Full episode: https://www.youtube.com/watch?v=JmRBqjSJxVY&list=PLV5CVI1eNcJgd2-5DISAbfVuNWa1-DZsj

Kent talks with Swizec Teller about product engineering for software that serves real businesses and non-developer users: how to learn a domain you did not grow up in, how to spot hidden friction by watching people work, and why the best product work focuses on outcomes, not engineering puzzles. They talk through biotech, internal tooling, habits users build around buggy software, feature placement, success metrics, and how to widen the pit of success for people who are just trying to do their jobs. Chapters 0:00 Intro 1:04 Swizec's path from startups to biotech 2:18 Learning a domain you didn't grow up in 5:14 Widening the pit of success 9:46 Introducing workflow changes without friction 12:11 Feature flags and early feedback loops 16:11 How to find real user needs 20:02 What support tickets tell you about users 22:55 Reading friction as a product signal 24:51 Automation and what it changes for users 26:58 Where to place new capabilities 29:26 Breaking big ideas into shippable pieces 33:31 Defining success before you ship 37:27 Software is valuable for what users can now do Swizec brings a perspective that broadens the season in a useful way. Instead of developer-facing tools, he has spent years building software that supports biotech, healthcare, and other real-world businesses where the user is trying to get work done, not admire your architecture. That makes the conversation very grounded in observation: shadowing experts, noticing workaround behavior, understanding existing habits, and putting new capabilities exactly where people already look. The second half of the episode turns that into a practical product loop. Swizec and Kent talk about defining success before you ship, measuring whether a workflow actually improved, and balancing long-range vision with the adjacent possible of what today's technology can support. The result is a strong reminder that software is valuable because of the user's new "superpower," not because the implementation was clever. Homework - Spend one hour watching users use your software. - If you do not have direct access to users, ask your manager or PM to connect you with someone internally, or watch a partner or friend try a real workflow while you take notes. - Treat every workaround or confusing step you see as a potential product opportunity. Resources - Swizec Teller — https://swizec.com/ - Swizec newsletter — https://swizec.com/letters - Swizec Teller - GitHub — https://github.com/Swizec Guest: Swizec Teller - GitHub: @Swizec — https://github.com/Swizec - X: @swizec — https://x.com/swizec Host: Kent C. Dodds - Website: kentcdodds.com — https://kentcdodds.com/ - X: @kentcdodds — https://x.com/kentcdodds - GitHub: @kentcdodds — https://github.com/kentcdodds - YouTube: Kent C. Dodds — https://www.youtube.com/channel/UCz-BYvuntVRt_VpfR6FKXJw - Podcast: epicproduct.engineer — https://epicproduct.engineer

Swizec Teller shares how customer support conversations revealed a whole class of biotech users the team was barely serving at all: admins with budget responsibility who had no visibility into what was happening. This clip comes from Kent's full conversation with Swizec about user research, workflow design, and building software for real businesses. Full episode: https://www.youtube.com/watch?v=JmRBqjSJxVY&list=PLV5CVI1eNcJgd2-5DISAbfVuNWa1-DZsj

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 fight 1:39 What type of feature is this? 2:15 Basics (Must-be) 3:47 Performance needs 5:38 Delighters 6:32 GPS lifecycle reveal 7:56 Why silence misleads teams 10:00 Cannot delight out of broken basics 10:36 AI and the junk drawer 11:52 Prioritized build order 14:25 Homework and close Better 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: https://www.youtube.com/watch?v=XYhLG7a5Qp0

Shipping on time is table stakes. Jack Ryan on whether people use what you shipped last week. This clip comes from Kent's full conversation with Jack about user empathy, feedback loops, and what not to build. Full episode: https://www.epicproduct.engineer/user-empathy-feedback-loops-and-what-not-to-build-product-engineering-with-jack-ryan~ed0b0

Ask "would this solve it?" and they'll say yes. Jack Ryan on why what to build is still your call. This clip comes from Kent's full conversation with Jack about user empathy, feedback loops, and what not to build. Full episode: https://www.epicproduct.engineer/user-empathy-feedback-loops-and-what-not-to-build-product-engineering-with-jack-ryan~ed0b0

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) ( https://www.infoworld.com/article/4176534/ai-coders-need-good-software-engineers.html ) * The Last Software Engineer (essay) ( https://www.epicproduct.engineer/the-last-software-engineer ) * Become an Epic Product Engineer (guest podcast) ( https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast ) * Better with Kent on kentcdodds.com ( https://kentcdodds.com/better ) Better with Kent Episode 1 May 29, 2026 ★ Episode details: https://share.transistor.fm/s/8db60551 ★ Additional episodes: https://kentcdodds.com/better

PM bets used to burn a million before you had proof. Jack Ryan on AI-sized teams that pivot before the miss. This clip comes from Kent's full conversation with Jack about user empathy, feedback loops, and what not to build. Full episode: https://www.epicproduct.engineer/user-empathy-feedback-loops-and-what-not-to-build-product-engineering-with-jack-ryan~ed0b0