Rethinking the Software Development Life Cycle in the AI Era
Are we using AI to make software development simpler, or are we on our way to making it more complicated?
Having spent many years in software engineering, both as a hands-on engineer and in various engineering leadership roles, I have seen the Software Development Life Cycle (SDLC) evolve through different methodologies, frameworks, tools, and engineering practices. Each evolution has brought improvements, but it has also introduced additional processes and layers of complexity that we eventually started treating as the normal way of building software.
Now we find ourselves in another significant transition, one driven by artificial intelligence and its rapidly expanding role in how we design, build, test, and deliver software.
The possibilities are exciting, and I believe we are only beginning to understand how much AI will change software engineering. However, rather than simply following the latest terminology and adopting whatever methodology is gaining momentum, I think it is important that we question what we are doing and reflect on what the next right step should be.
Over the last 12 to 18 months, the software engineering community has moved through several approaches to AI-assisted development. We started by occasionally asking AI to help us write a function, troubleshoot a problem, or generate a module. From there, we moved into prompt engineering and vibe coding, followed by spec-driven development, and more recently into concepts such as harness engineering and loop or graph engineering.
Each of these approaches brings something valuable to the table, and I see them as techniques that can help us improve how we develop software. However, I think the bigger question is how these techniques fit into the overall Software Development Life Cycle and whether we are doing enough to challenge the assumptions behind the processes we already have.
For example, what does AI mean for the Scrum methodology that many organizations have adopted? Which ceremonies still bring value, which ones need to evolve, and which ones might no longer be necessary? Are we simply introducing AI into our existing processes, or should we be questioning whether those processes still make sense in the first place?
We have already entered what many are calling the AI-SDLC era, and organizations are beginning to define and standardize their own approaches to it. While I understand the need for consistency, especially in larger engineering organizations, I believe it is still too early to carve these methodologies into stone.
More importantly, we need to be careful that we do not take something that has the potential to make software development significantly leaner, faster, and more enjoyable and turn it into another bloated system of processes, ceremonies, documentation, and organizational dependencies.
After all, the objective should not be to create a more sophisticated development methodology. The objective should be to help small teams build better products, deliver customer value faster, and enjoy the engineering work they are doing.
Let’s Start With What Product Development Actually Needs
Before discussing AI tools, agents, harnesses, or development methodologies, I think it is useful to temporarily put all of those things aside and look at product development from a more fundamental perspective.
If we remove the terminology and focus on what we are actually trying to accomplish, the process is relatively straightforward.
- Share the vision. The organization establishes a product vision and makes sure that the broader team understands where the product is going and what problems it is trying to solve.
- Translate the vision into product intents. Teams explore ideas and identify opportunities that could move the product closer to that vision.
- Turn product intents into clear requirements. Product, engineering, and UX collaborate to explore the problem, challenge assumptions, and define what needs to be built and what outcomes are expected.
- Build the solution. The team translates those requirements into working software, covering the frontend, backend, integrations, and everything else necessary to make the experience work end to end.
- Pressure-test and productionize the solution. The team validates functionality, resilience, performance, security, observability, and all the other requirements necessary to operate the software reliably in production.
- Release, stabilize, and learn. The team progressively exposes the solution to customers, monitors how it behaves, learns from actual usage, and makes the necessary improvements.
None of these steps should be particularly surprising because they represent what we have been trying to accomplish through software development for decades.
The challenge is not necessarily understanding what needs to happen. The challenge is finding a way for all of it to happen as one continuous effort without creating unnecessary handoffs, waiting periods, organizational dependencies, or a waterfall process disguised as Agile.
I also believe that we should be able to accomplish much of this with relatively small, cross-functional teams where product, engineering, and UX collaborate closely rather than operating as separate departments passing work from one group to another.
This is where I think AI has the potential to make a significant difference, but only if we approach it with the right foundation.
Before We Build Anything, We Need to Give AI the Right Context
One of the challenges I see with AI-assisted software development is that we often jump directly into asking AI to build something without first establishing whether it understands the product, the organization, the technology, and the architectural decisions that already exist.
A capable engineer joining an organization needs time to understand how things work before making meaningful changes. The same principle applies to AI, except that we have an opportunity to provide much of this knowledge in a structured way and make it reusable across teams and development efforts.
I believe organizations should invest in establishing a foundational set of product and engineering specifications that describe how their products and technology fit together.
This does not mean creating hundreds of pages of documentation that nobody reads or maintains. Quite the opposite. The objective should be to capture the important information at the right level of abstraction so that both engineers and AI can understand the system without needing to reverse-engineer every codebase whenever something needs to change.
I would approach this foundation in several layers.
The 30,000-Foot View: Understanding the Product and Technology
Let’s assume we have an organization with an overall product leader and an engineering leader.
At the highest level, the product leader should maintain a specification describing the overall product, the customers it serves, the problems it solves, and the vision behind it. This specification should provide enough context for someone unfamiliar with the product to understand what the organization is building and why.
At the same time, the engineering leader should maintain an equivalent specification describing the technology landscape at the 30,000-foot level.
This would include the overall architectural philosophy, major technology choices, system boundaries, integration principles, infrastructure direction, and the engineering practices that guide technical decisions across the organization.
The objective at this level is not to describe individual microservices, frontend components, or implementation details. It is to establish the broader context within which those decisions are made.
The Next Level: How We Build Software
Going one level deeper, engineering tech leads should document how the organization uses its technology stack.
For example, if the organization uses microservices, the specifications should describe how those services are structured, how they communicate, what shared infrastructure they can use, how security and authentication are handled, and what patterns engineers should follow.
Similarly, on the frontend, these specifications should describe the application structure, component patterns, state management approaches, API communication, testing practices, and other engineering conventions.
At this level, we are still not describing the actual features of the product. We are describing how the organization builds software so that teams and AI do not have to rediscover or reinvent the same engineering decisions every time they start working on something new.
This is also where I would expect information about resilience, observability, performance, security, and other engineering fundamentals to be captured.
The Feature Group Level: Understanding What Exists Today
Now let’s assume our organization has five major groups of product features, with multiple teams supporting each group.
For each feature group, product managers should maintain specifications describing what that group of features does, why it exists, which customer problems it solves, and how it contributes to the overall product.
At the same time, the engineering members supporting that feature group should maintain equivalent engineering specifications describing how the feature group is implemented in production.
These engineering specifications would cover the relevant frontend structure, backend services, APIs, integrations, data flows, dependencies, and other components that collectively deliver the functionality.
The goal is not to duplicate the source code in documentation. It is to create a map of the system that explains how the important pieces fit together and points engineers and AI toward the code that matters.
When we combine these specifications with the broader product and engineering foundations, we start building something much more useful than traditional documentation.
We are building a shared knowledge foundation that can guide future product decisions and AI-assisted development.
What If All of This Knowledge Lived in One Git Repository?
Imagine that the organization maintains these foundational specifications in a single Git repository, with a clear structure connecting the overall product vision, technology architecture, engineering conventions, and individual feature groups.
When a team wants to enhance an existing feature, introduce a new capability, or build an entirely new feature group, it can give its AI tools access to this repository.
Instead of asking AI to inspect thousands of files across multiple repositories before understanding the purpose of a relatively small change, we can first give it a structured understanding of the WHAT, the WHY, and the high-level HOW.
The AI should then be able to follow references through the specifications, retrieve the relevant information when needed, and understand which parts of the product and technology landscape are relevant to the work being considered.
Of course, this does not eliminate the need for AI to inspect the actual code. It simply gives AI a much better starting point and reduces the amount of unnecessary exploration required to understand the system.
I also think we can use AI itself to validate the quality of this foundational knowledge.
For example, imagine asking an AI tool something like this:
“I am thinking about building a new capability to solve this customer problem. I believe we will need several new screens and some backend functionality to support them. Based on our existing product and engineering architecture, how would you recommend approaching this, which technologies should we use, and how should we structure the solution?”
If AI can navigate the foundational specifications, identify the relevant product capabilities, understand the existing technology, and propose a reasonable product and technical architecture, that is a strong indication that the specifications provide useful context.
If the AI struggles, makes incorrect assumptions, or cannot determine how the pieces fit together, we have an opportunity to improve those specifications.
This should become an iterative exercise where we continuously refine the quality of our foundational knowledge rather than repeatedly compensating for missing context through increasingly complicated prompts.
I would also expect the specifications to evolve as the actual product and technology evolve. Ideally, keeping them synchronized with meaningful architectural and product changes becomes part of normal engineering work, rather than an independent documentation exercise.
The initial investment may require meaningful effort, particularly for organizations with years of accumulated technical complexity, but once this foundation is established, maintaining it should be relatively lightweight.
More importantly, this is an investment that can benefit every future development initiative rather than just one project.
Now Let’s Return to the Product Vision
With the foundational knowledge in place, we can return to the actual product development flow and explore how AI could help us simplify it.
The first activity is translating the broader product vision into product ideas and intents.
I see this as a discovery exercise that can happen through small, collaborative workshops involving product and engineering leaders, and UX when appropriate.
Because the team has access to the foundational product and engineering specifications, it can use AI to explore potential solutions while remaining grounded in the realities of the existing product and technology.
During this discovery work, AI can help challenge assumptions, identify potential dependencies, compare different approaches, and even generate quick prototypes that allow people to visualize possible experiences before committing to a direction.
Imagine the product lead and tech lead spending time together exploring a particular opportunity while the rest of the small team continues delivering work that is already underway.
They could use AI to explore multiple approaches, understand the tradeoffs, and refine the idea until they have a clear product intent.
I intentionally use the term product intent here because, at this stage, we should be defining the problem we want to solve and the outcome we are trying to achieve rather than prematurely locking ourselves into a detailed implementation.
Once that intent is clear, we are ready to bring the broader team into the next part of the development flow.
From Product Intent to Working Software: One Continuous Flow
This is where I think we need to be particularly careful not to recreate traditional waterfall development with AI tools attached to each phase.
If we define requirements, hand them over to engineering, wait for implementation, hand the result to testing, and eventually pass it to another group responsible for production readiness, we have not fundamentally changed the development process.
We may have accelerated some individual activities, but the organizational friction between them is still there.
Instead, I envision a small cross-functional team moving through a continuous development flow where the same people, the same AI workspace, and the same evolving context carry the work from product intent to production-ready software.
For the sake of discussion, I would break this into three steps, although I would not treat them as rigid phases or mandatory ceremonies.
Step 1: Turn Product Intent Into Detailed Product and Technical Requirements
Let’s assume our small team consists of product, UX, and software engineers who are familiar with the product and technology.
The team comes together with a clear product intent and uses AI, along with the foundational specifications, to turn that intent into a detailed understanding of what needs to be built.
AI can help break down the functionality, identify user journeys, propose technical approaches, map dependencies, define acceptance criteria, and generate the initial product and engineering requirements.
However, this is also where I believe the presence of knowledgeable product and engineering people becomes especially important.
AI may be able to generate a detailed breakdown quickly, but that does not mean the breakdown is correct.
The team needs to go through the proposed requirements carefully, challenge assumptions, correct misunderstandings, and make sure the decisions being made align with both the desired customer outcome and the realities of the technology.
I would not treat this as an exercise where AI produces a document and everyone simply approves it. It should be a collaborative working session where AI accelerates the thinking, but the people who understand the product and engineering environment remain responsible for the decisions.
A poor decision made at this point can create a compounding negative impact throughout the development effort. If the underlying requirements or architecture are wrong, generating code faster will only help us implement the wrong solution faster.
Depending on the complexity of the initiative, I can imagine this exercise taking a full day where the team works through the details and challenges each other until there is sufficient clarity to move forward.
That may sound like a significant investment for something AI can initially generate in minutes, but I believe the value comes from the quality of the understanding the team builds together.
At the end of this exercise, the team should have substantially more clarity about what it is building, why it is building it, and how it plans to approach the work.
This is also an opportunity to identify what can be delivered incrementally, where the biggest uncertainties exist, and which assumptions need to be validated first.
The output is not simply a document. It is shared understanding supported by specifications that AI can use in the next step.
Step 2: Build the Solution End to End Using AI
Now imagine that the team returns the next day and continues working in the same AI workspace, with the product and technical requirements already available and the foundational specifications still accessible.
Rather than starting from scratch or transferring knowledge to another group, the engineers can begin building the solution using spec-driven AI development.
When I say building, I mean building the functionality end to end.
We are not talking about generating only the frontend while leaving the backend for another team, or creating a collection of disconnected components that will eventually need to be integrated.
We are talking about developing the frontend, backend, APIs, integrations, data handling, and automated tests as one coordinated engineering effort.
The product person can remain available to answer questions, clarify behavior, and validate what is being built, while the engineers focus on moving the implementation forward.
The development process itself becomes a continuous cycle of generating, building, testing, reviewing, correcting, and improving.
AI generates code, the team validates it, automated tests expose problems, and the implementation is refined until the functionality behaves as expected.
Get Almir Mustafic’s stories in your inbox
Join Medium for free to get updates from this writer.
This is where concepts such as harness engineering and loop engineering become particularly useful.
Rather than treating AI as a tool that receives a prompt and returns code, we can create an environment where AI operates within clearly defined constraints, has access to the right tools and context, receives feedback from tests and other validation mechanisms, and can iterate toward a better implementation.
However, the team still needs to understand what is being built and remain accountable for the architectural decisions, security implications, system behavior, and quality of the resulting software.
Another important part of this process is improving the AI development environment itself.
If AI repeatedly makes the same incorrect assumptions, uses the wrong architectural patterns, or generates code that does not align with our engineering conventions, we should not simply keep correcting those mistakes manually.
We should determine whether the problem comes from missing specifications, unclear instructions, insufficient validation, or weaknesses in the development harness, and then improve the appropriate part of the system.
Over time, these improvements should reduce repeated mistakes and make future development work more effective.
For a relatively small and well-understood initiative, I can imagine this end-to-end building exercise taking somewhere between one and three days.
At the end of this step, the team could have a working solution that handles expected user journeys and negative cases, with automated tests providing confidence that the core functionality behaves as intended.
It may not yet be ready for production, but it is no longer just a prototype or a collection of disconnected features.
It is working software.
Could We Go From Intent to Working Software in a Week?
If we look at the first two steps together, it becomes interesting to consider what a small team might accomplish within a relatively short period of time.
Imagine spending approximately one day developing and validating the product and technical requirements, followed by a few days building and testing the functionality end to end.
For the right type of initiative, with a mature foundational specification repository and a well-designed AI development environment, it is reasonable to explore whether a small team could move from product intent to a functioning pre-production solution in approximately one week.
I am not suggesting that every product capability can or should be delivered within this timeframe, because complexity, dependencies, regulatory requirements, and the amount of uncertainty will vary significantly.
I am also not suggesting that speed alone is the measure of success.
What I find interesting is the possibility of reducing the time between understanding a problem and having real software that allows us to validate the proposed solution.
If AI can help us eliminate unnecessary implementation effort while keeping the right engineers involved in the important decisions, we can spend more time evaluating whether we are actually solving the customer’s problem.
That is a much more meaningful improvement than simply measuring how many lines of code AI generated.
Step 3: Turn Working Software Into Production-Ready Software
One area where I think we need to be particularly disciplined is recognizing the difference between software that works and software that is ready to operate reliably in production.
Just because AI can generate an end-to-end implementation quickly does not mean we should immediately expose that implementation to customers.
A working solution may successfully handle expected and negative user journeys while still having significant gaps in resilience, performance, security, observability, or operational readiness.
This third step is about taking the working implementation and making sure it meets the standards necessary for production.
The team should evaluate whether the system behaves correctly under load, handles downstream failures gracefully, manages retries and timeouts appropriately, protects customer information, and provides sufficient observability for engineers to understand what is happening when something goes wrong.
Depending on the product and industry, there may also be legal, regulatory, compliance, accessibility, and audit requirements that must be satisfied.
I would expect many of these requirements to already be represented in the foundational engineering specifications and incorporated into the AI development process from the beginning.
In fact, the more mature our engineering harness becomes, the more of these requirements should be validated continuously during Step 2 rather than discovered for the first time in Step 3.
The distinction between these steps is therefore not intended to create a new handoff. It is simply a way of recognizing that functional completeness and production readiness are not necessarily the same thing.
The same small team should remain responsible for both.
Over time, I would expect the boundary between building and productionizing software to become less visible as engineering organizations improve their specifications, automated validation, testing environments, and AI development practices.
That is the direction I believe we should be working toward.
Releasing to Production Should Be Part of the Flow
Once the team has sufficient confidence in the solution, the next activity is exposing it to real users in a controlled way.
Depending on the nature of the functionality, this might involve deploying it behind a feature flag, using a canary release, enabling it for a small percentage of customers, or initially making it available only to internal employees for early beta testing.
The objective is to reduce risk while creating opportunities to observe how the software behaves in a real production environment.
This also gives the team the ability to validate assumptions that cannot always be fully tested in development or staging environments.
AI can assist with release analysis, monitoring, troubleshooting, and identifying unexpected behavior, but the team still needs to understand the operational signals and make informed decisions about whether to continue, pause, or roll back the rollout.
I also think it is important that we view stabilization and customer learning as part of delivery rather than something that happens after the development team has moved on to the next project.
If we are serious about building software around customer outcomes, we need to remain engaged long enough to understand whether what we delivered is actually creating the intended value.
Shipping software is an important milestone, but it is not the ultimate objective.
What Does This Mean for Scrum and Our Existing Ceremonies?
This brings me back to one of the questions that motivated this entire discussion.
If AI changes how quickly a small team can move from product intent to working software, should we continue organizing the work through the same Scrum ceremonies and processes that were designed around a different development environment?
I am not suggesting that Scrum is inherently wrong or that organizations should immediately abandon every existing ceremony.
I am suggesting that we should be willing to question whether each activity still contributes meaningful value.
For example, if a small team can collaboratively turn a product intent into detailed requirements in one working session, followed by several days of building and validation, do we still need to approach backlog refinement and sprint planning in exactly the same way?
If the team is working closely together throughout the development effort, do we need a daily meeting where everyone reports what they did yesterday, what they will do today, and whether they have any blockers?
If AI can provide an accurate view of the state of the implementation, outstanding tests, known issues, and remaining work, could some of the traditional status-oriented activities become less necessary?
Perhaps the team would benefit more from short, focused conversations about decisions, risks, tradeoffs, and problems that require human collaboration.
Similarly, rather than treating a sprint review as a formal ceremony where the team demonstrates a collection of completed tickets, perhaps we should focus more on continuously validating working software with product stakeholders and customers.
I believe these are questions worth exploring, especially as AI reduces the effort involved in many of the activities that historically influenced how we organized engineering work.
There is still tremendous value in planning, coordination, retrospection, and making sure teams remain aligned. The question is whether we can accomplish those things in simpler and more effective ways.
We should not confuse the value of an activity with the ceremony we have traditionally used to accomplish it.
Keep the Teams Small and the Feedback Loops Short
Another important aspect of this approach is the size and composition of the team.
I believe AI creates an opportunity to rethink how many people and organizational layers are necessary to deliver a given product capability.
Historically, larger initiatives often involved multiple specialized teams with their own backlogs, planning cycles, priorities, and dependencies. Some of that specialization is necessary, particularly when dealing with complex platforms or highly specialized technical domains.
However, it is worth questioning how much of that structure exists because of genuine technical needs and how much exists because of the limitations of our traditional development processes.
If a small group of product, UX, and engineering people can use AI to collectively explore requirements, build functionality end to end, validate it, and release it, we may be able to reduce some of the coordination overhead that slows down larger organizations.
This does not mean everyone needs to become an expert in every technology, or that specialized engineering knowledge becomes less important.
Quite the opposite. I believe strong engineering fundamentals and deep subject matter expertise become even more valuable when AI is producing a larger portion of the implementation.
The people on the team need to be able to recognize when AI is making a poor decision, when an architectural assumption is incorrect, or when a solution introduces unnecessary complexity.
AI may reduce the amount of time we spend typing code, but it does not remove the need to understand the systems we are building.
I would rather see a small team of knowledgeable people working closely together, supported by capable AI tools, than a large organizational structure where work continuously moves between specialized groups and waits for the next handoff.
The goal should be to make the distance between an idea, a decision, an implementation, and customer feedback as short as reasonably possible.
We Should Be Improving the Development System, Not Just the Product
One of the more interesting opportunities in this AI-driven development model is that every initiative can improve not only the product but also the system we use to build the product.
When engineers discover missing context in the foundational specifications, they can improve that context.
When AI repeatedly generates an incorrect pattern, they can improve the instructions or validation rules.
When a particular category of defect escapes testing, they can strengthen the automated testing and feedback loops.
When an engineering decision requires clarification, they can capture that decision in a way that makes it reusable for future development.
Over time, the organization builds a continuously improving development environment that becomes more knowledgeable about its product, technology, and engineering practices.
This is where I see the real value of harness engineering and loop engineering. They should not become yet another set of buzzwords or standalone organizational initiatives. They should help us create a development environment that gets better through actual usage.
Of course, this only works if we remain disciplined about keeping the system simple.
It would be very easy to turn foundational specifications into an enormous documentation repository, create complicated dependency graphs that nobody understands, or introduce so many AI agents and validation steps that the development process becomes slower than the one we were trying to replace.
We need to continuously challenge whether every layer, tool, process, and piece of documentation is solving a real problem.
If it is not making the team more effective or improving the quality of what we deliver, we should question why it exists.
The Biggest Risk Is Standardizing Too Early
As organizations begin experimenting with AI-SDLC models, I expect we will see an increasing number of frameworks, process diagrams, recommended ceremonies, agent architectures, and standardized ways of working.
Some of these approaches will be valuable, and we should absolutely learn from what others are discovering.
However, I think there is a risk in trying to establish a rigid organizational standard while the technology and our understanding of how to use it are evolving so quickly.
What appears to be an effective practice today may become unnecessary six months from now because the underlying AI capabilities have improved or because we discover a simpler way of achieving the same outcome.
If we standardize too aggressively, we may end up institutionalizing practices that were only intended to help us navigate a temporary limitation.
I would rather see organizations establish a small number of important principles, such as maintaining clear product and engineering context, preserving engineering accountability, building in quality and security, and keeping teams closely connected to customer outcomes.
Within those principles, teams should have room to experiment with different AI tools, development harnesses, collaboration models, and ways of organizing their work.
We should measure whether those experiments are helping teams deliver better outcomes, not simply whether they are following a prescribed AI development methodology.
Once we have enough real experience to understand which approaches consistently work, standardization becomes more meaningful.
Even then, I would be careful not to standardize the process so tightly that teams lose the ability to improve it.
The Next Evolution of SDLC Should Be About Simplicity
When I think about where software development is heading, I do not see the biggest opportunity as simply generating more code in less time.
I see an opportunity to rethink how we organize the entire journey from product vision to customer value.
We can establish a shared foundation of product and engineering knowledge that gives AI the context it needs. We can bring small, cross-functional teams together to explore product intents and translate them into clear requirements. We can use spec-driven development and well-designed engineering harnesses to build and validate solutions end to end, and we can progressively release those solutions while learning from real customer usage.
More importantly, we can do all of this without necessarily introducing another complicated methodology or recreating the same organizational handoffs under different names.
I am not claiming that the three-step approach I described is the definitive AI-SDLC model, nor do I believe it should be adopted as a rigid framework.
It is simply one way of thinking about how we might take advantage of AI while remaining focused on the fundamentals of product development and software engineering.
I expect my own thinking on this subject will continue to evolve as I experiment with these tools, learn from what works, and discover approaches that are even simpler and more effective.
That is exactly why I believe we should resist the temptation to turn today’s AI development practices into permanent organizational structures.
The technology is changing quickly, and our methodologies should remain open to change as well.
We have spent decades trying to improve how software is developed, often introducing new frameworks and processes to address the limitations of the ones that came before them.
Perhaps the biggest opportunity AI gives us is not to create another methodology, but to remove some of the complexity we have accumulated along the way.
If we can make software development simpler, keep teams small, preserve the engineering fundamentals that matter, and shorten the path from an idea to customer value, I believe we will be moving in the right direction.
And maybe that is what the next evolution of the Software Development Life Cycle should really be about.
Thank you for reading this article. Keep geeking out!
Almir Mustafic
