---
title: Your SDLC wont survive contact with agents
canonical: "https://agenticup.dev/posts/your-sdlc-wont-survive-contact-with-agents/"
pubDate: "2026-06-26T00:00:00.000Z"
description: PwC predicts over half of engineering teams will run a fully agentic SDLC by 2027. The bottleneck moves from writing code to providing context. Here is what breaks first.
tags: [ai agents, software development lifecycle, agentic development, engineering teams, production patterns]
---

**TL;DR:** The traditional SDLC assumes humans write code. Agents break that assumption at every phase. The bottleneck moves from writing code to providing context. PwC predicts over half of engineering teams will run a fully agentic SDLC by 2027. Most teams aren't ready for what that means.

> **Key takeaways:**
> - Every phase of the classic 6-phase SDLC transforms when agents execute instead of humans. The bottleneck shifts from coding speed to context quality.
> - The biggest risk in an agentic SDLC isnt agent capability. Its context deprivation: agents producing code that is syntactically correct but organizationally wrong.
> - ThoughtWorks predicts smaller development teams as agents take on coding work. The remaining engineers shift from writing code to providing direction, context, and validation.
> - Start ASDLC adoption in low-risk phases (testing, documentation) where agent errors are easy to catch. Expand to implementation and design as your team builds the internal knowledge infrastructure.
> - The teams that succeed with ASDLC are the ones that invest in making their institutional knowledge accessible to agents, not the ones that buy better models.

## What changes when agents enter the SDLC?

The six-phase SDLC (planning, analysis, design, implementation, testing, maintenance) has evolved from waterfall to agile to DevOps. Through every iteration, one assumption stayed constant: humans write the code. Agents break that assumption at every phase.

PwCs research on the agentic SDLC predicts that [more than half of engineering teams will run a fully agentic pipeline by 2027](https://www.pwc.com/m1/en/publications/2026/docs/gen-ai-survey.pdf). EPAMs Agentic Development Lifecycle framework describes the shift as [humans express intent and agents execute](https://www.epam.com/insights/ai/blogs/agentic-development-lifecycle-explained). McKinsey research on [the agentic organization](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-agentic-organization-contours-of-the-next-paradigm-for-the-ai-era) identifies that forward-thinking teams are redesigning workflows around AI agency, not just layering AI tools on top of existing processes.

The shift is real and it's happening faster than most teams expect. But the question that matters isn't when agents will arrive. It is which phase of your SDLC breaks first when they do.

## How does planning change when agents generate the plan?

In the traditional SDLC, planning is a human meeting-heavy process. Product managers and engineering leads define scope, estimate timelines, allocate resources, and document requirements. The output is a PRD or a set of tickets. The quality depends on how well the team understands the codebase, past decisions, and organizational constraints.

In an agentic SDLC, agents can generate project plans from high-level prompts, surface related prior work, flag architectural conflicts before any code is written, and estimate complexity based on historical data. A KPMG report found that [agentic AI can compress the analysis phase from weeks to hours](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2025/agentic-ai-is-revolutionizing-software-development-1.pdf) for well-instrumented teams.

What changes: planning goes from a bottleneck activity that takes days or weeks to a near-instant feedback loop. But the quality of the plan depends entirely on whether the agent has access to your teams institutional knowledge. An agent that doesn't know why your team chose PostgreSQL over CockroachDB in 2024 will produce a plan that repeats mistakes your team already made.

## Why does design become a context problem instead of a creativity problem?

This is the phase where the shift is most dramatic and misunderstood. In the traditional SDLC, senior engineers design system components, data flows, and interfaces. The output is an architecture document or a design spec. The quality depends on the engineers experience and their knowledge of past decisions.

In an agentic SDLC, agents generate architecture proposals, evaluate multiple design patterns against internal constraints, and flag conflicts with existing services. EPAMs ADLC framework explicitly identifies this as the phase where [agent and human collaborate on system design](https://www.epam.com/insights/ai/blogs/agentic-development-lifecycle-explained), with the agent proposing options and the human validating tradeoffs.

The bottleneck shifts from having enough senior engineers to having enough documented context. An agent designing a new microservice needs to know why similar services were built the way they were, which patterns were tried and abandoned, and which standards are currently enforced. If that knowledge lives only in the heads of senior engineers, the agent produces generic designs. If it's documented and accessible, the agent produces designs that fit your specific architecture.

## What actually happens during implementation?

Agents write code. They refactor code. They document code. They are highly capable of generating syntactically correct code.

The problem is they're much less reliable at generating organizationally correct code. The Stack Overflow blog on [agentic AI rewriting the development playbook](https://stackoverflow.co/internal/resources/agentic-ai-is-rewriting-the-software-development-playbook/) calls this out directly: agents write code that passes tests but violates internal standards no one bothered to document in a machine-readable format.

This is the risk shift that the loop engineering pattern addresses. In [the pi-loop approach](https://agenticup.dev/posts/pi-loop-dot-ai/), solutions go through a decompose-solve-critique-iterate-synthesize cycle that catches organizationally wrong outputs before they ship. But that critique phase only works if the critic agent has access to the same internal standards the human team uses.

ThoughtWorks analysis on [preparing teams for the agentic SDLC](https://www.thoughtworks.com/en-us/insights/articles/preparing-your-team-for-agentic-software-development-life-cycle) predicts that teams will get smaller as agents take on implementation work. The engineers who remain shift from writing code to providing the context and standards that agents need to produce correct code. That's a fundamentally different skill set.

## How does testing change when agents write their own tests?

In the traditional SDLC, testing is a separate phase, often a bottleneck at the end of the cycle. QA engineers write test cases, run regression suites, and report bugs. Changes found late in the cycle are expensive to fix.

In an agentic SDLC, agents generate unit tests, integration tests, and edge case scenarios in parallel with implementation. They evaluate test coverage, identify gaps, and re-run tests automatically after code changes. Quality shifts left because testing happens continuously rather than at the end.

The catch: agents test against the same internal knowledge they used to write the code. If the spec is incomplete, the tests will be incomplete too. This is where the human validation layer matters most. The human reviews not just the code but the test coverage and flags gaps the agent missed.

## Where does maintenance go when agents monitor production?

This is the most underappreciated shift. In the traditional SDLC, maintenance involves human engineers monitoring logs, responding to incidents, and manually patching issues. Knowledge about system behavior lives primarily in the heads of the people who built it. When those people leave, the knowledge leaves with them.

In an agentic SDLC, agents continuously monitor deployed systems, detect anomalies, propose patches, and initiate rollback procedures. KPMG identifies this as one of the highest-value phases because [agentic AI can dramatically reduce mean time to resolution](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2025/agentic-ai-is-revolutionizing-software-development-1.pdf).

What changes: maintenance shifts from reactive human effort to continuous automated monitoring. But the agents effectiveness depends on how well the system is documented. An agent that inherits an undocumented system with no incident history, no architecture decisions recorded, and no runbooks will be barely more effective than a human in the same position. The difference is the agent can ingest and process institutional knowledge faster, if it exists.

## What is the bottleneck in the agentic SDLC?

The common thread across all six phases: the bottleneck shifts from human capacity to context quality.

McKinsey research on [agentic organizations](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-agentic-organization-contours-of-the-next-paradigm-for-the-ai-era) identifies context deprivation as the primary reason agentic AI underperforms in enterprise settings. Agents hallucinate not because the model is weak but because they lack access to the specific context about your codebase, your architecture decisions, your incident history, and your team conventions.

The Stack Overflow blog post frames this around their Stack Internal product, but the underlying problem is real and product-agnostic: your teams institutional knowledge is the critical input to your agentic pipeline. If it lives in Slack threads, hallway conversations, and senior engineers heads, your agents will produce generic code that looks correct to an LLM but wrong to your team.

The successful teams will be the ones that treat their institutional knowledge as infrastructure: continuously documented, accessible to agents, and validated by the engineers who own it. The teams that buy better models hoping to skip the context work will find that better models hallucinate differently, not less.

## FAQ

> **What is the Agentic SDLC (ASDLC)?**
> The ASDLC is a software delivery model where AI agents autonomously plan, code, test, and maintain software while humans set intent and validate outputs. It transforms the classic 6-phase SDLC by shifting execution from humans to agents.
>
> **How does ASDLC differ from traditional SDLC?**
> In a traditional SDLC, humans write code, make architectural decisions, and manually move work through each phase. In ASDLC, agents handle execution while humans focus on direction, review, and oversight. The key difference is who does the work and how continuously it flows.
>
> **What is the biggest risk in ASDLC?**
> Context deprivation. Agents produce syntactically correct code but organizationally wrong code when they lack access to internal architecture decisions, naming conventions, and past incident history.
>
> **When should teams adopt ASDLC?**
> Start in low-risk phases like testing and documentation, where agent errors are easy to catch. Expand to implementation and design as you build the knowledge infrastructure.
>
> **Does ASDLC mean smaller engineering teams?**
> Yes, ThoughtWorks predicts smaller teams. But the teams that remain need stronger context infrastructure, not less engineering talent.

## Related Posts

- [Loop engineering: the production agent loop](/posts/loop-engineering-production-agent-loops/). The internal loop pattern that makes agents self-correct during a single task.
- [pi-loop: decompose, solve, critique, iterate, synthesize](/posts/pi-loop-dot-ai/). A Pi extension that implements the loop engineering pattern as a practical tool.
- [When a worse model beats a frontier model for agent work](/posts/when-better-model-isnt-better-agent/). Why throughput and consistency matter more than benchmark scores in agent loops.
- [Agents break in production](/posts/agents-break-in-production/). The failure modes that emerge when agents run in production environments.

---

This article was published on Agentic Up (https://agenticup.dev) — practical guides for developers and founders building with AI agents. Reach me at hello@agenticup.dev