Literally doing this now and seems to be working. Having a good idea of infrastructure is really beneficial. Spend most of your time planning with the agent, don't just start building. Work on the guardrails that control approvals for things like dependencies, private key management, what the agent will have access to vs what you will do, as well as the incremental development lifecycle etc. I spent weeks planning and making decisions with the agent, building out the feature roadmap, database schema, API, frontend and the guardrails. Now I can iterate through the roadmap items, make corrections along the way as issues occur, and leave the agent running for long periods of time overnight working on features while I sleep.
We're at the dawn of a new era at the moment and it's only going to get crazier. Existing professional developers with deep understanding of code will do really well if they embrace it. People with understanding of cloud infrastructure will be similar. And subject matter experts with an idea can create something really awesome - although these people the most will need help to ensure potential products are production ready. SME's who rush products without proper understanding of security are the most dangerous in my opinion.
My own guess would be that what matters most for the frontend is UX (and accessibility).
So if you are able to properly evaluate the outcome, it is probably fine.
It will also depend on the type of frontend and its target complexity. From what I understand from your question, you would handle the backend and infrastructure so these do need higher rigour.
If you apply the principle of separation of concerns, the frontend shall be decoupled from the rest and may evolve on its own end. That means that you have some degree of freedom to test and fail the frontend without harming the rest of your project.
Your end users may not like it much, but from a dev perspective, there is no "flaw".
Also consider that LLM training dataset and available data is huge about frontends, so it is way better at doing these.
Depending upon whether its a temporary change or recurring change or permanent one, I would say get comfortable with instant feedbacks/changes/enhancements, thinking from user's point of view (non-negotiable) and more frequent releases.
If you are supposed to stay on frontend for long, then it is critical that you learn DOM fundamentals, even propagation, caching, browser storage, layouts, etc.
Vibe coding is absolutely okay, just pace yourself to build only what is absolutely required (spend time on refining this) and don't get carried away too much with what claude can do.
Most likely it will work. It will also look very LLM-generated, “claudish”, and people will be able to tell that they are looking at the vibe-coded frontend.
Inside, there will be dragons: you will probably learn that all your CSS and JS are inline in your HTML, and that each page has its own implementation of the header and the footer, and other things like that, but if you don't plan to support it as a real product, you probably won't care.
Literally doing this now and seems to be working. Having a good idea of infrastructure is really beneficial. Spend most of your time planning with the agent, don't just start building. Work on the guardrails that control approvals for things like dependencies, private key management, what the agent will have access to vs what you will do, as well as the incremental development lifecycle etc. I spent weeks planning and making decisions with the agent, building out the feature roadmap, database schema, API, frontend and the guardrails. Now I can iterate through the roadmap items, make corrections along the way as issues occur, and leave the agent running for long periods of time overnight working on features while I sleep.
We're at the dawn of a new era at the moment and it's only going to get crazier. Existing professional developers with deep understanding of code will do really well if they embrace it. People with understanding of cloud infrastructure will be similar. And subject matter experts with an idea can create something really awesome - although these people the most will need help to ensure potential products are production ready. SME's who rush products without proper understanding of security are the most dangerous in my opinion.
[dead]
My own guess would be that what matters most for the frontend is UX (and accessibility).
So if you are able to properly evaluate the outcome, it is probably fine.
It will also depend on the type of frontend and its target complexity. From what I understand from your question, you would handle the backend and infrastructure so these do need higher rigour.
If you apply the principle of separation of concerns, the frontend shall be decoupled from the rest and may evolve on its own end. That means that you have some degree of freedom to test and fail the frontend without harming the rest of your project.
Your end users may not like it much, but from a dev perspective, there is no "flaw".
Also consider that LLM training dataset and available data is huge about frontends, so it is way better at doing these.
Depending upon whether its a temporary change or recurring change or permanent one, I would say get comfortable with instant feedbacks/changes/enhancements, thinking from user's point of view (non-negotiable) and more frequent releases.
If you are supposed to stay on frontend for long, then it is critical that you learn DOM fundamentals, even propagation, caching, browser storage, layouts, etc.
Vibe coding is absolutely okay, just pace yourself to build only what is absolutely required (spend time on refining this) and don't get carried away too much with what claude can do.
Most likely it will work. It will also look very LLM-generated, “claudish”, and people will be able to tell that they are looking at the vibe-coded frontend.
Inside, there will be dragons: you will probably learn that all your CSS and JS are inline in your HTML, and that each page has its own implementation of the header and the footer, and other things like that, but if you don't plan to support it as a real product, you probably won't care.
You can also guide the AI to organize the codebase according to some principles and attempt to untangle the mess.
But I totally agree on the fact that it will probably look like just any other frontend.