No, it's worse. An up-front design is sometimes necessary and valuable, in both agile or waterfall projects, but it always carries a risk of including mistakes

No, it's worse. An up-front design is sometimes necessary and valuable, in both agile or waterfall projects, but it always carries a risk of including mistakes or mistaken assumptions that result in dangerous flaws. When such a flaw is discovered, especially late in the project, it is often very expensive and difficult to fix, because it has become foundational to the solution. This is true regardless of whether an waterfall or agile process has been adopted, and there will often be significant pressure to implement a hacky fix, instead of the truly correct one. Where agile differs from waterfall is that it does, at least, philosophically accept that nothing is set in stone, even at a late stage. Discussions regarding how to address a flaw can then proceed on a basis of cost vs. risk vs. difficulty, and a hopefully rational choice can be made. In contrast, the rigidity of the waterfall process is frequently used as a bureaucratic weapon to prevent these discussions from even happening. Decisions made in the project's initial stages are held to be settled and unalterable, and those seeking to overturn them usually have to fight a horrendous, uphill battle to do so, even when they're in the right. I would liken the difference between design in agile and waterfall to that of scientific theory vs religious dogma. Neither necessarily has a monopoly on truth: A theory might be mistaken while dogma, by chance, might be correct. And challenging well-established scientific theory can, in practice, be almost as difficult and painful as disputing dogma. But science at least accepts the possibility of change, however hard it may be.