Building Systems that Build Systems: Setting up the SDLC in LangGraph | Matt McCormick

Building Systems that Build Systems: Setting up the SDLC in LangGraph

Matt McCormick

2026/07/17

Over the past few weeks, I’ve been building a system to see how far I can go with AI agents running the entire software development lifecycle. Could I hand AI an idea and get back a working app?

This is a continuation from my last post about My Journey into AI-Assisted Development. See that post for context about where I’m coming from.

History

The process or workflow for developing software, known as the Software Development Lifecycle (SDLC), has been in place for decades now without major changes. Agile attempted to revolutionize it but the only difference between Agile and more traditional lifecycles is the size of the iteration. You’re still going through the same steps, just hopefully faster as you get feedback from customers earlier.

The earliest definition that I’m aware of comes from the 1970 paper by Dr. Winston Royce - Managing the Development of Large Software Systems. Dr. Royce mapped out the processes that he had followed in his software engineering career up until that point. The paper wrongly gets associated with waterfall due to the first diagram in the paper, where the stages advance in a sequential order.

Figure 1 Sequential SDLC taken from Royce paper

In today’s terminology, we might map the original terms to the following:

System Requirements => Non Functional Requirements

Software Requirements => Functional Requirements

Program Design => Technical Design Document

Operations => Deployment/Production

A Product Requirements Document would usually be produced, which would contain the System and Software Requirements.

As Dr. Royce noted though, a purely sequential flow opens up the team to a lot of risk since it’s impossible to see so far ahead. To address that risk, in reality, the phases flow together more fluidly. There are iterative cycles within each phase to address the reality that you tend to make progress and run into unknowns or new decisions that have to be made. Those decisions then need to feed back upstream as the team goes through the learning process.

Figure 2 Iterative SDLC taken from Royce paper

In extreme and unfortunate cases, you may discover during the testing phase that a major requirement was missed. These situations tend to result in a lot of rework as a large chunk of the design may need to be redone.

Figure 3 SDLC involving major requirement redo taken from Royce paper

Implementing the SDLC with AI and LangGraph

The system assigns AI agents to each of the roles needed as part of the SDLC. This is to help solve the problem of context switching that I wrote about in my previous post. Basically, the dream would be to build out an app purely from an idea:

Figure 4 Simplified SDLC - Idea -> Done

While AI can do this with simpler ideas, more complex ideas will need a back-and-forth discussion to help clarify requirements between both parties.

Initially, I started with a pretty simple setup and this has evolved into what the layout looks like today when the graph is exported directly to Mermaid from LangGraph:

graph.get_graph().draw_mermaid()

config:<br>flowchart:<br>curve: linear<br>graph TD;<br>__start__([__start__]):::first<br>pm_business_case(pm_business_case)<br>greenlight(greenlight)<br>scaffold_project(scaffold_project)<br>pm_prd(pm_prd)<br>prd_gate(prd_gate)<br>designer(designer)<br>design_gate(design_gate)<br>tech_design(tech_design)<br>tdd_gate(tdd_gate)<br>planner(planner)<br>plan_gate(plan_gate)<br>ticket_breakdown(ticket_breakdown)<br>next_ticket(next_ticket)<br>engineer(engineer)<br>lead_guidance(lead_guidance)<br>human_action(human_action)<br>open_pr(open_pr)<br>review(review)<br>qa(qa)<br>complete_ticket(complete_ticket)<br>ticket_guard(ticket_guard)<br>e2e_qa(e2e_qa)<br>security_review(security_review)<br>phase_review(phase_review)<br>escalation(escalation)<br>done(done)<br>end_rejected(end_rejected)<br>end_aborted(end_aborted)<br>__end__([__end__]):::last<br>__start__ --> pm_business_case;<br>complete_ticket --> next_ticket;<br>design_gate -. &nbsp;revise&nbsp; .-> designer;<br>design_gate -. &nbsp;rejected&nbsp; .-> end_rejected;<br>design_gate -. &nbsp;selected&nbsp; .-> tech_design;<br>designer --> design_gate;<br>e2e_qa -. &nbsp;escalate&nbsp; .-> escalation;<br>e2e_qa -. &nbsp;fail&nbsp; .-> next_ticket;<br>e2e_qa -. &nbsp;pass&nbsp; .-> security_review;<br>engineer -. &nbsp;escalate&nbsp; .-> escalation;<br>engineer -. &nbsp;needs_human&nbsp; .-> human_action;<br>engineer -. &nbsp;blocked&nbsp; .-> lead_guidance;<br>engineer -. &nbsp;ready&nbsp; .-> open_pr;<br>escalation -. &nbsp;abort&nbsp; .-> end_aborted;<br>escalation -. &nbsp;proceed&nbsp; .-> next_ticket;<br>greenlight -. &nbsp;rejected&nbsp; .-> end_rejected;<br>greenlight -. &nbsp;revise&nbsp; .-> pm_business_case;<br>greenlight -. &nbsp;approved&nbsp; .-> scaffold_project;<br>human_action -. &nbsp;done&nbsp; .-> engineer;<br>human_action -. &nbsp;reset&nbsp; .-> next_ticket;<br>lead_guidance -->...