You have a team of developers who typically write code at the rate of 1000 lines/week (okay, I know lines of code is a terrible way to measure productivity, but humour me). They're big on XP and evolutionary design, so they reject any up-front design, but spend 50% of their time redesigning existing code.
At the end of week 1 their application is 1000 lines (no existing code to be refactored).
At the end of week 2 their application has 500 extra lines (1500 total), plus 500 lines of existing code (1000 lines) has been refactored (50%)
At the end of week 3 their application has 500 extra lines (2000 total), plus 500 lines of existing code (1500 lines) has been refactored (33%)
...etc...
At the end of week 25 their application has 500 extra lines (13000 total), plus 500 lines of existing code (12500 lines) has been refactored (3%)
This is the big challenge with emergent design. As time passes you rapidly lose your ability to make major changes to it.
This doesn't mean emergent design is a bad idea, just that it needs to be balanced with up-front design. I've met people in the agile community who have an almost religious hatred of anything with 'up-front' in the title. To believe that 100% of a design can emerge is just as naive as to believe that 100% of a design really can be specified in advance.