Would this be considered as bad, cowboy coding, anti-pattern.

Short answer: no. Doing “agile” correctly does not mean “no planning”, it does mean not to overanalyse things.

one of the major reasons why Agile is used is because clients often change the requirements.

That’s an oversimplifying statement. “Changing requirements” is also about how the team’s understanding of the requirements change. And it is about how the customer’s priorities about the requirement change when he actually sees a few releases of the software.

In fact, “agile” works IMHO best exactly in the situation you describe – the client has a good knowledge about his overall requirements, you can write a general plan from it, fill your backlog with lots of “user stories”, and have already enough information to choose the right system architecture. The short iterations of an agile development strategy then will help to make the “vague requirements” more precise, with lots of feedback if you are still going into the right direction. It will also give you early feedback about the real effort and costs (which is something you can still fail in a waterfall approach, even if you know every single bit of requirement in detail).

Using agile in this situation is still a very good idea. There are many benefits to agile, only one of which is regular feedback from the customer and the ability to respond to changing requirements as you mention.

One of the main reason waterfall projects are notorious for failure is the ‘nearly done’ problem – testing produced piles of bugs at the end, leaving an unreleasable product and no idea whether it needs another two days or two years to fix the outstanding bugs. Agile removes this risk entirely. If an agile project is over-running, you can still deliver a working version which:

A) Proves to the customer you are actually nearly there through demo’s (“All these stories are done, we can do the last few if you want”) and some more time will get exactly what they want.

B) Potentially is good enough for them to be happy anyway and release.

To me, removing this risk of complete failure is enough reason alone for a business to move to an agile development process, the ability to build better software than initially planned is icing on the cake. As mentioned in other answers, those ‘concrete’ requirements are often still surprisingly malleable.

Agile is ideal if you need a frequent feedback loop with the client. This can be because the requirements change frequently, but it could also be for other reasons.

On the other hand, Agile can work equally well if the requirements are fully stable and the client expects only a single big-bang delivery, but you might have to adapt things a bit for the amount of involvement that the client expects to have during the project. This means that the Product Owner role must be filled from within your own organization and that person must have enough mandate from the customer to make decisions.

You can always split the big release into smaller releases(sprints) and ask your client for feedback. This way you are sure that you’re doing the right thing and the client can keep track of your progress.

If there is something wrong, you can offer your client the chance to correct you sooner, which is very good. It is better to correct your mistakes as soon as possible, rather than show him a bullshit at the end and try to fix it when you don’t even know where to start.