Max Headroom 
UNCLASSIFIED
AI-assisted development has made frontend work feel much faster. A developer can ask for a form, a dashboard card, a table, a modal, or a responsive layout and get a decent first version almost immediately. The code may compile. The page may render. At first glance, the UI may look done.
But frontend developers know that “it looks done” and “it works well” aren’t the same thing.
A generated form might show validation errors visually but fail to announce them to a screen reader. A modal might open but not move focus to the right place. A dropdown might work perfectly with a mouse and still be unusable from a keyboard. A loading state might look fine in a demo but become confusing when the network is slow. A component might behave well with sample data and break as soon as real content is longer, missing, delayed, or unexpected.
That is the frontend verification gap in AI-assisted development. In this context, verification means checking whether an interface actually works properly for users under realistic conditions, not just whether the code compiles, the page renders, or the screen matches a design. It includes things like accessibility, keyboard behavior, focus management, state changes, loading and error handling, and whether someone can complete the intended task from start to finish. AI can help teams produce interface code faster than they can confidently answer those questions.
This isn’t an argument against AI tools. They can be genuinely useful. They can reduce repetitive work, help developers get unstuck, and speed up the first draft of a feature. But AI-generated frontend code should still be treated as a draft. The next challenge isn’t just generating UI code faster. It’s verifying that code with enough care.
Frontend correctness is harder than it looks
Some kinds of code are easier to verify than user interfaces. A function returns the expected value or it doesn’t. An API sends back the right response or it doesn’t. A script completes successfully or it fails.
Frontend work is different because the interface is where software meets people. A UI has to satisfy many expectations at once. It has to render correctly, respond to input, preserve state, support keyboard navigation, expose the right information to assistive technologies, and handle loading, errors, empty states, and unexpected data. It also has to fit the design system so the experience feels consistent.
AI tools are often good at producing the visible part of this work. They can generate a form, card, or table that looks reasonable in the default state. That’s helpful, especially when a developer needs a starting point.
The problem is that the default state is only one part of the experience. The harder questions come after the screen appears. Can someone complete the flow using only a keyboard? What happens when the request fails? Does focus move somewhere useful after an error? Are field labels and error messages connected correctly? Does the UI still make sense when there are no results? Is the generated code using existing design-system patterns, or did it quietly introduce a new one?
These aren’t small details. They are part of whether the interface actually works.
A quick review is not enough
A common AI-assisted workflow looks something like this: write a prompt, generate code, review the result, make a few edits, and move on. That may be fine for prototypes or internal experiments. It is much weaker for production frontend work.
The issue isn’t simply that AI makes mistakes. Developers make mistakes too. The issue is that AI can make incomplete work look surprisingly polished. The code may be clean. The structure may look familiar. The component may follow common framework conventions. That polish can make reviewers less likely to question the behavior.
Frontend problems are often missed this way. Accessibility issues, focus bugs, race conditions, missing empty states, and unclear error messages usually don’t jump out from a quick visual scan. They show up when someone interacts with the feature under less-than-perfect conditions.
AI-generated tests can create the same problem. A test may confirm that a component renders but not that a user can complete the task. Another test may check internal state changes while missing keyboard behavior, validation messages, loading states, or failure paths.
So the workflow needs to be stronger than “prompt, code, review.” Teams need better validation around AI-generated frontend work. That doesn’t have to mean a heavy process. It simply means being more intentional about what must be checked before a generated UI is considered ready.
Be clearer about what “done” means
One of the simplest ways to improve AI-generated frontend code is to give the tool clearer expectations before it starts writing code. Some of those expectations shouldn’t have to be repeated in every prompt. Rules such as using existing design-system components, following accessibility standards, preferring native HTML, and handling loading and error states can often be placed in a persistent project instruction file, such as CLAUDE.md, or another startup file that the agent reads at the beginning of its work. That gives the agent a shared baseline for the whole project and reduces the chance that important standards are forgotten from one task to the next.
A task-specific prompt can then focus on the details that are unique to the feature. For example, instead of simply asking for a form, the task might explain which fields are required, what should happen after submission, where focus should move after validation, and how the user should recover if the request fails.
The persistent instructions and the task-specific prompt serve different purposes. The first captures the team’s standing engineering expectations. The second explains what this particular feature needs to do.
This also makes review easier. The reviewer is no longer asking only whether the screen looks close to the mockup. They can check whether the feature follows the project’s established rules and whether the specific flow behaves as intended.
This matters because many frontend quality expectations are easy to leave unstated. Accessibility, focus behavior, loading states, and error recovery should be part of the agent’s working context wherever possible, rather than depending on a developer remembering to mention them in every prompt.
Let the design system do more work
AI tools are most useful when they operate inside clear boundaries. For frontend teams, one of the best boundaries is a strong component system.
If every generated feature creates its own buttons, inputs, modals, dropdowns, alerts, and tables, the team has to review the same concerns again and again. Is this button accessible? Does this modal manage focus correctly? Is this error message connected to the field? Does this dropdown support keyboard interaction? Are the styles consistent with the rest of the product?
That creates unnecessary rework. A stronger pattern is to put those decisions into reusable components. A button component should already handle variants, disabled states, focus styles, and accessible naming expectations. A modal component should already handle focus movement, escape behavior, labeling, and returning focus to the trigger. A form field component should already connect labels, helper text, required state, and validation messages. Then AI isn’t being asked to invent the pattern from scratch. It’s being asked to compose pieces that already carry the team’s standards.
There’s a big difference between prompting, “Build a modal form,” and prompting, “Use the existing Modal, TextField, Button, and FormMessage components to build this flow.” The second request gives the tool a safer path. It also gives the reviewer fewer things to worry about because the riskiest interaction patterns are already handled by shared components.
In that sense, a design system isn’t only about visual consistency. It can become a verification layer. It narrows the possible output and helps teams reduce the number of problems they need to catch manually.
Test the behavior users actually depend on
Automated checks will never catch everything. They can’t tell you whether a flow feels intuitive, replace a thoughtful review, or guarantee that every user will have a good experience. But they can catch common problems early, which makes them an important part of frontend verification.
Accessibility checks can flag missing labels, invalid ARIA usage, some landmark problems, and other frequent mistakes. Component tests can check state changes and validation behavior. End-to-end tests can confirm that someone can complete an important flow, while visual tests can catch certain layout regressions. The important thing is to test behavior, not just structure.
For example, a basic test might confirm that a form renders. A more useful test checks whether a user can enter values, trigger validation, understand the errors, correct them, submit the form, and receive clear success or failure feedback. Similarly, instead of checking only that a modal appears in the DOM, a test can confirm that focus moves into the modal, keyboard navigation works, the Escape key closes it, and focus returns to the original trigger.
This is where Playwright-style user-flow testing can be especially useful. It allows teams to test an interface in a way that is closer to how a person actually experiences it. The question becomes less about whether the interface renders and more about whether the user can complete the task.
AI can help generate these tests, but the team still has to define which behaviors matter. Asking an AI tool to “write tests for this component” leaves too much open to interpretation. A request to test keyboard navigation, validation errors, loading behavior, empty states, and failed submissions gives it a much clearer target. The quality of an AI-generated test still depends on the quality of the verification intent behind it.
Review the experience, not just the code
Code review still matters, but AI-assisted frontend work needs a slightly different review mindset. Reviewers need to look beyond whether the code is clean and whether the screen matches the expected layout. They should also ask: Are we using existing design-system components? Did the generated code introduce a custom control where native HTML would have been better? Are labels and errors connected correctly? Can the flow be completed with a keyboard? What happens when data is empty, delayed, or invalid? Do the tests cover real user behavior or mostly implementation details?
These questions help shift the review from syntax to experience. That doesn’t mean every pull request needs a long checklist. The process can still be lightweight. But the important concerns need to be visible somewhere. If accessibility, focus behavior, loading states, and error recovery never come up during review, they’ll continue to be missed.
AI doesn’t automatically solve that. In some cases, it makes the gap easier to miss because the generated result looks more complete than it really is.
Use AI without lowering the bar
The goal isn’t to make AI-assisted development feel risky or slow. The goal is to use AI for what it does well without letting it quietly lower the quality standard.
AI is useful for first drafts, repetitive scaffolding, alternate implementations, test ideas, and refactoring suggestions. It can help developers move through routine work faster. But it shouldn’t define what “good enough” means.
Frontend teams can get more value from AI when they pair it with clear engineering habits. Use existing components instead of generating new patterns each time. Include accessibility and interaction behavior in the prompt. Ask for loading, empty, error, and success states. Add automated checks for common problems. Test important flows the way a user would experience them. Review behavior, not just code structure.
These habits reduce rework. They also make AI-generated code easier to trust, because the trust comes from verification rather than from how confident or polished the generated output looks.
The frontend engineer’s role is shifting
AI-assisted development does not make frontend engineering less important. It changes where the value is. The value is not only in writing every line of UI code by hand. It’s in defining good component boundaries. It’s in knowing which patterns should be reused. It’s in understanding accessibility and interaction details. It’s in writing meaningful tests. It’s in noticing when a UI looks finished but isn’t actually ready.
That judgment matters because frontend failures are often experienced directly by users. A backend failure may return an error. A frontend failure may leave someone confused, stuck, or unable to complete a task. The user may not know whether they did something wrong, whether the application failed, or whether the interface was never designed for their way of navigating. Good verification protects users from that confusion.
Closing the gap
AI is making frontend development faster. That’s a real benefit. But faster code generation doesn’t automatically create better interfaces. In many teams, the bottleneck will move from writing code to checking whether the code behaves well.
The teams that benefit most from AI-assisted development won’t be the ones that generate the most UI code. They’ll be the ones that build strong feedback loops around that code.
For frontend teams, that means treating verification as part of development from the start. Component contracts, design-system guardrails, accessibility checks, user-flow tests, and behavior-focused reviews aren’t extra polish. They’re how teams keep quality high while still using AI productively.
The future of AI-assisted frontend development is not just better prompting. It is better verification.
The views expressed are my own and do not represent those of my employer.
AI use acknowledgment
AI assistance was used lightly for phrasing, editing, and tightening parts of this draft. The article’s ideas, structure, examples, and final review are my own.
AI & ML, Commentary
Radar
