For twenty years, Agile won because coding was scarce. Teams iterated, let requirements change, and found the product while they built it. That was the right bet when the slow part of delivery was a developer at a keyboard.

AI changed what is scarce. The tools write, refactor, and document faster than any team can by typing harder. Output quality follows input quality. Hand an assistant a complete brief — context, requirements, architecture, acceptance criteria, and the business objective — and it works like the fastest developer you will hire. Hand it a vague ticket, and it produces vague code, only sooner.

Planning is back. Not the eighteen-month plan and the binder. The part of Waterfall that was always worth keeping, done before the first prompt goes out.

The bottleneck moved

The speed data is hard to ignore, and it points at the same place.

  • GitHub's controlled Copilot study found developers using the assistant finished a coding task 55% faster than the group working without it.
  • McKinsey found generative AI can help developers complete common engineering tasks up to twice as fast. In that research, documentation took about half the time, new code a little more than half, and refactoring about two-thirds of the usual time.

Those gains show up when the task is already understood. On complex work, the same research shows the advantage shrinks when the problem itself is unclear. AI does not replace the brief. It sends the bill for skipping one.

The limit is no longer how fast someone can type. It is whether the organization can define the work:

  • Requirements that say what done means
  • An architecture someone can draw
  • Dependencies mapped before the build
  • Business rules written down
  • Specifications an engineer, or a model, can execute without guessing

The engineering leaders getting the most from AI are not managing coding velocity. They are managing context quality.

Waterfall for the thinking. Agile for the build.

Traditional Waterfall still fails the test that matters. The market moves faster than a frozen plan. What deserves a second look is the discipline Waterfall refused to skip: detailed requirements, a real system design, documentation someone else can use, and a plan made before execution starts.

Calling one camp good and the other bad made sense when developer capacity was the constraint. It is a weak operating model now. The enterprises I work with need the structure of Waterfall and the tempo of Agile, in that order. I call the combination Watergile.

Waterfall for thinking

Before development starts, the direction is explicit:

  • Business objectives are defined
  • Architecture is planned
  • Security requirements are documented
  • Integration points are mapped
  • Success metrics are agreed
  • The specifications and prompts the team will actually use are prepared

Agile for execution

Once that direction is clear, delivery stays fast:

  • AI accelerates the coding
  • Teams iterate in short cycles
  • Features are tested continuously
  • Feedback stays close to the work
  • Priorities can still move when the business learns something new

Less rework. Less accidental technical debt. A faster path to the thing you meant to ship.

The question a CTO should ask now

The old question was how fast the developers can code. The new question is how clearly the organization can define what needs to be built.

AI turned a large share of software delivery into a planning problem. A team that simply turns on more tools will not beat a team that shows up with a sharper definition of the problem. Strong planning. Rapid execution. AI in the middle. That is Watergile, and it is where technology leadership is heading.

If you want that planning standard and the production discipline in one engagement, book a strategy call. Shipping AI in Production picks up the next step: how the feature stays reliable once the brief is good enough to run.