Vibe Coding the Frontend: What to Keep in Mind for the UI

The short answer: the frontend is where a vibe-coded app leaks what it shouldn't and lags when it should feel instant. Agents ship secrets into the browser bundle (everything there is public), reach for heavy libraries without a thought for load time, skip accessibility entirely, and treat client validation as if it were security. The fixes are cheap and the same every time: keep secrets server-side, hold a bundle budget, make it keyboard- and screen-reader-usable, and remember the browser is never a trust boundary.

The frontend feels like the safe, cosmetic part — it's "just the UI." That framing is exactly why agents (and the humans accepting their output) let real problems through here. Your UI is also a public distribution of everything in its bundle and the only thing many of your users can actually operate. Treat it with the same seriousness as the backend.

1. Everything in the bundle is public — act like it

The number-one frontend security mistake in vibe-coded apps: shipping a secret to the browser. The agent sees an API call, grabs the key, and puts it in the frontend because that's where the call lives. But the browser bundle is downloaded, in full, by every visitor — including the attacker. There is no "hidden" frontend code.

Only publishable keys (the ones designed to be public) belong in the frontend. Everything else — secret keys, business logic you don't want copied, anything that grants privileges — goes behind a server route the browser calls. This connects directly to the security and networking precautions: the client is the attacker's playground.

2. Hold a bundle budget — agents don't

Ask an agent for a date picker and it may pull in a library that drags a whole moment-of-time dependency tree with it. Ask for an animation and you might get a heavy library for a fade that CSS does for free. Every dependency is bytes the user downloads, parses, and runs before your page is usable — and on a mid-range phone on bad wifi, that's the difference between "instant" and "gave up."

The discipline:

• Audit what you actually ship. Run a bundle analysis; be surprised; cut.
• Lazy-load the heavy stuff. A charting library, a rich-text editor, a 3D scene — dynamically import them so they load only when that feature is used, not on first paint.
• Prefer the platform. Modern CSS, the native <dialog>, Intl for formatting — a lot of what agents reach for a library to do, the browser now does natively and for zero bytes.
• Set a CI budget that fails the build when the main bundle crosses a threshold.

This is the same measure-and-cut approach I detail in shaving 35% off a React bundle, and the whole-page version lives in turning a red Lighthouse score green. The metric that actually matters is field data — Core Web Vitals: the numbers that move the needle — measured at the 75th percentile of real users, not your fast laptop.

3. Accessibility is not optional — and agents skip it

Left to its own defaults, an agent builds a <div onClick> instead of a <button>, forgets labels on inputs, uses color as the only signal, and never considers keyboard or screen-reader users. That's not an edge case — it's a chunk of your users locked out, and in many contexts a legal obligation.

The baseline to check on anything the agent generated:

• Semantic HTML — real <button>, <a>, <nav>, <label>. A clickable <div> isn't focusable or announced.
• Keyboard operability — every interaction works without a mouse, and the focus order is sane.
• Labels on every input, alt text on meaningful images, and color never the only way to convey state.
• Visible focus states — don't strip the outline without replacing it.
• Respect prefers-reduced-motion — the flashy animation the agent added should calm down when the user asked it to.

I make the full case for why this is just good engineering in accessibility is not a nice-to-have, it's the job. The short version: accessible design is good design with the edge cases taken seriously, and the edge cases are where products hold up or fall apart.

4. Client validation is UX, not security

Worth repeating because it's a frontend framing of a backend truth: the validation on your form is there to help honest users fix typos. It stops exactly nobody determined. Keep it — good UX — but never let it stand in for the server-side check. Every rule that protects your data or your system is enforced again on the server, because the frontend is fully under the user's control.

The one-pass frontend checklist

• [ ] No secrets or private keys in the bundle; only publishable keys client-side; real calls proxied through your server
• [ ] Bundle audited; heavy libraries lazy-loaded; a CI size budget in place
• [ ] Core Web Vitals measured on real devices at p75 (LCP, INP, CLS)
• [ ] Images optimized and correctly sized (no layout shift)
• [ ] Semantic HTML, keyboard operable, labels + alt text, visible focus, prefers-reduced-motion respected
• [ ] Client validation present for UX but every real check duplicated server-side

Use agents and skills deliberately

• A performance-optimization skill pointed at the bundle and render path — ask it to find the heavy imports and the components re-rendering on every keystroke.
• A security-and-hardening skill to confirm nothing sensitive is shipping to the browser and that API calls are proxied, not direct.
• An accessibility audit pass (axe-style tooling, or an agent instructed specifically to check semantics, keyboard, labels, and contrast) — because "it looks right" and "it's usable by everyone" are different claims.

The through-line of the whole vibe-coding series applies hardest here: the agent builds a UI that looks finished, and "looks finished" hides whether it's fast, safe, and usable. Point specialized agents at those three questions, run the checklist, and your frontend earns the polish the demo only pretended to have.

This is one of four vibe-coding deep-dives alongside architecture by user scale, choosing a backend, and security and networking — all gathered in the vibe-coding precautions overview.