Last week, I was talking with a colleague about how AI is changing software development and what that means for people entering the field. We’re both fairly deep into our careers and have our own perspectives on development processes. He’s a seasoned agile practitioner, and he wondered aloud whether the skills he’s spent years developing will be as relevant to the next generation of software developers.
My own experience goes back to the days when waterfall was still common, particularly in the Department of Defense acquisition process. That process evolved primarily around the procurement of physical systems such as ships, aircraft, and weapons platforms, and software development had to fit within it. I spent more hours than I care to count in requirements meetings, working through business rules, exceptions, dependencies, and everything else that needed to be settled before implementation.
Those meetings involved plenty of iteration, despite the way waterfall is often characterized today. We didn’t walk into a room, write down a set of requirements, and hand them off to developers. Requirements were negotiated, challenged, revised, and sometimes discarded. Stakeholders frequently disagreed about what they wanted, and resolving those disagreements was part of the work. The objective was to arrive at a sufficiently complete understanding of what we intended to build before committing substantial resources to building it. The acquisition process also imposed its own documentation, review, and approval requirements, which didn’t always make the work more efficient.
There were good reasons for doing much of that work upfront. Writing software was expensive, and changing it after substantial implementation could be considerably more expensive. The farther the result deviated from what was needed, the more work it generally took to correct. A requirements problem discovered during development could affect architecture, interfaces, databases, testing, and anything else that depended on the original assumption.
Agile emerged partly in response to those economics. Teams could build in smaller increments and obtain feedback while there was still time to change direction. Working software became a way to discover requirements as well as satisfy them. That emphasis was formalized in the Agile Manifesto, although the history is more complicated than the usual waterfall-versus-agile narrative suggests. As Craig Larman and Victor Basili documented in 2003, iterative and incremental software development practices long predated agile.
It was a reasonable response to a real problem, although I wonder whether we’ve adequately considered the costs of the processes that replaced waterfall. Agile, particularly as implemented through Scrum and scaled frameworks, brought its own administrative structure. Sprint planning, backlog refinement, estimation, standups, reviews, retrospectives, and the coordination required to keep multiple teams aligned all consume time. In some organizations, managing development became a substantial activity in its own right. Research on large-scale agile transformations has documented many of these coordination challenges.
It’s difficult to establish whether the savings from reduced rework consistently exceeded those costs. The research on agile’s effectiveness is more mixed and methodologically limited than its widespread adoption might suggest. A study of 1,002 projects by Serrador and Pinto found positive associations between agile adoption, project efficiency, and stakeholder satisfaction. The study relied on self-reported, cross-sectional data, however, and couldn’t establish how much of the benefit came from different aspects of the development process.
I’ve long suspected that a meaningful share of agile’s perceived success came from getting users more involved in development. That’s valuable, but stakeholder participation isn’t exclusive to agile. We had plenty of it in those old requirements meetings, even if the process wasn’t always particularly pleasant. Whether the recurring governance of agile delivers enough additional value to justify its costs is a question worth asking.
AI may make that question more pertinent. One of the more visible effects of AI-assisted development is that producing code for certain kinds of tasks has become much less expensive, though the evidence isn’t uniform. A controlled study involving GitHub Copilot found that developers completed a bounded programming task 55.8% faster with AI assistance. Subsequent research across three enterprise development environments found an average 26% increase in completed tasks. A 2025 study by METR, on the other hand, found that experienced developers working in familiar, mature codebases took 19% longer when using AI tools. Those developers nevertheless believed AI had made them faster. There’s enough evidence to conclude that AI can improve implementation productivity, although the gains vary considerably depending on the work and the people doing it.
There’s also the matter of what happens after the code is generated. A 2026 study of Cursor adoption in open-source projects found short-term increases in development activity alongside persistent increases in code complexity and static-analysis warnings. Google’s 2025 DORA report found that increased AI adoption was associated with higher delivery throughput but lower delivery stability. Generating more code more quickly doesn’t necessarily produce better software, and it may leave more work for the people responsible for maintaining it.
These findings suggest an interesting change in the economics of software development. For some kinds of projects, producing code may no longer be the dominant constraint. Understanding what the software needs to do, expressing that understanding precisely, and verifying that the implementation meets those expectations become relatively more important. Those activities have always mattered, but their relative costs are changing.
AI also makes it easier to explore requirements before committing to production implementation. Working prototypes can be generated quickly. Alternative designs can be compared, and acceptance criteria can be developed and checked for consistency. Stakeholders can examine something tangible without requiring a development team to spend weeks building every alternative. Research on generative AI in requirements engineering is beginning to examine these capabilities, although the empirical evidence is less mature than the research on coding productivity.
I wouldn’t underestimate the human effort involved. AI can help clarify a requirement, but it can’t necessarily resolve disagreement about the requirement itself. An organization still has to decide what it wants, reconcile competing priorities, and accept responsibility for those decisions. In my experience, those were frequently the most time-consuming parts of requirements development anyway.
Still, suppose we can use AI to conduct much more extensive requirements analysis, prototyping, and validation before beginning production implementation. That process could produce a coherent specification against which AI generates software and automated tests verify the result. Some implementation might still be incremental, but a much larger share of the requirements work would occur before construction.
That sounds like waterfall to me. I’m not particularly interested in debating the terminology. We could call it specification-driven development or something else. If the process involves developing and validating requirements, producing a specification, implementing against it, and verifying the result, most people will recognize the resemblance. If it walks like a duck and quacks like a duck…
More importantly, comprehensive upfront specification doesn’t mean every aspect of implementation must be sequential. A system can be specified as a whole and still be built, tested, and deployed incrementally. The question is where it makes economic sense to concentrate requirements discovery and validation.
Which brings me back to the conversation with my colleague. For the past couple of decades, developers have been encouraged to become proficient in agile development practices. Those practices include valuable skills in collaboration, incremental problem-solving, and adapting to changing requirements. I don’t expect those abilities to become irrelevant.
I do wonder about the administrative and procedural skills associated with managing iterative implementation. If implementation requires less time and coordination, knowing how to conduct sprint planning or estimate a backlog may matter less than knowing how to evaluate requirements, recognize architectural consequences, formulate meaningful acceptance criteria, and identify when generated software is wrong.
There’s also a question about how younger developers acquire that expertise. Historically, developers learned a great deal about systems by implementing them. They encountered edge cases, discovered inconsistencies in requirements, and learned how design decisions affected subsequent work. Some of that knowledge came from spending time debugging code that didn’t behave as expected. If AI increasingly handles implementation, we need to consider how developers will gain the experience required to make sound decisions about what gets implemented.
This is an aspect of AI-assisted development that I think deserves more attention. We talk a great deal about how much more productive developers might become, but relatively little about how someone becomes an experienced developer when much of the work that traditionally produced that experience is automated.
I wouldn’t particularly want to repeat those old requirements meetings. Some were productive, others were borderline painful, but we were trying to understand what needed to be built before spending considerable time and money building it. Agile changed where much of that effort occurred, and for understandable reasons. AI may change the calculation again.
I don’t know whether waterfall will return or whether we’ll develop another set of practices that happen to resemble it. My colleague’s question about the future value of his agile expertise may be a useful starting point for thinking about what comes next. Understanding what software should do has always been important, but it was often easy to get stuck in “how” and lose sight of “why.” If the production of software becomes less of a constraint, then maybe it will be easier to remain focused on the purpose of the software.
Header image: Ragesoss, CC BY 3.0 https://creativecommons.org/licenses/by/3.0, via Wikimedia Commons
