Does AI Turn Developers into Managers?

Andrey recalls the beginning of his career, when an IT professional might be expected to speak to the customer, define requirements, write software, test it, deploy it, and provide support. As companies grew, this work split into specializations. Managers delegated understandable pieces of work, and the industry learned to reproduce outcomes through large teams. Alexander describes an experimentation system built from components in C++, Go, and TypeScript. Some engineers resisted working outside their preferred language, even though their domain knowledge was valuable across the system: allocating traffic, calculating statistical criteria, and interpreting results correctly. Defining a profession through a particular technology could obscure the problems a person was capable of solving. Specialization helped during rapid growth, but it also established professional boundaries that now need reconsideration. The current shift is connected to agents being able to perform work across several stages of development.

Writing code, formatting requirements, digital testing, and cloud deployment are activities where agents can assist or perform substantial parts of the work. Responsibility for the product, however, still rests with a person. This leads to the product engineer: someone who understands the need, connects the stages, and verifies the outcome. Andrey emphasizes domain knowledge and the ability to discover what users actually want. People may struggle to explain their own problems; a carefully formatted document does not resolve that uncertainty. Alexander contrasts an accounting expert who learns to instruct an agent with an experienced programmer waiting for complete requirements in an unfamiliar field. Technical seniority alone does not confer product understanding. Engineering expertise remains necessary too: someone must understand what has been built, how it operates, and how to respond when it fails. The proposed role combines those responsibilities rather than treating implementation as an isolated contribution.

Andrey applies an employee lifecycle to agents: select them, bring them into the system, develop them, supervise them, and eventually retire them. The last step is easy to overlook. An agent may keep producing reports, spending resources, and using permissions after its output has ceased to matter. Alexander argues that the problem often starts earlier, when an obsolete activity is automated without asking who uses its results. A short briefing with follow-up questions may be more useful than another extensive report. Andrey describes a manager of an analytics department who tested demand by temporarily stopping selected report deliveries. Some recipients never noticed. The conversation does not establish an exact proportion; the example illustrates freeing capacity by checking usefulness instead of accelerating every existing operation. A manager’s responsibility begins with deciding which work is worth continuing.

Buying an agent subscription does not establish a working process either. A company may provide the tool, data connections, and shared instructions, then expect a large productivity increase. Engineers still need to organize execution, decide where to check results, and supply relevant knowledge. Andrey warns about operational knowledge that exists only in employees’ heads: premature layoffs can destroy the foundation that an organization hoped to automate. Alexander develops the idea of software whose code can be regenerated from a more durable description of the system. That requires intent, architectural constraints, observable behavior, and reasons for earlier decisions. Andrey highlights the opposite risk: accumulated documents can contradict one another, while regeneration without continuity can change a system unpredictably. Knowledge organization and verification therefore matter, including security and architectural checks. A functionally correct output is not sufficient evidence that the agent worked within the organization’s acceptable boundaries.

The change also affects who products are designed for. Andrey describes JUG Ru Group’s interest in how conference information appears in AI-generated answers: the searcher might be a person or their assistant. Alexander connects this to interaction through agents. Discussing SWE-agent, he recalls how a specialized interface helped earlier models work, while stronger models later needed only access to a command shell. This leaves two possible directions: adapt the environment to the agent, or improve agents so they can navigate the existing environment. The participants also consider assistants that assemble a workflow from available capabilities instead of guiding users through a predetermined set of screens. Search, marketing, and design may all be affected. These are developing possibilities, however, rather than evidence that every product has already undergone the same transformation.

Alexander offers a concrete example: a personal website for choosing a London neighborhood. Working with an agent, he brings together a map, schools, filters, and rental information to answer a specific family question. Previously, the development cost might have outweighed the value of a one-off tool; now a personal solution can replace manually visiting several services. Limitations remain: information may be stale, some sources restrict collection, and update frequency requires a separate decision. Andrey describes a bot that gathers requirements and creates a website, where explaining design preferences remains difficult. His closing priorities are critical thinking, experience, and a durable knowledge foundation. Alexander adds a question for managers: what do they contribute when some coordination can also be automated? Neither participant offers certainty about professions a year from now. Technical experience helps with technical management, but the appropriate management style depends on the organization’s task, and taking on new responsibilities requires practice and support.