Traditional Software Development Lifecycle
Over the past decade, most mature engineering teams have converged on a shared understanding of what a well-run software development lifecycle should look like to build software that meets customer requirements, and is reliable, supportable, scalable, and secure.
The process usually starts with getting to a clear understanding of what should be built and why. That is where the Product Manager or Product Team comes in. This initial phase, often called product discovery, involves customer interviews to refine the problem, and may also include building Figma prototypes or a simple mocked UX to gather customer feedback. The output of this phase is a set of requirements for the engineering team.
Once there is confidence in the product direction, the team moves into a more structured flow. Requirements are written down in a way that engineering can act on, typically as a Product Requirements Document (PRD). Work is then broken into smaller pieces with clear acceptance criteria, often tracked as tickets in tools like Jira or Linear. At this point, engineering teams also start thinking about how the feature will be tested. What are the critical paths? Where are the edge cases? What would failure look like?
In parallel, the design team works on wireframes, some of which may have been used during product discovery, and evolves them into a more refined user experience and pixel-perfect UI. This ideally builds on an existing design system, which provides a centralized set of reusable components and standards.
Mature engineering organizations typically create an engineering design document at this stage. This document is reviewed by other engineers, and key technical decisions are recorded. The design also includes security and reliability considerations. This may involve building a lightweight threat model to think through how the system could be misused. Where does data enter the system? What are the trust boundaries? What happens if users try to access something they should not?
The team also defines a test and release strategy. Testing includes unit tests for core logic, integration tests for service interactions, and end-to-end tests for critical workflows. Smoke tests are defined to ensure that core functionality does not break with new changes.
During implementation, a well-run SDLC requires that every change goes through code review. A good reviewer looks at correctness, coding standards, security concerns, and scalability. These checks are often supported by automations run in the Continuous Integration (CI) pipeline. These include functional checks (typically unit tests) as well as Application Security (AppSec) checks: static analysis tools scan for common vulnerabilities, and dependency scanners flag outdated or insecure libraries on every change.
After code is merged into a designated branch for a release candidate, the release validation process includes running a broader set of automated tests along with manual exploratory testing. Performance testing may also be conducted at this stage. The goal is to validate that the release is ready for production.
Deployment is typically handled in a controlled manner. Techniques such as canary releases and feature flags allow teams to roll out changes gradually and limit the impact if something goes wrong.
Once the code is running in production, the operations/site reliability function, whether a dedicated team or a rotating responsibility within engineering, focuses on monitoring and alerting. This includes tracking error rates, latency, and overall system health.
The security counterpart to site reliability/operations, the Security Operations (SecOps) team, monitors production for unusual behavior such as repeated failed logins or unexpected access patterns. Periodic penetration testing may be conducted to simulate real-world attacks and uncover issues that automated tools might miss.
While this diagram gives the impression of a waterfall process, modern engineering teams run the process far more iteratively. Design and engineering are involved during discovery, security and QA planning starts at design time, QA runs alongside implementation, and deployment is a continuous capability rather than a discrete phase. Feedback loops exist at every stage.
Even with all of these feedback loops in place, shipping complex software changes still took weeks. AI-assisted development tools are compressing that cadence enough that the shape of the SDLC process itself starts to change.
How AI Will Change the Way We Build Software
The future is already here — it's just not evenly distributed. ~ William Gibson
The core structure of the SDLC described above does not go away: teams will still need to understand the problem, design a solution, build it, test it, and run it in production. What will change is the speed of iteration, the shape of the work, and the boundaries between roles.
Product: Faster Validation, Tighter Loops
The PM's job will move from writing detailed requirements to driving rapid validation.
Tools like v0, Lovable, and Bolt let product teams generate mockups and working prototypes in an afternoon without pulling in engineering. Perplexity accelerates competitive research and customer insight synthesis. Feedback cycles that used to take weeks will take days.
Requirements do not go away, but they get lighter. You still need a clear problem definition, success metrics, and the constraints that matter.
The risk is that faster prototyping gets mistaken for faster thinking. Compressing the discovery cycle is only valuable if the team is still asking the hard questions: whether the problem is real, whether the solution fits, whether the assumptions hold. Moving quickly through discovery without that discipline does not shorten the path to a good product. The teams getting this right use the faster tools to run more experiments, not fewer conversations.
Engineering: From Writing Code to Validating It
The development team is where this gets most disruptive. AI tools can generate large amounts of code quickly. This increases velocity, but it also increases the need for discipline. The role will shift from writing code to validating it. Less time spent generating implementations, more time spent thinking through correctness, edge cases, and system behavior.
In practice, this means using tools like Cursor, Claude Code, or GitHub Copilot to generate initial implementations, iterating quickly on small changes instead of writing everything from scratch, and spending more time reviewing logic, edge cases, and failure modes.
Best practices for AI-assisted development are still evolving. On one end, engineers are learning to be more deliberate in how they prompt, making assumptions and constraints explicit rather than leaving gaps for the model to fill. On the other end, more formal approaches are emerging. Spec-driven development treats a written spec defining inputs, outputs, and constraints as the primary artifact, with code following from it rather than the other way around. AI development platforms like Kiro are making spec-driven development more accessible: instead of starting from a blank page, you describe what you want in natural language, and Kiro generates a structured first pass at requirements, architecture, and an implementation plan. From there, engineers refine it into a spec they can actually build against. Another approach is to use contract testing, such as Pact. Contracts are defined upfront, and implementations are validated against them. When agents are writing code, this gives you a clear guardrail by shifting the focus away from reviewing every line toward verifying that the code satisfies the contract.
Regardless of the approach, the underlying principle is the same: define guardrails for AI-assisted development. When code can be generated in minutes, the scarce resource is not the implementation but the precise description of what it must do. Whether that means a formal spec, a contract, a test written before the code, or simply a more explicit prompt, the goal is the same: give the model something to execute against rather than gaps to fill.
Code review will matter more, not less, but the nature of it will change. Reviewers are running into a scaling problem. If an engineer can generate ten times more code in the same amount of time, the review load grows just as fast, but reviewer attention does not scale with it. Reviews risk becoming superficial, and a rubber-stamped review is worse than no review because it creates a false sense of safety. This is where a new class of AI-assisted code review tools is emerging. Tools like Optimal AI's Optibot, CodeRabbit, and Qodo sit inside the pull request flow, flagging breaking changes, risky patterns, and logic issues with awareness of the broader codebase rather than just the lines being changed. They bring context a human reviewer would need to go find manually: cross-repo dependencies, past decisions, related components. The reviewer still makes the call, but starts from a better position.
But tooling alone will not solve the underlying challenges. More of the safety net needs to shift toward things that scale automatically: tests that actually exercise behavior, complexity metrics that flag hard-to-reason-about code, and static analysis that catches entire classes of issues without human intervention. Code review will still matter, especially for architecture decisions and sensitive areas. But relying on it as the primary quality gate for the volume of code AI can produce is a shaky assumption.
Engineers will need to move up a level of abstraction: less time spent writing code, more time spent thinking through correctness and system behavior. Most engineering teams are still hiring, training, and structuring work for the old version of the job.
QA: From Gatekeeper to Continuous Validation
Because shipping velocity is higher, quality checks need to be stronger and more automated. QA teams already define test strategies early and build continuous regression coverage. What changes is that test generation itself gets automated.
Newer tools like Meticulous and Reflect are going further than traditional testing frameworks like Playwright and Cypress, automatically generating regression tests by observing how users actually interact with a product rather than requiring engineers to write every scenario by hand. The goal is coverage that keeps pace with the rate at which code is being produced.
QA will become less of a technical function and more of a product one. When test generation is largely automated, the value is no longer in writing and running tests. It is in knowing which edge cases matter, what a failure actually means for a user, and where automated coverage is likely to be shallow. That requires someone who deeply understands the product, not just the testing framework.
The role does not disappear, but teams that keep defining it around test execution will find it increasingly hard to justify.
Design: From Artifact Production to User Experience Decisions
AI tools are compressing the design function faster than most design teams have anticipated. Tools like v0 and Lovable mean that a PM or engineer can generate a working UI in an afternoon without a designer in the room. The prototyping phase, which used to be a core design deliverable, is now something almost anyone can produce.
So will we still need designers?
What these tools cannot reliably do is make good decisions about information hierarchy, user mental models, or accessibility. Those are judgment calls that require understanding users deeply.
If design is defined around producing artifacts, AI tooling will replace it. If it is defined around user experience decisions, skipping it shows up later as a product that feels incoherent.
The teams that get it right will use faster tooling to get to higher-fidelity feedback sooner, with design involved at the decision-making level rather than the artifact-production level.
Security: More Surface Area, Legacy Controls
Generated code can include insecure patterns, outdated libraries, and incorrect assumptions about authentication or data handling. These tools are built to produce working code, not necessarily safe code, and what used to surface over weeks of development can now appear in a single afternoon session.
The threat landscape is also moving faster. AI models are accelerating the pace at which vulnerabilities are discovered and exploited. They are already being used to analyze codebases and identify attack surfaces at a speed and scale that human security researchers cannot match, which means the window between a vulnerability being introduced and being exploited is shrinking. AI-driven attacks are becoming more sophisticated. Models are being used to craft more convincing phishing attempts and automate reconnaissance. They can also adapt to defenses at a pace manual attackers could not match.
Application security tooling has to evolve in response. Static analysis (SAST) has historically been pattern-based and signature-driven. Traditional tools like Semgrep and Snyk work well for known vulnerability classes but struggle with the context-dependent issues that AI-generated code tends to introduce. A newer class of AI-assisted security tools is emerging to fill that gap. Tools like Optimal AppSec Agent, Aikido, and Socket review pull requests and dependencies with broader codebase context, catching issues that pattern-based tools miss because they have no awareness of how the system fits together.
The same shift is happening in dynamic testing (DAST). Traditional tools like Burp Suite and ZAP run defined payloads against defined endpoints, relying on the human running them to interpret findings and chain them together. Newer AI-driven tools like XBOW and Pynt can reason about application context, generate targeted test cases based on what an endpoint actually does, and chain findings the way a human pen tester would. The category is earlier than AI-assisted SAST, but evolving along the same path.
The tooling shift alone does not address the broader problem. Shipping velocity and manual security processes are on a collision course. AppSec and SecOps will need to be largely automated. The focus will shift to designing the right controls upfront rather than auditing after the fact.
AI agents also introduce a threat vector that the traditional SDLC did not have to account for. When an agent can read files, execute commands, and operate with some autonomy, the questions around access control, least privilege, and trust boundaries become significantly more complicated. What can the agent modify? What happens if it is manipulated through a prompt injection in a file it is asked to process? Most teams do not yet have good answers, and the industry is still working out what the right patterns even look like. How you scope agent permissions, how you defend against prompt injection, how you audit what an agent actually did: these are open problems, and the conventions that will eventually govern them are still being written.
Threat modeling at the design stage and penetration testing in production still matter. But as shipping velocity increases, any manual process sitting in between becomes a bottleneck.
The Faster Horses Are Here
If I had asked people what they wanted, they would have said faster horses. ~ Henry Ford (allegedly)
Cursor, v0, Lovable, Claude Code: each of these tools compress steps that used to take days into hours. But they fit into the existing models: the engineer still writes and reviews code, the product manager still owns the requirements, and the QA engineer still runs tests. The roles are intact (for now); the work just moves faster.
The open question is whether what comes next is an even faster horse, or something else entirely.