{"slug": "building-systems-that-build-systems-setting-up-the-sdlc-in-langgraph", "title": "Building Systems That Build Systems: Setting Up the SDLC in LangGraph", "summary": "Matt McCormick built a system using LangGraph to automate the software development lifecycle with AI agents, assigning agents to roles such as requirements, design, and testing to reduce context switching. The system processes ideas into working apps by iterating through SDLC phases, with early results showing promise for simpler projects while complex ideas require human clarification. The project highlights the importance of documentation and front-loading decisions to minimize rework.", "body_md": "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?\n\nThis is a continuation from my last post about [My Journey into AI-Assisted Development](https://mattmccormick.ca/we-re-all-managers-now-my-journey-into-ai-assisted-development/). See that post for context about where I’m coming from.\n\n## History\n\nThe 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.\n\nThe earliest definition that I’m aware of comes from the 1970 paper by Dr. Winston Royce - [Managing the Development of Large Software Systems](https://www.praxisframework.org/files/royce1970.pdf). 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.\n\nIn today’s terminology, we might map the original terms to the following:\n\n- System Requirements => Non Functional Requirements\n- Software Requirements => Functional Requirements\n- Program Design => Technical Design Document\n- Operations => Deployment/Production\n\nA Product Requirements Document would usually be produced, which would contain the System and Software Requirements.\n\nAs 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.\n\nIn 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.\n\n## Implementing the SDLC with AI and LangGraph\n\nThe 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:\n\nWhile AI can do this with simpler ideas, more complex ideas will need a back-and-forth discussion to help clarify requirements between both parties.\n\nInitially, 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:\n\n```\ngraph.get_graph().draw_mermaid()\n```\n\nThis is difficult to follow so I’ve had AI generate simpler flowcharts. Below, I’ll share what I’ve learned from building and running the system.\n\nLangGraph lets you define agents, which are really just fairly straightforward and simple prompts to help guide the model into playing a role.\n\nThe Build cycle has nodes that pull tickets off the backlog in a kanban queue format and move through the execution phase.\n\n## Learnings\n\n### Importance of Documentation\n\nThe goal with this type of setup is to try to reduce the number of decisions that I need to make and try to front load as much as possible. In real life, everyone talks about the importance of documentation. Enforcing it, however, is much tougher. Creating early documents doesn’t feel like “real work”. It’s tough to walk the fine line between writing enough documentation and not documenting everything that may change later on.\n\nGetting people to place enough focus and energy reviewing early documents is another challenge. The project is still in an early phase where it’s too abstract. It’s not real and people are likely devoting most of their energy towards implementation of something else that feels more urgent and higher priority. Good documentation will only show benefits well down the road. Basically, the tradeoff that comes down to the individual is “why should I spend much time and effort reviewing something that may be beneficial months from now when I have tasks to complete today or for the sprint?”.\n\nWith an agentic AI SDLC process, the Coding phase will happen much faster due to AI performing most of the work here. That results in a faster feedback loop to help us understand the importance of getting upstream documentation right.\n\nI noticed this during an experiment I did one day where I tried to see if I could push AI to do more work than I was doing. Before this day, I was using AI to complete one task at a time. With this experiment, I basically wanted to see how it would do with completing a larger series of tasks, maybe several days’ worth. Unfortunately, after AI completed them, I found out that it took a different direction than I was thinking. This is pretty similar to something a lot of junior engineers will face early in their career. They’ll get assigned some small project and then go off and build it only to find out that they misunderstood some key context and now major chunks need to be redone. In this case though, I had not paid enough attention to the upstream documentation. There was a clear gap between how I was envisioning the system in my mind and what was written down. In real life with humans, you would likely have discussions of going over the document designs before implementation that will help suss this out and correct it early. That doesn’t exist with AI. AI, so far, mostly goes ahead and just does what it’s asked. (I have, however, seen better pushback from the newest Anthropic models, Opus 4.8 and Fable 5 at the time of writing.)\n\nDr. Royce devotes a whole page of his 6-page written article to documentation to illustrate how important it is. Producing well-defined requirements documentation is going to become even more critical going forward as we work with machines that can take action from natural language. That likely means more time spent in development teams on creating and reviewing documentation to make sure it’s all correct before passing off to AI agents for the implementation phase. Unfortunately, for a lot of engineers who enjoy programming, this does mean more time spent on this type of work and less time spent on coding.\n\n### Human Value\n\nIn an AI world where people are trying to understand what roles are “safe” from AI impact, this upstream requirements gathering and writing will be something that remains uniquely human. We all have our own experiences, knowledge and judgement that AI will not be able to replace. Ideas are kicked off when we encounter problems and recognize that things could be improved. That won’t go away as AI doesn’t have any real world experience or emotions to use as input.\n\nWith a system like this, the value I can provide is early on in the process for refining the idea and making sure the requirements are fully understood and written down. After that, it’s mainly verification for the implementation and noticing any gaps and prompting the system to improve so that those gaps are reduced in future iterations.\n\n### Feedback\n\nOne of the main complaints I’ll read from people using AI is their frustration that it doesn’t learn. This is by design with the way Language Models work. They have their pre-training dataset but anything outside of that which you provide will need to be fed into the prompt again to simulate “learning”. The [Explore the context window](https://code.claude.com/docs/en/context-window) docs from Claude Code do a good job of illustrating this. When you have a session with ChatGPT or Claude Code, everything you previously wrote is re-fed into the request in order for the model to retain context of that session. If you start a new session, that context is lost unless it’s saved.\n\nClaude Code has implemented memories to help solve this, and their docs also map out the files that Claude Code reads and when, so you can save context permanently for how you’d like Claude to work.\n\nWith this system, I’ve utilized a command line feedback tool that will take in my feedback at the gates and append that to context files which are always read by the agent fulfilling a certain role. For example, if I notice that the Technical Design Document was missing an important section, as part of the prompt at the gate I may write something like “TDDs should always have X section because Y”. This will then get parsed by Claude and appended to a global context file so that the next time an agent is writing a TDD it should hopefully “learn” from this and not make the same mistake.\n\n### Stand Up\n\nWhile going through the SDLC (or any project for that matter) there’s a need to understand where things currently stand. Many teams have standups for this purpose where everyone is expected to say what they completed yesterday and what they’ll be working on today, along with anything that is blocking them. This helps to communicate context to the rest of the team. With agents doing a lot in the background, it’s difficult for me to get the right amount of observability. I’ve attempted to replicate standup through a custom webpage that I have set up and running locally. It’s not perfect but it’s a good start to give me a timeline of what is going on. If anything looks odd, I can then dig into more details if needed.\n\n### Do It Twice\n\nSimilar to documentation, Dr. Royce devotes one of his steps to “Do It Twice”:\n\nAfter documentation, the second most important criterion for success revolves around whether the product is totally original. If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned….Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort.\n\nThis principle has been known in software for more than 50 years, with many people likely being aware of it from Fred Brooks and his book *The Mythical Man-Month*, where he said “Plan to throw one away. You will anyhow.” Basically, it means that if you ship the first version, it will be riddled with design errors that you only come across later once more users are on it, and it will need to be redone at some point anyway.\n\nOne of the huge benefits of AI is how quickly it can build a prototype. This is a step that should always be mandatory now before proceeding with development: build a quick and simple interactive prototype that can be shared, and then use that as input for AI to break down the final prototype into requirements and start building a productionized version from that.\n\n## Conclusion\n\nWorking with LangGraph has been very interesting and educational. I really think this is the future of software development. Rather than implementing code directly, software engineers will be expected to create and maintain the systems that do that instead. This will involve patterns and design choices on the right amount of checks and balances, both machine and human, as well as making sure to get the right amount of observability into what has happened for auditing purposes and for setting up continuous improvement feedback loops.\n\n**AI Disclaimer**: This article is original content written 100% by me (a human). Flowchart images were generated with AI. AI was used in an editor role to help edit my original draft.", "url": "https://wpnews.pro/news/building-systems-that-build-systems-setting-up-the-sdlc-in-langgraph", "canonical_source": "https://mattmccormick.ca/building-systems-that-build-systems-setting-up-the-sdlc-in-langgraph/", "published_at": "2026-07-17 22:55:30+00:00", "updated_at": "2026-07-17 23:22:15.915088+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "artificial-intelligence"], "entities": ["LangGraph", "Matt McCormick", "Winston Royce"], "alternates": {"html": "https://wpnews.pro/news/building-systems-that-build-systems-setting-up-the-sdlc-in-langgraph", "markdown": "https://wpnews.pro/news/building-systems-that-build-systems-setting-up-the-sdlc-in-langgraph.md", "text": "https://wpnews.pro/news/building-systems-that-build-systems-setting-up-the-sdlc-in-langgraph.txt", "jsonld": "https://wpnews.pro/news/building-systems-that-build-systems-setting-up-the-sdlc-in-langgraph.jsonld"}}