Redefining the SDLC for GenAI: Practical Insights from the Field
This blog post explores how GenAI is transforming software development by requiring a fundamental redesign of the Software Development Life Cycle (SDLC) rather than simply adding AI assistants to existing workflows.
It's been about 3 years since developers have started experimenting with GenAI-powered coding assistants and for about the same time the tech industry is trying to understand how AI will change the software engineering profession. I've never been of the opinion that the world will need fewer software engineers and from the many conversations I've had with customers, developers and engineering leaders, I'm starting to get a clearer picture how we need to re-define the SDLC to benefit from GenAI. In this blog post I want to summarize my most important insights.
Why re-define the SDLC anyways?
While coding assistants and their underlying LLM's have become powerful enough to write compileable and runnable code, we have learned that retrofitting the SDLC in narrow areas with assistants and agents doesn't produce meaningful results. Simply giving developers access to such tools, without guidance and customization, often led to feedback like:
"It's nice but somehow not good enough to make us measurably better or faster."
So when it comes to re-defining our methodologies, I can recommend reading the AI-DLC whitepaper . It goes into much more detail about the rituals and processes we believe need to change in the age of AI. In the following sections I want to dive into some practical and technical requirements of the AI-DLC.
The developer stays in the drivers seat - but steering became asynchronous
Coding has traditionally been a synchronous activity that required contiguous time. We see developers who successfully use GenAI leverage the asynchronous nature of agents, meaning they spend short bursts of time writing specs or reasoning with the agent, and then let them build. When developers come back from meetings, code reviews or operational tasks they take the time to deeply understand every line of code the agent wrote. This requires developing intuition of what and how to ask the LLM but it ensures that the developers stay connected to the entire code base.
Shifting left became even more important
If our cycles to build and test a feature take hours or even days, caused by slow pipelines or the need to test in Prod, we can't expect AI to produce useful results. Agents code fast, so they need fast feedback cycles. In practice this means 2 things:
1) Establish an extremely comprehensive suite of unit tests (with the help of AI) and, if needed, provide high-quality mocks of dependencies.
2) Provide the agent tools (and access) to do end-to-end testing, e.g. through the browser, DB, emulators...
The goal is to do as much quality assurance on the left, in a matter of minutes, as is needed to confidently roll out to Prod. We need to be honest about this - there is no point in letting agents crank out features, if we don't dare to launch them. In reality, this might encompass big investments into the code base and the CI/CD environment but those investments could pay off double: Developers will benefit from quality of live improvements and agents are empowered to work exponentially faster.
Limiting tool selection
Giving agents tools through MCP has opened up many new possibilities but we need to keep one thing in mind: Every tool takes up space in the LLM's context window, together with your prompts and steering files. Context rot has been observed in research and in practice: It simply means agents will produce worse results the more you fill up the context window. In practice you can do the following:
1) Manage MCP tool selection actively. Think about which MCP servers are useful for the current task and disable all others.
2) Be prescriptive, through steering files, in which situations the agent should select a certain tool and how to use it, e.g. :
plaintext
AGENT.mdWhen starting a debug session, use the cloudwatch-mcp-server with profile 123, to retrieve logs from...
Equip the agent with all of the necessary knowledge
Agents rely on you to provide them with your domain-specific knowledge to effectively develop in legacy applications. This turns out to be a massive challenge because not only is knowledge spread across sources (README's, wikis, file shares...) and outdated, it often falls between ownership boundaries and is left completely undocumented. In conversations with customers, I found the most useful question to start with:
"When you onboard a new developer, what are all the docs and pointers you give them, enabling them to implement a feature independently?"
Besides providing a dozen links, chances are your answer includes "talk to X" and "play around with Y", which are both indications that developers require tribal and undocumented knowledge to be effective. That's bad news for agents. What can you do?
1) Start building up all documentation of the application in your source repository (inline comments, Markdown files, diagrams). This needs to happen gradually and GenAI can help.
2) Don't just squeeze everything into steering files, keep a lightweight steering file, guiding the agent to pull documentation as needed:
plaintext
AGENTS.md- When implementing a feature concerning user authentication, read the docs in ./docs/auth- When you make changes to the front-end, read the design guidelines in ./docs/frontend
3) If you want to retain knowledge outside of source repositories, connect those knowledge bases through MCP (e.g. Notion MCP ). But beware that this introduces latency and complexity.
Provide examples - mimic patterns
We learned that LLM's are great at understanding and following patterns. So wether you are building a new feature, setting up a new service or debugging an issue, let the agent mimic patterns that you deem best practice, instead of building up a tree of complex rules:
- Point the agent to a catalog of "reference architectures" in the form of Terraform modules
- Provide an actual class hierarchy you want it to mimic
- When root causing an issue, let it read through tickets that captured production outages (e.g. through MCP).
It's still early days...
...in the age of AI-powered development but these are all things you can do today to get a head start. Here a few resources to keep exploring further:
- BrowserMCP allows your AI assistant to navigate and debug in a browser window
- How the Audible team leveraged Amazon Q Developer to boost unit test coverage
- Joe Magerramov, Sr. Principal Engineer at AWS, on asynchronous coding
Let me know what you think in the comments!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article