How AI Changes Programmers, Teams, and IT Companies

Large engineering organizations grew around specialized stages: product discovery, requirements, implementation, testing, release, and operations. Specialization made delivery more predictable without requiring everyone to understand every layer. It also introduced waiting and coordination between people responsible for different pieces of one feature. Early AI assistants increased output within those existing boundaries. Product managers could generate more proposals, analysts more requirements, and developers more changes, while relatively little additional work reached users. Alexander therefore focuses on reducing handoffs and enabling an engineer to carry a task further. He explicitly distinguishes roles from positions: the necessary work can remain, while fewer separate people are required to perform it. This is a direction for organizational change, not a claim that every enterprise has already reduced its teams to a product manager and one developer.

Kirill sketches a target arrangement in which a product specialist explores a hypothesis, an engineer supported by agents turns it into a working change, and operations provides ongoing support. Alexander adds a condition: security, reliability, and other shared requirements must be available early and checked within the workflow. Otherwise, quickly generated code simply waits for a later manual approval. Agent instructions should be combined with deterministic checks, with recurring problems becoming new rules that can be tested. A platform team can provide a Model Gateway, an MCP Hub for tools, a Skill Hub for reusable instructions, and isolated execution environments. Leadership within each product area must change its own delivery process. Successful pilots do not automatically scale, because exceptions negotiated for one business unit may not be available company-wide. Technical enablement and organizational adoption remain distinct responsibilities.

The return of the generalist engineer does not make frontend, backend, or architecture trivial. Agents help execute work across technical areas, while the engineer connects that work to a domain problem and evaluates the result. This also changes the economics of practices that small teams once considered heavyweight: specifications, plan reviews, RFCs, and architecture decision records. Kirill describes adopting them even on small projects because an agent reduces the effort involved in documenting decisions. Alexander emphasizes explicit intent and acceptance criteria. Without them, the person must repeatedly explain what they meant and manually judge whether the work is complete. Reviewing a plan before implementation brings alternatives and tradeoffs into the discussion before they become a large body of code. A document is useful when it supports a decision or a meaningful acceptance check, rather than merely satisfying a template.

Knowledge, however, extends beyond repositories. Product managers, analysts, designers, and support teams use enterprise documentation, so moving everyone into Git changes everyday working habits. Alexander recalls a mobile banking initiative where even reorganizing requirements from screen descriptions into feature descriptions took two years. Search across existing systems can provide an intermediate solution, but retrieval alone does not establish authority: a frequently visited departmental interpretation of a strategy may outrank the original company document. Internal platforms present a related problem. A heavily modified fork of an open source product may behave differently from the software a model expects. Previous investments in scale and customization can consequently create additional integration and explanation costs. Compatibility with upstream interfaces becomes valuable. Kirill describes contributing fixes upstream and removing local customizations; Alexander notes that this is considerably harder for a large enterprise fork.

The measurement discussion separates three layers. First, are people using the tools, and which workflows do agents cover? Second, how long do particular engineering activities take, such as finding information, creating a change, reviewing code, or handling an incident? Third, what happens to the saved time once model, platform, and adoption costs are included? Alexander recalls measuring the interval between opening and merging a change request: it missed the initial work where an agent might provide most of the acceleration. Observation boundaries therefore matter. Detailed instrumentation also has a cost, and the speakers do not assume every company can reproduce Google’s approach. More completed tasks need not mean more business value. Without better product discovery, extra capacity may merely pull lower-value items from the backlog. Kirill offers a contrasting example: product colleagues begin supplying previously deferred, useful ideas once they see development capacity improving.

For junior engineers, a familiar learning signal breaks down: a completed small feature no longer demonstrates that its author understands the system. Alexander suggests assigning achievable work with agents and reviewing the framing, acceptance criteria, evaluation of the proposed plan, and explanation of the result. Hiring must likewise distinguish independent understanding from effective tool use, though standardizing that assessment is difficult. Kirill adds a personal observation: generating code in a language he does not know deeply creates a growing understanding gap, eventually requiring him to stop and investigate directly. The participants leave open how much low-level knowledge the next generation will retain. Legacy systems expose a related limit to autonomy: nobody may know why existing behavior arose, who depends on it, or what can safely change. Agents work more effectively when boundaries and feedback are explicit. Investigative skill and responsibility for consequences therefore remain substantial parts of engineering.