State of AI4SDLC (Category AI4SDLC)
Appeared. record I gave a talk at DevOps Conf in April about “State of AI4SDLC” or what’s really going on with AI in development and why the story isn’t just about code generation.
About the research itself. told Many times, so short. AI has become an everyday tool for coding. According to our data, 58% often or always use AI to generate code 64The percentage sees increased productivity. But then the picture is more complicated: trust in the AI code remains low, and the quality does not improve automatically. The main conclusion for me is this: AI does not accelerate the entire SDLC, but its individual parts. If nothing changes in the engineering system, bottleneck simply moves from code writing to review, tests, CI/CD, integration, security, releases and context management.
And that's where the fun begins: we're moving away from Software Engineering. 1.0 Software Engineering 2.0.
In Classical Software Engineering 1.0 Development often looks like a chain of stages and handoffs: requirements, design, implementation, review, testing, release. Even in agile teams, this logic has not completely disappeared: there is a ticket, there is a performer, there is a diff, there is a review, there is a pipeline. In the AI-native version, assistants and agents begin to do some of the work. They can write code, offer tests, read documentation, analyze bugs, prepare PR, help with migrations. But man doesn't disappear. Rather, his position is changing.
The developer becomes not only the author of the code, but also the navigator: sets the intention, collects the context, formulates constraints, decomposes the work graph, delegates tasks to agents, checks the result and makes an engineering decision.
I like to describe it as a chain: intent -> context -> plan -> tasks -> implementation -> verification.
This changes the internal loop. Previously, the main effort was often to write the implementation yourself. More and more effort now goes into setting the task right, giving the system enough context, limiting decision space, and building a validation that can be trusted.
Hence the next important shift: the classic ticket tracker begins to crack. Ticketing as “task description + status + comment” was the normal unit of coordination for humans. But it's not enough for an agent. An agent needs a related context: purpose, limitations, dependencies, decisions from the past, access rights, codebase, tests, logs, acceptance criteria, available tools, and the boundaries of what can be changed. The new unit of work is not a ticket, but a context-rich work graph in which a person and an agent can safely bring a task to a conclusion.
It also affects organizational design. An AI-native organization isn’t just less people. Rather, it is less handoffs, more senior and staff engineers, more self-service, more platform engineering, more automation and guardrails. That is, the organization must not only generate more output, but also be able to safely digest it.
This is why usage metrics say almost nothing. The number of AI requests, licenses included, or lines of code generated is vanity metrics. Look at the whole chain. adoption -> throughput -> quality/risk -> economics. That is, whether the tool is used; whether PR, review, time to merge and cycle time have accelerated; whether defects, incidents, security risk and technical debt have increased; what is the economy of this new speed?
For developers, the conclusion is that you need to be able to work with AI as an engineering circuit: decompose tasks, write good acceptance criteria, check the diffs generated by AI, understand the architectural implications and keep operation in mind.
For teamlids, EM and CTO, the conclusion is even tougher: AI implementation cannot be conducted as a tool purchase. This is a change in the production system of development. You need rules, context access, secure contours, CI/CD, tests, ownership, platform engineering, evals, observability, and result metrics.
#AI #AI4SDLC #Engineering #DevOps #Management #Architecture