Blog
/
AI is rebuilding software delivery from SDLC to ADLC

AI is rebuilding software delivery from SDLC to ADLC

Photo of Andrew Zigler
|
Blog_AI_rebuilding_software_delivery_2400x1256_3fd5887e75

The conversation around AI in software development has shifted dramatically. A year ago, engineering leaders obsessed over adoption metrics and experimentation. Today, they're dissecting every stage of their software delivery lifecycle, hunting for bottlenecks, and demanding measurable ROI. This transition from the traditional Software Development Lifecycle (SDLC) to an Agentic Development Lifecycle (ADLC) represents one of the most significant transformations in modern engineering operations, and it's happening right now across Fortune 500 organizations.

Ori Keren, CEO and co-founder of LinearB, and Dan Lines, COO and co-founder, recently sat down to discuss what they're seeing on the front lines of this transformation. Working with some of the world's largest engineering organizations, they've witnessed firsthand how AI is reshaping not just how code gets written, but how entire teams operate, plan, and deliver value.

ADLC turns software delivery into an AI operating model

The shift from SDLC to ADLC goes beyond adding AI tools to existing workflows and involves fundamentally reimagining how software gets built and shipped.

Lines describes a stark divide between two types of organizations: AI-native companies born in the last few years, and incumbents who dominated markets before AI existed. The latter face a much harder challenge because they must transform existing processes, systems, and deeply ingrained team habits rather than starting fresh with an agent-first operating model.

For these established organizations, transformation begins with identifying high-performing internal teams who've already cracked the code on agentic development. These teams serve as internal laboratories, experimenting with spec-driven development, autonomous agents, and new quality gates. The goal is to extract their practices and scale them across thousands of developers rather than merely celebrate their success.

Keren points out that mature organizations are increasingly relying on spec-driven development to structure agent behavior and make workflows more repeatable. Before AI, improving developer practices meant months-long education programs. Now, it can mean refining a prompt or adjusting how specs guide autonomous agents. This shift makes improvement exponential rather than linear because when you teach an agent better practices, every developer using that agent benefits immediately.

The transformation touches every stage of delivery: planning, coding, review, testing, deployment, and release management. Organizations are no longer asking "How many developers have adopted AI?" Instead, they're asking "Which parts of our delivery pipeline are ready for autonomous operation, and which still need human oversight?"

AI spending now demands measurable engineering returns

The bill is coming due. What started as cheap experimentation is rapidly becoming a significant line item in engineering budgets, and leaders are being asked to justify every token spent.

This gap between code generation and realized productivity represents one of the most uncomfortable truths in AI-driven development. Organizations are seeing massive increases in pull request volume, often 2X or more, while actual productivity gains hover in the low double digits. The math doesn't add up, especially as token-based pricing and usage-based tooling make AI costs increasingly visible.

Lines draws a parallel to the streaming service revolution. Cable TV seemed expensive until Netflix arrived at $19.99 per month. Fast forward a few years, and many households are paying $500+ annually across multiple streaming platforms. AI development tools are following the same trajectory, heavily subsidized now to drive adoption, but with costs inevitably rising as the technology matures.

The shift from adoption metrics to business justification is forcing engineering leaders to connect AI spending directly to measurable outcomes: faster delivery, improved quality, reduced technical debt, or better production stability. Token costs must translate into proportional value, and many organizations are discovering that simply generating more code doesn't automatically deliver more business value.

This reality is driving demand for end-to-end engineering observability. Organizations need baseline data on efficiency, quality, and spend before they can prove transformation is working. Leaders must now answer questions like: "How does agent usage relate to team performance? Which autonomous workflows deliver the best ROI? Where is AI spend outpacing realized value?"

The most mature organizations are treating AI cost management as inseparable from engineering outcomes, building systems that connect agent usage to shipped value and downstream operational results.

AI-generated code is overwhelming senior reviewers

AI has solved the code generation problem and created a new one around who reviews all this code.

"Senior developers across all companies are swamped. They are tired. They're underwater. They need to read all this code and approve all these changes." — Ori Keren

The bottleneck has shifted from writing code to validating it. AI has significantly increased code throughput, but review capacity, testing infrastructure, and release operations haven't scaled at the same rate. The result is a persistent delivery bottleneck that's burning out the most valuable members of engineering organizations.

Senior engineers have become the primary constraint. They possess the contextual judgment, system knowledge, and architectural understanding that autonomous systems can't yet reliably replace. They know where the skeletons are buried, which services are fragile, and what changes carry hidden risk. But now they're spending most of their time triaging an endless stream of AI-generated changes rather than spreading that crucial system knowledge to junior team members.

This creates both immediate burnout risk and long-term capability risk. If senior engineers are perpetually underwater reviewing code, when do junior engineers develop the context and judgment needed to become senior engineers themselves? The traditional growth path from junior to senior developer relied on exposure to complex problems, architectural decisions, and deep system understanding, which are exactly the experiences that are now being abstracted away by AI.

Autonomous pull requests often lack clear ownership, which dramatically slows pickup and merge rates. When a human writes code, they advocate for it by pinging reviewers, answering questions, and driving the change through the process. When an agent writes code, no one owns that follow-through, and changes languish in review queues.

Organizations are responding by building quality gates specifically for autonomous code. These gates reduce review burden by automatically validating that AI-generated changes meet basic standards before consuming senior engineer time. The goal is making organizations comfortable enough with autonomous code quality to allow more changes to flow downstream with lighter human oversight.

A strong context layer makes autonomous delivery reliable

The most successful AI transformations aren't happening because of better models or more powerful agents. They're happening because organizations are building shared operational context that helps both humans and agents make better decisions.

Before AI, engineering teams needed context to work effectively. With AI, context has become mission-critical. Agents need more than code access to make sound decisions about implementation, routing, review, and release risk. They need to understand repositories, services, incidents, teams, ownership relationships, and the broader operational environment.

"AI made it mission-critical. If you don't have context, what do you do? How do you even move?" — Ori Keren

Keren frames this as building an operational context store with two distinct legs. The first leg serves AI-native development workflows, helping agents understand what to build, how to build it, who should review it, and where it should deploy. The second leg serves engineering operations, where planning, staffing, and roadmap decisions can be improved through agent support.

This second leg excites Keren even more than autonomous coding. He describes a future where engineering leaders wouldn't enter roadmap sessions without first running an analyst agent that processes customer calls, delivery data, and team capacity to suggest priorities. Team leads wouldn't plan iterations without agents analyzing what's realistic given current velocity and constraints. Even staffing decisions could benefit from agents that understand skill distribution, team performance patterns, and project requirements.

The key insight is that context is about visibility and actionability. A true context engine doesn't just surface insights; it enables orchestration and follow-through through automation layers and agent integrations. It becomes the foundation for better decision-making across planning, execution, and delivery.

Organizations that build strong context layers are the ones seeing productivity gains that match their code generation increases. They're moving beyond the 10-15% productivity plateau because their agents make smarter decisions, their humans spend less time gathering information, and their processes adapt automatically to changing conditions.

The human-agent inner loop now defines developer productivity

The metrics that have defined engineering productivity for decades are no longer sufficient. A new inner loop has emerged, centered on how humans and agents collaborate.

The traditional outer loop of cycle time, deployment frequency, and mean time to recovery still matters. But it no longer captures the full picture of developer productivity. Today's engineering work includes an inner loop of prompting, agent runtime, human feedback cycles, and waiting periods where either the human or the agent is idle.

This inner loop fundamentally changes how developer work should be measured. Progress now depends on prompt quality, session flow, and how effectively humans manage agent interactions. Git commits alone can't represent this activity, and meaningful process data now includes session-level details like agent idle time, prompt effectiveness, and whether developers are successfully running multiple tasks in parallel.

"There's this classic outer loop that's always existed, and you can kind of frame that by DORA metrics, cycle time, MTTR. That's the outer loop. But there's an inner loop now." — Dan Lines

Spec-driven development supports this inner loop by giving agents clearer direction and making iterative work more structured and reproducible. When specs are well-defined, agents spend less time waiting for clarification and humans spend less time correcting course. The workflow becomes more predictable and efficient.

Advanced inner-loop maturity unlocks harder use cases, particularly brownfield refactoring with AI. Organizations are reporting projects they expected to take eight person-years completing in two to three months. But these successes require strong context, comprehensive testing discipline, and effective human-agent collaboration rather than simply pointing agents at legacy code.

The inner loop also reveals why greenfield development has been easier to automate than brownfield work. Starting fresh, agents can operate with relatively simple context and minimal constraints. Refactoring existing systems requires understanding architectural decisions made years ago, navigating technical debt, and respecting implicit contracts between services, which is exactly the kind of nuanced judgment that requires rich context and careful human oversight.

Organizations that master the inner loop aren't just writing code faster, they're fundamentally changing how work gets done, how progress gets measured, and how teams collaborate with increasingly autonomous systems.

Engineering leaders who build ADLC systems will outpace the market

The transformation from SDLC to ADLC isn't optional and is already happening. The organizations that will thrive aren't necessarily the ones with the most AI tools or the highest adoption rates. They're the ones building the context engines, quality gates, and operational frameworks that make autonomous development reliable, cost-effective, and genuinely productive.

The question isn't whether AI will reshape software delivery. It's whether your organization will lead that transformation or struggle to keep up. The answer depends on how quickly you can identify what's working, scale it across your teams, and build the infrastructure that makes both humans and agents more effective.

The ADLC era is here. The best engineering leaders are already building it.

Headshot3_d7231cbda7

Andrew Zigler

Andrew Zigler is a GTM Engineer at LinearB and the host of Dev Interrupted, a twice-weekly podcast and newsletter where 40k+ builders decode the transition to AI-native development and agentic orchestration. A classicist by training with a degree from The University of Texas at Austin, Andrew spent his early career teaching in Japan before channeling his interdisciplinary instincts into the tech world. His polymath background informs everything he builds, from automated workflows to the stories he tells about the seismic shifts reshaping software creation.

Connect with

Your next read