Ha ha, may be that came out a bit wrong. What I meant is I don’t have a complete understanding of the architecture and the structure before I start coding. It is only when I write the first test and the first function that I start noticing the structure and the limitations. I can’t think of all the branches where the code might fail unless I start writing and realizing the elses.
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.
Ha ha, may be that came out a bit wrong. What I meant is I don’t have a complete understanding of the architecture and the structure before I start coding. It is only when I write the first test and the first function that I start noticing the structure and the limitations. I can’t think of all the branches where the code might fail unless I start writing and realizing the
elses.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.
This is the mark of a good engineer, don’t let anyone neg you for engaging with problems with your whole brain.