Ask HN: Is Vibe coding the frontend okay for someone who is expert in DevOps? | Hacker News Reader

Ask HN: Is Vibe coding the frontend okay for someone who is expert in DevOps?

3 pointsskwasimin6 comments

That's so crucial for me. I'm learning more about DevOps so I want to know whether I have to deeply learn frontend too or not.

View on HN

The failure mode a sibling comment names - "it will look LLM-generated" - is a design problem, not a coding problem, and the model cannot fix it for you because you are not yet able to evaluate the output. The cheap way around that is to not generate the design at all. Start from an existing template or a component library with sane defaults (Material UI, shadcn, Tailwind UI - pick one and commit) and have the model fill it in. Constrained generation looks far less generic than open-ended generation.

Concretely, I would learn three things properly and vibe the rest:

- flex and grid, well enough to look at a broken layout and say why it broke. That is a weekend, and it is the difference between fixing a bug and re-prompting until it disappears. - the devtools element inspector. You already debug systems; this is the same muscle. - basic accessibility: labels on inputs, visible focus states, contrast. Models are inconsistent here and it is the part that gets flagged in review.

I maintain a free React/Material-UI portfolio template (https://github.com/p32929/portfolio-v2), and the reason people fork it is not the code, it is that they do not have to make any design decisions. Same principle scales up: borrow the design, generate the wiring, own the layout debugging.

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.

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.

Reply on news.ycombinator.com