At the Ruby Community Conference in Kraków, Obie Fernandez told a story about his first one-on-ones as a new CTO. He’d inherited ten engineers, split the usual way into backend and frontend, and he opened each conversation the same way: congratulations, you’re no longer a frontend or backend engineer. You’re a product engineer. People on a leadership Slack told him that was against the rules. His answer, more or less: there are no rules anymore.
I run my company on the same bet, and we made it before it was comfortable. “Product engineer” is the title on our team page where other companies would list a stack (with one deliberate exception, and I’ll get to why he’s the exception). So this post is partly a definition, partly an argument about why the shift stopped being optional, and partly what we look for when we say the words.
The economics that made specialists
Role titles are downstream of costs. When writing code was the expensive part of building products, it paid to split the job: one person deep in the backend, one deep in the frontend, designers somewhere upstream, product managers translating between all of them. Specialization amortized the high cost of implementation skill. The translation layers between specialists were overhead, but overhead worth paying, because the alternative was generalists doing everything slowly.
AI broke the cost structure that justified all of it. When agents write most of the code, implementation depth in one layer stops being the scarce asset. What’s scarce is everything the splitting optimized away: knowing what’s worth building, recognizing when the built thing is wrong, and carrying an idea across design, code, and business without dropping it at a handoff.
Obie’s framing for the residual human value is the one I’d steal: taste and judgment. His argument is that a model trained on the world’s code pulls relentlessly toward the median, and the human’s job is to be the chaos monkey that breaks you out of the average. You can’t do that job from inside one layer of the stack, because the average asserts itself at the seams. A change can be correct in the backend and correct in the frontend and still wrong as a product, and that wrongness is invisible to everyone whose job ends at a layer boundary.
What a product engineer actually is
Startups used the title for years before AI; what’s changed is that the economics now push everyone toward it. Our working definition, from the careers page we hire against: a product engineer does the whole job. Four traits carry it.
Product judgment: you ask why before how, and if the feature is wrong, you say so, because the goal is someone’s life measurably better, not code that runs. End-to-end range: you connect dots across design, product, business, and code, the skills the industry spent years splitting across a dozen roles. You don’t have to be expert at all of them, but you have to refuse to ignore any of them. An AI-native way of working: you’ve made agents ship real code, or hit the wall trying and want to learn why. And clear writing, because when specs become the thing humans review, writing is the production skill: if you can’t write it, you haven’t thought it yet.
What that looks like in practice: Katarzyna went to Oslo Airport and watched passengers and drivers before designing a screen, because the design decisions were product decisions were business decisions, and one person carried all three. Wojtek works where frontend meets design and refuses to pick a side of that line. Neither fits a lane, and the value is exactly the lane-refusal.
What you do on Monday, if the title is yours
The path into the role is the role: take your next feature from the why to the metric yourself. Write the spec before any code exists and treat the writing as the work. Have an agent build something real against that spec and review what comes out, because hitting that wall is the fastest education available. Sit in one customer call a month even if nobody invites you. None of this needs a reorg or permission, and a quarter of it changes what your title means regardless of what it says.
What changes for teams
If you lead engineers, the uncomfortable version of Obie’s one-on-one is coming to your org whether you schedule it or not, because the alternative is engineers whose moat was implementation depth in one layer competing against harnessed agents with implementation breadth in all of them. The kind move is to schedule it: redefine the job around judgment, range, and ownership of outcomes while there’s time to grow into it.
Two honest caveats so this doesn’t read as a pep talk. First, deep specialists don’t disappear; they concentrate. Databases at scale, security, the gnarly corners of infrastructure keep rewarding depth, and a product engineer knows when to call one. Mateusz, who has owned FastTravel’s payments for years, is our living version of that first caveat: money paths reward depth, and the team is better because one person went deep. Second, not everyone wants the whole job. Some excellent engineers want a well-specified problem and silence, and they did real work in the old structure. The shift has real losers, and pretending otherwise is how trust gets burned during reorgs.
But the direction is set by arithmetic, not fashion. Every handoff between specialists was always a place where intent degraded; we tolerated the loss because specialization was buying us something. Now the same intent can travel from “why” to production inside one head, with agents carrying the implementation load, and the people closest to the customer shipping directly. The translation layers stopped earning their overhead.
If your title still has a layer in it, this shift will reach you either way. The open question is whether you meet it halfway while it’s still a choice.