Kent talks with Robert C. Martin - Uncle Bob - about what AI agents change, what they do not change, and why software architecture, design sense, and customer empathy still matter.

They cover why engineers may need to "walk away from the code" while still caring about structure, how agents can be guided with quality tools, why beginners still need to learn the material agents manipulate, and what product engineering looks like when implementation gets cheaper.

• (00:00) - Meet Robert C. Martin

Robert C. Martin has watched software move through layers of abstraction for decades: binary, assembly, high-level languages, frameworks, and now AI agents. In this conversation, he and Kent talk about the next layer up and the durable engineering judgment that still belongs to humans.

A major theme is that the low-level work keeps changing while the high-level rules of design and architecture stay remarkably stable. Bob argues that if engineers want the real benefit of agents, they will eventually need to stop treating code as the primary surface and start reviewing module structure, dependencies, data flow, and system behavior. But that does not mean code quality stops mattering. It means humans need better feedback loops, better tools, and enough design sense to know what to ask the agents to improve.

They also talk about new engineers, education, and the danger of skipping the code too early. Agents are power tools, and Bob's advice is that engineers still need to understand the material those tools are shaping. The episode lands on product engineering as the marriage of deep technical skill and deep customer understanding: the product engineer lives partly in the technology and partly in the customer's world.

Homework

• Try Robert C. Martin's SwarmForge project locally and follow the setup instructions far enough to run it.
• Use it to experiment with coordinated agents passing tasks or information to each other.
• If you find a problem or a useful improvement, leave an issue on the GitHub repo so the product feedback loop closes.

Resources

• Robert C. Martin
• Clean Coders
• SwarmForge
• Agile Manifesto
• Clean Code

Guest: Robert C. Martin

• Company: Uncle Bob Consulting LLC
• GitHub: @unclebob
• 𝕏: @unclebobmartin

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See on Epic Product Engineer

Kent talks with Annie Sexton, developer educator at ngrok, about the durable skills engineers need as AI changes the shape of software work.

They cover how to teach complex technical ideas without assuming too much, why curiosity keeps engineers from becoming button pushers, how pacing and storytelling make educational content work, and why UX and product judgment are becoming harder to ignore.

• (00:00) - Meet Annie Sexton

Annie Sexton is a developer educator, software engineer, and technical video creator whose work has focused on making difficult infrastructure and software concepts feel approachable. In this conversation, she and Kent talk about teaching developers in an AI-heavy world, where syntax and implementation details are cheaper but curiosity, taste, pacing, and user empathy matter more.

A major thread in the episode is education as product work. Annie describes writing for the mid-level JavaScript developer, using curiosity to pull people into topics they did not expect to care about, and treating comments, retention, and repeated confusion as feedback loops. Kent connects that to jobs to be done, teaching with agents enabled, and the need to understand what learners actually need now instead of preserving old rituals just because they were once necessary.

They also dig into the emotional and practical shift AI has created for engineers. Annie talks honestly about losing some of the old joy of hands-on coding while finding a new place for that energy in product thinking, UX, and education. The episode closes with two concrete pieces of homework: read Badass: Making Users Awesome, and practice noticing every little point of friction in a product you almost chose but did not.

Homework

• Read Badass: Making Users Awesome by Kathy Sierra and pay attention to the shift from making an impressive product to making users feel capable.
• Pick a product you considered using but rejected, then go through its onboarding or core flow again.
• Write down every specific point of friction, confusion, hidden error, awkward field, or moment where your eyes glaze over.

Resources

• Annie Sexton
• ngrok
• Fly.io
• Badass: Making Users Awesome
• Webcomic Studio

Guest: Annie Sexton

• Company: ngrok
• GitHub: @anniebabannie

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See on Epic Product Engineer

Kent talks with Michael Shimeles - Rasmic - about building products in the AI era without losing the engineering judgment that makes software useful.

They cover AI consulting, why clients often ask for the wrong thing, how to push conversations back to the real problem, why simplicity is a product advantage, and why developers are more valuable when they combine technical skill with taste, domain knowledge, and user empathy.

• (00:00) - Meet Michael Shimeles

Michael Shimeles is a full-stack engineer, DevX engineer at Convex, creator, and the person behind a product studio and AI consultancy. In this conversation, he and Kent talk about what happens when every company suddenly wants agents, automation, and custom AI tools - and why the right answer is sometimes "you do not need AI yet."

A major thread in the episode is problem discovery. Michael describes clients who come in excited about subagents, custom harnesses, or the newest tool from a YouTube video, while the real job is to slow down, ask what problem they are trying to solve, and decide whether a simple workflow, an off-the-shelf tool, or a custom product is actually warranted. Kent connects that to The Mom Test and the value of doing things the hard way first so you know where existing solutions fall short.

They also dig into taste and simplicity. Michael argues that AI has made it easier to ship software, but not easier to care. Taste comes from shipping, noticing products you wish you had made, learning from feedback, and making the path from a user's problem to a solved problem as short as possible. The episode closes with a practical challenge for engineers using agents: go back to the old engineering books. Syntax is cheaper now, but engineering, architecture, first-principles thinking, and simplicity make you better at directing AI.

Homework

• Pick one classic engineering book you have ignored or dismissed and read it with AI-assisted development in mind.
• Notice how the engineering principles from that book change the way you prompt, review, and steer coding agents.
• Treat agents as code-writing accelerators, not replacements for architecture, simplicity, and first-principles thinking.

Resources

• Ras Mic - Michael Shimeles
• Convex
• Fabrika
• The Mom Test
• Clean Code

Guest: Michael Shimeles

• Company: Convex
• GitHub: @michaelshimeles
• 𝕏: @rasmic

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

Kent talks with Lucas Wargha, engineering manager at FamilySearch, about turning software engineers into product engineers: understanding mission and business outcomes, talking to real users across cultures, and stopping the assembly line of JIRA handoffs.

They cover customer personas at global scale, the Gmail password-loading story as product-engineering thinking, owning epics end-to-end, creators vs consumers, and a hopeful take on historic days in our industry.

• (00:00) - Introduction to Product Engineering

Lucas leads engineers building FamilySearch Memories - tools for photos, audio, and stories that help people connect with family beyond names and dates. He describes a shift away from engineers as expensive task-takers toward people who understand company vision, product outcomes, and why a rewrite or maintenance project is worth doing.

A thread through the episode is customer literacy: mapping personas, interviewing users in Brazil and discovering translation nuances you would never see in analytics alone, and balancing qualitative insight with data when the customer base is literally global. Lucas and Kent compare product engineers and product managers, why role sprawl happened, and what changes when engineers own milestones across web and mobile instead of finishing isolated stories.

They also talk about practical culture moves - engineers delivering food like DoorDash did, using your own product, the Gmail team preloading after you type your email, and why fulfillment comes from creating value for people rather than optimizing reducers. Lucas closes with homework grounded in his motto: know your customer better than your code, and talk to three users before you implement your next story.

Homework

• Know your customer better than you know your code - measure whether you get as passionate about product outcomes as you do about architecture debates.
• Take the first story on your board (or next assigned work) and talk to three different potential users across personas before you implement it.
• Resist finishing the story in isolation - what you learn from those conversations should change what you build.

Resources

• FamilySearch
• Lucas Wargha (site)
• Competing Against Luck (Jobs to Be Done)
• UtahJS

Guest: Lucas Wargha

• Company: FamilySearch
• GitHub: @lucaswargha
• 𝕏: @lucaswargha

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: Kent C. Dodds
• Podcast: epicproduct.engineer

See on Epic Product Engineer

Kent talks with Ruben Casas about building products again in the AI-agent era: why experienced engineers can now stay close to customers and code, how demos turn vague ideas into something people can react to, and why product judgment matters more as implementation gets cheaper.

They cover Postman, MCP, agent-driven UI, prototypes, early user feedback, feature product-market fit, and the engineering guardrails that help teams ship quickly without turning the product into a pile of disconnected features.

• (00:00) - Introduction to Product Engineering

Ruben brings a practical perspective from building developer tooling, platform work, and AI-agent products at Postman. The conversation starts with a shift many experienced engineers are feeling right now: agents make it possible to stay involved in higher-level product decisions while also getting hands-on with implementation again. That is exciting, but it also raises the bar for deciding what is worth building in the first place.

A recurring theme in the episode is that demos and prototypes are not just engineering exercises. They are product tools. Ruben and Kent talk about starting from a real pain point, building just enough to show the opportunity, putting it in front of users quickly, and using that feedback to decide whether the idea deserves more investment. They also dig into the risk of shipping too many mildly useful features, and why product engineers still need architecture, testing, taste, and guardrails as more people use AI to touch production code.

Homework

• Find a real problem that is bothering you.
• Use an agent to build a quick prototype for it, especially if you have not tried AI coding tools seriously yet.
• Record a short demo, send it to someone, and ask for feedback.

Resources

• Ruben Casas
• Postman
• Rethinking UI in Agent-Driven Systems
• MCP Apps

Guest: Ruben Casas

• Company: Postman
• GitHub: @infoxicator
• 𝕏: @infoxicador

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: Kent C. Dodds
• Podcast: epicproduct.engineer

See on Epic Product Engineer

Kent talks with Sean Roberts, engineer at PhotoShelter, about product engineering shaped by agency work and small teams: being the technical person in sales conversations early, planning with product judgment, and knowing when to speak up (and when to listen).

They discuss why implementation skill still matters in the AI era, how to avoid "vibes-only" product calls, budgeting and sequencing work with business context, and why striking up real conversations (with customers or anyone) is a trainable muscle.

• (00:00) - Introduction to Product Engineering

Sean's path is a familiar pattern for this season: years of agency and startup work where engineers sit close to customers, budgets are real, and the person writing code is often in the room when the problem gets defined. He describes learning to ask questions on sales calls as a junior developer, sometimes literally driving the founder to the meeting, and translating needs into feasible software on the spot.

The middle of the episode turns toward planning inside a product company: helping teams separate solved problems from "dark forest" work, pushing back on specs that underestimate legacy complexity, and bringing beginner's mind even when you are senior. Sean is honest that much of his product sense today is still conversation-driven, and he wants better analytics to complement that, not replace it.

Kent and Sean also touch the emotional side of the job: positive feedback when you save someone tedium, the risk of changing UX too often because *you* are bored, and why relationships matter if you want to hear "you made my life easier." The homework is deliberately low ceremony: talk to someone you do not normally talk to and practice curiosity.

Homework

• Ask someone you do not normally talk to at work for 15 minutes: a salesperson, PM, support lead, or another engineer on a different team.
• Ask about their job, challenges, and customers; practice translating what you hear into software constraints without jumping to solutions too fast.
• If work feels awkward, practice the same muscle outside work (cashier, server, neighbor) - the goal is conversation comfort, not a formal interview.

Resources

• PhotoShelter
• Sean Roberts - GitHub

Guest: Sean Roberts

• Company: PhotoShelter
• GitHub: @seanroberts
• 𝕏: @sean_j_roberts

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: Kent C. Dodds
• Podcast: epicproduct.engineer

See on Epic Product Engineer

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

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
• Computing: The Human Experience
• The Last Software Engineer
• The End of History and the Last Man
• Anil Seth: Why AI is unlikely to become conscious
• Kluge
• The Society of Mind
• World Models
• Global Workspace Theory
• A Robust Layered Control System for a Mobile Robot
• I Am a Strange Loop
• The C++ Programming Language
• D3
• Victorian Engineering Connections
• Computer History Museum Software History Center
• MacPaint and QuickDraw Source Code
• MediaWiki Source Code
• Linux Kernel Archives
• The Sciences of the Artificial
• Systemantics

Guest: Grady Booch

• Company: Computing: The Human Experience
• GitHub: @gradybooch
• 𝕏: @grady_booch

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See on Epic Product Engineer

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.

• (00:00) - Intro

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
• Swizec newsletter
• Swizec Teller - GitHub

Guest: Swizec Teller

• GitHub: @Swizec
• 𝕏: @swizec

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See on Epic Product Engineer

Kent talks with Jack Ryan, Principal Engineer at Intercom, about product engineering at scale: why implementation is only part of the job, how to broaden what you measure as success beyond shipping tickets, and why customer feedback is an input, not a product roadmap.

They cover startup lessons from property tech, metrics vs. conversation, AI-era decision-making, performance trade-offs, PM/engineering overlap, and practical ways engineers can tighten feedback loops without outsourcing judgment to users.

Jack brings a useful split perspective: early UK proptech startup experience where engineering success and company success were basically the same thing, followed by years of technical leadership at Intercom without people management. That combination shows up throughout the episode in how he talks about responsibility, ambiguity, and what still matters when agents can generate more code faster.

A big theme is reframing success. Instead of celebrating "I shipped the ticket on time," Jack argues product engineers look back at whether the thing they shipped is being used, whether customers are happy, and whether the work connected to business outcomes. Metrics help start those conversations, but he is skeptical of sweating small week-to-week movements on a single number when qualitative signals and customer conversations often tell you more.

The close is especially practical: engineers can use their craft to improve product judgment, not only implementation - by wiring up real customer feedback channels (Slack feeds, sales-call snippets, forward-deployed engineer patterns) and learning to ask *why* people want something before deciding what to build.

Homework

• Find good sources of customer feedback in your org (support, sales, success, research, or forward-deployed engineers).
• Use engineering to put that feedback somewhere you will actually see it regularly - wire up a Slack channel, dashboard, or digest so the signal can "wash over you" the way Jack describes.
• Practice asking *why* a customer wants something before treating their feature request as the spec.

Resources

• Jack Ryan - Intercom Blog
• Intercom
• requisite (Intercom open source)

Guest: Jack Ryan

• Company: Intercom
• GitHub: @jmfryan
• 𝕏: @jmfryan

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See on Epic Product Engineer

Kent talks with Rhys Sullivan about building Executor and thinking like a product engineer in the AI-agent era: how to design the right primitives, why agent experience is becoming its own product surface, and how to keep quality high when shipping has never been easier.

They cover MCP, code mode, approvals, workspace scoping, docs and APIs as user experience, and why slowing down can still be the right move even when agents make speed feel free.

Rhys has an unusually current perspective on product engineering because he is working right at the edge of the agent tooling shift. The conversation starts with his recent work on Vercel Domains and then moves into Executor, where the challenge is no longer just implementing integrations, but choosing the abstractions that make a system composable, safe, and pleasant to use over time.

What makes the episode strong is how often it comes back to product judgment instead of novelty. Rhys and Kent talk about finding the right primitives, observing how other products solve hard UX problems, resisting the urge to ship every request immediately, and building systems that help agents without letting them become dangerously "helpful."

Homework

• Create a dedicated notes channel or system where you save examples of products doing something well.
• Use those notes as reusable product input: when you need to build a flow later, pull the examples back up instead of starting from scratch.

Resources

• Executor
• Rhys Sullivan - site
• Executor - GitHub
• OpenCode

Guest: Rhys Sullivan

• Company: Executor
• GitHub: @RhysSullivan
• 𝕏: @RhysSullivan

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See on Epic Product Engineer