Agile software development is supposed to help manage changes in project requirements mid-way through development (amongst other things). In fact, the second point in the principles behind the Agile manifesto states:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
But it seems like Agile methodologies often get misused to justify the lack of up-front planning and design by cowboy coders. I've been guilty of that too at times.
Even though Agile development is supposed to be able to handle changes in requirements, such changes aren't free (in project-delay costs). Even in Agile development, a change in requirements can cause a re-writing of certain parts of the code-base. In that respect, I don't agree with the "Welcome changing requirements.." part of the principles behind the Agile manifesto.
Changes in requirements should be avoided even in Agile development. If a change occurs because a hypothesis about the behaviour of the users was incorrect, that change is unavoidable and should be made. But if a change occurs because people didn't think through the feature they were trying to implement, that change causes an un-necessary penalty that could have been avoided.
Just because one purchased a car insurance doesn't mean they should drive wrecklessly. And just because one follows "Agile" software development doesn't mean they shouldn't try to minimize changes in requirements.