How AI Changes the Tech Lead’s Role

Alexander opens by describing a tech lead through engineering practices, architecture within a domain, the path to production, and involvement in difficult incidents. Agents can perform some of that work without assuming the team’s commitments to users. If every developer produces changes faster, the lead may face a stream no individual can review properly. The response requires rules for agent use, accessible context, and clear ways to accept results. Rafael adds another responsibility: explaining to business leaders why the transition deserves investment and why adopting a new workflow may initially slow a team down. Computing costs are visible immediately, while more delivered user stories do not necessarily mean more revenue. Technical leaders must connect these observations, acknowledge the limits of measurement, and avoid promising effects that the evidence does not yet establish. Access to tools alone says little about which work has actually improved.

The Sber example distinguishes the volume of artifacts produced, time spent on work, and delivered user stories as a compromise between engineering and business language. The panel does not present lines of code as a universal measure of value. Rafael argues that strict early limits can discourage adoption, even though costs will eventually need to be attributed to business units. Showing users a monetary estimate of consumption and helping them select models for task complexity can prepare that transition. Alexander suggests examining whole tasks and working sessions: human effort, agent effort, tool changes, and waiting. Telemetry should explain the workflow rather than merely count subscriptions. Model routing also has costs: transferring context, processing it again, and potentially losing information when history is compressed. A cheap request is not necessarily a cheap completed task.

Access to model knowledge weakens the position of someone whose authority rests entirely on remembering technical details. Yet the speakers distinguish access to answers from the ability to apply them. Alexander compares the moment with the arrival of open university courses: available material does not automatically produce a trained specialist. An experienced engineer can frame a useful question and recognize an unsuitable answer. In discussing Anthropic research, he describes a progression from asking for something attractive to using domain terms, expressing the task fully in domain language, adding verification criteria, and specifying what must remain untouched. Better framing can let an agent work more independently. Product engineers may need to handle fewer technical details when a platform team already provides constraints and checks. That condition matters: equal access to a model does not erase differences in understanding. Some complexity shifts to the people building the development environment.

How beginners should acquire that foundation remains unresolved. Rafael worries about a curriculum that teaches the vocabulary without developing fundamentals or experience in comparing solutions. A constrained environment may reduce the consequences of mistakes, but that is a hypothesis, not evidence that education is unnecessary. The conversation describes a recurring problem: someone quickly builds a working prototype and only later encounters architectural, storage, or scaling limitations. Alexander also separates technical leadership from people management. A tech lead helps prepare projects and establish engineering practices; discussing a particular employee’s performance and adoption of tools may belong to their manager. Checking whether someone uses an agent is insufficient. What matters is how they frame work, use context, and evaluate results. Counts of tokens or instructions can become reporting activity that explains little about the quality of the work.

Alexander returns to replaceable implementations: when an agent frequently rewrites code, that code cannot be the only repository of system knowledge. Intent, architectural rules, behavioral checks, and decision rationale need independent form. Obsolete components should be removed, and complexity must remain understandable. The panel then debates shifting review toward requests and the history of agent interaction. Andrey provocatively argues for dropping conventional code reading when automated verification is sufficiently capable. Rafael asks what reliable reference an agent would use to establish the correctness of human intent. Acceptance criteria, high-risk changes, and model ensembles are discussed without agreement to abolish code review. Alexander specifically calls for deterministic checks, including static analysis and, for particularly critical components, formal methods. An audience question about an incident returns the conversation to current practice: accountability is assigned to a person, not to the model.

Task decomposition also depends on the workflow. Rafael describes an automated pipeline for minor defects that produced a queue of finished patches awaiting acceptance: many unrelated fixes impose repeated context switching. Alexander ties task size to model capability, evaluation on representative work, and cost. Larger tasks can be delegated when the process demonstrably handles them, not simply because a model promises success. A similar constraint appears upstream when an accelerated team starts implementing old backlog items the business no longer wants. The backlog needs pruning, and product discovery must develop alongside engineering. As the team reaches lower-priority work, each additional change may contribute less value. A tech lead therefore needs to look in both directions: help frame useful work and ensure its outcomes can be verified. Forecasts about the profession in five years remain speculative. Alexander emphasizes choosing a domain and developing capabilities beyond carrying out routine requests.