Blog
The golden age of the destination engineer
Why the engineers who care more about users than code are going to run the table.

Recently, I told one of our engineers something I don't think they expected to hear from their PM:
"You have no constraints. Throw any part of the product away. No shipping deadlines, no roadmap commitments — just go hack on it. What would you actually build?"
I was asking because I genuinely didn't know the answer. And I knew they eventually would.
"Are you sure you want us to go that radical? There's a middle ground option."
Fair. That's a well-trained engineering instinct: build what's shippable and don't burn down what's working. In the old world, those were exactly the right reflexes. But we're not in that world anymore. Since that exchange, I’ve been thinking a lot about who thrives when constraints disappear.
There's a lot of angst right now about AI replacing engineering talent. I'd argue the opposite: this is the golden age for a specific kind of engineer — and if you're one of them, you already know it.
I’ve found there are generally two buckets:
Journey engineers love the process of building. They think about code as craft, and the satisfaction lives in finding the optimal solution. The elegance of the thing matters.
Destination engineers love building for a user. The code is a means to an end. They want to ship something someone loves.

Journey engineers are the gatekeepers between stunning and slop. But this post is a love letter to destination engineers, everyone being told they're ripe for automation and destined for the permanent underclass.
At Berkeley, while my classmates debated the elegance of their solutions, I was mostly just relieved when mine ran — and that gap made me feel like an imposter. When I started my career, I would drag myself to engineering book clubs even when what I actually wanted to do was to talk to users. When I'd get code review feedback, pushing for a more efficient solution, my first instinct would be to debate it. Not because the feedback was wrong, but because I wanted to prioritize shipping to a customer for validation — a classic engineering dilemma that I often seemed to land on the wrong side of.
It took me much longer than it should have to realize that destination engineers have always been valuable. But in the new era we're living in, that feeling of liability is now obviously leverage — and in a world of agents, we're about to find out just how much.
The journey is faster than it's ever been. The question that used to take a week to answer now takes an afternoon. Which means the real question, the one that was always more interesting: “should we build this, and for whom?” gets a lot more airtime.
An unexpected promotion
We keep talking about everyone being automated — but actually? I think everyone has been promoted one level up, whether or not they were ready for it.
Designers spend less time designing pixels and more time pair-programming after an engineer has pushed the v0. Engineers spend less time writing boilerplate and more time making the call on what's good enough to ship after iterating directly with customers. Destination engineers are why the feedback loop that used to run through a PM now runs directly to the person building.
So the PM role is screwed, right? Not quite. It hasn't shrunk — it's expanded horizontally. One PM can now be across more projects because engineering and design own more of the feature-building end-to-end. But the PM work that remains is harder, not easier. My job isn't to write the next version of the spec. It's to recognize which bets are worth taking, clear a path, and absorb the pain of saying no to everything else.
The most ambitious product ideas can't come from PMs like me anymore — and honestly, they probably shouldn't have been coming from me before. What's possible changes mid-build. The people closest to implementation have the most current information about what the technology can actually do, and a PM writing a spec two weeks ahead of build is often working from a stale world model.
Enjoy the gold rush
When I look forward, I don't know exactly where this will land in five years or, frankly, five months. But I know the lines between product, design, and engineering are blurrier than they've ever been, and that's made building more fun, not less.
Unfortunately or fortunately, there is stubbornly human work required. And that looks like figuring out the right problem, for the right user, in a way that actually works and ignoring everything else. No shortcut (yet).
So if you're a destination engineer, the kind who always cared the most about the user, this is your moment. The constraints are gone. The journey just got a lot shorter. And you're at the head of the table.
Ps: We're hiring engineers across the board! Come join :)
Ps2: If you're wondering what project I reference at the beginning of this post. We're launching it next week. Stay tuned.