Coding agents made a first draft cheap, and that turned product engineering into the useful name for work that frontend and backend hiring buckets always described poorly: applying the stack to ship the product, working backwards from the experience.
Lee Robinson's Product Engineers is still the cleanest public description, and it fits 2026 better than when he wrote it, because AI flattened much of the syntax while taste, the paths through a product, and the definition of done stayed exactly where they were.
I wrote about the skillset in 2025. This is the update on why the role is more relevant now and how I use agents inside that work.
Layers vs outcomes
Software engineer, as most teams use the title, still means a layer or a ticket: frontend, backend, infra, a slice of a backlog. That work is real, and it is a different job from owning whether the product works.
A product manager owns the problem, the sequence, and a lot of the why, but not the last mile of making it real: the empty states, the error when the API fails, the session that dies on a bad connection, and the control a team needs after launch.
A forward deployed engineer owns adoption in one customer's environment. The two roles overlap, and the difference is the unit of accountability, since FDE work answers for the account and product engineering answers for the product.
Product engineers sit in the gap Lee describes, less deep in every subsystem than a specialist and deep in applying the stack to the experience across interface, application, data, and now the model and tools around it. Engineering in the AI Era covers how that engineering shift works, with less time translating ideas into syntax and more time deciding what should exist, and this post covers the loop the product owns.
Why the title is not junior
Coding agents write a first draft without knowing what done means in a product. They don't notice that a slow or missing network turns a feature into a brick, or that an error state dumps the user out of a flow they cannot reconstruct.
Lee's questions are still the spec: what happens offline, what happens when the API errors, how this feels on a phone, and which latency is acceptable. Taste, constraints, and those paths do not become commodities because a model can emit React.
That is why this is not an entry-level title. You can hire people early in their careers to ship tickets, but you cannot hire a "product engineer" as a first job and expect the same ownership, because the scarce skills are judgment and contact with the user. Coding still matters, and when agents produce the first pass, the differentiator is whether you can tell if that pass is the product.
Empathy is an engineering input. Sitting with the people who use the thing, watching where they stall, and changing what the product is allowed to do is how the system actually changes, and agents do not do that on their own.
Using AI in the work
The loop runs from the experience to its constraints, to something in users' hands, to whether it holds, and agents work in the middle of that loop while people still own both ends.
Specify the experience, not the ticket. User paths, empty and error states, offline and mobile behavior, latency, permissions, and what the model is allowed to do are the constraints agents will not invent, so I write those down as the spec instead of a backlog item that only names a component. Those constraints are also the intake for an AI coding factory: the factory runs the loop, and product engineering decides what goes in.
Prototype to feel the product. I use coding tools to try the interaction rather than to generate more tickets, because the speed is for learning whether the experience holds, and until you can click through it you don't know yet.
Done is a path through the product. Green CI is necessary and not sufficient. Acceptance is Lee's questions, failure states included, so if the happy path works and a timeout dumps the user, the work is not done.
Review generated UI and behavior as product decisions. Copy, empty states, permissions, latency, and tool or model boundaries belong in the review alongside architecture, because an agent will happily ship a screen that compiles and is still the wrong product.
Spend the extra capacity on alternatives. Cheap implementation means more approaches in the same week, and taste still chooses between them.
Coding tools also lower the syntax floor for people who already know what to build, including PMs who can now prototype. The combination that matters in 2026 is product sense together with the ability to ship, review architecture, and hold those paths while agents do more of the typing, and a PM with a new coding tool has only the first half.
What companies are actually asking for
Startups still post fullstack or frontend roles when they need someone who can take a product from a vague constraint to something in users' hands. Lean AI product teams need the same person, because the model is available and the product around it is not.
I would not keep a list of who is hiring this month, since the pattern is stable: companies that sell software to end users, run small teams, and have AI in the loop. Vendors separately staff forward deployed programs to close the gap from demo to production in one account. If you are hiring for the product itself, you want a product engineer, and if you are hiring for one customer's adoption of a platform, you want an FDE.
If you are hiring for this, look at shipped products and the decisions in them rather than at who produces the most code in a take-home. If you are doing the work, own the path from the experience back to the system, and treat layer titles as staffing labels.