Skip to content
all episodes
Code of Leadership · episode 76

Product Engineer: How the Programmer's Role Will Change in the Next Three Years

1:46:01
Conversation

What we discussed on the recording

Gleb Mikheev and Alexander Polomodov begin with their own returns to individual engineering work. Gleb stepped away from management for six months, worked with agents every day, and found implementation becoming cheap and parallel: several working approaches can be produced and compared in hours instead of waiting for a team. The shift changes both speed and the source of professional satisfaction, while creating a risk of an endless loop of new tasks.

In this conversation, a product engineer is neither a new title nor one person forced to replace a product manager, analyst, designer, and developer. It is a return to end-to-end engineering ownership: understand the user's problem, propose a solution, design the system, ship it, and collect feedback. Agents reduce the cost of narrow specialization, allowing a small team to cover a broader value stream, while regulated and safety-critical systems will retain specialist roles and stricter boundaries.

Faster delivery moves the constraint into discovery, hypothesis testing, code review, operations, and product analytics. Expanding the engineering pipeline fivefold does not make the lower four-fifths of an old backlog valuable. Teams will need to frame metrics more often, test alternatives faster, and push decisions closer to execution. Product and management accountability remain, but there should be fewer interpretive layers and more understanding at each level.

For an experienced developer, the hardest barrier is psychological: writing clean code by hand can no longer be the sole basis of professional value. A newcomer faces a different problem: an agent can produce a convincing artifact without leaving the human with an understanding of the system. Progress therefore has to show up in the ability to explain a decision, choose the right abstraction, verify the outcome, and own its consequences. The closing advice is to stay curious, notice opportunities, and run small experiments regularly; changing one's practice takes months and cannot be learned from a single article.

Engineering managementProductStrategyHiring & growthLeadershipTeams & culture