avatar
KO
In the Age of AI-Generated Code, Where is Frontend Engineering Headed?
avatar

yceffort

·10 min read
aifrontend

Table of Contents

Overview

I recently asked AI to create a component for me. The code was ready in 30 seconds. It even worked. But I felt uneasy about deploying it to production. There were unnecessary re-renders, state was being managed in the wrong place, and the API call pattern was creating waterfalls. This was the result of asking it to "just make something" without proper specifications. In the end, fixing the AI-generated code took longer than writing it from scratch.

There's talk that "developers will become obsolete." That's wrong. What's disappearing isn't developers, but the form of what developers used to do. While time spent typing code has decreased, the work of determining "is this code ready for production?" has actually increased. The faster AI generates code, the more important the role of those who validate that code and provide direction becomes.

Here are the changes I've observed as a frontend engineer who actively uses AI coding tools.

Define Specifications First, Before Asking AI to Write Code

The most common mistake when using AI coding tools is asking them to create both code and tests simultaneously. AI ends up creating tests that confirm its own incorrect code as "correct." It's like creating your own answer key to match a wrong test paper.

This leads to the principle: "Write tests first, then ask AI for the code." The idea is that TDD becomes the most powerful quality control tool in the AI era, but this is hard to apply directly in frontend development. To be honest, frontend and TDD aren't a great match.

There are fundamental reasons why TDD is difficult in frontend development.

First, frontend output is visual. You can test "clicking a button opens a modal," but you can't express "does this modal match the design mockup?" in a test. Unit tests won't catch layout breaks from changing a single line of CSS.

Second, UI tests have high maintenance costs. Using Testing Library to test based on roles or labels reduces vulnerability to DOM structure changes. But when you split components or change state management approaches, you still need to update the tests. In projects with frequently changing UIs, many teams repeat the cycle of "write → abandon maintenance → delete" due to high test maintenance costs.

Third, "correct behavior" in frontend varies by context. The same component should behave differently on mobile vs. desktop, and show different UIs based on network state. Covering all these combinations with tests is impractical.

So in frontend development, we need to expand "write tests first" to "define specifications first." The form of specification varies by domain.

TDD works well for business logic. Things like credit limit calculations, installment interest computation, and input validation can be separated into pure functions with clear inputs and outputs. Write tests first and tell AI "create a function that passes these tests" and you'll get fairly accurate results.

Storybook serves as specification for UI components. First define each component state (default, loading, error, empty state, etc.) as stories, then have AI create components that match them. Visual regression testing tools (like Chromatic) automatically catch "did this change from before?" The form differs from TDD, but the principle is the same: "define validation criteria first, then let AI handle implementation."

Type systems become specifications for state management and data flow. With precise TypeScript type definitions, when AI generates code that doesn't match types, it's caught at compile time. This makes it impossible for incorrect code to exist in the first place. You can't expect this effect in codebases that abuse the any type. The stricter your types, the more reliable AI-generated code becomes.

In summary, before asking AI to write frontend code, you need to first define: tests for business logic, stories for UI, and types for data flow. All three share the same essence—they're "criteria for automatically validating AI-generated results."

The Four Roles of Code Review Are Getting Distributed

Code review was actually doing four things simultaneously:

  1. Junior education. Seniors teaching juniors better approaches while reviewing their code.
  2. Coding style unification. Making the entire team write code in a consistent way.
  3. Bug catching. Finding logical errors and edge cases.
  4. Building confidence. Getting assurance that "this code is safe for production."

When AI mass-produces code, line-by-line human review becomes practically impossible. The volume of daily PRs is incomparable to before. But eliminating reviews would lose all four functions.

Coding style unification → Linters, formatters, and custom rules. ESLint and Prettier already handle basic code style. But what gets repeatedly flagged in reviews isn't formatting—it's team conventions. Turn these into custom ESLint rules. Things like "event handlers use handle- prefix" or "API calls must use this wrapper function." Previously, creating custom rules was too costly to consider, but now you can ask AI "create an ESLint rule that catches this pattern" and get results quickly. Move repetitive review feedback from humans to tools.

Bug catching → Automated tests and static analysis. Whether AI-generated or human-written, code that doesn't pass tests doesn't get merged. TypeScript's type checking, ESLint rules, and CI test pipelines catch bugs instead of humans.

Building confidence → Validation levels proportional to risk. We must abandon reviewing all code at the same depth. Adjust review depth based on "how big a problem would it be if this code is wrong?" Payment flows and personal data handling code must be thoroughly reviewed by humans. Internal admin tool UI changes are sufficiently covered by passing automated tests and visual regression testing. Engineering shifts from an artisan model (human inspection of every line) to a risk management model (validation investment proportional to risk).

Junior education → Time coding together. This is the most challenging. Code review was asynchronous with low time burden. Pair programming is synchronous and directly consumes both parties' time. But in an environment where reviews pile up at AI's code generation speed, expecting educational effects from asynchronous reviews becomes increasingly difficult. When a junior submits AI-generated code and a senior asks "why did you do it this way?" the answer is "AI made it this way." Code review stops functioning as a learning channel.

A realistic alternative is changing the format. Pair programming where seniors coach juniors through the process of writing prompts for AI and evaluating results, or weekly short live coding sessions to review "the most concerning AI-generated code from this week" together. This requires time investment, but in a world where AI writes code, education focus should shift from "how to write code" to "how to evaluate AI-generated code."

Worry About "Cognitive Debt," Not Technical Debt

Technical debt is a familiar concept. It accumulates in code and gets paid back through refactoring.

What we should worry more about is "cognitive debt"—the gap between system complexity and the team's understanding of that system.

Frontend is particularly prone to accumulating cognitive debt. With hundreds of components, understanding what state each manages, which APIs they connect to, and what screens they show under what conditions isn't easy. When AI speeds up code changes, code evolves quickly but human understanding speed remains the same. Reduced code reviews eliminate the natural learning channel for system changes.

If only one person in a 5-person team understands the entire system, that's cognitive debt for the team. No matter how capable that person is, the team stops when they leave. The faster AI increases code production speed, the more rapidly this problem worsens.

Frontend teams can realistically do several things:

  • Weekly architecture retrospectives. The entire team spends 15 minutes reviewing how component structure or state management changed this week. Not examining code line by line, but sharing the direction and intent of changes.
  • Use Storybook as component documentation. Enable understanding of each component's states without reading code. New team members should be able to visualize the system's UI structure just by browsing Storybook.
  • Use AI for code understanding too. Simply asking AI "explain the component dependency relationships in this directory" speeds up system comprehension. If cognitive debt accumulates at AI's code generation speed, it's also possible to pay back cognitive debt with AI.

Requirement Quality Becomes More Important Than Code Quality

Earlier I discussed technical validation criteria like tests, stories, and types. Here I'm talking about an earlier stage problem—the quality of requirements themselves. To have AI write code, you need to accurately specify "what should be built." Vague user stories like "as a user, I want ~" are too ambiguous for AI to interpret. AI confidently produces plausible but incorrect results from ambiguous inputs.

This problem is particularly prominent in frontend areas like form validation and conditional UI. Specs like "show error when email format is wrong" aren't sufficient for AI to create proper implementation. You need specification-level detail like "don't show errors while typing email, validate after losing focus, server and client validation have different error messages, and errors disappear when typing resumes after error state."

It's even more pronounced in financial service frontends. Writing "how should it behave when card limit is exceeded?" vaguely in natural language makes AI create plausible but incorrect implementations. Precisely defining each screen state and transition conditions with state machines enables AI to generate much more accurate code.

This paradoxically increases the value of frontend engineers. Writing good UI specifications requires understanding user behavior patterns, predicting edge cases (network errors, simultaneous input, slow responses), and knowing browser and device constraints. While AI can replace coding ability, this capability is much harder to substitute.

Bottlenecks Shift from "Speed of Creation" to "Speed of Decision"

Adopting AI tools definitely speeds up code production. Creating a component that used to take half a day now finishes in 30 minutes. But organizational decision-making speed remains the same.

Time waiting for design review, API spec finalization, resolving dependencies with other teams—AI tools can't reduce these. Teams can process backlogs in days, but immediately hit these walls. Overall speed doesn't change, only frustration increases.

This problem affects all engineering teams, but it's particularly severe in frontend. Frontend sits at a position receiving dependencies from three directions simultaneously: design, backend APIs, and product planning. A common scenario: you rapidly create components with AI, but designer feedback comes a week later. The fix takes 30 minutes, but waiting for feedback takes 5 days. API isn't ready so you work with mock data, but actual API response structure differs requiring rebuilding. Product can't decide on A/B testing so you build both versions, then end up using neither. No matter how fast code production gets, it's powerless against these structural bottlenecks.

Recognizing this changes direction when pursuing productivity improvements. Instead of "let's use AI tools better," it becomes "let's create structures where decisions are made quickly." Reduce design-development synchronization cycles, agree on API specs first and work in parallel, or delegate authority so the frontend team can make low-risk UI decisions autonomously.

Even Though AI Makes Mass Production Easy, Deploy in Small Pieces

With AI tools making large-scale code changes easy, some teams are returning to "deploy big all at once" approaches.

Ten years of DORA research repeatedly proves the conclusion: "small, frequent deployments are more stable." This contradicts intuition. Large changes at once seem more efficient, but when problems arise, finding causes is much harder and rollbacks become complex.

Frontend is particularly susceptible to this trap. AI can refactor 10 components simultaneously. Having AI batch process common style changes, state management migrations, or API integration method changes creates one massive PR. Reviewing this is practically impossible, and when post-deployment incidents occur, you can't tell which of the ten places caused the problem.

AI-generated changes don't change deployment principles. Instead of asking AI "change everything at once," ask "change only this component" ten times. PR size limits and deployment frequency must be consciously managed.

Role Transition for Senior Frontend Engineers

It's natural that experienced engineers produce more effective results when using AI tools. With deeper understanding of system architecture, they can provide more accurate context to AI and quickly judge the quality of generated results.

There's a typical scene in frontend where this difference shows. AI creates a component, and a junior thinks "it works, so it's done." A senior immediately catches "this component takes up too much bundle space," "this dependency isn't tree-shakeable," "this data fetching pattern creates layout shift." In a world where AI writes code, the value of such judgment actually increases.

The role of senior engineers is shifting from "person who directly creates many components" to "person who finds and removes team and system bottlenecks." Why bundle size grew, which dependencies slow builds, where component structure complexity explodes—only experienced people can know these things.

However, this transition isn't easy. It's telling people who entered this industry because they love coding to "reduce direct coding now." The history of computer graphics provides a good analogy. Engineers who hand-coded polygon rendering algorithms in the early 1990s saw that work move to hardware as 3D accelerator cards like 3dfx Voodoo became widespread. But new specialized areas like animation, lighting, and physics engines opened up above that. People who stopped at each abstraction layer saying "I was hired to render polygons" fell behind.

The same thing is happening in frontend. When direct component creation moves down to AI, specialized areas above it—performance optimization, architecture design, managing team cognitive debt—become more important.

Conclusion

Talk of agent operating systems and self-healing systems is still distant future. What frontend teams can do right now:

  • Define tests for business logic, Storybook for UI, and types for data flow first, then have AI handle implementation.
  • Separate code review purposes—have humans thoroughly review high-risk areas like payments and personal data, but rely on automated verification for the rest.
  • Consciously manage PR size and deployment frequency even when using AI tools.
  • Periodically check "how well does our team understand the system?"

AI is indeed changing frontend development. But what's changing is "how to create components," not "what's needed to create good user experiences." The ability to understand user behavior, design complex state, diagnose performance bottlenecks, and create a culture where teams understand systems together—these remain human responsibilities no matter how well AI writes code.

Tools changing doesn't mean principles change too.