It is only when I write the first test and the first function that I start noticing the structure and the limitations
To an extent, you can do this with “the vibe” as well, you just have to stay engaged, do lots of reviews (by which I mean, have the LLM review for you and explain what it finds) and when you decide the architecture needs to be revised, do it - in writing. Your requirements and architecture should be “living documents” developed at least a little bit ahead of the code implementation, and if the current implementation is too far removed from your current vision of how things should fit, throw it out and re-implement from the requirements and revised architecture documents. That’s one huge benefit of a tool that writes code so quickly, it’s much less costly to throw it all out and start over.
To an extent, you can do this with “the vibe” as well, you just have to stay engaged, do lots of reviews (by which I mean, have the LLM review for you and explain what it finds) and when you decide the architecture needs to be revised, do it - in writing. Your requirements and architecture should be “living documents” developed at least a little bit ahead of the code implementation, and if the current implementation is too far removed from your current vision of how things should fit, throw it out and re-implement from the requirements and revised architecture documents. That’s one huge benefit of a tool that writes code so quickly, it’s much less costly to throw it all out and start over.