Where AI Agents Break on Frontend Work (and Where They Shine)

Frontend is where AI agents look the most impressive — and where they fail the most quietly.

A backend endpoint either sends back the right data or it doesn't. But a frontend component can build fine, pass its tests, show up on the screen with no errors, and still be wrong. Maybe the spacing is off. Maybe a button can't be reached with the keyboard. Maybe no one designed an empty state. Maybe the layout breaks on a small phone screen.

I use AI coding agents every day on real work: building new features, migrating old code, refactoring, and reviewing pull requests. This post is about where agents have earned a real place on my team, where they keep breaking, and what I now do to stop that breakage from reaching production.

Why frontend is a different problem

Most AI agents only see files of code. Users see pixels on a screen, where their keyboard focus is, and how long things take.

That gap explains almost every problem below. Getting frontend code right means getting four things right:

• Visual — it has to match the design system, not just have the right types.
• Stateful — you need a loading state, an empty state, an error state and a success state, not just the happy path.
• Contextual — the same component can behave differently depending on screen size, input type, or whether someone is using a screen reader.
• Time-based — how fast something feels doesn't show up when you read the code diff.

An agent that never sees the real, rendered page is guessing at all four of these. Sometimes the guess is right. The problem is that a wrong guess can look exactly like a right one when you're just reading the code.

Where agents shine

These are the jobs I now give to an agent by default, without thinking twice.

1. Boilerplate with a clear shape

A new route, a new form, a new API client, a new Storybook story. If the pattern already exists somewhere in the codebase, the agent can copy it and usually get it right the first time. This is also the work most engineers enjoy the least.

2. Typed plumbing

Turning an API response into TypeScript types, a Zod schema, a typed fetch function, and a mock for testing. Types are great for agents because the feedback loop is fast — the compiler tells them right away when something is wrong, so they can keep fixing it until it's right.

3. Mechanical migrations

Turning class components into hooks. Moving from one routing setup to another — for example, migrating pages from the Next.js Pages Router to the App Router, one route at a time. Renaming a prop across 80 files. When the change follows the same pattern every time and you have decent tests, agents do this faster and more consistently than people do.

4. Test scaffolding

Give an agent a component, and it can write a solid first set of unit tests — does it render, do the props work, do the obvious interactions work. This doesn't replace thinking through edge cases yourself, but it removes the pain of starting from a blank file.

5. Explaining unfamiliar code

Asking "walk me through how this checkout code works" is one of the most useful prompts I use — especially when I'm helping someone new understand an old codebase.

Where agents break

These are the mistakes I see again and again, no matter which AI tool or model I'm using.

1. Design-system drift

The agent needs a card that's slightly different, so it just writes a new one. It uses a raw hex color instead of a design token. It writes margin-top: 13px instead of using the spacing scale. It creates a new button style that already exists under a different name.

Each of these changes looks small and reasonable on its own. But six months later, you end up with two design systems: the one in Figma, and the one the agents quietly built.

2. Accessibility that looks right

This is the most dangerous mistake, because the code often looks accessible at first glance:

// Agent output: passes review at a glance
<div className="card" onClick={openDetails} aria-label="Open details">
  <h3>{title}</h3>
</div>

It has an aria-label, so it looks fine. But you can't reach it with the keyboard, it has no role, and screen readers read it out inconsistently. The fix is simple and correct:

<article className="card">
  <h3>
    <button type="button" onClick={openDetails}>{title}</button>
  </h3>
</article>

Agents like to add ARIA attributes, but they rarely handle focus correctly — sending focus back after a dialog closes, trapping focus inside a modal, or announcing results that load after a delay. These are exactly the things that people using assistive technology depend on.

3. The missing states

Ask for a list view, and you usually get the happy path, plus a loading spinner if you're lucky. The empty state, the error state, partial data, a slow network, permission denied — these are usually missing.

This is the same mistake people make when estimating work, just made faster. If you don't ask for these states by name, the agent won't build them.

4. Layout it never saw

Without an actual browser to look at, an agent has never seen your component on a small 320px-wide screen, zoomed in to 200%, or with a German translation that's much longer than the English text. Overflow, text getting cut off, and text wrapping badly are the most common bugs our QA team finds in agent-written UI.

5. Server/client boundaries

In codebases using React Server Components, agents love adding "use client" at the top of a file just to make an error disappear. This pulls the whole file, and everything it uses, into the browser bundle. The build still passes. The bundle just quietly gets bigger.

6. Performance you can't see in a diff

Importing an entire icon library just to use one icon. An image with no set size, which causes the layout to jump around. A large date library pulled in just to format one date. A useEffect that runs on every single render. None of these problems fail a test. All of them show up in real performance data a month later.

7. Confident answers about fast-moving APIs

Framework APIs change between versions, but agents will happily write code for whatever version they learned from — not necessarily the version in your package.json. The code looks correct and idiomatic. It's just not correct for your version.

8. Making the test pass instead of the feature work

When a test fails, some agents will "fix" the test instead of fixing the actual bug. This doesn't happen often, but it's the one mistake that actively hides itself from you. That's why I read an agent's changes to test files more carefully than anything else.

The short version

The guardrails I put around agents

None of this means you shouldn't use agents. It means you should treat their code like a pull request from a fast, well-read junior engineer — one who has never actually seen the product running.

1. Write tasks like tickets, not chats

Every task I give an agent includes some background, a clear goal, a list of acceptance criteria, and the exact commands to check the work. The acceptance criteria always list out the states by name:

Render the orders list with loading, empty, error and success states. Use existing Card and EmptyState components. Keyboard-accessible. No new colour values. npm run lint && npm test must pass.

Writing that one paragraph avoids most of the problems above, before a single line of code gets written.

2. Give the agent the house rules

Keep a short file at the root of your repo (AGENTS.md, CLAUDE.md, or whatever file your tool reads) that lists the rules that can't be broken:

## Frontend rules
- Use design tokens only. Never hard-code colours, spacing or radii.
- Reuse components from src/components/ui before creating new ones.
- Interactive elements must be native <button>/<a> unless a documented pattern says otherwise.
- Default to Server Components. Add "use client" only to leaf components.
- Every data view needs loading, empty and error states.

Agents follow written rules far better than implied ones. So do people.

3. Let machines check what machines can

If a rule really matters, enforce it in your CI pipeline instead of just mentioning it in code review:

• Lint rules that block raw hex colors and random spacing values.
• axe-core running in your tests, so it blocks the build on serious accessibility issues.
• Performance budgets with Lighthouse CI on pull requests.
• Strict TypeScript, so the compiler catches the things the agent guessed wrong.
• Visual regression tests on core components.

Agents are very good at fixing a failing check. So give them checks that can fail.

4. Give the agent eyes

The biggest quality improvement I've seen comes from letting the agent actually look at what it built — through a browser tool, screenshots or Storybook — instead of only working from code files. Layout and visual bugs drop a lot once the agent can see its own work.

5. Keep PRs small and review like it's a junior's work

Keep pull requests small and focused on one thing. Read the changes to the tests first. Check the different states, check that you can use it with a keyboard, and check the impact on bundle size. Don't approve something just because the diff looks clean — agent-written diffs almost always look clean.

What this changes for frontend leaders

Three things have shifted on my teams:

• Reviewing code is now the bottleneck. Writing code got cheaper. Reading and checking it didn't. Spend time building good review checklists and automated checks before you buy more agent licenses.
• Time estimates shift toward integration and testing. The time it takes to scaffold new code goes down. But the time spent on states, accessibility, edge cases and QA doesn't go down — so it becomes a bigger share of your total time.
• Junior engineers need a deliberate learning path. If agents write all the boilerplate, junior engineers miss out on the repetition that used to teach them the fundamentals. I pair juniors with agents on purpose, and ask them to explain what the agent did during code review.

The takeaway

Agents are genuinely good at frontend work that has a clear, repeatable shape. They're unreliable at the parts users actually notice: consistency, accessibility, different states, layout and speed.

The answer isn't to use agents less. It's to make it easy to check their work — written rules, automated checks, a real browser in the loop, and a reviewer who knows what to look for. Do that, and an agent becomes what it should be: the fastest junior engineer on your team, working inside guardrails set by a senior one.