How Good is AI at Coding React (really)?

Así que hoy vamos a cortar a través del bombo de la IA para responder a una pregunta crítica. ¿Qué tan buena es la IA codificando en React? Con suerte, al final de esta charla sabrás exactamente qué puede hacer la IA y qué no puede hacer para tus proyectos de React y cómo aprovecharla de manera efectiva.

Ahora, el 90% de los desarrolladores están usando IA para codificar de alguna manera. En un mundo asistido por IA, el valor de los frameworks como React depende de cuán efectivamente la IA pueda usarlos. Así que si la IA no puede manejar un framework o una biblioteca de UI muy bien, significa que la calidad de las experiencias que puedes construir con ellos va a requerir mucho trabajo manual.

Ahora, gran parte de la calidad del código de IA se reduce al contexto. Quieres exprimir el mayor valor de tu presupuesto de tokens en tu ventana de contexto. Pero el modelo y las herramientas que, ya sabes, las cosas se sientan encima, todas estas capas juegan un papel importante. Ahora muchos de nosotros tenemos lecciones duramente ganadas sobre el uso de la IA para codificar con React.

Algunas más útiles que otras. Por ejemplo, ahora me doy cuenta de que Tony Stark era un codificador de vibraciones. Totalmente lo era. Solo estaba hablando indicaciones a Jarvis y esperando que sus créditos de API no se agotaran. Aprendimos sobre la codificación de vibraciones y su primo la depuración de vibraciones. La IA puede escupir como 10,000 líneas de código en un minuto, pero si todavía estás pasando mucho tiempo depurándolo, puede haber consecuencias.

La IA es un multiplicador de fuerza. Amplifica todo. Así que si tienes buenas prácticas, si tienes malos hábitos, va a amplificar esos. Si tienes requisitos claros, un diseño sólido, código modular, puede ayudar a amplificar eso y ayudarte a enviar cosas más rápido. Si tienes requisitos vagos, la IA generará felizmente miles de líneas de código que tendrás que desenredar.

Ahora, antes de sumergirnos adecuadamente, quiero recordarte las diferencias entre la codificación de vibraciones y la ingeniería asistida por IA. La codificación de vibraciones es rápida y exploratoria, realmente prioriza la velocidad y la experimentación sobre la revisión profunda y el rigor de la ingeniería. Y luego la ingeniería asistida por IA es realmente esa integración metódica de herramientas de IA en un ciclo de vida de desarrollo de software maduro, donde tú, el humano, todavía tienes el control y, en última instancia, la calidad de lo que se está produciendo. Así que hay bastante consejo práctico que podemos obtener de los benchmarks de codificación de IA, y esto es algo de lo que quiero hablar hoy.

Ahora, para medir la calidad de codificación de IA, necesitamos tanto pruebas objetivas de aprobación y falla como juicio humano subjetivo. Los benchmarks objetivos terminan probando mucho la corrección técnica, así que ¿puede la IA resolver problemas reales? Las arenas calificadas por humanos prueban algo que es igualmente importante. ¿Realmente quieren los humanos usar lo que construye la IA?

La pila es tan prevalente en los datos de entrenamiento que la IA puede manejar con relativa competencia muchos prompts de React, pero puede tener dificultades con alternativas. Y esto tiene algunas implicaciones interesantes si resulta que estás usando otras dependencias de terceros o frameworks más nuevos. Así que muchas plataformas de codificación de vibraciones, muchos IDEs, muchas herramientas manejarán una pila que esté usando React, Tailwind, ShadCN, TypeScript bastante bien. Pero para cualquier recién llegado, eso es algo que es una conversación que debemos tener en el ecosistema. Ahora, desde tu perspectiva como ingenieros de React, tal vez esto sea reconfortante.

Creo que lo es. Creo que hay algo positivo que se puede extraer de ahí. La experiencia en React sigue siendo muy valiosa en este momento. El soporte de IA para React solo va a mejorar, pero también significa potencialmente menos diversidad, tal vez una innovación de frameworks más lenta. Quizás eso pueda llevar a un ecosistema más estable.

Pero hay muchas salidas de escape para esto. Si un framework gana tracción, los creadores de IA entrenarán en él. Los desarrolladores humanos podrían deliberadamente usar mejores herramientas y forzar a los modelos de IA a ponerse al día. Pero la versión corta de esto es que los desarrolladores de React están en un buen lugar por ahora.

Ahora, hay un abismo de complejidad del que quiero hablar. La brecha entre cómo los modelos se desempeñan en los puntos de referencia y cómo se comportan en tus bases de código reales puede ser enorme. Podemos idear un nuevo modelo que pueda parecer muy brillante, pero luego lo usas y tal vez tu experiencia sea ligeramente diferente. Quiero mostrarte cómo se ve esa brecha y por qué importa para el trabajo de React. Voy a mencionar algunos puntos de referencia diferentes hoy.

Uno de ellos es Design Arena. Ahora, Design Arena es una plataforma de referencia de código abierto que evalúa las capacidades de diseño de los modelos de codificación de IA al hacer que los usuarios voten sobre sus creaciones en muchas categorías diferentes. Cosas como generación de sitios web, aplicaciones web, agentes, herramientas de codificación de vibraciones. Y al usar una especie de sistema de comparación por pares, donde votas por lo que crees que se ve mejor, genera tablas de clasificación que clasifican los modelos de IA según las preferencias humanas. Y eso ayuda a medir e impulsar mejoras en cosas como calidad de diseño, usabilidad y estética. Así que las personas que están trabajando en modelos pueden echar un vistazo a este tipo de puntos de referencia y luego trabajar en las brechas.

Ahora, uno de los primeros hallazgos de Design Arena aquí es que la IA ha dominado en muchos casos la lógica, pero aún no el gusto. Los modelos pueden resolver tareas de razonamiento complejas y aún producir interfaces de usuario que pueden parecer básicas o tal vez tener fallos de diseño. Cosas como tal vez malas elecciones de color, espaciado inconsistente, sin jerarquía visual. Y para los desarrolladores de React, esto significa que la IA puede implementar tus componentes técnicamente, pero no siempre puede tomar buenas decisiones de diseño por ti de manera autónoma. Y esta división de alguna manera da forma a cómo usas la IA. Para la lógica algorítmica, ya sabes, estructuras de datos, integraciones de API, la IA puede ser realmente poderosa.

Para la lógica algorítmica, ya sabes, estructuras de datos, integraciones de API, la IA puede ser realmente poderosa. Para el diseño visual, ya sabes, decisiones de UX, consideraciones de accesibilidad, tienes que mantener el control como humano.

Así que piensa en ello como que la IA maneja el código que funciona y tú manejas la experiencia que va a deleitar a tus usuarios. Ahora, otro de los hallazgos de Design Arena fue que el andamiaje y las herramientas alrededor del modelo base pueden impulsar gran parte de la dispersión del rendimiento al comparar plataformas de codificación de vibraciones con agentes genéricos. Y esto probablemente significa dos cosas. La primera, el andamiaje y el flujo de trabajo alrededor del modelo base importan bastante para qué tan buena termina siendo la UI.

Y segundo, muchos constructores especializados probablemente comparten los mismos o muy similares modelos base, por lo que sus puntuaciones en este tipo de puntos de referencia pueden agruparse un poco más. Ahora hay un pequeño hueco funcional y estético aquí. La IA puede estructurar UIs de manera bastante razonable, pero aún necesitas el juicio humano si te importa ese gusto, esa calidad y la arquitectura. Así que puede darte algo que funcione, pero no algo de lo que puedas estar completamente orgulloso de enviar a tus usuarios.

Otro reciente fue el trabajo realizado por Vercell en evaluaciones de Next.js, y tienen un tablero de líderes. Observa cosas como qué tan bien los modelos podrían estar implementando soporte para renderizado del lado del servidor, migrando a app router, y así sucesivamente. Y los mejores modelos hoy en este punto de referencia, como Gemini 3 y GPT-5 codecs, aún solo completan alrededor del 42% de esas tareas. Clouds on Thropic está actualmente alrededor del 40%, pero de 50 desafíos, la mejor IA completa completamente alrededor de 20. Así que hay muchas fallas en un framework en el que supuestamente está entrenado. Y creo que esto solo identifica que todavía hay brechas en términos de cuán buenos pueden llegar a ser los modelos y las capas de herramientas.

Podemos mirar otro punto de referencia. Webbench es un punto de referencia de ByteDance, y simula el desarrollo web real. Tiene alrededor de 50 proyectos con 20 tareas secuenciales, y los mejores modelos aún solo resuelven alrededor de una cuarta parte de las tareas. Así que pueden pasar las iniciales, pero luego tropiezan a medida que esa complejidad crece. Y esto es un poco de nuestra verificación de la realidad. Cuando se te pide construir una pequeña aplicación web de principio a fin, la IA de hoy tal vez lo logre un 25% bien en el primer intento, pero mucho del resto de ese trabajo aún requiere intervención humana para obtener una calidad lo suficientemente buena para producción.

También podemos mirar otros puntos de referencia como Suibench. La IA puede manejar tareas simples en este punto de referencia bastante bien, como escribir un componente de formulario, implementar una función de utilidad, pero el rendimiento cae bastante bruscamente con la complejidad. Así que en Suibench Pro, que intenta observar problemas reales a través de bases de código privadas, los mejores modelos aún solo completan alrededor del 20 al 43% de las tareas. Y esa brecha entre el éxito en el punto de referencia y resolver problemas reales arbitrarios es bastante grande. Así que necesitas calibrar tus expectativas a esta realidad. También tenemos Web Dev Arena. Es una plataforma de LM Arena donde los usuarios pueden comparar el rendimiento de diferentes modelos de lenguaje grande en tareas de desarrollo web. En sus pruebas de preferencia humana, Quad lideró el camino a lo largo de 2024. Los usuarios consistentemente prefirieron sus resultados.

Para finales de 2025, hasta hoy, Gemini 3 y GPT-5 habían alcanzado, y eso nos dice que los llamados mejores modelos para diseño ya no son tan obvios. En realidad, tienes muchas opciones reales ahora mismo. Así que ahora que tenemos la visión general, quiero acercarme más. Vamos a desglosar los resultados de algunas arenas diferentes, observando la generación de código de sitios web, agentes, plataformas de vibe coding, componentes de UI, y visualización de datos y 3D. Y para cada uno, vamos a ver a los mejores intérpretes y también extraer algunos consejos prácticos que puedes usar para mejorar tu flujo de trabajo de React cuando usas IA para codificar.

Así que comenzamos con Website Arena de Design Arena. Es una prueba clásica de prompt a sitio web, y es una gran medida de la capacidad de un modelo para equilibrar la generación de código con la sensibilidad de diseño. Y los modelos que lideran este tablero son elogiados por su salida limpia y rápida, o sobresalen en diseños más creativos y complejos. Aquí hay solo algunos de los ejemplos de la última semana o dos. Este es un sitio web para la Chica de Lo-Fi Beats. El modelo ganador fue uno que produjo la página más completa y coherente, tal vez no el diseño más llamativo.

Tenemos un ejemplo de marketing de rendimiento. Este es un buen lugar para mencionar que incluso los modelos más nuevos, como AES Coder 4B, este es un pequeño modelo de cuatro mil millones de parámetros entrenado por Microsoft Research. Usan Design Arena como referencia en su documento. Aquí hay una comparación de paneles de CRM. Las mejores entradas aquí están bastante cerca en términos de calidad, pero lo que las separa no es necesariamente la corrección, sino detalles como jerarquía, espaciado, y qué tan rápido puedes escanear los métricos clave en el diseño. Ahora, si prestaste atención a algunos de esos diseños que te estaba mostrando, podrías estar preguntándote, ¿por qué hay tanto púrpura en los diseños generados por IA? Como, ¿en serio?

Muchos de nosotros hemos estado usando cosas como Tailwind mucho en los últimos años. Tal vez haya contribuido un poco. Pero hay algunas opciones diferentes para cómo resolver esto. Anthropic recientemente dejó de intentar solucionar el problema púrpura en el entrenamiento, y lo movieron a la capa de la aplicación con habilidades. Algunos problemas de LLM se resuelven mejor con herramientas que con pesos de modelo. En este caso, simplemente usan habilidades. Las habilidades son archivos markdown que Cloud lee bajo demanda. Esto puede ayudarte a sortear este problema.

Si quieres revisar sus habilidades de diseño de front-end, esto puede ayudarte a sortear ese problema de generación de sitios web púrpura. A medida que avanzamos, quiero compartir algunos de los consejos que han estado funcionando bien para mí y las ideas que he extraído de estos. No voy a poder repasarlos todos, pero para sacar el máximo provecho de la IA para construir sitios con React, necesitas ser realmente muy específico con tus instrucciones. Idealmente, define todo, desde el diseño general y la estructura de tus componentes hasta el enrutamiento y tu comportamiento responsivo. Aplica tu sistema de diseño existente, si tu equipo tiene uno, y los estándares de codificación para asegurar que la consistencia y la calidad estén en su lugar.

También podemos generalizar aquí. Esto no es solo sobre sitios web, por supuesto, pero el desarrollo de usar React para aplicaciones web, para componentes de UI, para todo tipo de cosas se puede generalizar un poco aquí. La IA puede ser un socio de codificación poderoso, pero realmente necesitas gestionarla como a un desarrollador junior. Como dije, sé muy explícito. Define tus APIs de componentes, tus estados, tu arquitectura, desde el principio, si quieres guiar a la IA. Solo al codificar más de lo que quieres ver en las convenciones que tiene tu equipo, puedes mantener la salida de la IA consistente y en línea con la marca, especialmente si puedes comprometer esas cosas al repositorio para que puedas seguir reutilizándolas.

Solo al codificar más de lo que quieres ver en las convenciones que tiene tu equipo, puedes mantener la salida de la IA consistente y en línea con la marca, especialmente si puedes comprometer esas cosas al repositorio para que puedas seguir reutilizándolas.

A continuación, tenemos Agent Arena, y esto es un aumento en la complejidad. No solo estamos generando un solo archivo o una sola vista para un sitio web aquí, sino que estamos evaluando la capacidad de una IA para actuar como un desarrollador. Creando archivos, ejecutando pruebas, ejecutando navegadores, depurando. Aquí es donde vemos el poder de los bucles de agentes. Los mejores desempeños aquí están realmente construidos sobre modelos específicos de código poderosos.

Ahora, revisar código que es claramente generado por IA ha sido probablemente la segunda cosa más deprimente que he encontrado este año en el trabajo, siendo la primera los desarrolladores tratando de explicarlo. Pero creo que hay mucho que podemos aprender de este tipo de experiencias que todos tenemos. Ahora, si estás usando un agente, de nuevo, sé específico. Notarás que hay un tema aquí. Sé específico, sé preciso en lo que quieres. Usa un plan, usa una especificación, indícalos en cualquier contexto adicional que tengas, como registros y monitores. En última instancia, mantén la supervisión humana.

Puedes imponer cosas como pequeñas solicitudes de extracción para revisión, usar unidades de trabajo atómicas. Puedes requerir pruebas unitarias con cada corrección. Y realmente solo asegúrate de que el agente sea un miembro productivo pero supervisado de tu equipo.

Hablemos sobre el contexto. La mayoría de los fallos de los agentes no son necesariamente fallos del modelo ya, sino que son fallos de contexto. Si el agente no ve los registros, pruebas o restricciones correctas, puede hacer cambios seguros pero incorrectos. Y muchos de nosotros hemos probado la ingeniería de prompts, ¿verdad? Así que ajustar palabras sin fin solo para ver fallos.

Pero como muestra este iceberg, los problemas reales a menudo están debajo de la superficie con un contexto mal gestionado. Ahora, la ingeniería de contexto, muchos de los que están viendo esto probablemente han aprendido sobre esto. Se trata de el arte y la ciencia de llenar la ventana de contexto con la información justa necesaria para guiar el rendimiento de un agente. Hay muchas capas en esto, pero idealmente incluyendo especificaciones claras, ejemplos, datos, referencias a documentos más actualizados. Hay mucho que puedes incluir. Puedes hacer contexto visual, capturas de pantalla. Cualquier cosa que el agente no pueda ver es de alto valor.

Aquí tienes una gran plantilla para la ingeniería de contexto de Anthropic. Es algo genial para compartir en redes sociales y luego olvidar por completo. Pero estoy deseando que más y más de estas ideas se codifiquen en nuestras herramientas. Así que, probablemente no tengas mucho control sobre la calidad de los modelos base que usas, pero puedes dirigir las herramientas a su alrededor. Así que, quiero compartir algunos consejos sobre eso también.

Así que, primero, tenemos Context-7. Vamos a hablar un poco sobre MCPs. Entonces, Context-7 extrae documentos y ejemplos específicos de versión frescos directamente de los sitios de las bibliotecas y los inyectará en el conjunto de trabajo del modelo. Eso detiene al asistente de adivinar APIs o usar fragmentos obsoletos de los datos de entrenamiento del modelo. Es realmente poderoso. Puedes guiarlo hacia temas como routing o hooks y simplemente limitar cuánto traes. Así que, Context-7 es algo que recomiendo que la gente use.

Next.js también tiene un servidor MCP de DevTools. Esto se conectará a un agente para que pueda pedir datos reales sobre tu aplicación en ejecución, errores de compilación o tiempo de ejecución actuales, rutas y diseños, metadatos de componentes, acciones del servidor. Y también viene con una base de conocimiento específica de Next.js que puede ayudar una vez más a trabajar alrededor de cualquier brecha en la calidad del modelo base. En mi equipo, recientemente lanzamos Chrome DevTools MCP. Esto le da a tu agente de codificación de IA ojos y manos en un navegador real. Así que, puede abrir páginas, hacer clic en flujos, leer registros de consola y red. Realmente puede ver en tiempo de ejecución lo que se ha renderizado en el navegador. Y eso solo te ayuda con un ciclo de calidad general, mejorar lo que se está generando.

Ahora, si quieres conectar todo esto junto, aquí tienes un flujo de trabajo que funciona. Context-7 puede darle a tu asistente el conocimiento adecuado. Next DevTools puede darle la verdad de la aplicación. Y DevTools MCP puede, de alguna manera, probar el resultado en un navegador real. Así que, usados juntos, conviertes a un asistente que adivina en un codificador de bucle cerrado y un depurador que puede citar fuentes, colocar cambios correctamente y verificar resultados antes de que presiones commit.

A continuación, vamos a ver unas... Disculpa. A continuación, vamos a ver herramientas de Vive coding. Así que, estas son plataformas diseñadas para la creación rápida de productos impulsados por prompts.

Y el objetivo aquí no es solo crear código, sino un resultado cohesivo y bien diseñado. Así que, algunos ejemplos aquí, un sitio de portafolio para un fotógrafo de gatos, un panel de investigación oceánica, un panel de experiencia de desarrollador, qué ver según tu estado de ánimo. Ahora, aquí tienes algunos consejos si estás usando Vive coding. Nuevamente, realmente, me gusta usar estas herramientas como generadores de prueba de concepto de ideas para MVPs para explorar diseños e interacciones, pero siempre estoy preparado para realmente refactorizar lo que se está generando por las plataformas de Vive coding. Y trato de consolidar el código generado en mi arquitectura existente.

Y creo que hay algo realmente poderoso en eso, especialmente si comienzas con una especificación de producto sólida y un sistema de diseño bloqueado. También tenemos la arena de componentes de UI. Esta es una de las más directamente aplicables al trabajo diario de un desarrollador de React. La tarea aquí es realmente generar componentes aislados y reutilizables. Y debido a que el alcance está tan enfocado, la tasa de éxito es un poco más alta y el resultado a menudo está muy cerca de estar listo para producción. La tabla de clasificación aquí muestra una mezcla de modelos con Gemini 3 valorado por su pulido y algunos modelos abiertos siendo un contendiente sorprendentemente fuerte.

Y la gran conclusión de la arena de diseño para componentes de UI es que los modelos han dominado en gran medida la corrección lógica. El gusto, nuevamente, todavía requiere un poco de trabajo. Pueden conectar tus props, tu estado, tu flujo de datos, pero aún pueden elegir colores pobres, fuentes, espaciado inconsistente y una jerarquía visual débil. Así que eso significa que puedes confiar en que se acerque bastante a tu estructura y comportamiento, pero aún necesitas tomar las decisiones finales de diseño. Y hay varios ejemplos aquí. Así que estos son diferentes modelos creando componentes como una tarjeta para información de registro, una galería de imágenes deslizable, hojas apiladas, un componente de mercado de valores.

Una cosa que quiero que te lleves de esto es que comparar la salida visual entre diferentes modelos puede ser realmente poderoso, especialmente si tu equipo se ha inclinado hacia un modelo, pero tenías curiosidad si podría ser diferente o mejor con uno de los otros. Algunos consejos para la generación de componentes de UI. A menudo los modelos van a requerir una guía específica de componentes de UI para implementar aspectos cruciales, como accesibilidad, consistencia con los patrones de mejores prácticas de tu equipo, separando las preocupaciones de estilo y creando comportamientos componibles. Y por último de nuestras arenas están las arenas de visualización de datos y 3D. La visualización de datos y 3D empujan a los modelos a una generación más estructurada y compleja. Así que para los desarrolladores de React, a veces estaríamos construyendo una página de aterrizaje o un sitio y necesitaremos incluir experiencias interactivas allí.

Los asistentes de AI pueden ayudar aquí, pero a menudo requiere una estrategia de integración ligeramente diferente. Así que hay algunos ejemplos aquí. Nuevamente, un coche rojo 3D junto a un hotel. Este es Gemini siendo capaz de crear un hombre 3D con diferentes tipos de poses y acciones que están completas. Un edificio moderno 3D, una aldea navideña. Y AI realmente puede ayudar mucho con la visualización de datos y 3D, pero solo si eres, nuevamente, muy específico. Si nombras las bibliotecas exactas que deseas, como React 3 fiber o ReChart. Si describes la escena o gráfico en términos muy concretos, puedes obtener mucho de esto. Si pides activos de baja poligonización y carga diferida primero, para que puedas mantener el rendimiento bajo control, eso también es bastante bueno.

Deja que el modelo genere tus mallas, tus datos y tu configuración, pero aún estás un poco en control de las interacciones, la tasa de fotogramas y los fallbacks. Ahora he estado bromeando sobre el vibe coding. Como autor de O'Reilly, trato de no tomarme demasiado en serio. Todos estamos aprendiendo. Todos estamos cometiendo errores. Estamos dominando cómo deshacer nuestros desastres. Y en última instancia, por qué el código de AI funciona o falla se reduce a esta pila. Comprender esta pila te ayuda a depurar fallos y mejorar resultados.

Cuando el código de AI funciona maravillosamente, usualmente múltiples capas están bien alineadas. Y cuando falla, puedes rastrearlo hasta un eslabón débil. Un eslabón débil. Ahora usar AI para productividad, para velocidad, no significa nada si las ruedas van a caerse en el camino. La velocidad no significa nada sin calidad. Y cuando todas estas capas interactúan bien, puedes obtener mejores resultados. Usualmente es porque el modelo era fuerte, le diste un buen prompt, tenía el contexto adecuado de la documentación y pruebas, le diste algunas iteraciones para resolver los problemas. Y cuando falla, casi puedes señalarlo a una de estas capas siendo débil. Así que modelo fuerte, buen prompt, contexto relevante. Y si no estás solo haciendo un intento, puedes obtener una salida decente. Pero por el contrario, esos fallos, nuevamente, se reducen a estos eslabones débiles. Así que si usaste un modelo general en lugar de uno especializado en código, si tu prompt era ambiguo, si no incluías contexto adicional, puedes terminar en un lugar donde la calidad no es excelente. Pero la buena noticia es que todo esto es accionable.

un lugar donde la calidad no es excelente. Pero la buena noticia es que esto es algo que se puede solucionar. Puedes usualmente arreglar al menos algunos de los factores de esto por tu cuenta. Espero que algunas de estas sean lecciones que tomes y que realmente encuentres útiles.

Este es mi flujo de trabajo de depuración actual en una imagen. Es como 21 millas de decirle al cursor que por favor arregle y de alguna manera nunca tomar el detalle de un cuarto de milla para entender cómo realmente funciona algo. Creo que hay mucho en las lecciones de hoy que pueden aplicarse a muchos de nosotros, independientemente de dónde estemos en nuestras carreras. Y este es como el nuevo estado de flujo para el desarrollo asistido por AI. Es donde este flujo de trabajo simplemente se vuelve una segunda naturaleza. Ya no solo estás tratando de escribir.

Estás orquestando la creación de código, estás haciendo prompts, revisando, probando, refinando y repitiendo. Y creo que es un poco diferente del desarrollo tradicional, pero es igualmente enfocado y productivo. Ahora, si has estado prestando atención un poco, mencioné algunas cosas que acabamos de lanzar hoy. Acabamos de lanzar Gemini 3, que es el mejor modelo de Google para desarrollo web, vibe coding y tareas agenticas. Espero que algunas personas lo revisen. Estamos orgullosos de este modelo. Creemos que es bastante bueno para el desarrollo en React también. Gemini 3 encabeza la arena de diseño en este momento en múltiples categorías, incluyendo la arena de sitios web, componentes de UI y la arena de diseño 3D. También ha encabezado la tabla de clasificación de la arena de desarrollo web, obteniendo un impresionante 1487 ELO en eso. Y quería mostrarte ejemplos muy rápidos de esto en acción. Este es Gemini 3.

Esto no es solo un sitio web que parece que AI necesariamente lo generó. Tiene un poco de gusto, un poco de estilo. Se siente un poco único para la persona que lo estaba construyendo. Y hay muchos ejemplos ahora disponibles desde esta mañana que puedes revisar. Este es otro sitio que incluyó un encabezado 3D genial. Estas interacciones a medida que navegas por la página. También tenemos un ejemplo de este hermoso sitio de tipografía con animaciones que muestran el contenido. Widgets interactivos para entender estas diferentes secciones y jugar con el contenido. Nuevamente, estamos empezando a mejorar un poco en la estética del diseño en general.

Si pensaste que cubrimos mucho hoy, estás absolutamente en lo correcto. Lo hicimos. Lo importante es ser proactivo en el uso de las herramientas que están a tu disposición. Personalmente creo que el futuro es brillante. Tienes más ventaja que nunca como desarrolladores de React. Espero que utilices los benchmarks, algunas de las técnicas que compartí, y el entendimiento que has obtenido de toda la conferencia para construir mejores productos más rápido. Mantente curioso sobre AI. Las cosas se están moviendo rápido, pero siempre recuerda que tú eres el arquitecto, tú eres el diseñador, tú eres quien asegura que se construyan experiencias de usuario de calidad. Gracias por estar aquí. Ve y construye cosas increíbles. Gracias.

Tenemos algunas preguntas llegando, y una de ellas se relaciona con algo que creo mencionaste un par de veces durante la charla, que es la depuración. ¿Dónde estamos en términos de conseguir que AI depure por nosotros? El KD, el que hace la pregunta también quiere simplemente pararse y mirar. ¿Podemos llegar allí? Sí, sí podemos. Creo que con Chrome DevTools MCP, Playwright MCP, muchos de diferentes MCP de navegadores, y especialmente IDEs como Cursor, como otras herramientas que comienzan a integrar estas ideas por defecto. Veo que estamos llegando a un lugar donde los agentes de AI pueden depurar automáticamente, y veo que eso es parte de este ciclo de calidad automatizado, donde si estás solicitando, simplemente usan automáticamente las herramientas correctas, obtienen la información correcta del navegador, de cualquier otro lugar que necesite contexto, y pueden evitar que los humanos tengan que depurar. Genial. Aunque nuevamente, todos todavía necesitamos estar un poco conscientes de cómo esto, me gusta el contexto de AI como programador en pareja, está trabajando junto a nosotros. Increíble.

Bueno, entremos en lo, ya sabes, lo que está en la mente de todos es, ¿dónde se detiene? ¿Se detiene? ¿Qué tan cerca crees que estamos de alcanzar los límites de lo que AI puede hacer por nosotros? Creo que estamos realmente lejos de alcanzar los límites de AI. Creo que una conclusión de algunas de las cosas de las que hablé hoy es que incluso nuestra capacidad para medir si AI está generando código que es de calidad suficientemente alta, algo que un ingeniero senior escribiría para una base de datos de producción, una base de código de producción, o alguien en una empresa, siento que todavía hay un largo camino por recorrer, y así veo que los modelos todavía tienen un poco de pista por delante para mejorar. Queda mucho trabajo por hacer, amigos. Bien, bueno, supongo que, hablando de generar diseños con buen gusto, tenemos una pregunta que, bueno, supongo que contiene una pregunta implícita. ¿Generaste imágenes para tus diapositivas? Y si es así, ¿qué herramienta usaste? Las dibujé todas a mano. No, si viste alguna imagen de mis diapositivas, fueron generadas usando Gemini. Usamos NanoBanana para estas, y si te gusta NanoBanana, mantente atento a otros anuncios esta semana. Oh, mantente atento, amigos. Increíble, y, por supuesto, ya sabes, estamos probando nuestras propias herramientas. Estamos usando las herramientas para hablar sobre las herramientas para que todos podamos mejorar en las herramientas. Increíble. Bien, veamos. Tenemos una pregunta aquí sobre seguridad y arquitectura y estos otros aspectos de nivel superior de una base de código. Entonces, ¿cuál es la regresión de seguridad o arquitectónica más común en los PRs o cambios generados por AI en React, y cómo la revisarías? Creo que hay dos partes aquí. Así que para las regresiones arquitectónicas, lo que a menudo veo, y hemos hecho algunos estudios al respecto, es que los modelos pueden generar código que parece aproximadamente correcto pero puede que no esté siguiendo los patrones del equipo correctamente, porque no necesariamente está mirando el contexto completo de tu base de código, todos los PRs, como esa historia, esa historia del equipo. Y así que creo que ese es un lugar donde necesitamos aplicar un poco más de diligencia durante la revisión de código. Tengo la esperanza de que en la capa de herramientas, podamos aprovechar CI, podamos aprovechar más bots para prestar atención a eso y señalarlo como una preocupación antes de que las personas realmente revisen manualmente el código. Los problemas de seguridad más comunes son en realidad cosas muy básicas, y parte de ello es porque ahora hemos aumentado el mercado total direccionable de quién puede construir para la web. Tenemos muchas personas codificando que no tienen un profundo conocimiento técnico, y así incluso cosas como problemas de XSS, filtraciones de claves API del lado del cliente, todos estos son los problemas comunes más grandes en este momento. Hay muchos más matices, pero esos son los realmente grandes, porque ahora tenemos esta enorme audiencia construyendo. Entendido. Bien.

Bueno, probablemente tendremos algunos como tablas de clasificación para Pwn.AI o lo que sea en algún momento. Increíble. Bien. Creo que tenemos tiempo para otra pregunta o dos. Aquí hay una jugosa. Supongo que vamos a entrar en ello. Entonces, en primer lugar, hay un poco de, ya sabes, ¿va AI obviamente a quitar mucho del trabajo manual de la programación? Y si es así, ¿realmente importa el framework de front-end, o estaremos en una cumbre no-React el próximo año? Esa es una pregunta fantástica. Tiendo a pensar que el ritmo de lo rápido que se siente que las cosas están avanzando es más claro en lugares como Twitter, pero la realidad aún no está del todo allí. Creo que pasarán años antes de que dejemos de hablar sobre, ya sabes, personas teniendo que mantener bases de código de React. Al mismo tiempo, por supuesto, como en los círculos de frameworks, la gente está comenzando a pensar en cómo será la próxima generación de un framework. ¿Va a estar más optimizado para que lo lea un agente en lugar de un humano? ¿Y terminamos optimizando completamente para el agente? ¿Nos encontramos en el medio y decimos, bueno, está un poco más optimizado para el agente, pero aún se espera que el humano mantenga ese código de alguna manera? Y estoy muy interesado en cómo se verá ese espectro en los próximos dos años. Creo que vamos a ver algo de evolución de frameworks, seguro. Tiempos emocionantes. Tiempos emocionantes.

¿Y qué tal cuando se trabaja en grandes equipos? Y me imagino que tienes algo de información privilegiada sobre esto. ¿Deberían los equipos tener un proceso estandarizado para trabajar con agentes de AI y proporcionar servidores MCP y cosas así? Incluyendo, ¿deberían todos estar estandarizados en torno al uso del mismo agente de AI, teniendo los mismos flujos de trabajo, etc.? Sí, absolutamente. Una de las grandes conclusiones de muchas conversaciones con personas en JS Nation y React Summit ha sido que la alineación a nivel de equipo en el flujo de trabajo, las herramientas, los modelos, los servidores MCP que estás usando, todo el flujo de trabajo de herramientas es una gran brecha que falta en este momento. Mucha gente no lo está haciendo. Lo que diré desde el lado de Google es que eso es algo que hemos estado tratando de estandarizar. Emprendimos este viaje de que todos usaran su propio sabor de lo que les gustaba. Terminó en un gran conjunto de ideas educativas para nosotros. Pero realmente creo que mucha alineación en torno a eso significará que tienes este conjunto único para el que todos están optimizando, y puedes hacerlo realmente increíble. Así que, sí, creo que los equipos deberían tener un proceso estandarizado en torno a esto. Absolutamente. Entendido. Y supongo que eso se deriva de la conclusión más general de que en los equipos es más fácil si todos nos estandarizamos en torno a un cierto conjunto de herramientas y flujos de trabajo. Así que supongo que esto es solo la siguiente capa de eso. Increíble.

Bueno, veamos si podemos tomar una pregunta más aquí. Y las votaciones son para, ¿podrías ayudarnos a pensar en los bugs de contexto? Entonces, ¿hay maneras, hay estrategias que usas para resolver conflictos, quizás diferentes contextos que se están proporcionando o problemas de depuración con proporcionar el contexto incorrecto? Sí. Así que muy a menudo en estos días cuando hablamos de ingeniería de contexto, te daremos una lista muy larga de aquí están todas las cosas que necesitas hacer. Necesitas incluir los ejemplos, una especificación clara, PRD, documentar como una lista completa de cosas. Y el desafío es que incluso si estás optimizando esta ventana de contexto con toda esta información rica, la realidad es que cosas como la degradación del contexto son un problema. No tienes garantía de que todo ese contexto realmente se vaya a usar. Y entonces si escribes, como estaba hablando con algunas personas, escribes una especificación muy larga, un modelo y las herramientas podrían solo llegar al 60 por ciento de ella. No tienes garantía de que vaya a llegar al final. Así que una de las cosas que hago para solucionar eso es que realmente divido mi contexto en varios archivos más granulares en una carpeta local para que si noto que un modelo solo ha llegado al 60 por ciento, simplemente entonces etiqueto, bien, los pasos seis, siete y ocho son necesarios. Y encontré el peso de tener que reiniciar desde cero y eso simplemente ha ayudado mucho a mi flujo de trabajo. Así que eso es algo que haría. Entendido. Así que como siempre, dividamos las cosas en las piezas más pequeñas posibles, supongo. Asombroso. Bueno, tenemos tantas preguntas geniales, pero desafortunadamente se nos ha acabado el tiempo. Así que gracias de nuevo por estar aquí con nosotros y por cerrar nuestro increíble día. ¡Por favor, den otro gran agradecimiento a Addy!