Claude Opus 5 supera a GPT-5.6 y Grok 4.6 en una prueba de desarrollo web

Una prueba con el mismo proyecto web puso a Claude Opus 5, GPT-5.6 y Grok 4.6 frente a los problemas que suelen separar el código funcional de una aplicación bien diseñada.
***

• Según la prueba descrita, Claude Opus 5 fue el modelo más sólido en arquitectura y experiencia de usuario.
• Grok 4.6 destacó por su velocidad, pero presentó una interfaz con controles de filtrado visualmente saturados.
• GPT-5.6 construyó una base sólida, aunque recibió críticas por su ventana modal, la tipografía pequeña y el arrastre limitado de tarjetas.

La capacidad de una inteligencia artificial para generar código en segundos ya no constituye, por sí sola, una medida suficiente para evaluar su utilidad profesional. En aplicaciones complejas, el reto consiste en tomar decisiones coherentes de arquitectura, anticipar errores de interacción y mantener una experiencia de usuario que no se deteriore cuando el proyecto crece. Una prueba comparativa con Claude Opus 5, GPT-5.6 y Grok 4.6 intentó medir precisamente esa diferencia.

El ejercicio consistió en entregar a los tres modelos el mismo encargo, sin instrucciones adicionales ni correcciones durante el proceso. El proyecto exigía construir desde cero un tablero Kanban colaborativo y listo para producción con React, TypeScript y Tailwind CSS, además de incorporar varias funciones que obligan a coordinar diseño, estado y comportamiento. El resultado favoreció a Claude Opus 5 por la forma en que abordó el sistema completo, aunque cada modelo mostró fortalezas concretas.

Una prueba más exigente que generar código básico

El encargo evitó deliberadamente una aplicación sencilla, como una lista de tareas, porque ese tipo de proyecto permite que casi cualquier modelo moderno produzca una demostración convincente. En su lugar, la prueba pidió un tablero colaborativo con estado normalizado, movimiento de tarjetas mediante arrastrar y soltar, actualizaciones optimistas y mecanismos de reversión cuando una operación falla. Esas condiciones exigen pensar en la relación entre la interfaz y la lógica interna, no solamente escribir componentes visualmente atractivos.

También se solicitó a cada modelo que actuara como un ingeniero senior y que diseñara la arquitectura antes de comenzar a programar. Esa instrucción buscaba observar si el sistema identificaba dependencias, organizaba el flujo de datos y establecía una estrategia antes de generar archivos y componentes. En una aplicación de este tipo, una decisión aparentemente menor puede afectar la consistencia de las tarjetas, el rendimiento del tablero y la forma en que el usuario recupera una acción fallida.

La comparación se realizó en los entornos que correspondían a cada herramienta. Claude Opus 5 se probó en la aplicación oficial de Claude, GPT-5.6 se ejecutó dentro de ChatGPT y Grok 4.6 se utilizó en Cursor. La evaluación dio a los tres modelos el mismo prompt y no ofreció pistas posteriores, con el objetivo de observar su desempeño autónomo.

El criterio no se limitó a comprobar si el código podía ejecutarse o si la pantalla inicial parecía terminada. La evaluación consideró la claridad de los controles, la facilidad para crear y mover tareas, la jerarquía visual de la información y la capacidad del diseño para sostener un flujo de trabajo real. Bajo esa perspectiva, la velocidad de generación dejó de ser una ventaja decisiva frente a la calidad de las decisiones tomadas durante la construcción.

Grok 4.6 priorizó la velocidad, pero saturó la interfaz

Grok 4.6 fue el modelo que comenzó con mayor rapidez dentro de Cursor. En cuestión de segundos creó la estructura inicial y empezó a transmitir código directamente al espacio de trabajo, sin detenerse demasiado en una fase visible de planificación. Esa respuesta veloz puede resultar atractiva para quienes buscan un prototipo inmediato, especialmente cuando la prioridad es obtener una primera versión funcional en el menor tiempo posible.

En el plano visual, el modelo acertó con varios elementos básicos del tablero. La interfaz adoptó una estética oscura y moderna, las columnas conservaron proporciones equilibradas y las tarjetas mostraron la información sin verse comprimidas. Las etiquetas de prioridad, las fechas de entrega y los elementos de listas de verificación aparecieron organizados, lo que permitió que la primera impresión fuera positiva.

El problema apareció en la zona superior destinada a filtrar las tareas. En vez de construir una barra de búsqueda sencilla o menús desplegables modulares, Grok 4.6 colocó una acumulación de botones sin una jerarquía clara, creando un encabezado visualmente cargado. El defecto no era meramente estético, porque un área de controles saturada puede dificultar la navegación y obligar al usuario a buscar entre opciones que deberían estar agrupadas.

La comparación hizo evidente que generar una interfaz rápidamente no equivale necesariamente a resolver bien su organización. Claude Opus 5 y GPT-5.6 distribuyeron ese espacio de manera más inteligente, mientras Grok 4.6 dejó una sensación de desorden pese a haber avanzado primero.

GPT-5.6 construyó una base sólida con fricciones importantes

GPT-5.6 ofreció una estructura general convincente y resolvió una de las carencias observadas en otros resultados al incluir desde el principio una barra lateral plegable. Ese recurso facilitaba la organización del espacio y podía servir para moverse entre diferentes proyectos o tableros. El menú superior de filtros también apareció ordenado, una decisión que permitió evitar la acumulación de controles que perjudicó a Grok 4.6.

Sin embargo, la experiencia empezó a perder calidad cuando se probó el tablero en lugar de observarlo superficialmente. La tipografía utilizada en las tarjetas y en los metadatos resultó demasiado pequeña, por lo que información importante quedaba menos accesible de lo esperado. En una herramienta colaborativa, reducir demasiado el tamaño de textos secundarios puede dificultar la lectura rápida.

La apertura de una tarjeta produjo otra fricción notable. En lugar de mostrar los detalles en un panel lateral o mediante una transición que conservara visible el tablero, GPT-5.6 desplegó una ventana modal de gran tamaño en el centro de la pantalla. Ese elemento bloqueaba prácticamente toda la vista de trabajo y convertía una acción habitual en una interrupción más pesada.

El arrastrar y soltar fue el punto más criticado del resultado de GPT-5.6. El sistema no permitía tomar la tarjeta desde cualquier zona y moverla naturalmente entre columnas, sino que restringía la acción a un pequeño control de seis puntos ubicado en una esquina. Si el usuario no acertaba con precisión en ese espacio, la tarjeta no se movía.

Claude Opus 5 destacó por la arquitectura y los detalles

Claude Opus 5 tardó considerablemente más en completar el encargo, pero el tiempo adicional se reflejó en una propuesta más coherente. Desde la primera revisión, el tablero presentó una combinación más pulida de diseño, controles y jerarquía visual. La evaluación concluyó que el modelo no se limitó a producir una pantalla atractiva, sino que tomó decisiones que mostraban una comprensión más amplia del flujo de trabajo.

Entre sus aciertos estuvo un interruptor de un solo clic para cambiar entre los temas claro y oscuro. Las tarjetas también utilizaron indicadores visuales pequeños e intuitivos para destacar las tareas de prioridad crítica, sin esconder la información relevante en menús secundarios. Esa solución permitía identificar rápidamente los asuntos urgentes y mantenía el diseño limpio.

La sección de filtros siguió el mismo criterio de organización. Claude Opus 5 separó las opciones por responsable, nivel de prioridad y etiquetas, con una disposición más modular que la fila de botones creada por Grok 4.6. El resultado redujo el ruido visual y ofreció una ruta más clara para localizar tareas específicas.

La diferencia más significativa apareció al crear una tarea nueva. En vez de abrir una ventana modal o enviar al usuario a otra pantalla, el sistema insertó un espacio provisional al final de la columna correspondiente, donde era posible escribir el título y confirmarlo con la tecla Enter. Después, el usuario podía abrir la tarjeta completa para añadir descripciones y listas de verificación, un flujo breve que preservaba el contexto del tablero.

La solución no fue perfecta: la evaluación señaló que habría sido preferible contar con una barra lateral plegable dedicada a cambiar entre varios proyectos o tableros. Aun con esa carencia, Claude Opus 5 logró el mejor equilibrio entre estructura, apariencia y uso cotidiano. Su ventaja no provino de terminar primero, sino de dedicar más atención a los pequeños momentos que determinan si una aplicación se siente natural.

Causas de movimientos recientes

La prueba no aporta datos sobre movimientos recientes de precios ni permite atribuir cambios en el mercado a estos modelos. Por tanto, no hay un catalizador de mercado identificado que deba incorporarse en esta sección.

La diferencia entre escribir código y ejercer ingeniería

El experimento plantea una distinción relevante para cualquier equipo que utilice IA en desarrollo de software. Un modelo puede generar sintaxis válida, levantar una interfaz atractiva y cumplir parte de los requisitos visibles, pero eso no garantiza que haya resuelto los problemas de navegación, accesibilidad operativa o mantenimiento que aparecen en un producto real.

Grok 4.6 mostró que la rapidez puede acelerar la creación de un prototipo, aunque también puede dejar controles desordenados cuando el modelo no dedica suficiente tiempo a planificar. GPT-5.6 presentó una base más estructurada y añadió una barra lateral útil, pero sus decisiones sobre la ventana modal, la tipografía y el control de arrastre introdujeron fricciones en funciones esenciales. En ambos casos, el código inicial parecía prometedor hasta que la interacción cotidiana reveló sus limitaciones.

Claude Opus 5, en cambio, trató el proyecto como un sistema que debía ser utilizado y no únicamente como una colección de componentes. La creación en línea, los indicadores de prioridad, la organización de filtros y el cambio de tema mostraron una atención especial a la continuidad del trabajo. Esa mirada explica por qué la evaluación lo consideró el modelo más cercano al comportamiento de un ingeniero senior, aun cuando necesitó más tiempo para entregar su resultado.

La conclusión no convierte la velocidad en un defecto ni demuestra que un modelo pueda reemplazar por completo a un equipo de ingeniería. El resultado sí sugiere que las comparaciones basadas exclusivamente en rapidez o en la cantidad de código generado pueden pasar por alto la parte más costosa del desarrollo: decidir qué debe ocurrir en cada interacción y cómo evitar que el usuario pague por una mala elección.

Para proyectos de producción, la supervisión humana continúa siendo necesaria, especialmente en pruebas, seguridad, accesibilidad y consistencia de datos. Aun así, la prueba ofrece una señal clara sobre el valor práctico de los modelos: cuando el encargo exige arquitectura y criterio, el ganador puede ser el sistema que dedica más atención a planificar antes de escribir código.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín