{"slug": "what-would-the-last-software-engineer-still-need-to-do", "title": "What would the last software engineer still need to do?", "summary": "Software engineer and educator Kent C. Dodds said in CodeRabbit's podcast *The Merge* that as AI agents take over more implementation work, the last software engineer's core skill will be 'knowing what to build,' shifting the role toward product judgment and problem definition rather than coding. Dodds, who has taught JavaScript testing, React, and full-stack development, argues engineers must 'fall in love with the problem, not the solution' and understand both the product context and technical constraints to decide which targets are most valuable to hit.", "body_md": "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.\n\nWe’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?\"\n\nKent 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.\n\nHis answer is simple: “I think that it’s knowing what to build.”\n\n## When every arrow hits, choosing the target becomes the skill\n\nFor 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.\n\nAs agents take on more implementation, the engineer’s role shifts toward deciding what to build, shaping the system, and judging the result.\n\nKent 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.”\n\nThat is the evolution Kent sees for software engineers, and he uses product engineering to describe it.\n\nA 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.”\n\n“Does that require an expansion of our system?”\n\nKent 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.\n\n## Fall in love with the problem, not the solution\n\nOne 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.\n\nAn 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?”\n\nAsking 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.\n\nThat 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.\n\n“You do need to deeply understand the domain and deeply understand the problem,” he said.\n\nAs Kent puts it, “we just fall in love with the solution ... we should instead fall in love with the problem.”\n\nIn 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.\n\n## Own both sides of the implementation\n\nThe code is only the middle of a change.\n\nUpstream, 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.\n\nKent describes that responsibility this way: “I understand everything on both sides of the implementation.”\n\nThe 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.\n\nThat makes ownership part of the engineering judgment Kent is describing.\n\nKent 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.”\n\nAn agent can tell you that a change is possible. A product engineer decides whether the change should exist and accepts responsibility for the answer.\n\n## Review the system, not only the syntax\n\nKent's current workflow offers a concrete picture of this role.\n\n“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.\n\nHe 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.\n\nIn the end, the goal is to keep accountable judgment in the loop while agents handle more of the implementation and review work.\n\n## Tool expertise is a sinking stepping stone\n\nDevelopers 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.\n\nHe is more skeptical of spending months perfecting a workflow primitive.\n\nA 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.\n\nKent 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.”\n\nKent sees value in learning these workflows while cautioning against going too deep on techniques that the tools may soon build in.\n\n## A practical curriculum for developers\n\nWhat should developers, especially junior developers, practice now?\n\n**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.\n\n## The developer's job is getting bigger\n\nAs agents take on more implementation, Kent’s argument points toward a broader role for software engineers.\n\nThe 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.\n\nI closed the conversation by putting the idea to Kent this way:\n\n“The best product engineer in 2030 will be the one who can understand what to build.”\n\nKent replied: “That's the simplest way I can say that.”", "url": "https://wpnews.pro/news/what-would-the-last-software-engineer-still-need-to-do", "canonical_source": "https://coderabbit.ai/blog/the-last-software-engineer-knows-what-to-build", "published_at": "2026-09-03 00:00:00+00:00", "updated_at": "2026-09-03 16:54:51.711241+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-tools"], "entities": ["Kent C. Dodds", "CodeRabbit", "The Merge"], "alternates": {"html": "https://wpnews.pro/news/what-would-the-last-software-engineer-still-need-to-do", "markdown": "https://wpnews.pro/news/what-would-the-last-software-engineer-still-need-to-do.md", "text": "https://wpnews.pro/news/what-would-the-last-software-engineer-still-need-to-do.txt", "jsonld": "https://wpnews.pro/news/what-would-the-last-software-engineer-still-need-to-do.jsonld"}}