Rise of the Product Engineer

I’m not an engineer. I’m a product person who was always upstream of the code. Then coding agents happened — and I didn’t stop coding, I started. Not writing code directly, but working through it. Shaping architecture, iterating on UI, every day.

That’s the shift nobody expected. Agents didn’t push people away from code — they pulled product-minded people in. Coding got cheap. Engineering didn’t. And that gap is creating a new role: the Product Engineer.

The Old Loop Is Broken

Here’s how products have been built for decades. A PM writes specs. A designer creates mocks. An engineer implements them. QA validates. Feedback trickles back weeks later. Repeat.

It works. Sort of. But the cost is enormous — and I don’t mean money.

Every handoff dilutes the original vision. The PM felt something about the user’s pain, but by the time it passes through a spec, then a mockup, then a Jira ticket, then an implementation, then a code review — the feeling is gone. What’s left is a technically correct execution of a diluted idea.

Engineering gets pushed downstream. Product thinking becomes abstract. Iteration becomes so expensive that people stop iterating and start “planning” instead. Creativity doesn’t die in this model, but it gets throttled by coordination cost. You can’t try thirty variations of a flow when each one requires a sprint.

The New Loop

Now picture this instead. One person observes how the product actually behaves. They feel what’s wrong — not read about it in a report, feel it. They describe the change to a coding agent. They see results in minutes. They keep it or throw it away. They repeat immediately.

No handoffs. No specs. No waiting.

This loop runs dozens of times per day. It’s not planning. It’s not coding in the traditional sense. It’s live sculpting of software. You’re working with the actual product, shaping it in real time, the way a sculptor works with clay — except the clay compiles and ships to production.

The key shift: engineering happens inline with product decisions. You don’t separate “what should we build” from “how should we build it” anymore. They’re the same thought, expressed in the same moment, by the same person.

Taste Is the New Bottleneck

Here’s the provocative claim: taste is now the most valuable skill in software.

Not architecture. Not algorithms. Not system design. Taste.

I mean this concretely. Taste is knowing when the spacing feels wrong before you can articulate why. It’s recognizing cognitive overload in a UI — the moment a screen asks the user to hold too many things in their head. It’s sensing when a feature dilutes clarity instead of adding value.

Most critically, taste is knowing when to remove instead of add. Most people’s instinct when something isn’t working is to bolt on more. Taste is the discipline to strip away.

This doesn’t mean the Product Engineer suddenly replaces the designer. Far from it. A designer on the team is interfacing directly with the product too — iterating on the design in real time, just like the engineer iterates on the code. The point isn’t that one person knows everything. It’s that everyone interfaces directly with the thing they’re shaping. No handoffs, no telephone game. The designer sculpts the experience. The engineer sculpts the system. They’re both hands-on with the actual product.

And here’s why taste matters now more than ever: agents amplify it. If you have good taste, you can express it at a speed that was previously impossible. Try the version with the extra step, see that it’s wrong, remove it, try the collapsed version, feel that it’s right, ship it — all before lunch. But if you don’t have taste, agents just let you ship bad decisions faster.

Taste is rare. Taste compounds. Agents don’t replace taste — they reward it.

Engineering Still Matters

I can already hear the objection: “So you’re saying engineering doesn’t matter anymore?”

No. The opposite. Product Engineers still need to understand architecture, data flow, state management, performance constraints, deployment pipelines, and reliability boundaries. You can’t shape a system you don’t understand. You can’t give good instructions to an agent if you don’t know what good looks like at the systems level.

The difference is how that knowledge gets expressed. Instead of writing thousands of lines of code, you express engineering judgment through agent instructions, structural decisions, and system-level constraints. You’re choosing the right database, defining the right abstractions, catching the architectural mistake before it calcifies — you’re just not manually typing the implementation.

This isn’t less engineering. It’s broader engineering. Code is substrate. Systems are medium. Product is the goal. Engineering moves from implementation to orchestration — from writing functions to shaping systems.

What This Changes

The organizational implications are profound and uncomfortable.

Teams shrink radically. One Product Engineer, a designer, and one or two infrastructure engineers replaces teams of ten to twenty. Not because the work disappears, but because the coordination cost — which was most of the overhead — evaporates.

The PM role weakens. When the person building the product is the person with product vision, specs become obsolete. Feedback becomes direct. Product direction moves to the people who can actually ship.

Solo founders gain disproportionate power. One person can now ship a full product, iterate at market speed, and outpace funded teams bogged down in process. VC evaluation shifts from team size to individual taste, from roadmaps to iteration velocity, from resumes to shipped artifacts.

What dies: large PRDs, long planning cycles, design handoff meetings, sprint rituals, feature backlogs, most middle management. What matters: engineering judgment, taste, velocity, systems thinking, creative intuition, and the ability to direct agents effectively.

Execution becomes abundant. Judgment becomes scarce.

The Meta Shift

Software creation is moving from engineering via code to engineering via iteration. From “Can we build this?” to “Should this exist?” From implementation difficulty to experiential quality.

The Product Engineer is an engineer first, a product thinker by default, armed with coding agents, sculpting live systems at the speed of thought. They’re not replacing engineers. They’re replacing the distance between imagination and reality.

This isn’t automation. It’s amplification of engineering judgment.

In the agentic era, code is cheap, ideas are abundant, and distribution is noisy. Engineering still matters — but iteration matters more. The winners will be those who can feel what’s right and engineer it into existence.

Taste becomes destiny.