How Good is AI at Coding React (really)?

So today we're going to cut through the AI hype to answer one critical question. How good is AI at coding React? Hopefully by the end of this talk you'll know exactly what AI can do and what it can't for your React projects and how to leverage it effectively.

Now 90% of developers are using AI for coding in some way. In an AI-assisted world, the value of frameworks like React depend on how effectively AI can use them. So if AI can't handle a framework or a UI library very well, it means the quality of experiences that you can build with them is going to require a lot of manual work.

Now a lot of AI code quality comes down to context. You want to squeeze the most value out of your token budget in your context window. But the model and the tools that, you know, things sit on top of, all of these layers play an important role. Now many of us have hard won lessons about using AI for coding with React.

Some more useful than others. For example, I now realize Tony Stark was a vibe coder. He totally was. He was just speaking prompts to Jarvis and hoping his API credits didn't run out. We learned about vibe coding and its cousin vibe debugging. AI can spit out like 10,000 lines of code in a minute, but if you're still spending a lot of time debugging it, there may be consequences.

AI is a force multiplier. It amplifies everything. So if you have good practices, if you have bad habits, it's going to amplify those. If you've got clear requirements, a solid design, modular code, it can help amplify that and help you ship things faster. If you have vague requirements, AI will happily generate thousands of lines of code that you're going to have to untangle.

Before we properly dive in, I want to just remind you about the differences between vibe coding and AI-assisted engineering. Vibe coding is fast and exploratory, really prioritizes speed and experimentation over deep review and engineering rigor. AI-assisted engineering is that methodological integration of AI tools into a mature software development life cycle, where you, the human, are very much still on the hook for control and ultimately the quality of what is getting output. Practical advice can be derived from AI coding benchmarks, focusing on both objective pass and fail tests and subjective human judgment.

AI models excel at what they've seen the most. They can competently handle a lot of React prompts due to the prevalence of the stack in training data but may struggle with alternatives. React expertise remains valuable, with potential for AI support to improve, albeit with implications for diversity and framework innovation speed. React developers are currently in a favorable position, with opportunities for improvement and stability within the ecosystem.

The stack is so prevalent in training data that AI can relatively competently handle a lot of React prompts, but it can struggle with alternatives. This has interesting implications for using other third-party dependencies or newer frameworks. Many vibe coding platforms, IDEs, and tools excel with React, Tailwind, ShadCN, and TypeScript stacks. React engineers find comfort in the value of React expertise amidst AI advancements. AI's potential for React support hints at stability despite potential diversity challenges.

React developers are currently in a favorable position, with room for improvement and ecosystem stability. However, the gap between model performance on benchmarks and real codebases is significant. The complexity cliff highlights the discrepancy between ideal model performance and practical usage in React work. Design Arena, a crowdsourced benchmark platform, evaluates AI coding models' design capabilities based on human preferences. AI's mastery of logic over taste leads to technical implementation of components but challenges in autonomous design decision-making for React developers.

AI's capabilities in logic and reasoning tasks do not always translate into good design decisions autonomously for React developers. While AI models can solve complex tasks, they may struggle with design aspects like color choices and visual hierarchy. This divide shapes how React developers interact with AI tools, emphasizing the need for human input in design decisions. React developers can leverage benchmark platforms like Design Arena to improve design quality, usability, and aesthetics in AI models.

Now, there's a complexity cliff I want to talk about. The gap between how models perform on benchmarks and how they behave on your real codebases can be huge. We can come up with a new model that can look very shiny, but then you actually use it and maybe your experience is slightly different. I want to show you what that gap looks like and why it matters for React work. I'm going to mention a few different benchmarks today.

One of them is Design Arena. Now Design Arena is a crowdsourced benchmark platform that evaluates the design capabilities of AI coding models by having users vote on their creations across lots of different categories. Things like website, web app generation, agents, vibe coding tools. And by using a sort of pairwise comparison system, where you vote on what you think looks best, it generates leaderboards that rank AI models based on human preferences. And that helps to measure and drive improvements in things like design quality, usability, and aesthetics. So people who are working on models can take a look at these kinds of benchmarks and then work on gaps.

Now one of Design Arena's first findings here is that AI has in many cases mastered logic, but not yet taste. Models can solve complex reasoning tasks and still produce UIs that can come across as basic or maybe have design failures. Things like maybe poor color choices, inconsistent spacing, no visual hierarchy. And for React developers, this means that AI can implement your components technically, but it can't always make good design decisions for you autonomously. And this divide sort of shapes how you use AI. For algorithmic logic, you know, data structures, API integrations, AI can be really powerful.

For visual design, you know, UX decisions, accessibility considerations, you kind of have to stay in control as a human. So think of it as AI handles the code that works and you handle the experience that's going to delight your users.

Now another one of Design Arena's findings was that the scaffolding and tooling around the base model can drive a lot of a performance spread as you compare sort of vibe coding platforms to generic agents. And this likely means two things. The first, scaffolding and workflow around the base model matters quite a lot for how good the UI ends up. And second, many specialized builders probably share the same or very similar base models, so their scores on these kinds of benchmarks can cluster a little bit more.

Now there is a little bit of a functional and aesthetic gap here. AI can scaffold UIs pretty reasonably, but you still need your human's judgment if you care about that taste, that quality, and the architecture. So it can get you something that works, but not something you may be completely proud of shipping to your users. There are lots of efforts around web-based evals and benchmarks at the moment.

Another recent one was work that was done by Vercell on Next.js evals, and they have a leaderboard. It looks at things like how well models might be implementing support for server-side rendering, migrating to app router, and so on. And the best models today on this benchmark, like Gemini 3 and GPT-5 codecs, still only complete about 42% of those tasks. Clouds on Thropic is currently around 40%, but out of 50 challenges, the best AI fully completes about 20. So there are a lot of failures on a framework that it is supposedly trained on. And I think that this just identifies there are still gaps in terms of how good models can get and the tooling layers can get.

We can look at another benchmark. Webbench is a benchmark by ByteDance, and it simulates real web development. It's got about 50 projects with 20 sequential tasks, and top models are still only solving about a quarter of the tasks. So they might pass initial ones, but then they stumble as that complexity grows. And this is a little bit of our reality check. When you're asked to build a small web app end-to-end, today's AI maybe gets it 25% right on the first try, but a lot of the rest of that work still requires human intervention to get quality good enough for production.

We've also got Web Dev Arena. It's a platform from LM Arena where users can compare the performance of different large language models on web development tasks. In their human preference tests, Quad led the way sort of through 2024. Users consistently preferred its outputs. By late 2025, as of today, Gemini 3 and GPT-5 had caught up, and that tells us that so-called best models for design are no longer quite obvious. You actually have a lot of real choices right now. So now that we have the big picture, I want to zoom in. We're going to break down the results from a few different arenas, looking at website code generation, agents, vibe coding platforms, UI components, and 3D and data visualization. And for each one, we're going to look at the top performers and also extract some practical tips that you can use to improve your React workflow when you're using AI for coding.

By late 2025, as of today, Gemini 3 and GPT-5 had caught up, and that tells us that so-called best models for design are no longer quite obvious. You actually have a lot of real choices right now. So now that we have the big picture, I want to zoom in. We're going to break down the results from a few different arenas, looking at website code generation, agents, vibe coding platforms, UI components, and 3D and data visualization. And for each one, we're going to look at the top performers and also extract some practical tips that you can use to improve your React workflow when you're using AI for coding.

So we're starting off with Website Arena from Design Arena. It's a classic sort of prompt to website test, and it's a great measure of a model's ability to balance code generation with design sensibility. Models that lead this leaderboard are kind of praised for clean, fast output, or they excel at more creative and complex layouts. Here are just some of the examples from the last week or two. This one is a website for the Lo-Fi Beats Girl. The winning model was one that produced the most complete and coherent page, maybe not the flashiest layout.

We have a performance marketing example. This is a good place to call out that even newer models, like AES Coder 4B, this is a tiny four billion parameter model trained by Microsoft Research. They use Design Arena as a baseline in their paper. Here's a CRM dashboard comparison. The top entries here are pretty close in terms of quality, but what separates them isn't necessarily correctness, but details like hierarchy, spacing, and how quickly you can scan for key metrics in the design. Now, if you paid attention to some of those designs that I was showing you, you might be questioning, why is there so much purple in AI-generated designs? Like, really?

Many of us have been using things like Tailwind a lot in the last couple of years. Maybe it's contributed a little bit. But there are a few different options for how you solve this. Anthropic recently stopped trying to fix the purple problem in training, and they moved it to the app layer with skills. Some LLM issues are solved better with tooling than model weights. In this case, they just use skills. Skills are markdown files that Cloud reads on demand. This can just help you work around this problem.

If you want to check out their front-end design skills, this can help you work around that purple website generation problem. As we go through, I want to just share some of the tips that have been working well for me and insights I've extracted from these. I'm not going to get to go through all of them, but to get the most out of AI for building sites with React, you need to be really highly specific with your instructions. Ideally, define everything from the overall layout and your component structure to the routing and your responsive behavior. Enforce your existing design system, if your team have one, and coding standards to ensure that consistency and quality are in place.

We can also generalize here. This isn't just about websites, of course, but the development of using React for web apps, for UI components, for all kinds of things can be generalized a bit here. AI can be a powerful coding partner, but you really need to manage it like a junior developer. As I said, be very explicit. Define your component APIs, your states, your architecture, up front, if you want to guide the AI. Just by codifying more of what you want to see in the conventions that your team have, you can keep the AI's output consistent and on brand, especially if you can commit those things to the repository so you can continue reusing them.

Just by codifying more of what you want to see in the conventions that your team have, you can keep the AI's output consistent and on brand, especially if you can commit those things to the repository so you can continue reusing them.

Next up, we've got Agent Arena, and this is a step up in complexity. We're not just generating a single file or a single view for a website here, but we're evaluating an AI's ability to act like a developer. Creating files, running tests, running browsers, debugging. This is where we see the power of agent loops. The top performers here are really built on powerful code-specific models.

Now, reviewing code that is blatantly AI generated has probably been the second most depressing thing I've encountered this year at work, the first being developers trying to explain it. But I think that there is a lot that we can learn from these kinds of experiences that we all have. Now, if you're using an agent, again, be specific. You will notice there is a theme here. Be specific, be precise in what you want. Use a plan, use a specification, point them in any extra context that you have, like logs and monitors. Ultimately, maintain human oversight.

You can enforce things like small pull requests for review, use atomic units of work. You can require unit tests with every fix. And really just ensure that the agent is a productive but supervised member of your team.

Let's talk about context. Most agent failures are not necessarily model failures anymore, but they're context failures. If the agent doesn't see the right logs, tests, or constraints, it can make confident but wrong changes. And many of us have tried out prompt engineering, right? So tweaking words endlessly only to see failures.

But as this iceberg shows, the real issues are often below the surface with mismanaged context. Now, context engineering, a lot of folks watching this have probably learned about this. It's about the art and science of filling the context window with just the right information needed to guide an agent's performance. There are lots of layers to this, but ideally including clear specifications, examples, data, references to more up-to-date docs. There's a lot that you can include. You can do visual context, screenshots. Anything that the agent may not be able to see is of high value.

Here's a great template for context engineering from Anthropic. It's a great thing to share on social media and then completely forget. But I'm looking forward to more and more of these ideas being codified in our tooling. So, you probably don't have a lot of control over the quality of the base models that you use, but you can steer the tooling around it. So, I want to share some tips around that as well.

First up, we've got Context-7. We're going to be talking a bit about MCPs. Context-7 pulls fresh version-specific docs and examples straight from library sites and will inject them into the model's working set. That kind of stops the assistant from guessing APIs or using stale snippets from the model's training data. It's really powerful. You can nudge it towards topics like routing or hooks and just cap how much that you bring in. Context-7 is something I recommend folks use.

Next.js has also got a DevTools MCP server. This will connect to an agent so it can ask for real data about your running app, current build or runtime errors, routes and layouts, component metadata, server actions. And it also ships with a Next.js-specific knowledge base which can help you once again work around any gaps in base model quality. On my team, we recently shipped Chrome DevTools MCP. This gives your AI coding agent eyes and hands in a real browser. So, it can open up pages, click through flows, read console and network logs. It can really like see at runtime what has been rendered in the browser. And that just helps you with an overall quality loop, improve what is getting generated.

Now, if you want to connect all of these together, here is one workflow that works. Context-7 can give your assistant the right knowledge. Next DevTools can give it the app's truth. And DevTools MCP can kind of prove the result in a real browser. So, used together, you kind of turn a guessing assistant into a closed loop coder and a debugger that can cite sources, place changes correctly and verify outcomes before you hit commit.

Next up, we are going to look at Vive coding tools. So, these are platforms designed for rapid, prompt-driven product creation. And the goal here is really not to just create code, but a cohesive, well-designed output. So, a few examples here, a portfolio site for a cat photographer, a dashboard for oceanic research, a developer experience dashboard, what to watch based on your mood.

We've also got UI components arena. This is one of the most directly applicable to the daily work of React developer. The task here is really to generate isolated, reusable components. And because the scope is so focused, the success rate is a little bit higher and the output is often very close to being production-ready. The leaderboard here shows a mix of models with Gemini 3 valued for polish and some open models being a surprisingly strong contender.

And I think that there's something really powerful with that, especially if you are starting with a solid product spec and a locked design system. We've also got UI components arena. This is one of the most directly applicable to the daily work of React developer. The task here is really to generate isolated, reusable components. And because the scope is so focused, the success rate is a little bit higher and the output is often very close to being production-ready. The leaderboard here shows a mix of models with Gemini 3 valued for polish and some open models being a surprisingly strong contender.

And the big design arena takeaway for UI components is that models have largely mastered logical correctness. Taste, again, still requires a little bit of work. They can wire up your props, your state, your data flow, but they can still choose poor colors, fonts, inconsistent spacing and weak visual hierarchy. So that means that you can trust it to get pretty close on your structure and behavior, but you still need to own the final design decisions. And so there are a number of examples here. So these are different models creating components like a card for signup information, a swipeable image gallery, stacked sheets, a stock market component.

One thing I want you to take away from this is that comparing the visual output across different models can be really powerful, especially if your team have leaned into one model, but you were curious if it could be different or better with one of the others. A few tips for UI component generation. Often models are going to require specific UI component guidance to implement crucial aspects, such as accessibility, consistency with your team's best practice patterns, separating styling concerns and creating composable behaviors. And last up from our arenas is the 3D and data visualization arenas. 3D and data viz push models of more structured and complex generation. So for React developers, sometimes we'd be building a landing page or a site and we will need to include interactive experiences in there.

AI assistants can help here, but it often requires a slightly different integration strategy. So there are a few examples here. Again, a 3D red car by a hotel. This is Gemini being able to create a 3D man with different kinds of poses and actions that are complete. A 3D modern building, a Christmas village. And AI can really help a lot with 3D and data visualization, but only if you're, again, very specific. If you name the exact libraries that you want, like React 3 fiber or ReChart. If you describe the scene or chart in very concrete terms, you can get a lot out of this. If you ask for low poly assets and lazy loading first, so you can keep performance under control, that's also pretty good.

Let the model generate your meshes, your data, and your configuration, but you're still kind of in control of the interactions, the frame rate, and the fallbacks. Now I've been joking about vibe coding. As an O'Reilly author, I try not to take myself too seriously. We are all learning. We're all making mistakes. We're mastering how to undo our messes. And ultimately why AI code works or fails is down to this stack. Understanding this stack helps you debug failures and improve results.

When AI code works beautifully, usually multiple layers are well aligned. And when it fails, you can trace it to a weak link. A weak link. Now using AI for productivity, for velocity, it means nothing if the wheels are going to fall off down the road. Speed means nothing without quality. And when all of these layers interact well, you can get better outcomes. It's usually because the model was strong, you gave it a good prompt, it had the right context from documentation and tests, you gave it some iteration to iron out the kinks. And when it fails, you can almost point it to one of these layers being weak. So strong model, good prompt, relevant context. And if you're not just one-shotting, you can get decent output. But conversely, those failures, again, they come down to these weak links. So if you used a general model instead of a code-specialized one, if your prompt was ambiguous, if you didn't include additional context, you can end up in a place where quality isn't great. But the good news is that this is all actionable.

You can usually fix at least some of the factors on this on your end. I hope that some of these are lessons that you take and can actually find helpful. This is my current debugging workflow in one picture. It's kind of 21 miles of telling cursor to please fix and somehow never taking the quarter-mile detail to understand how anything actually works.

I think there's a lot in the lessons from today that can apply to many of us regardless of where we are in our careers. And this is sort of the new flow state for AI-assisted development. It's where this workflow just becomes second nature. You're not just trying to type anymore. You're orchestrating code creation, you're prompting, reviewing, testing, refining, and repeating. I think it's a little bit different from traditional development, but it's equally focused and productive.

Now if you've been paying attention a little bit, I snuck in a few mentions of something we just released today. We just launched Gemini 3, which is Google's best model for web development, vibe coding, and agentic tasks. I hope that some folks will check it out. We're proud of this model. We think that it's pretty good for React development too. Gemini 3 tops design arena at the moment in multiple categories, including website arena, UI components, and 3D design arena. It's also topped the web dev arena leaderboard, scoring an impressive 1487 ELO on that. I wanted to show you very quick examples of this in action. This is Gemini 3.0, working on a brutalist design. And the prompt is here as well.

This is not just a website that looks like AI necessarily generated it. It's got a little bit of taste, a little bit of style. It feels a little bit unique to the person that was building it. And there are lots of examples now out as of this morning that you can check out. This is another site that included a cool 3D header. These interactions as you navigate through the page. We've also got an example of this beautiful typography site with animations that display the content. Interactive widgets for understanding these different sections and playing around with the content. Again, we're starting to get a little bit better at design aesthetics across the board.

If you thought that we covered a lot today, you're absolutely right. We did. The important thing is to just be proactive in using the tools that are at your disposal. I think personally that the future is bright. You have more leverage than ever as React developers. I hope you'll use the benchmarks, some of the techniques I shared, and the understanding that you've gotten from the whole conference to build better products faster. Stay curious about AI. Things are moving fast, but always remember that you're the architect, you're the designer, you're the one that ensures that quality user experiences get built. Thank you for being here. Go build amazing things. Thank you.

We have a few questions coming in, and one of them relates to something that I believe you mentioned a couple of times during the talk, which is debugging. Where are we at in terms of getting AI to debug for us? The KD, the question asker also wants to just stand and watch. Can we get there? Yes, yes we can. I think with Chrome DevTools MCP, Playwright MCP, a lot of different browser MCPs, and especially IDEs like Cursor, like other tools starting to integrate these ideas by default. I do see us getting to a place where AI agents can debug automatically, and I see that being part of this automated quality loop, where if you are prompting, they just happen to automatically use the right tools, get the right information from the browser, from anywhere else it needs context, and can hopefully avoid humans having to debug. Nice. Although again, we all still need to be kind of aware of how this, I like the context of AI pair programmer, is working alongside of us. Awesome.

Well, let's get into the, you know, the thing on everyone's mind is, where does it stop? Does it stop? How close do you think we are to hitting the limits of what AI can do for us? I think we're actually far off from hitting the limits of AI. I think that one takeaway from some of the things I talked about today is that even our ability to measure whether AI is generating code that is sufficiently high quality, something that a senior engineer would write for a production database, a production code base, or someone in an enterprise, I feel like there's still a long way to go, and so I see models still having a little bit of runway left to get better. Plenty of work still to be done, folks. Okay, well, I guess, speaking of generating tasteful designs, we have a question that, well, I guess it contains an implied question. Did you generate images for your slides? And if so, what tool did you use? I hand drew them all. No, if you saw any images of my slides, they are generated using Gemini. We use NanoBanana for these, and if you like NanoBanana, keep an eye out for other announcements this week. Oh, stay tuned, folks. Amazing, and, of course, you know, we're dogfooding. We're using the tools to talk about the tools so that we can all get better at the tools. Amazing. All right, let's see. We have a question here around security and architecture and these other kind of higher level aspects of a code base. So what is the most common security or architectural regression in AI-generated React PRs or changes, and how would you review for it? I think there's two bits here. So for the architectural regressions, what I often see, and we've done some studies around this, is that models can generate code that looks roughly right but may not be following the team's patterns correctly, because it's not necessarily looking at the full context of your code base, all the PRs, like that history, that team history. And so I think that that is a place where we do need to apply a little bit more diligence during code review. I'm hopeful that at the tooling layer, we can leverage CI, we can leverage more bots to pay attention to that and flag it as a concern before you have people actually manually reviewing the code. The most common security issues are actually very basic things, and part of it is because we've now increased the total addressable market of who can build for the web. We have a lot of people via coding who don't have a deep technical background, and so even things like XSS issues, client-side API key leaks, all of these are the biggest common problems right now. There are many more nuanced ones, but those are the really big ones, because we've got this huge audience now building. Gotcha. All right.

Well, we're gonna probably have some like leaderboards for Pwn.AI or whatever at some point. Amazing. Okay. I believe we have time for another question or two. Here's a juicy one. I guess we'll get into it. So, first of all, there's a bit of a, you know, is AI obviously going to take a lot of the manual work of programming away? And if so, does the front-end framework really matter, or will we be at a non-React summit next year? That's a fantastic question. I tend to think that the pace of how fast things feel like they're going is most clear on places like Twitter, but reality is still a little bit not quite there. I think it's going to take years before we stop talking about, you know, people having to maintain React code bases. At the same time, of course, like in framework circles, people are starting to think about what is the next generation of a framework going to look like? Is it going to be more optimized for an agent reading it rather than a human? And do we end up fully optimizing for the agent? Do we meet in the middle and say, well, it's a little bit more optimized for the agent, but the human is still expected to maintain that code in some way? And so I'm very interested in what that spectrum looks like over the next two years. I think we are going to see some framework evolution for sure. Exciting times. Exciting times.

So how about when working across big teams? And I imagine you have some inside info into this. Should teams have a standardized process for working with AI agents and providing MCP servers and things like that? Including, should they all be standardized around using the same AI agent, having the same workflows, etc? Yes, absolutely. One of the big takeaways from a lot of conversations with people at JS Nation and React Summit has been that team level alignment on the workflow, the tools, the models, the MCP servers you're using, the entire tooling workflow is a big missing gap right now. A lot of people are not doing it. What I'll say from the Google side is that that is something that we've been trying to standardize. We went on this journey of everyone kind of using their own flavor of what they liked. It ended up in a great set of educational insights for us. But I genuinely think a lot of alignment around that is going to mean that you have this one set that everybody's optimizing for, and you can make it really awesome. So, yes, I do think that teams should have a standardized process around this. Absolutely. Gotcha. And I guess that sort of follows from the more general conclusion that on teams it's easier if we all standardize around a certain set of tools and workflows. So I suppose this is just the next layer of that. Awesome.

Well, let's see if we can grab one more question here. And the votes are for, could you help us think through context bugs? So are there ways, are there strategies that you use for de-conflicting, perhaps different contexts that's being provided or debugging issues with providing not the right context? Yes. So very often these days when we talk about context engineering, we will give you a very long list of here are all the things that you need to do. You need to include the examples, a clear specification, PRD, documentate like a whole list of things. And the challenge is that even if you are optimizing this context window with all of this rich information, the reality is that things like context rots are a problem. You are not guaranteed that all of that context is actually going to get used. And so if you write, like I was talking to some people, you write a very long spec, a model and the tools might only get through 60 percent of it. You're not guaranteed it's going to get through the end. So one of the things that I do to work around that is I actually split up my context into a number of more granular files in a local folder so that if I notice that a model has only gotten through 60 percent, I just then tag in, okay, steps six, seven, and eight are needed. And I found the weight having to restart from scratch and it's just helped my workflow quite a lot. So that's one thing that I would do. Gotcha. So as always, let's break things up into the smallest possible pieces, I suppose. Amazing. Well, we have so many great questions, but unfortunately we are out of time. So thank you again so much for being here with us and for wrapping up our awesome day. Please give another huge thank you to Addy!