Writing code used to be the hard part. It is not anymore. The hard part now is knowing what to build — and that changes everything about what it means to be an engineer.

What is happening?#

You can generate a working feature in the time it used to take to read the ticket. That feels like power. But if your job was turning a spec into code, you are now competing with something that does exactly that, faster and cheaper, every month.

This is not a doom piece. It is the opposite. The same shift that threatens the order-taker is the biggest opportunity in a generation for engineers who want more ownership. But you only get that opportunity if you are honest about what has changed.

The floor under “I implement what I’m told” is falling out. What is rising in its place is a role that combines product judgment with engineering craft: the product engineer.

Let me explain why.

Why more code does not mean more value#

AI produces more code, faster, cheaper. Every developer knows this. But more code does not mean more value. It is Jevons’ paradox: make a resource cheaper and total consumption goes up, not down. Cheap code does not shrink the amount of code we write. It explodes it.

And that collides with the oldest disease in our industry. Pendo’s Feature Adoption Report found that around 80% of features in the average product are rarely or never used. About 12% of features drive most of the daily usage. We were already building mountains of software nobody wanted. Now hand that same broken selection process an engine that produces code at near-zero cost, and you don’t get less waste. You get waste at scale, faster.

The bottleneck was never typing speed. It was never even implementation. The scarce, valuable thing — knowing what is worth building — just went from being part of the job to being the whole job.

That is the product engineer’s territory. And it is expanding fast.

What do product engineers actually do?#

Think of your work as split in two:

  1. The transactional half: ticket in, code out. Translate a requirement into an implementation. This half is being commoditized to zero. Competing here is a losing race.
  2. The relational half: understanding the customer, the stakeholder, the business you are building for. What I have elsewhere called relationship before transaction. Knowing which problem actually matters, for whom, and how you will know if you got it right. This half was always quietly where the value lived. We just let it hide behind roles and process.

The pattern underneath is uncomfortable: we are automating the easy stuff and bureaucratizing the hard stuff (I wrote more about this in The Fast Track to Incompetence). The routine, well-defined work — the kind that fits neatly in a ticket — is exactly what AI does well. The work that starts with I don’t know — ambiguous, creative, cross-functional discovery — is the work that can not be ticketed, can not be automated, and is now the entire reason to have you in the room.

People call this “taste.” Engineers roll their eyes because it sounds like vibes. It is not. Taste is judgment you can only develop by being close to the thing: building, shipping, watching real people use what you made, and learning the difference between “it compiles” and “it is the right thing.”

How taste is acquired: AI gives quantity, real users filter the noise, taste emerges
Taste is the muscle built after watching 100+ choices collide with real human users — illustration by the author

An agent can produce something that runs, passes tests, and matches the spec. It can not tell you the spec was aimed at something no one wanted. That gap is the product engineer’s territory.

Ship small, learn fast#

Here is the trap dressed up as best practice.

The industry’s answer to “AI writes plausible junk” has been spec-driven development: write a complete, detailed spec, then let the agent build it. Done carelessly, that is just waterfall wearing new clothes. A flawed plan now gets you to a flawed result in twenty minutes instead of six months.

The fast agent loop is seductive, but notice what it actually tests: does the code match the spec? It says nothing about does anyone want this? That second loop — the only one that decides whether you built waste — is still slow, still human, and now entirely yours to own.

So work the other way:

  1. Talk to a real user. Develop a deep understanding of her reality and her problem.
  2. Build the smallest viable change that addresses what you learned.
  3. Ship it to production and get it in front of that same user.
  4. Listen again. Usually this leads to several more iterations — each one informed by a real conversation, not a spec.
  5. At some point, that user smiles. Now you can add the next layer.

Why so careful? Because adding a feature is now super cheap. Removing one is still super hard. Every feature you ship without validation is a feature you may have to support forever — or fight to kill later. The loop protects you from that.

This is not a four-step recipe. It is a loop, and the number of iterations depends on how well you listen. GitLab calls the underlying principle the Minimal Viable Change: it is not the same as an MVP. It is the single smallest step that still teaches you something real. Think big, ship small, learn fast (see also: Iterate Like a GitLab Designer).

I felt how deep this runs when I interviewed at GitLab for a Group Product Manager role. Iteration was not a slogan on a wall, it was baked into the interview itself. One exercise was entirely about the smallest possible iteration — not the grandest design, but the single step that teaches you something real. I loved that part, and it has stuck with me since.

Viable is the floor, not the goal#

In a world where anyone can ship anything, viable and usable are table stakes. The bar I actually hold to is a minimally enJoyable product: the smallest thing that sparks real joy, not mere tolerance. Viable ships; joy earns the smile. I made this case back in 2020: Don’t give us MVPs, we want Minimally enJoyable Products →.

This also means it is time to retire the definition of done you inherited:

  • Old definition (transactional): tests pass, code reviewed, merged, deployed. This is exactly the part a machine now handles.
  • New definition: it works in production, and an early customer tells you it works with a smile on their face.
The smile is the definition of done
The smile is the definition of done — illustration by the author

No smile, not done. The smile is the signal that you built the right thing, not just a thing that runs. It is also the one signal no agent can fake, generate, or measure for you.

Value, usability, feasibility — at once#

Good product decisions live in one place: the overlap of three questions.

  • Is it valuable — worth building at all?
  • Is it usable — does it actually work for the person?
  • Is it feasible — can we really build and run it?

Picture the three as a Venn diagram. The decision you are looking for sits in the small space where all three circles meet. Miss any one and you have built the wrong thing, a thing no one can use, or a thing you can not ship.

Venn diagram: valuable, usable, feasible — the product engineer owns all three circles
The product engineer stands where all three circles meet — illustration by the author

For decades we split those three circles across three people — product owned value, design owned usability, engineering owned feasibility — and stitched them back together with meetings, specs, and handoffs. I wrote about this three-way overlap in Trifecta: How to Maximize a Product Team’s Impact.

AI changes where the circles live. It does not remove any of them. It pushes the whole overlap down into one person. The product engineer now has to hold all three questions at once — because the seam between them, the handoff, is exactly where the wrong thing gets built efficiently.

Concretely, every real decision is two entangled bets:

  • this feature is the right thing to build (value + usability)
  • this architecture is the right way to build it (feasibility)

You can not choose the best feature without knowing what is cheap or expensive to build. You can not choose the architecture without knowing which feature will win. Split those bets across two people and you cut the one thing that made them good: they informed each other in real time.

Standing in the middle of that Venn, in small steps, against a real customer — that is the core of product engineering. And it is exactly what an agent can not do. Not because it is not smart enough, but because one circle — is this valuable? is this wanted? — can only be answered by a human reading a real person in a real context.

You do not have to become a one-person show#

This is the part that gets misread, so let me be direct: becoming a product engineer does not mean becoming a mediocre generalist who does everything alone. Software is still a team sport.

Deep craft still matters. Real ML, real data work, real frontend, real design judgment do not collapse into prompts. AI extends your reach across the old boundaries — your backend instincts can now touch the frontend through an agent — but it does not erase the depth. It blurs the edges of the specialties. It does not dissolve their cores.

What changes is that inside a team organized around a business area — a real customer domain, not a technical layer — you have frontend, backend, full-stack, data science, ML, and design people who all share the customer context and all own the outcome. The strongest version of this is the one I keep coming back to: embed the specialists in the team so the expertise is already in the room. Nobody has to file a ticket into a queue to get help. They differ in what they build, not in whether they own whether it was worth building. The wall that comes down is not between you and your craft — it is between you and the customer.

And you are not doing this on bare ground. The shared substrate — infrastructure, pipelines, tooling — belongs to a platform and DevOps team whose whole job is to make that undifferentiated work disappear for everyone else. This is what Matthew Skelton and Manuel Pais describe in Team Topologies: stream-aligned teams over a platform team. It is also where AI compounds hardest: a strong platform beneath you makes the feasibility circle cheap, so more of your hours go to the customer-facing judgment that is actually yours to make.

The role that is disappearing is not the specialist. It is the order-taker.

And this is not just happening at the team level. The same force that is creating product engineers among ICs is creating CPTOs — Chief Product and Technology Officers — at the executive level. The wall between “what to build” and “how to build it” is collapsing at every altitude, from the individual contributor to the C-suite. This is a systemic shift, not a career hack.

What to do Monday#

None of these is a ticket. Every one builds a relationship — with a customer, a tester, or a teammate — because relationships are the scarce half of the work now.

  • Talk to a customer this week about a feature you shipped last week. Not a survey, not a ticket — a real conversation. Watch their face while they describe using it.
  • Ship a half-built feature behind a feature flag to one real customer — then put a follow-up meeting on their calendar. The working software is just the reason to earn the conversation. The conversation is the point.
  • Build trust with every alpha and beta tester. Either improve the feature they actually need, or courageously kill it. A feature that can not make them smile is not helping them.
  • Invest in the relationships inside your team — the designer, the data scientist, the platform engineer next to you. Shared customer context is what lets the group make the joint bet without a handoff.
  • Protect time to reflect and build taste. Slowing down to understand what you shipped — instead of racing to the next ticket — is how judgment compounds. It looks slower this week and makes you irreplaceable next year (I explored this idea in When Doing Stopped Being Learning).

Conclusion#

The engineers who thrive from here will not be the fastest typists or the ones with the most merged PRs. They will be the ones who own the outcome — who know what is worth building and can prove it with a real person on the other end.

Let me be clear: code was the hard part, for decades. Entire careers and companies were built on the difficulty of turning ideas into working software. That era is closing. The hard part now is product judgment — knowing what is worth building, for whom, and how you will know you got it right.

That is not a demotion. It is the biggest promotion the industry has ever handed out.

Product engineers are eating the world. Reach out and take your seat.

Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts

Two ways to share your thoughts with me: