3 Habits of Product Engineering With AI Agents

When AI agents level the implementation playing field, product engineering becomes the differentiator that decides which software wins. Kent C. Dodds argues that knowing what to build, and whether it is worth building at all, is the durable skill left for engineers once agents handle implementation. This article distills his workshop on validating ideas, choosing the smallest useful slice, and connecting user understanding to architecture.

Why Product Engineering Is the Durable Skill Left

Product engineering is the skill of deciding what to build and whether it is worth building, and it becomes the differentiator once AI agents make implementation cheap. Dodds, a long-time educator of experienced software engineers and founder of Epic Web, presented this thesis at the AI Engineer conference in a two-hour workshop titled "Build the Right Thing."

His argument starts with an archer metaphor. Engineers spent careers getting good at hitting any target a product manager set. Agents now act like homing arrows: most targets are reachable, and engineers can reach far more targets than before. The remaining scarcity is choosing which target has value, because resources and user attention are finite and users can be overwhelmed by features they never asked for.

The thesis comes from Dodds' own career shift. He graduated from BYU in 2014, spent 12 years developing software, and went full-time teaching in 2019, accelerating how experienced engineers gain experience. In 2026 he watched agents get good enough that he questioned whether anyone still needs a React course, and two existential crises later he landed on this: teach durable judgment, not frameworks that change every month.

Dodds is explicit that this is directionally true rather than absolute. Agents still make mistakes, and handing today's tools to a non-technical person will not produce maintainable software that lasts 35 years. But the trajectory matters: implementation is in the process of leveling, so ideas and judgment are becoming more valuable relative to execution. He calls this the last skill a software engineer needs to learn.

Product Engineer vs Product Manager: Where the Line Sits

A product engineer is not a product manager with a different title. The product engineer stays in the code and the system; the product manager owns the upstream problem space. Wayne Allen, on Dodds' podcast, put the split this way: the product concern is building the right thing, the engineering concern is building the thing right, and building the thing right is downstream of building the right thing.

The comparison, based on Dodds' workshop, looks like this:

Dimension	Product engineer	Product manager
Core focus	Connecting user needs to technical choices	Defining what to build and why
Owns	Data model, workflow shape, constraints, observability, failure modes, smallest slice	Priorities, roadmap, user discovery
Key asset	Knowledge of system primitives and their limits	Depth of customer conversations
Failure mode	Polished implementation that misses the point	Requests handed off without technical context

An engineer who just turns a ticket into an implementation looks, in Dodds' words, a lot like an agent, and that makes the role replaceable. The product engineer instead asks why the request exists, because that answer shapes the system: a one-off experiment deserves different investment than a capability the business depends on.

How Agents Change What Is Scarce

Agents change the economics of software by making implementation a commodity, which means bad decisions now propagate faster. Dax Raad, creator of OpenCode, observed on Dodds' podcast that the default destination of new coding-agent ability is work on the wrong things, so products go from good to bad faster than ever. An agent will not stop and say the system is bloating; that restraint is human responsibility.

Rita Kozlov, a product leader at Cloudflare who appeared on the same podcast, added the flip side: it is easy to get a functional-looking prototype quickly and ship it, but the surface layer can hide something that does not scale or handle edge cases. Her advice, as Dodds reports it, is for engineers to take ownership, sometimes throwing away the prototype and having Cursor rebuild it in two hours with proper framing, because engineers who expect a 2 a.m. page build careful systems.

Aaron Francis compressed the risk into one line Dodds quoted: you can do the wrong thing incredibly fast and feel like you are making a ton of progress. Dodds' own version of the nightmare is producing 10,000 lines of code a day on the wrong thing, then hitting sunk-cost paralysis because you cannot stop now. With editors like Cursor, the cost of building the wrong abstraction has dropped while the long-term cost of changing architecture, in team impact and user impact, has not.

Validating Ideas With The Mom Test

The Mom Test, Rob Fitzpatrick's book on customer conversations, is Dodds' primary framework for early idea validation. The rule is simple: do not ask users to evaluate your idea or diagnose the problem. Questions like "Would you use this?" invite compliments, because people want to end the conversation politely, the same way your mom praises everything you make.

Better questions target past behavior instead of future intent:

• Tell me about the last time this happened.
• What did you do instead? What was the workaround?
• What did that workaround cost you, in time or money?
• How often does this happen, and how much effort are you already spending on it?

Dodds ran the exercise live using the workshop's own problem: a long line outside the room. Questions such as "Is this a problem?" produced speculation, while "When were you last stuck in a line like this, and what did you do?" produced evidence. If someone cannot remember the last occurrence, or gave up and stopped caring, that is a real signal the problem may not be worth solving.

The payoff connects directly to architecture. Knowing what users currently do to solve the problem helps an engineer decide whether the problem is core to the business or an experiment, and that decision determines how much investment the data model, migration strategy, and failure handling deserve. Michael, founder of the authentication platform WorkOS, told Dodds he asked prospects what they were losing by not having a solution; those interviews also led him to choose a hosted model, because a security fix cannot wait for customers to upgrade an npm package.

Why User Understanding Changes Architecture

User understanding is not soft context; it changes hard technical decisions. Dodds points to Instagram's origin: the app started as Burbn, a check-in product, and the team noticed the only feature people actually used was photo sharing, so they removed everything else and focused on that one job. Watching real behavior, not opinions, drove the architecture.

Uncle Bob, on Dodds' podcast, described being sent out on a telephone repair truck to watch a technician use his software while hanging off a pole. Watching the man work gave him 30 ideas for improving the interface on the spot. The experience changed how he designed software and, in his view, a product engineer lives half in the technology and half in the customer's house. Grady Boch, also a guest, framed engineering judgment as technical experience married to human issues.

Don Norman, who coined the term user experience at Apple and wrote The Design of Everyday Things at 90 years old still guesting on podcasts, gave the strongest version of the point: after the 1979 Three Mile Island accident, he concluded the operators were competent and the system was wrong, because user error does not exist. If the system makes mistakes easy, the fix is design, and that fix starts with understanding users.

The Wayne Allen story is the expensive counterexample. His team in Australia spent about a year and 1.2 million Australian dollars, roughly 900,000 US dollars, building a microservices product scaled for every person in Australia logging in at once. Nobody used it, not one person. He later calculated they could have launched in two weeks and handled integration manually, which is always the painful part anyway, and learned far more far cheaper.

The Smallest Slice and Closing the Feedback Loop

The smallest useful slice is the product engineer's antidote to overbuilding. Dodds contrasts three delivery shapes: waterfall ships one complete thing at the end, agile ships small useful slices repeatedly, and AI generation tends to produce the whole thing at once, leaving the engineer to whittle it down to what is actually useful.

Validation does not end when the idea is approved. Dodds says talking to customers and building happen constantly, in a loop that never stops. Early prototypes go to early adopters even with gaping holes, because reactions are diagnostic: users who push through rough edges and still reach their goal reveal a problem worth solving, while users who quit over paper cuts reveal one that is not.

Asked how many features an MVP should have, Dodds called the question wrong. The real question is what minimal thing demonstrates that you solve a problem for a target audience, and in a crowded space, that means niching down further on the audience as well.

Hiring and Interviewing for Product Judgment

Hiring for product engineering changes the interview itself. Dodds rejects coding challenges that ban AI agents, because the job now includes directing agents, and asks systems questions instead: here is a problem, what questions would you ask to find the core of it, and what are the system implications of that discovery?

On whether engineers and product managers should sit in separate organizations, he notes that applications end up looking like the org chart, and argues for tight integration. Engineers should also see at least one neighboring team in each direction, so they reuse existing organizational primitives instead of rebuilding solved problems, the same way a React developer must understand JavaScript and the browser to use the framework well.

As teams scale, he expects smaller organizations to run bigger businesses than before, because agents absorb coordination work. The junior-to-senior path, though, has not fundamentally changed: juniors emulate seniors until the judgment transfers, and the promotion conversation remains a conversation with a person.

FAQ

• What is product engineering? Product engineering is the practice of connecting customer needs to technical choices such as the data model, workflow shape, constraints, observability, and the smallest useful slice. It differs from product management by staying grounded in the actual system and its primitives.

• Why does product engineering matter more with AI agents? Agents make implementation cheap, so producing code no longer differentiates engineers. Deciding which target is worth hitting, and whether a feature deserves engineering time at all, remains a human judgment call.

• What are good Mom Test questions? Ask about the last time the problem happened, what the person did instead, what the workaround cost, and how much effort they already spend on it. Avoid "Would you use this?" and "How much would you pay?" because those invite polite compliments rather than evidence.

• Should engineers talk to customers? Yes, continuously. Dodds argues the feedback loop never closes, and that engineers who watch users work, like Uncle Bob on the telephone truck, make systematically better architectural decisions.

• Does product engineering replace product management? No. The product manager owns upstream problem definition while the product engineer translates that understanding into system shape. Small startups may combine the roles, but the responsibilities remain distinct as companies grow.

• What happened in the Wayne Allen failure story? His Australian team spent a year and 1.2 million Australian dollars on a microservices product nobody used. He concluded they could have launched a manual version in two weeks and tested the market far cheaper.

• How do you interview for product judgment? Dodds would not run coding challenges that ban agents. He asks candidates what questions they would use to find a problem's core, then what the system implications of that discovery are.

• Can you give today's tools to non-technical people? Not yet for maintainable software. Dodds says the playing field is leveling rather than leveled, and that he would not expect a non-technical person to ship software that lasts decades with current agents.

• When do you stop validating and start building? You never fully stop. Dodds says customer conversations and building run as one continuous loop, and early prototypes should reach early adopters even with obvious gaps.

Turn Your Own Talks Into Written Insight

The core lesson of the workshop is that valuable knowledge already exists in conversations, and the skill is getting it to the people who need it. The same applies to your own content. If you have talks, interviews, or explanations sitting inside YouTube videos, Skala Blog turns them into structured, publishable articles.

The flow is simple: paste a YouTube URL, transcribe the video, and generate an article. Readers of Gustavo Dev Doido know this pattern from the Skala Blog, which also covers material like Crazystack Typescript and the Bootcamp do Dev Doido. If a two-hour workshop can become a reference document, your videos can too.

Source video