State of AI4SDLC: from AI assistants to agentic development

The talk starts not with a universal recipe but with the frame in which the problem appears. AI4SDLC Research, SE 2.0, spec-driven development, and evals for SDLC agents. What matters is the link between the goal, the shape of the system, and the constraints of the organization, rather than individual terms.

The material connects its stated topic to engineering practice: team decisions, ownership boundaries, and how the result is verified. The material clarifies what the concepts mean and compares expectations with practice: which questions to ask before choosing a tool or an organizational model.

Practical examples connect a technical decision to the product, the delivery process, and team ownership. What matters is not that a tool was adopted but that an observable outcome changed: feedback speed, quality, reliability, or the cost of further change. That framing guards against local optimization, where one stage speeds up while the whole system grows slower and more complex.

Examples and objections show where the approach works, what trade-offs it creates, and when it has to be adapted to the organization. Examples here are useful not as templates to copy but as a way to see the causal chain: initial state, intervention, consequences, and side effects.

Mature practice does not remove trade-offs. A technical improvement can raise the cost of ownership, a local speed-up can create a queue in the neighbouring process, and a metric can become a harmful individual target. A decision should be judged together with the cost of adoption, the effect on the whole system, the observable product outcome, and the option of a safe rollback.

How to use this: describe the problem and the desired effect, test the hypothesis on a limited scope, agree on owners and success signals, and then revisit the decision against actual feedback. The full talk recording remains the source of examples and nuance.