Product engineer and agentic engineer: the two new roles of 2026
Product engineer isn't a new title, but AI coding agents are reshaping what it requires day to day. Agentic engineer is the newer role forming alongside it.
- Product engineer is not a new title, PostHog and others have defined it for years, but coding agents are pushing the role further from hands-on technical execution and harder toward product/business judgment, its actual differentiator from a traditional software engineer.
- Agentic engineer is the genuinely new half. IBM traces "agentic engineering" directly to Andrej Karpathy, who coined the term in February 2026 to describe orchestrating and validating AI agents through the development process.
- The two roles sit at opposite poles of the same shift: as agents absorb technical execution, the remaining human judgment splits into deciding what to build (product engineer) and building the system that lets agents execute it reliably (agentic engineer).
- OpenAI's own Codex team is real evidence of the pull toward the product-engineer pole: with agents writing every line, their engineers' job became specifying intent and reviewing outcomes, not typing code.
- Most engineers will hold pieces of both roles on any given task, even without a formal two-title split; knowing which pole a given task calls for is more useful than picking one chair permanently.
Two role labels keep showing up together in conversations about AI-agent-driven development: product engineer and agentic engineer. Neither is brand new in the sense of never having existed before. AI coding agents are actively reshaping what each one requires.
Product engineer already has a real, years-old definition, the same one behind the older "product engineer vs software engineer" debate. What's changing is which side of that definition matters most: the role is being pushed further toward product judgment and further from hands-on code. Agentic engineer is the newer role emerging to own the technical side that shift leaves behind.
Product engineer: an old title, a new center of gravity
PostHog's Product Engineer Handbook is the clearest existing definition, and it predates the current AI-agent wave entirely. Former Shopify VP Jean-Michel Lemieux's version, quoted in the handbook: a product engineer is someone with "a thirst for using technologies to leapfrog human/user problems." The handbook is specific about what that means in practice: a product engineer owns outcomes, not just implementation, is opinionated about the roadmap, and is judged by user impact rather than code elegance. That's the substance behind the older "product engineer vs software engineer" debate: scope of ownership, not which languages someone writes.
What's changed is how much of the job that ownership now has to cover. A product engineer has always been expected to think in business terms as well as technical ones. But when writing the code itself consumed real hours, technical skill still did a lot of the actual differentiating.
Once an agent can produce working code from a clear brief, those implementation hours open up. What's left to judge someone on shifts hard toward the product half: is the roadmap call right, does the feature solve the actual user problem, is the UX decision defensible.
OpenAI's own Codex team is a real example of this pull in practice, covered in detail in this pillar's harness-engineering piece. With every line of a five-month build written by agents, their engineers' actual job became specifying intent and reviewing outcomes, not typing. A product engineer today is being asked to be product-oriented in a more literal sense than the title implied five years ago, because the technical half of the job now takes up less room, not because the definition itself changed.
Agentic engineer: the newer half
Agentic engineer doesn't have an equivalent multi-year definition. What it has is "agentic engineering," a practice IBM traces directly to Andrej Karpathy. Karpathy coined the term in February 2026 as a more accurate label than "vibe coding" for professional, reviewed AI-assisted development.
IBM's own framing: agentic engineering is "the practice of using engineering expertise to orchestrate and oversee AI agents through the software development process." A human stays in the loop to validate output, rather than accepting it blind, the line IBM draws between agentic engineering and vibe coding.
Simon Willison's independent definition lands in the same place: professional engineers "using coding agents to improve and accelerate their work by amplifying their existing expertise."
The role-shaped version of that practice is what people mean by "agentic engineer": whoever owns the technical environment an agent operates inside. That's a genuinely concrete job. Harness engineering vs prompt, context, and loop engineering covers that layer in detail, the guides that steer an agent before it acts and the sensors that catch what it gets wrong after.
Deciding what an agent can reach, what it's blocked from doing, and what catches its mistakes before a human does is real, specialized work. It's the work a product engineer's shift away from technical execution leaves for someone else to own.
| Product engineer | Agentic engineer | |
|---|---|---|
| Primary focus | Outcomes: roadmap, UX, customer impact | Orchestration: agent oversight, validation, guardrails |
| Term origin | Established role, defined in detail for years (PostHog's handbook, among others) | New: built on "agentic engineering," a practice Karpathy named in February 2026 |
| What agents change for this role | Frees up time for more product judgment, less hands-on code | Creates the role: someone has to own the harness agents run inside |
| Judged by | User and product impact | Whether agent output is safe, correct, and actually reviewed |
Why the two roles are showing up together now
Both shifts trace back to the same mechanism: as agents absorb more of the actual typing, the human judgment that's left splits toward two poles. One pole is deciding what to build and whether it's right, the other is building and maintaining the system that lets an agent execute that decision reliably. Product engineer gravitates to the first pole. Agentic engineer is the name for the second.
This is a different angle on two things this pillar already covers, not a restatement of either. From code writer to orchestrator covers the same pull toward oversight for a single engineer's day-to-day work. Does agentic engineering kill Scrum? covers what changes at the team-process level once agents write most of the code. This piece is about where the two poles concentrate hard enough to earn separate names.
What this actually means for how you work
Most engineers will hold pieces of both roles on any given task, whether or not their team ever formalizes two separate titles. What's useful about naming the two poles isn't a mandate to pick one permanently, it's a way to notice, on a given task, which kind of judgment it's actually asking for: a product call about what's worth building, or a technical call about whether the system around the agent will catch it if the build goes wrong. Knowing which one you're doing is worth more than the title on either chair.