In CodeRabbit's latest episode of The Merge, I sat down with software engineer and educator Kent C. Dodds, who has spent much of his career teaching developers how to build better software. He has taught JavaScript testing, React, full-stack web development, and, more recently, how to work with AI tools.
We’ve watched AI tools improve quickly, with agents implementing changes, opening pull requests, and iterating on review feedback. That raises a question many developers might be asking, and one Kent asked himself: "What is it that I do here now?"
Kent frames the future of software engineering through a thought experiment. As AI takes on more implementation work, he asks what the “last software engineer” would still need to do.
His answer is simple: “I think that it’s knowing what to build.”
When every arrow hits, choosing the target becomes the skill
For decades, a large part of a developer's value came from turning a defined idea into working software. Take the ticket, understand the requirements, write the code, ship the change, and repeat.
As agents take on more implementation, the engineer’s role shifts toward deciding what to build, shaping the system, and judging the result.
Kent compares developers to archers. “What makes one archer better than the other is the archer that knows which target is most valuable to hit. When those arrows just always hit, it's which one is being hit that will create the most value.”
That is the evolution Kent sees for software engineers, and he uses product engineering to describe it.
A product engineer understands architecture, data models, migrations, infrastructure, and the limits of the stack. But they connect those constraints directly to a user's problem. Kent describes that judgment as “could versus should.”
“Does that require an expansion of our system?”
Kent says engineers have to decide whether the system can reuse or consolidate what it already has, or whether the change truly requires a new primitive.
Fall in love with the problem, not the solution
One exercise Kent is designing for his product-engineering course starts with an ordinary request. A support team is processing too many refunds manually. Someone proposes adding a refund button to the support interface.
An implementation-first developer can take that request and start building. Kent’s exercise pushes the engineer one step upstream: “Why are we getting refund requests so much?”
Asking why can reveal whether a refund button addresses the underlying problem or simply makes the existing process faster. Kent's takeaway is that a technically sound solution can still miss the problem.
That same focus on the problem shapes how Kent thinks engineers should work with product managers. A product manager can help engineers understand the domain, but engineers also need direct exposure to the problems users are experiencing. That might mean listening in on customer calls or spending time with support.
“You do need to deeply understand the domain and deeply understand the problem,” he said.
As Kent puts it, “we just fall in love with the solution ... we should instead fall in love with the problem.”
In Kent’s framing, engineers bring two perspectives together. One is that product context explains which outcome matters and why. The other is that technical context explains what the system can support and what each choice will cost.
Own both sides of the implementation
The code is only the middle of a change.
Upstream, someone has to understand the user, the domain, the business constraint, and the reason the work deserves attention. Downstream, someone has to live with the migrations, maintenance costs, infrastructure demands, and user response.
Kent describes that responsibility this way: “I understand everything on both sides of the implementation.”
The agent can do substantial work in the middle. It can explore the repository, implement a change, run tests, open a pull request, and address valid review findings. The engineer carries responsibility for the decision and its consequences.
That makes ownership part of the engineering judgment Kent is describing.
Kent says ownership “forces you to stop and think about the impact, the downstream effects of the thing that you're about to do, that you're committing to do.”
An agent can tell you that a change is possible. A product engineer decides whether the change should exist and accepts responsibility for the answer.
Review the system, not only the syntax
Kent's current workflow offers a concrete picture of this role.
“I'll have the agent run. It will write the implementation, put it in a PR, and then there will be a review,” Kent said. He then asks the agent to keep working through CI and valid review feedback, with CodeRabbit as one of the reviewers in that loop. By the time Kent returns, the pull request has already gone through multiple rounds of implementation and review.
He looks at what changed, what new primitives were introduced, and migrations that may affect the broader system. That kind of review requires an understanding of the system before the change and an opinion about what it should become afterward.
In the end, the goal is to keep accountable judgment in the loop while agents handle more of the implementation and review work.
Tool expertise is a sinking stepping stone
Developers still need to learn how to use coding agents. Kent recommends choosing one tool, becoming productive with it, and staying aware of how the field changes.
He is more skeptical of spending months perfecting a workflow primitive.
A year ago, developers invested in prompt engineering, editor rules, hand-built orchestration, and Ralph loops. Kent's view is that agent platforms can quickly absorb these workflow techniques as built-in features.
Kent compares that kind of tool expertise to a sinking stepping stone: “The money you spend now to learn that is just getting you to the next stepping stone. And that stepping stone is sinking.”
Kent sees value in learning these workflows while cautioning against going too deep on techniques that the tools may soon build in.
A practical curriculum for developers
What should developers, especially junior developers, practice now?
- Learn one agent workflow well enough to ship. Choose one coding-agent tool and learn it well enough to work productively. Stay aware of how the field is changing without spending all your time chasing every new model, harness, or workflow technique.
- Build a strong model of one technical system. Depth still matters. Learn the framework, architecture, and operational constraints of a real codebase. Agents are more useful when you can tell whether they reused the right primitive or quietly introduced a second way to solve the same problem.
- Practice problem discovery. Talk to the people affected by the software. Spend time with support, listen in on customer calls, and ask questions that reveal the problem before committing to a solution.
- Review decisions, not just diffs. For every meaningful change, ask what new workflows entered the system. Look at migrations, maintainability costs, and downstream effects. A technically sound implementation can still reflect a poor system decision.
- Own something after it ships. Use observability and user feedback to see what happens after release. Feed what you learn back into the next decision. Ownership closes the loop between the original decision and its effects on users and the system.
The developer's job is getting bigger
As agents take on more implementation, Kent’s argument points toward a broader role for software engineers.
The engineer who can bridge product context and technical context understands both the user and the system. They give agents a productive environment, decide what to build, and remain accountable after it ships.
I closed the conversation by putting the idea to Kent this way:
“The best product engineer in 2030 will be the one who can understand what to build.”
Kent replied: “That's the simplest way I can say that.”
