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

Mikheev has written software professionally since 2003. He worked at NVIDIA, spent nine years growing a custom development company, taught at Skillbox for three years, and later joined Sber. To avoid watching the agent revolution only from a manager's chair, he returned to individual engineering work for six months and often spent ten to twelve hours a day with agents. He traces the turning point to GPT-3.5: the model could identify memoization and input-validation risks in an old JavaScript fragment. Later agents inspected a supervisor for parallel micro-frontend development and found runtime port-management problems he would expect a strong Staff engineer to raise. He can now ask five workers for different implementations, receive tested versions, and keep the best. Two or three visible completions become dozens, making the feedback cycle productive and dangerously addictive.

That experience supplies the episode's definition of a product engineer. This is not a developer who keeps the old workload and also replaces the product manager, analyst, architect, and designer. It is an engineer who owns a user problem rather than a slice of code. Mikheev recalls a task at NVIDIA seventeen years earlier: visit the users of an automated game-testing system, understand the scripts they had built around it, identify missing capabilities, defend a redesigned interface, implement it over existing services, add tests, release it, and collect feedback. The role predates AI, but it used to be more common in strong engineering cultures and small companies. Agents make it easier to scale: narrow front-end, back-end, and infrastructure duties partly converge, so two or three engineers with complementary strengths can cover a stream that once needed a large cross-functional team. Payment systems, government services, spacecraft, and other critical domains will retain specialization longer because the cost of error demands conservative verification.

Smaller teams do not mean that products will stop at their previous scope. Cheaper production frees resources, but competitors can invest the same gain in new capabilities, so the market is likely to demand more experiments. The deeper problem is that a delivery system able to build five times as much does not make the lower four-fifths of an old backlog valuable. Product work has to discover needs, frame hypotheses, and evaluate metric changes at a comparable pace. The conversation uses the theory of constraints to make the point: a cow may produce one hundred litres of milk, but twenty caps limit output to twenty bottles; buy more caps and fifty bottles become the next constraint. Once coding accelerates, queues appear in business requirements, code review, QA, integration, release, observability, and incident response. Five working interface variants still have to reach users safely, be separated into valid experiments, and be distinguished from background noise.

The product manager's accountability therefore remains: research needs, describe the capabilities a product should provide, prioritize, work on distribution, and check value after release. A model can turn a rough conversation into clearer business requirements, scenarios, and acceptance criteria, but the underlying knowledge and judgment about value stay with people. Managers can no longer inspect every expanded backlog or pass complete answers down through several interpretive layers either. Goals remain a leadership responsibility, while teams closer to the context choose the next route toward them. The organization becomes flatter not because leadership disappears but because there are fewer handoffs and more understanding at each level. Mature, entrenched processes cannot become AI-native in one move: new operating loops will begin alongside them for products with acceptable risk, then spread gradually into more critical areas as their safeguards earn trust.

For experienced programmers, the hardest transition is letting go of the belief that their primary purpose is to write clean, modular, well-tested code by hand. Mikheev invokes a principle he associates with Jensen Huang: an engineer solves known problems and discovers unknown ones; code is only one instrument. Skills once peripheral to implementation become central: form a technical picture, select a path, decompose the work, specify architecture and non-functional properties, define independent checks, and correct the course. Models do not erase experience. It reveals a wrong decision beyond one component, chooses an existing library over forty hours of construction, and recognizes where automation cannot be trusted. Yet the practice must change. Mikheev describes months of intense work, recursive dreams about unresolved debugging, and a new way of organizing agents. One article or prompt collection cannot provide that experience.

A junior faces the opposite problem: a polished pull request no longer shows what the person learned. The engineer may have framed the goal and constraints, reviewed the plan, understood the architecture, and owned the release—or merely handed an issue number to a model. Simpler work will not vanish completely. Large systems always contain changes with less scope, risk, and uncertainty. But the manager must define the abstraction level at which a newcomer is expected to understand the system and observe more than the artifact. Useful evidence includes the engineer's mental model of the feature, the history of agent interaction, the response to a changed condition, the ability to explain an incident, and the quality of independent verification. Platform builders share accountability: when an automated loop promises a capacity or safeguard and fails, that is a system failure, not merely an operator's mistake. Growth appears in the complexity a person can hold deliberately and in impact appropriate to the level—from a shipped feature and useful documentation to better developer experience, reliability, or a well-supported negative research result.