So far, I mostly see people trying to use vibecoding to clone existing applications. To avoid paying for external apps or to be able to have their own personal version of such apps.
But many of such efforts fail as people only replicate what they see. And this is much less than what they believe. They only see a partial view on the app behaviour. But not how this was implemented. Or why.
And even for the “what” they see, they only have a limited perspective informed by the way they use the app. They can “poke” the app with some inputs and see the outputs and use that as a kind of results table the vibe coding agent could use as tests. But there are many more possible inputs they can’t even imagine, as they do not correspond to the typical way they use the app. As of today. As this can change in the future, when that future arrives, they won’t be able to check what the original app was returning then.
Nevertheless, as Hanna Siemaszko pointed out in our LinkedIn discussion on this topic, this exercise would be very useful as a teaching exercise for new CS students. It would be a good exercise to tell students to clone an app and then highlight all the corner cases, security issues,… their clone is unable to handle compared to the original one. And explain them and implement together a step-by-step evolution of the initial clone until it becomes a real match of the original app.