In general, I agree with you. No methodology is a silver bullet that will magically transform a bunch of mediocre people into a tight, intelligent productive team. In fact, I would go so far as to say that most methodologies exist to mitigate the effects of the mediocre. A really good team of people can produce great code no matter what methodology is presented to them (even if they have to work around bits of it sometimes).
I successfully introduced Agile development into my last organisation, which was very much a traditional waterfall style, make-promises-we-can't-keep-but-at-least-there's-a-plan sort of place. We adapted the methodology to fit the organisation to some extent (mostly scrum, with a bit of kanban thrown in, and interfacing it all with traditional Gant chart people). It worked pretty well - mostly because the people we had were really committed to making it work, and I worked double-time on getting the organisation on board, particularly inviting them to sprint-reviews. It created a buzz - and the organisation was sold on it - which helped a lot.
In my new role in a much smaller organisation, I'm not so sure it will work as well - so I'm holding off a bit until I get the measure of the place. I have really talented developers - but communication and visibility is not a big issue due to the small size of the place, and people tend to work individually on tiny projects rather than collaborate as a team on small bits of shared functionality.
Anyway, Agile won't make mediocre people great, and Waterfall won't make great people mediocre. There are advantages and disadvantages to each style of development. The one thing you really do need to make great code is at least a few great (or at least, highly committed) people.