Claude Opus 5.5 frente a GPT-6.1 Sol en proyectos reales: mi impresión personal

Quería construir una aplicación para hablar con mis agentes desde el móvil. Puse a trabajar a los dos modelos en el proyecto. Claude Opus 5.5 empezó dos horas después que GPT-6.1 Sol y terminó una hora antes. Además, el prototipo de Claude me pareció mejor.

No presento ese resultado como una prueba científica. Un proyecto concreto depende del encargo, del contexto que recibe cada sistema, de sus herramientas y de las decisiones que se toman durante el trabajo. Pero el episodio puso nombre a una diferencia que ya había visto en otros proyectos.

GPT-6.1 Sol puede hacer un trabajo excelente cuando le doy una tarea concreta. Sin embargo, algunos proyectos que he iniciado con Sol al frente de toda la coordinación han acabado atascándose. Al revisar lo ocurrido y pasar la orquestación a Claude Opus 5.5, he conseguido que vuelvan a avanzar. Cuando empiezo con Opus en ese papel, mi impresión es que llego antes y mejor al resultado que buscaba.

Ser buen trabajador no garantiza ser buen coordinador

Ejecutar una tarea y dirigir un proyecto exigen cosas distintas. Un trabajador puede recibir un objetivo delimitado, desarrollar una solución y entregarla para revisión. El coordinador tiene que mantener a la vista el conjunto: decidir qué va primero, repartir trabajo, detectar bloqueos, comprobar que las piezas encajan y saber cuándo algo está realmente terminado.

Esa distinción me ha resultado más útil que preguntar «¿cuál es el mejor modelo?». Para ciertos encargos, GPT-6.1 Sol es un trabajador muy eficaz. Para coordinar varios frentes, auditar un proyecto detenido y decidir el siguiente paso, mi experiencia reciente favorece a Claude Opus 5.5.

«Jefe» es aquí una forma de describir una función dentro del sistema. La decisión final y la responsabilidad siguen siendo mías.

Compararlos en paralelo enseña más que elegir por costumbre

Mi consejo es no casarse con ningún modelo. Si un proyecto importa, merece la pena dar el mismo encargo a dos IA y comparar lo que entregan. No basta con mirar cuál respondió primero o cuál escribió más código. Me interesa saber cuál produjo antes un resultado utilizable, qué correcciones hicieron falta, cuánto tiempo tuve que dedicar a revisar y qué problemas aparecieron al integrar el trabajo.

Para que esa comparación enseñe algo, los modelos deberían partir, en lo posible, del mismo objetivo, los mismos materiales y los mismos criterios de aceptación. También hay que conservar los encargos y las versiones. De otro modo, es fácil atribuir al modelo una ventaja que quizá procedía de una instrucción mejor o de disponer de más contexto.

La aplicación móvil me dio una señal clara para mis decisiones, pero no cierra el debate. Volvería a hacer pruebas con otros proyectos. Y si mañana Sol coordina mejor uno de ellos, cambiaré de opinión.

El proyecto debe poder cambiar de motor

Trabajar así plantea un problema práctico. Si todo lo que sabe un proyecto está disperso en conversaciones de una sola plataforma, cambiar de modelo puede obligarme a reconstruir decisiones, instrucciones y trabajo ya realizado. Entonces sigo usando el mismo sistema por el coste de marcharme, incluso cuando otro podría servir mejor.

Por eso, al construir Alonides sobre Hermes, mi apuesta es conservar fuera de cada modelo el contexto que necesito para continuar: objetivos, archivos, instrucciones, decisiones, tareas pendientes, resultados y revisiones. Quiero poder hablar con los agentes de un proyecto o dirigirme a Alonides como coordinador del conjunto; y quiero poder cambiar el modelo que desempeña cada función sin perder la historia del trabajo.

Hoy mi combinación preferida para muchos proyectos es Claude Opus 5.5 coordinando y GPT-6.1 Sol ejecutando tareas delimitadas. No necesito que sea la combinación definitiva. Necesito una organización que me permita comprobar cuándo funciona, reconocer cuándo deja de funcionar y cambiarla sin empezar de cero.