When Andrej Karpathy first used the phrase vibe coding in early 2025 to describe the practice of describing what you want to an AI model and accepting whatever it gives you, the framing was half-ironic. The original tweet treated the workflow as a recreational experiment, something a senior engineer might do on a weekend project, not a serious method for production work. Eighteen months on, the irony has thinned. Vibe coding has become a recognisable, sometimes dominant, mode of how new code is being produced in the JavaScript and CSS ecosystem in 2026.

This is not the usual breathless framing. The mode has limits, some of them severe. But the limits are not where the early sceptics said they would be, and the working practices that have emerged are worth understanding even if you have no intention of adopting them in their pure form.

This is a frontend engineer's view of where vibe coding actually works in 2026, where it falls over, and what the productive integration looks like for someone who still cares about how their CSS audits read.

What vibe coding actually is in practice

The simplest version of the practice is this. The developer opens a chat panel inside their editor, describes the component or screen they want to build in natural language, and accepts the generated code with light review. The developer may iterate by asking for changes, but they do not, in the pure form of the workflow, study the generated code line by line. They run it. They look at the result. They iterate.

The tools that have made this mainstream are familiar. v0.dev from Vercel for component-level UI generation. Cursor as the canonical AI-native IDE. Claude Code as the terminal-based agentic option for larger refactors. Lovable and Bolt for end-to-end app scaffolding. The list is longer than this and changes monthly, but these are the surfaces where the practice happens in 2026.

What is interesting about the workflow is not the existence of code generation. That has been around for a decade. What is interesting is the interaction model. The developer is no longer producing code. They are producing prompts and reviewing outcomes. The cognitive shape of the work has changed, and the practical consequences of that shift are now visible in actual codebases.

Where vibe coding genuinely works

Three categories of frontend work have absorbed AI generation almost completely in production teams.

The first is boilerplate and scaffolding. New route in Next.js, new page in Astro, new component shell with prop types, new form with field validation. These are tasks where the destination is well-understood and the cost of a slightly imperfect first draft is low. The AI tools produce the scaffold faster than typing, and the developer's role is to verify that the scaffold matches the intended shape. Almost no productive frontend team in 2026 still hand-types this category.

The second is CSS for routine layouts. A two-column responsive grid, a hero section with centred text, a card with a hover state. The AI tools produce serviceable, sometimes elegant, CSS for these patterns. The output is usually adequate to ship and frequently better than what a mid-level developer would write under time pressure. Where the tools fall down is on non-routine CSS, and we will come back to that.

The third is content-only components. Marketing pages, documentation layouts, blog templates. The combination of text, basic typography, layout primitives and predictable interaction patterns sits well inside the model's competence. The same component built three times across three tools will produce three roughly equivalent results.

In each of these categories, the gain in developer time is real and measurable. The teams that have integrated the workflow cleanly are shipping the same volume of UI work with meaningfully fewer engineering hours.

Where it breaks badly

Five categories of work resist vibe coding more strongly than the discourse acknowledges.

The first is accessibility. AI-generated components have improved noticeably over the past year, but the median output still ships without proper ARIA labelling, focus management or keyboard navigation. The developer who accepts the generated code without auditing the accessibility layer is shipping a regression that the tooling did not warn them about. Stylestats-style audits across hundreds of recently shipped sites in 2026 show accessibility metrics on average lower for projects that lean heavily on AI generation than for projects that do not, even controlling for project size and team experience.

The second is state management and data flow. The AI tools produce convincing-looking React or Vue components in isolation, but the wiring between components, the management of shared state, the handling of optimistic updates and the integration with server actions is where the generated code most frequently introduces subtle bugs. The bugs are not catastrophic. They are exactly the kind of state-related glitch that takes three hours to find and ten minutes to fix.

The third is animation and motion design. Sophisticated motion, the kind that defines the feel of a polished product, is one of the harder things to specify in natural language. The tools produce baseline motion that works on the first iteration but rarely produces the kind of detailed, intentional timing that distinguishes a memorable interface from a generic one. This is one of the strongest remaining moats for senior frontend engineers in 2026.

The fourth is non-standard CSS. Container queries with internal logic, custom properties forming a token system, sophisticated grid layouts, anything involving math at the CSS layer. The tools either avoid these patterns or produce code that technically works but reads as if the model has not internalised the modern CSS model. Stylestats analyses of AI-generated CSS consistently show lower container-query usage and higher specificity drift than the equivalent codebase written by humans.

The fifth is semantic HTML. The default output of most current AI tools is a sea of div elements with class names rather than the nav, article, section, aside, figure, button elements that the language has provided for years. The generated code works visually. The semantics are weaker than they should be, and the cost shows up in accessibility, SEO and long-term maintainability rather than in the first demo.

The productive integration

If you are a working frontend engineer in 2026 and you are trying to decide where vibe coding fits in your practice, the honest answer is that the best teams have settled on a hybrid model.

The hybrid model treats AI generation as the first pass of any task that fits into the categories where the tools genuinely work. Scaffolding, routine CSS, content components. The developer then does the second pass as a deliberate review, paying particular attention to the categories where the tools fall down. Accessibility, semantic HTML, state wiring, motion.

This is not the pure vibe-coding workflow that the original framing suggested. It is a hybrid that respects the strengths of both the model and the developer. The teams that have got the integration right have not eliminated frontend engineering as a discipline. They have shifted the centre of the work from production to review.

The discipline that compounds in this workflow is knowing what to look for in the output. The senior engineer who can scan a generated component and identify the three things that are subtly wrong in the first thirty seconds is, in the AI-augmented workflow, more valuable than they were in the manual workflow. The mid-level engineer who accepts the generated output uncritically is, in the same workflow, producing meaningfully worse code than they would have produced by hand.

What this means for hiring and team structure

Two consequences are starting to appear in how teams are being structured.

The first is fewer junior frontend roles. The work that juniors used to do, building out scaffolds and learning the craft by writing boilerplate, is the work that AI tools now do. The path into a frontend career is harder than it was three years ago, and the entry-level positions that remain require demonstration of senior-level review judgement, which is exactly the skill that takes years of writing code yourself to develop. This is a structural problem the industry has not yet solved.

The second is higher expectations of mid-level engineers. The mid-level developer in 2026 is expected to produce at the level of a senior developer of 2022, because the tools have moved the floor up. The salary curve has not yet adjusted to this expectation in most companies, which is producing friction in the labour market that will probably resolve over the next eighteen months.

For team leads, the practical question is no longer whether to allow AI generation in the codebase. It is how to structure the review process so that the generated code is held to the same standard as the hand-written code. This is mostly a cultural question, not a tooling one. The teams that treat AI-generated code as automatically trusted are shipping worse software than the teams that treat it as automatically suspect.

Where the practice goes next

Three developments in the next twelve months are worth watching.

The first is AI agents that can run audits on their own output. The tools that integrate Stylestats-style analysis, axe-core accessibility checking and Lighthouse performance scoring into the generation loop are starting to ship. When the model can iterate against an objective audit rather than against the developer's gut sense, the output quality should rise substantially.

The second is better support for modern CSS in the models themselves. The training data for current models skews toward older patterns. As newer models train on more recent codebases, the output should shift toward container queries, custom properties and semantic HTML by default rather than as an explicit prompt requirement.

The third is shared agents across teams. The current workflow has each developer prompting in isolation. The interesting next step is shared agents that have absorbed a team's specific conventions, design tokens and code style. Teams that build this layer well in 2026 will pull ahead of teams that treat generation as an individual practice.

Vibe coding, in its pure form, is not what most working frontend engineers should be doing. The hybrid model, where generation accelerates the first pass and disciplined review carries the rest, is. The discipline of knowing what the model gets wrong is the discipline that compounds, and it is the discipline that the next generation of frontend engineers is being asked to learn before they have written enough code by hand to know what they are looking at.

The work has changed. The standards have not. That is the part that the discourse around vibe coding consistently understates.