When Code Became Cheap: Value, Responsibility, and Expertise

The panel opens by asking which bottleneck matters most once writing code becomes cheaper. Answers include product discovery, organizational willingness to change, and available compute. The speakers then distinguish delivered changes from business outcomes. In one example, changes reaching production increased by more than 20% from the beginning of the year after excluding minor fixes and automated changes. That alone does not demonstrate greater product value. Polomodov describes a different pattern: product managers generate more briefs, analysts more requirements, and developers more code, while each recipient first asks an agent to summarize the incoming material. Every stage produces more, but knowledge transfer remains unchanged. The overall process can even slow down. Smolyakov suggests evaluating routine work separately: automating unavoidable maintenance already frees engineering capacity, although deciding how to use that capacity is a separate management problem.

One proposed response is to make an engineer accountable for a useful change from start to finish and involve them in understanding the product problem. The panel disagrees about how far this can scale. A small, well-defined change can fit within one person’s scope; a complex new product and the expertise of a large organization cannot. Reducing unnecessary process complexity should therefore preserve access to specialists. Polomodov describes a team that moved requirements and change discussions into a shared repository, allowing product staff and engineers to work from one source and refine the result through demonstrations. Another approach brings security, architecture, and legal constraints into specification work instead of discovering them at the final approval stage. The practical limit remains integration: a prototype may take several days to write and weeks to connect to other systems. Leaders must redesign the whole process, beyond purchasing model access.

Smolyakov introduces permissions with a story about asking a bot to speed up his pull-request workflow tenfold and allowing it to do whatever was necessary. A colleague pointed out that taking the request literally could affect a substantial part of the company. This illustrates a risk rather than reporting an actual outage. Agents act quickly, work in parallel, and can interpret instructions unexpectedly, so their permissions should reflect the potential impact of failure. Panelists discuss read-only access to critical infrastructure, restricted interfaces, and isolated development environments. Yet an agent without usable tools produces little value. The practical challenge is to design effective boundaries with security teams while preserving the developer experience. Polomodov separates exploring capabilities in a safe environment from routinely executing a validated scenario: first establish what the agent can do, then define the necessary access and external checks.

Instructions and agent skills can communicate policies, but they cannot guarantee enforcement. Mazko notes that an agent may read an instruction incompletely or work around restrictions, bringing the discussion back to isolation and deterministic checks. A larger flow of changes also makes unchanged review time a warning sign. One proposed response is to use automation to flag dangerous changes that require human attention. Another is to check product behavior after release with dedicated probes rather than monitoring server errors alone. Accountability also depends on architecture. A product specialist changing an isolated business-logic layer poses a different risk from modifying a core service. Architects need to create safe boundaries, while service owners need to support the resulting system. Passing checks does not answer who will respond to an incident. Building a prototype quickly is not equivalent to integrating it safely into an existing product.

Junior education produces an explicit disagreement. Smolyakov discusses an internal training environment that constrains unthinking agent use: simple production tasks may already be cheaper to automate, but companies still need a path to experienced engineers. Lukyanchenko opposes a blanket restriction on tools and emphasizes changing expectations of the role. Engineers should solve product problems while retaining technical foundations. Polomodov proposes assessing both the delivered artifact and what the person learned while creating it. A mentor can ask why an architecture was chosen, how the code works, and what happens when something fails. Effective agent collaboration also requires domain knowledge: the person needs to describe the task precisely, define success, and identify unacceptable actions. That does not eliminate technical expertise, because people still maintain systems and investigate unexpected failures. A working application alone is insufficient evidence of learning.

Performance assessment remains focused on outcomes, but speakers discuss a widening gap between stronger and weaker contributors and possible increases in expectations. Parallel agent work has a human cost. The relevant question is how often each session needs attention, rather than simply how many sessions are running. Covering multiple platforms and stages can leave an engineer in continuous intense focus with little of the normal interaction with colleagues. Short-term acceleration may therefore be unsustainable. Audience questions bring the discussion back to budgets: benefits should appear as useful changes or comparable work done with fewer resources, and token consumption proves neither. Engineering persists, while the balance between product work, specifications, architecture, and verification changes. Panelists expect some convergence of roles without treating every system as equally simple. Specialized expertise and accountability for a working service remain necessary even when agents increasingly handle implementation.