What the AI4SDLC evidence can show
The argument begins with a meta-analysis of more than fifty studies published from 2023 through 2025, followed by a survey of engineers and technical leaders. The evidence includes broad questionnaires, repository telemetry, field experiments, and internal corporate research; the local survey adapts DORA-style questions. Polomodov is careful about interpretation: self-reports do not establish causality, response counts vary, organizational changes affect productivity, and enthusiasm for a new tool can distort early assessments.
Even with those limits, the signals form a coherent picture. Fifty-eight percent reported using code generation often or always, and 64% saw a personal productivity gain. Code quality improved for 32% and worsened for 14%; 49% did not trust AI-generated code, while only 11% trusted it. Review and legacy work remained less common use cases. This is evidence of faster artifact production, not proof that a company now delivers value faster or more safely.
From local gains to Software Engineering 2.0
A role-based SDLC encourages each profession to optimize its own loop: product generates ideas, analysts draft specifications, developers produce code, and QA creates tests. Every station may become faster while work still waits at the handoffs. If review, integration, testing, and release remain unchanged, commit-to-production time barely improves. Extra code then increases queues, rework, and instability. The unit of improvement has to be the entire value stream rather than the output of one specialist or tool.
Software Engineering 2.0 is presented as an agent-based loop with broader responsibility. A product manager may carry an idea into requirements and a prototype; an engineer may use agents across implementation, testing, deployment, and operations. Fewer handoffs do not remove the need for branch protection, CI policy, artifact signing, and supply-chain controls. Greenfield products are useful laboratories for this model, while brownfield systems retain the mature discipline of SE 1.0. Practices should travel in both directions as evidence accumulates.
Organization design and the team lead's job
As implementation time shrinks, decision latency and context transfer become more visible constraints. Industry examples point toward wider management spans, fewer layers, and stronger individual contributors, but the talk explicitly rejects ratios such as one manager to fifty engineers as templates. A flat organization without a capable platform simply floods senior people with exceptions. It needs golden paths, automated policy, observability, and rapid feedback. Success should be judged by value-delivery time, product quality, and developer experience, not headcount or code volume.
The team lead consequently becomes a designer of the human-agent system. The role sets autonomy according to task risk, makes verification part of the definition of done, and turns implicit knowledge into ADRs, runbooks, repository guidance, and maintained documentation. It also owns useful metrics, training, and team trust. Skill erosion among junior engineers and the illusion of speed remain open risks. Human advantage moves toward choosing worthwhile problems, supplying constraints, evaluating results, and learning from the feedback loop.
What to take away
- 01AI can accelerate individual engineering actions, but team-level gains require redesigning the end-to-end delivery flow.
- 02Software Engineering 2.0 depends on mature tests, CI, policy, and platform capabilities; agents amplify a weak foundation as readily as a strong one.
- 03Greenfield work can test an agent-based model, while brownfield systems supply the guardrails and operating practices needed to make it safe.
- 04Team leads own autonomy boundaries, context quality, automated verification, skills development, and measures of delivered value.
Sources
- Automatic captions from the recording
- Presentation slides
- Talk recording