GPT-5.6 Sol vs. Claude Fable 5
Les di mi laboratorio para que lo destriparan

La idea no era «a ver si la IA encuentra bugs» —eso ya lo sabemos, los encuentra—. La idea era más fina y más útil: poner dos modelos punteros ante el mismo producto, con el mismo encargo y las mismas reglas, y ver en qué se fijaba cada uno. Porque un modelo no es solo «mejor» o «peor». Es que miran distinto. Y esa diferencia, cuando la que audita es la máquina que va a tocar el código, importa muchísimo.

Elegí dos de última generación: GPT-5.6 Sol, trabajando desde ChatGPT Work con Codex —le puse de mote SOL—, y Claude Fable 5 —a la que llamé Fable—. A partir de aquí las llamo así. Yo me quedé en el único puesto que me interesaba: el de árbitro. Ni programé mientras auditaban, ni les soplé respuestas. Navegaban, observaban, anotaban. Y al final, cruzábamos.

V.A.I. —mi fórmula: Voz + Automatización + IA— es el centro de mando de una operación de agentes de voz. Tiene dos paneles. El de Admin, desde donde yo gestiono campañas salientes, enrutado de llamadas entrantes, post-call, calidad, agentes, conocimiento, clientes, márgenes y calculadora de rentabilidad. Y el de Cliente, donde cada cliente ve solo su actividad: su resumen, su ROI, sus llamadas, sus números.

Esa palabra —solo lo suyo— es la que convierte a este producto en un campo de minas. En un panel donde un cliente jamás debe ver los datos de otro, un fallo de aislamiento no es un bug estético: es una fuga. Por eso quería una auditoría de verdad, no un paseo.

El encargo que les di fue idéntico para las dos, palabra por palabra. Un rol de auditor de producto y QA senior, con cuatro ejes obligatorios en cada pantalla y una escala de gravedad de tres niveles:

Y una escala de severidad que luego sería decisiva: 🔴 Crítico —rompe una función, dato que engaña o fuga de información—, 🟡 Mejora —funciona pero hay un problema real de usabilidad o coherencia— y 🔵 Pulido —detalle menor o cosmético—. Guárdate esta escala. Al final del duelo se convierte en el terreno donde se decidió casi todo.

La primera pasada fue un desastre productivo. Las dos IAs entraron en el modo demo y, en varias pantallas, se encontraron con algo feo: el error técnico crudo volcado directamente en la cara del usuario. No un «vaya, algo ha fallado» con cariño. El churro entero: el HTML de un error 404, tal cual, dentro de un recuadro rojo enorme.

¿La causa? En modo demo, la app seguía llamando por detrás al backend real de la plataforma de voz — un backend que sin sesión de administrador no existe. Y en vez de tragar ese fallo con elegancia, lo escupía en pantalla. Un bug real, no del demo: los errores internos se propagaban sin filtrar hasta la interfaz.

Y ahí saltó la cuestión metodológica, que es de las cosas más importantes de todo esto: la plataforma había cambiado durante el examen. Si una IA conoció el fallo y la otra no, la comparación deja de ser limpia. Así que tomamos una decisión de árbitro: todo lo anterior queda como «ronda de diagnóstico previa» y no cuenta. El duelo oficial empieza de cero, sobre la versión ya corregida, y las dos IAs vuelven a recorrerlo entero.

Lo dejo escrito aquí porque es de honestos: hubo una asimetría —una de las IAs llegó a ver parte del código y la causa raíz durante ese ensayo— y esa asimetría se anota, no se esconde. Una comparación solo vale si cuentas también dónde no era justa.

Mismo prompt, palabra por palabra. Mismo deploy corregido. Mismo orden: primero Admin al completo, luego Cliente. Nada de lanzar campañas, nada de borrar, nada destructivo. Solo navegar, observar e interactuar sin romper. Hasta aquí, simétrico.

Pero hubo dos asimetrías que no se pueden barrer debajo de la alfombra, porque cambian la lectura del resultado:

¿Por qué me obsesiona esto? Porque es exactamente el mismo error que veo en las empresas cuando «prueban» dos herramientas: las prueban en condiciones distintas y luego sacan conclusiones como si fueran iguales. Una comparación sin sus asimetrías anotadas no es una comparación: es una anécdota.

Voy a enseñarte los hallazgos que más me dolieron —porque son los que de verdad enseñan—. No están todos; están los que cuentan una lección. Los agrupo por gravedad, con la escala de antes.

🔴 El que me quitó el sueño: identidad cruzada

El panel de Cliente te saluda por tu nombre. En la demo, ese nombre era «Cliente A». Y en la pantalla de Ajustes, en efecto, ponía Cliente A. Perfecto. Salvo que el resumen, las llamadas, los agentes y hasta las transcripciones que veía esa cuenta eran de OTRO cliente — el Cliente B, una operación completamente distinta.

En la demo es una mezcla confirmada de datos de prueba (fixtures). En producción, con datos reales, el mismo patrón sería una fuga de información entre clientes. Y aquí un matiz que importa, técnica y jurídicamente: no hemos demostrado una fuga real. Hasta revisar el tenant, las consultas y las políticas de aislamiento (RLS) en el código, se trata como riesgo crítico, no como fuga probada. Aun así, es exactamente el hallazgo que, si estás vendiendo un panel multi-cliente, te hunde la venta. Las dos IAs lo cazaron por separado y las dos lo marcaron como lo más grave del panel. Cuando dos auditores independientes coinciden en tu peor pesadilla, ya no es opinión.

🔴 Varios universos de datos disfrazados de uno

El panel mezclaba, sin avisar, tres conjuntos de datos que no encajaban entre sí. Un resumen enseñaba millones de llamadas; otra pantalla, con los mismos «clientes», hablaba de 880; y las herramientas de construcción vivían en un tercer mundo con otros agentes distintos. Números correctos cada uno dentro de su fuente, pero engañosos cuando los lees juntos.

El detalle que lo resume: en el panel de Cliente, el Resumen presumía de 1.241 citas y, dos clics después, la pantalla de ROI usaba 223 «citas reales» para calcular el retorno. La misma cuenta, dos verdades. Un cliente que mira eso no piensa «qué interesante la arquitectura de datos». Piensa «esto no me lo creo».

🔴 El error crudo que sobrevivió

Tres pantallas seguían mostrando el churro técnico —FAILED TO SEND A REQUEST TO THE EDGE FUNCTION— en la cara del usuario. El fix de la ronda cero había tapado unas pantallas, pero no las que llamaban a otro servicio. Lección de fontanería: tapar una fuga no es arreglar la instalación.

🔴 El «éxito falso» (este solo lo vio una)

En el editor de agentes, le das a Guardar y el panel te felicita: «Guardado. Los cambios crean una versión borrador». Suena a que ha ido bien. No ha ido bien: no se guarda nada. La escritura está bloqueada en demo, como debe, pero en vez de decírtelo, finge que ha funcionado. De todos los fallos, este es el más traicionero: un error que se disfraza de acierto es peor que un error a secas, porque no te enteras. Solo lo encontró Fable — porque fue la que se puso a pulsar botones de guardar. SOL, que no ejecutó escrituras, no podía verlo.

🔴 Los decimales fantasma de la calculadora

Este es de orfebrería, y lo cazó SOL. En la calculadora de rentabilidad, con los mismos valores a la vista, el resultado cambiaba: 8.935 € la primera vez, 8.933 € después de tocar y volver. ¿Por qué? Precisión oculta detrás de los números redondeados que se muestran. Un cálculo que da dos respuestas distintas con los mismos datos visibles es, para una herramienta que sirve para decidir dinero, veneno.

🔴🟡 Y una constelación de datos que engañan y funciones a medio cerrar

Algunas rompen de verdad y otras solo rozan, pero todas mienten un poco: un gráfico que dibuja citas (decenas al día) y llamadas (cientos de miles) sobre el mismo eje, haciéndolas parecer comparables. Un panel que dice «880 analizadas» cuando la suma da 846. Una sección llamada «No interesado» que mete dentro a los que pidieron «llamar más tarde» — que no es lo mismo, ni de lejos, y contamina la métrica. Un botón «Escuchar grabación» que apunta a la nada. Formularios que se lanzan con el nombre vacío, que aceptan fechas en el pasado, que tragan una tasa de cierre del 150 % o un volumen negativo. Y selectores, botones y pesos sin nombre accesible — invisibles para quien navega con lector de pantalla. Cuáles de estas son críticas y cuáles mejora lo verás en la tabla de arbitraje, un poco más abajo.

Cruzar no es sumar dos listas. Es preguntarse, por cada hallazgo: ¿lo vieron los dos? ¿es exclusivo de uno? ¿es el mismo problema con dos nombres? ¿es síntoma o causa? Y sobre todo: ¿es verdad? Antes de clasificar nada, volví al panel y re-verifiqué a mano cada hallazgo exclusivo que se pudiera comprobar sin código. Los números finales:

Léelo despacio, porque hay dos datos gordos ahí dentro. El primero: cero falsos positivos entre los hallazgos consolidados. Tras la verificación, ninguno de los que entraron en el cruce resultó inventado —un único hallazgo de Fable quedó fuera del recuento por falta de evidencia suficiente, no por ser falso—. Para quien tenga la idea de que la IA «alucina bugs», ahí está el dato: con un encargo cerrado y verificación posterior, ninguno de los hallazgos consolidados resultó inventado.

El segundo: 21 coincidencias plenas. Veintiuna veces, dos modelos distintos, mirando por separado, apuntaron al mismo problema. Ese solapamiento es oro: son los hallazgos con máxima confianza, los que priorizas sin discutir — aunque la causa raíz todavía haya que validarla en el código. Y el núcleo duro —identidad cruzada, universos de datos, errores crudos— está entero ahí dentro.

Luego está lo que hace interesante la comparación: los exclusivos. Y aquí viene el matiz honesto — buena parte de esos exclusivos no son «uno es más listo que el otro», sino cobertura distinta. Fable ejecutó guardados y probó el móvil; por eso vio el éxito falso y el responsive roto — cosas que SOL, por su forma de auditar, ni tocó. SOL desmenuzó formularios, accesibilidad y decimales; por eso vio cosas que a Fable se le escaparon. No miraron lo mismo con distinta vista. Miraron sitios distintos.

Hubo 9 hallazgos en los que los dos coincidían en el qué pero discrepaban en el cómo de grave. Y esto, para mí, es lo más revelador de todo el experimento. Porque no me fié de ninguna: cogí la escala del prompt, la apliqué literalmente a cada uno de los nueve, y arbitré.

El resultado del arbitraje, aplicando la letra de la escala: SOL estuvo mejor ajustado en 8 de los 9. Y no por casualidad. Fable tendía a leer un «dato que engaña» como un problema de coherencia (🟡), cuando la escala decía claramente que un dato falso presentado como verdadero es crítico (🔴). SOL calibraba mejor la gravedad. En el único donde le di la razón a Fable —el del showcase—, era porque ese bloque sí estaba rotulado como simulado, así que era incoherencia, no mentira.

Si la pregunta es «¿qué modelo hizo la auditoría más profunda del producto y entendió mejor dónde podía engañar al usuario?» — la respuesta es SOL. Desmontó la lógica, calibró la gravedad y se metió en los rincones semánticos donde un producto miente sin querer.

Si la pregunta es «¿qué modelo cubrió más tipos de interacción, más bordes, más comportamiento real?» — la respuesta es Fable. Pulsó, rompió, estiró, giró la pantalla. Encontró el único fallo que se disfrazaba de acierto.

Pero hay un dato difícil de esquivar, y como árbitro me toca decirlo: SOL sacó una parte importante de sus hallazgos en modo ligero, mientras Fable trabajó toda la ronda en medio. Y en las nueve peleas de severidad, la lectura de SOL se impuso en ocho. Eso no es una paliza. Es algo más fino y más publicable:

Y la conclusión de verdad, la que me llevo a la mesa de trabajo, no es «gana este». Es que la auditoría ideal usa a los dos. Uno para tensar el comportamiento hasta que algo cruja; otro para entender por qué crujió y cómo de grave es. Quedarte con uno solo es renunciar a media foto.

Porque ya me ha pasado en este mismo proyecto: cada parche a medida que salía el síntoma creaba una isla nueva. Al arreglar unas pantallas apareció un tercer universo de datos. Al tapar unos errores, quedaron otros. Parchear en caliente, hallazgo a hallazgo, no arregla el sistema: lo emborrona.

Así que el cruce queda congelado como documento oficial. No se negocian más cifras ni severidades. Y antes de tocar una sola línea, toca una revisión del repositorio —solo lectura, sin modificar nada— limitada a cuatro preguntas que ninguna auditoría de caja negra puede responder, porque viven en el código:

Y solo después de responderlas: se construye el backlog por causa raíz —no por síntoma—, se corrige sobre el repositorio —nunca sobre el paquete desplegado—, y se vuelve a pasar únicamente la checklist afectada para tener el «antes y después» con pruebas. Medir, entender, agrupar, arreglar, verificar. En ese orden. Siempre en ese orden.

Para que veas de qué hablo cuando digo «centro de mando», este es el corazón del panel Admin: la vista agregada de toda la operación. Bonita, ¿verdad? Ese es precisamente el riesgo — que lo bonito tape lo que no cuadra por debajo. De ahí toda esta auditoría.

¿Sirve una IA para auditar el producto de otra empresa (o el tuyo)?

Sí, y muy bien, pero con condiciones. En esta prueba puse dos modelos punteros a auditar el mismo panel con el mismo encargo. Entre los dos encontraron decenas de fallos reales —ni un falso positivo entre los hallazgos consolidados— y coincidieron por separado en el núcleo más grave: datos de un cliente vistos bajo la identidad de otro, errores técnicos crudos en pantalla y varios universos de datos presentados como uno. La clave no es lanzar el modelo y ya: es darle un encargo cerrado, reglas iguales y cruzar sus hallazgos con criterio antes de tocar una línea de código.

¿Qué modelo audita mejor: el que prueba los límites o el que entiende el sistema?

Los dos, pero distinto. Uno fue más fuerte tensionando el comportamiento —ejecutó guardados, metió valores extremos, revisó el responsive y encontró el único caso de éxito falso al guardar—. El otro desmontó mejor la lógica: coherencia financiera, semántica de las métricas, validación de formularios, accesibilidad y contradicciones entre módulos, y su lectura de la gravedad se ajustó mejor a la escala acordada en 8 de 9 discrepancias. Uno probó más bordes; el otro entendió mejor el sistema. La auditoría ideal usa a los dos.

¿Por qué no hay que arreglar los bugs según van apareciendo?

Porque parchear a medida que salen los síntomas crea islas nuevas y esconde la causa raíz. En esta misma auditoría, cada parche parcial de una ronda anterior había generado un problema nuevo. Lo correcto es medir entero primero: cerrar el cruce de hallazgos, separar síntoma de causa raíz, revisar el repositorio para las preguntas que solo el código responde, y solo entonces construir un backlog único por causa y aplicar el lote de fixes. Sin meter la pala antes de terminar de medir el agujero.

¿Qué es un hallazgo de identidad cruzada y por qué es tan grave en multi-cliente?

Es cuando el panel identifica la cuenta como un cliente pero muestra los datos, agentes y transcripciones de otro. En la prueba, el panel de cliente saludaba como «Cliente A» mientras enseñaba las métricas de otra cuenta (Cliente B). En una demo con datos ficticios es un defecto de configuración; en producción con datos reales, el mismo patrón sería una fuga entre clientes. Por eso se trata como riesgo crítico hasta que el código y las consultas demuestren lo contrario: hay que revisar cómo se resuelve el inquilino (tenant) y las políticas de aislamiento antes de dar acceso a clientes reales.