Blog
The SDLC is broken: why AI moved the bottleneck to architecture
Can your architecture review keep up with an AI that ships a working service before lunch? For most teams it can't, and that gap is where the SDLC is breaking.
AI can write an application faster than most organizations can approve one. Code generation got cheap. Requirements, architecture review, security review, and operational governance still run at the speed of a calendar invite.
The bottleneck has moved somewhere most delivery models don't look: the architecture that decides whether a generated system is the right system, built the right way, and still running the way it was approved.
The short version
- AI made software generation abundant. Assurance didn't scale with it, so the bottleneck moved from writing code to trusting what gets built.
- Code review and manual QA can't be the only controls between a prompt and production. Architecture, where business intent becomes technical intent, is the control layer that has to keep pace.
- Architecture automation turns written standards into designs that are checked before deployment and compared with what's running after.
What is the software development lifecycle (SDLC)?
The software development lifecycle (SDLC) is the process teams use to plan, design, build, test, deploy, and maintain software. NIST defines it as "a formal or informal methodology for designing, creating, and maintaining software" (NIST glossary).
The phases haven't changed much in fifty years. What changes is which phase slows everything else down, and that's what pushes teams to a new way of working.
What is the history of SDLC evolution?
Every big change in how teams build software has the same origin story. Something was slowing everyone down, and the next approach was built to fix it.
Waterfall, often traced back to Winston Royce's 1970 paper on managing large software projects, organized delivery into sequential stages because change was expensive and deployments were rare. It optimized for predictability, and it worked until markets started shifting while projects were still underway. Teams shipped what had been specified instead of what the business needed at release. Waterfall hadn't become irrational. Its assumptions had stopped matching the pace of the business.
Agile answered in 2001 by treating requirements as something you discover and refine continuously. Then deployment and operations became the constraint, and DevOps, infrastructure as code, and continuous delivery closed the distance between a commit and a dependable release. Google Cloud's DORA research frames delivery performance as a balance of throughput and instability: speed and reliability have to improve together (DORA).
How has AI changed the software development lifecycle?
AI made writing software abundant. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they use or plan to use AI tools, and 51% of professional developers use them daily (Stack Overflow). Google's 2025 DORA report puts AI use at nearly 90% of technology professionals (InfoQ on DORA 2025).
The output is real. A one-year study of 300 engineers reported a 31.8% reduction in pull-request review cycle time and a 28% increase in code shipment volume after rolling out AI tooling, along with adoption and governance challenges (Kumar et al., 2025). Not every team will see that uplift. The structural point holds anyway: implementation can now accelerate independently of the controls around it.
Put simply, teams can now generate more than they can check. More output doesn't automatically mean more trusted delivery. The limiting factor isn't writing the code anymore. It's deciding whether the generated system is appropriate, secure, resilient, economical, and operable.
Why is assurance the new bottleneck?
Because every step after "build" still depends on scarce human attention, and AI just exposed all of them at once.
Developers already feel it. The same Stack Overflow survey found more developers distrust the accuracy of AI output (46%) than trust it (33%), and 66% named "AI solutions that are almost right, but not quite" as their top frustration (Stack Overflow). Almost right is a review problem. Multiply it across every generated component and it becomes a capacity problem.
The security picture matches. Veracode tested more than 100 large language models on 80 coding tasks and found security flaws in about 45% of the results (Veracode, 2025 GenAI Code Security Report). DORA's 2025 research describes AI as an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones (InfoQ on DORA 2025).
Traditional controls weren't built for this. Code review assumes authors and reviewers work at comparable speeds, and research on AI-driven review reports efficiency gains alongside persistent concerns about trust and context (Cataldi, 2025). Manual QA can't keep up with continuously generated change. And AI can ship a working prototype before anyone finishes the requirements, which locks in decisions nobody actually made.
None of this makes review, testing, or specialist judgment obsolete. It changes where they're applied. Experts should define intent, approved patterns, risk boundaries, and exceptions. Automation should apply and check those decisions every time.
Architecture is the missing control layer
The question has changed. It's not whether AI can generate software. It's whether AI can generate and run systems that consistently meet your security, resilience, performance, cost, and business requirements.
Architecture is where that gets decided. It's where business intent becomes technical intent, trade-offs become explicit, and a pile of generated components becomes a coherent system. In most organizations it's still done by hand: a Word document, a Visio diagram, a review meeting, and one person who remembers why the network is shaped the way it is.
Production keeps changing. The document stays tidy while it drifts further from what's actually running.
That's the difference between a record and a system. Documented architecture is a record: it's true on the day you write it. Adaptive architecture is a system: it stays true because it keeps checking.
What is architecture automation?
Architecture automation is the practice of turning an organization's architecture standards, security controls, and requirements into machine-readable rules, then using those rules to design cloud architecture, check designs before deployment, and continuously compare running environments with what was approved. It replaces review by hand with checks that run at the pace of delivery.
Most organizations already have the inputs. Architecture principles, approved patterns, security policies, resilience targets, and cost guardrails exist today, scattered across wikis, slide decks, and people. Architecture automation gathers that intent into one model so a developer doesn't have to master every domain before shipping, and an architect doesn't have to review every design personally to keep the standard.
In practice it works as a loop you can enter at any point:
- Discover. Map what's running in your cloud estate and the standards you already have.
- Design. Turn requirements into architecture that uses your approved patterns and controls from the start.
- Deploy. Generate infrastructure as code from the approved design, so the reasoning travels with the build.
- Detect. Always on. See what matches the approved design, what has drifted, and the fix. A person decides and applies it.
How is that different from the tools teams already own? Enterprise architecture repositories document architecture. Cloud posture and drift tools report on what's running. Architecture automation connects the two: the approved design and the running environment are checked against each other, continuously, with the standard as the reference point.
This is what Dawnguard builds. Build cloud architecture to your standards, and keep it that way. Developers describe the outcome they want. Architecture and security teams define the rules once and apply them every time, instead of in a review queue.
AI workloads make infrastructure part of the SDLC
Software runs on infrastructure, assumes identities, holds permissions, and reaches data. AI agents make that sharper: they get connected to cloud APIs, repositories, deployment pipelines, and customer data, so an application-level weakness can turn into an identity or infrastructure incident.
Governance hasn't caught up. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls (Gartner, June 2025).
Nobody can prevent every prompt injection, leaked credential, or over-privileged agent, so the architecture also has to limit what a failure can reach. NIST's Zero Trust Architecture puts it plainly: no implicit trust based on network location alone, and authentication and authorization before access to a resource (NIST SP 800-207).
For AI workloads, containment belongs in the design from day one:
- Least-privilege identities for agents, services, and automation
- Segmentation and workload isolation to limit lateral movement
- Explicit data-access boundaries and controlled tool permissions
- Separate development, test, and production environments
- Recoverable infrastructure definitions and resilient deployment patterns
- Continuous checks of deployed posture against the approved design
That leaves two questions for every AI workload. Is this system behaving as intended? And if it fails or gets compromised, is the blast radius contained?
The next SDLC runs on intent
Waterfall optimized for predictability. Agile optimized for responsiveness. DevOps optimized for delivery. AI has now removed software creation as the main constraint, and for the first time organizations can generate applications and infrastructure faster than they can validate them.
The next SDLC will be built around intent. Requirements become machine-readable. Architecture becomes adaptive. Governance runs continuously instead of in a quarterly review. And the lifecycle extends past code into the identities, permissions, and environments AI workloads depend on.
The goal was never more generated code. It's more business outcomes you can stand behind, on the day you ship and every day after.
Keep reading: [Related post: Documented architecture is a record. Adaptive architecture is a system. (link)] | [Related post: What architecture drift costs you (link)] | Follow Dawnguard on LinkedIn for more on adaptive architecture, or [subscribe to our newsletter (link)].
Frequently asked questions
What is architecture automation?
Architecture automation turns an organization's architecture standards, security controls, and requirements into machine-readable rules. Those rules are used to design cloud architecture, check designs before deployment, and continuously compare running environments with the approved design, so the standard holds without every decision going through a manual review.
How is architecture automation different from enterprise architecture tools?
Enterprise architecture tools document and catalog architecture, which makes them a record of intent. Architecture automation uses that intent as executable rules: it generates designs that follow them, validates designs before they're built, and detects when the running environment drifts away from what was approved.
What is architecture drift?
Architecture drift is the gap that opens between an approved architecture and what's actually running in production. It builds up through manual changes, exceptions, emergency fixes, and new services added outside the original design. Drift matters because decisions, reviews, and audits based on the documented design no longer reflect reality.
How do you secure AI agents in cloud infrastructure?
Design for containment as well as prevention. Give agents least-privilege identities, isolate workloads, set explicit data-access boundaries and tool permissions, separate environments, and continuously check deployed posture against the approved design. NIST SP 800-207 (Zero Trust Architecture) and the NIST AI Risk Management Framework are useful reference points.
Does architecture automation replace architects?
No. Architects define the patterns, constraints, trade-offs, and exceptions that the automation applies. Automation takes over the repetitive part, checking every design and every change against those decisions, so architects can spend their time on the judgment calls instead of the review queue.
