Agile and RDD
Agile wanted working software early. AI changes how early early can be.
RDD is not an argument that Agile failed. It is an argument that implementation economics changed enough to move more learning before production commitment.
Agile made learning part of delivery
Agile correctly pushed teams toward working software, shorter feedback cycles, customer collaboration, and adaptation. RDD depends on that inheritance. It would be unserious to pretend those ideas are new.
The constraint was not philosophical. It was economic. Substantial implementation still carried enough cost that many commitments had to be made before stakeholders had experienced broad product behavior.
RDD moves learning earlier when feasible
AI makes it increasingly feasible to put a broad working model in front of people before the full production delivery machine starts. That does not eliminate Agile delivery. It changes what delivery receives.
The question becomes: if stakeholders can operate a realistic model before the project is industrialized, how much scope, estimation, and commitment should be based on that shared experience rather than interpreted documents alone?
The respectful distinction
Agile improves learning during delivery. RDD asks what can be learned before delivery starts, while change is still cheap and nobody has promised production.
That is a process implication of changed implementation economics, not a vocabulary replacement for Scrum, XP, product discovery, or dual-track Agile.
Working software validates and improves increments after delivery has begun.
Candidate reality exposes consequential scope and behavior before production work hardens.
RDD does not claim Agile failed, that all discovery should move upfront, or that prototypes remove the need for disciplined delivery.