El mismo Claude Opus 5.5: por qué unos sacan una app y otros dicen que es tonto
Una app React Native + Expo desde cero con Claude Code y Opus 5.5: tres diseños rechazados, abandonar uni-app x y Lynx, pruebas con adb, actualizaciones OTA y versión HarmonyOS.
Es el mismo Claude Opus 5.5, y aun así hay quien dice que en media jornada le saca el trabajo de una semana y quien dice que de cada tres respuestas falla dos.
Hace poco lo usé para construir una app móvil llamada Ruzai (如在): cuando no estás delante del ordenador, te permite ver desde el móvil las conversaciones del asistente de IA que corre en el ordenador, enviarle mensajes y aprobar las operaciones críticas que quiere ejecutar.
Desde el diseño de producto, la interfaz y el código hasta el empaquetado automático del APK de Android y de las builds de iOS para TestFlight con GitHub Actions, las actualizaciones en caliente con servidor propio y los recursos para publicar en la App Store: prácticamente todo lo hizo Opus 5.5 dentro de Claude Code. Por el camino cambiamos una vez de stack, evaluamos dos alternativas multiplataforma y le tumbé la interfaz tres veces.
Mirándolo en retrospectiva, la capacidad del modelo casi nunca fue el cuello de botella. Con el mismo modelo, que el resultado salga bien o mal depende de quien lo usa. En este artículo desgloso esa diferencia en varios puntos concretos, a partir de lo que pasó de verdad en el proyecto.
Primero, el stack
| Parte | Lo que usamos al final | Lo que probamos / descartamos |
|---|---|---|
| Framework móvil | React Native 0.88 + Expo SDK 58 | uni-app x (descartado), Lynx 4.0 (descartado tras un prototipo) |
| Enrutado y compilación | Expo Router, React Compiler, TypeScript 6 | TypeScript 7 (incompatible con typescript-eslint) |
| Gestos y animaciones | Reanimated 4.7, Gesture Handler 3.3 | |
| Empaquetado | GitHub Actions: APK de Android, subida de iOS a TestFlight | |
| Actualizaciones en caliente | Protocolo expo-updates, alojado en servidor propio | |
| HarmonyOS | Versión nativa en ArkTS, compila en CI | |
| Desarrollo y depuración | Expo Go con dispositivo real; la IA controla el móvil directamente por adb |
Cada “descartado” y cada “cambiamos a” de esta tabla fue un desacuerdo entre la persona y la IA. Vamos uno por uno.
Diferencia uno: si solo dices “es feo”, la IA tiene que adivinar durante tres rondas
Salió la primera versión de la interfaz y yo dije: es feísima.
Primera ronda: Opus 5.5 cambió la paleta. Buscó en internet tres esquemas consolidados y los metió en el prototipo para que eligiera:
| Opción | Origen | Color principal |
|---|---|---|
| A Crema cálido | Paleta oficial de Claude | Terracota #c96442, fondo blanco roto #faf9f5 |
| B Verde azulado | Gris Sage + verde Jade de Radix | #29a383 |
| C Índigo | Gris Slate + azul Indigo de Radix | #3e63dd |
Las paletas eran correctísimas, pero a mí me seguía pareciendo feo.
Segunda ronda: ya no se limitó a cambiar colores, sino que lo rehízo entero siguiendo el estilo del rediseño de la app de Gemini de 2026: fondo blanco o negro puro, sin ningún borde, saludo en tamaño grande y un campo de entrada flotante en forma de cápsula.
En esta ronda también dio con una causa que a mí no se me había ocurrido: las propias capturas se veían baratas. Las maquetas se capturaban con Chrome headless en Windows, donde el chino se renderiza por defecto con Microsoft YaHei. Al cambiarlo a Source Han Sans (Noto Sans SC), el aspecto pasó de golpe a parecerse a MiSans y PingFang en el móvil. Parte de lo que me parecía feo en las dos primeras rondas era, en realidad, la fuente de las capturas.
Tercera ronda: pensé que el problema podía estar en los colores del icono y decidí quitar todos los degradados. Me propuso 6 iconos de color plano (fondo negro con letra de palo, fondo negro con letra serif, sello rojo bermellón…) y al final nos quedamos con una “Z” blanca sobre negro puro.
Tras tres rondas me di cuenta de que yo solo había dado valoraciones, nunca una dirección. Si desde la primera frase hubiera dicho “centrado en la conversación, como ChatGPT, en blanco y negro, sin degradados”, la primera versión ya habría estado cerca de la definitiva.
La IA no tiene preferencias estéticas: lo que te da es la media de un montón de diseños. Si no sabes explicar lo que quieres, pásale una captura de una app que te guste; sirve más que diez “hazlo un poco más elegante”.
Diferencia dos: lo que pone el documento de requisitos, lo ejecuta al pie de la letra
En este proyecto trabajaban dos ordenadores: uno para el servidor y la app móvil, otro para el cliente de Windows. Las IAs de cada lado no comparten memoria y se coordinan mediante documentos de requisitos en el repositorio: el protocolo, las interfaces, qué hay que cambiar esta vez. Un lado lo escribe y lo sube, el otro lo baja, lo implementa y marca el estado al terminar.
El sistema funciona muy bien. Cambiar el icono del cliente de escritorio o integrar el relé con el móvil fueron cosas en las que este lado escribió el documento de traspaso y el otro lado simplemente lo siguió hasta terminar.
Pero tiene un efecto secundario: cualquier decisión que quede escrita en el documento, la IA la ejecuta sin rebajas.
Una vez el documento cambió la tecnología móvil a uni-app x, y Opus 5.5 escribió en consecuencia todo un código en uni-app: lo subió, corrigió los problemas y lo dejó impecable. Solo cuando estaba terminado caí en que eso ataba el producto a una única plataforma, DCloud, de la que dependerían las notificaciones push, el empaquetado y las actualizaciones en caliente. Así que lo tiré todo y empecé de nuevo con React Native + Expo.
La IA no te va a preguntar por iniciativa propia “¿te arrepentirás de esta elección dentro de tres años?”. Las decisiones irreversibles de stack tiene que tomarlas una persona.
Diferencia tres: que escriba código primero, o que explique el porqué primero
Más adelante quise probar Lynx, de ByteDance: un único código para Android e iOS, y quizá en el futuro también HarmonyOS. Opus 5.5 montó rápidamente un prototipo que compilaba, se conectaba al servidor y renderizaba las conversaciones.
Pero la interfaz volvió a ser fea, nada que ver con el diseño definitivo.
Esta vez no le pedí que lo arreglara directamente, sino que le dije: no escribas código todavía; primero aclaremos por qué, luego propón una solución y solo al final escribe.
Las razones que dio fueron muy concretas:
| Elemento | Versión React Native | Prototipo Lynx | Causa |
|---|---|---|---|
| Iconos | Iconos de línea en SVG | Símbolos de texto ☰ ＋ ↑ | Lynx no muestra SVG por defecto |
| Barra lateral | Se desliza desde la izquierda, ocupa el 84 % del ancho, con capa de fondo | Se sustituye la página entera por una lista | No hay componentes de cajón ni de modal listos para usar |
| Panel inferior | Selección de ordenador, detalle de confirmación con captura | No existe | Ídem |
| En conjunto | Ajustado poco a poco según el prototipo | Montado en una hora para validar viabilidad | Los componentes de React Native no sirven en Lynx; solo se puede reutilizar la lógica pura |
A eso se sumaron las regresiones que encontramos en las pruebas: en Lynx 4.1.0 los toques dentro de un scroll-view no se disparaban, y en ReactLynx 0.128 directamente no funcionaba ningún toque, así que hubo que volver a 4.0.3 y 0.126.
Con las causas sobre la mesa, la decisión era sencilla: seguir con React Native.
Si en ese momento hubiera dicho “pon la interfaz bonita”, probablemente se habría pasado horas reajustándolo todo en Lynx para acabar volviendo atrás igualmente. Cuanto más rápido escribe la IA, más lejos llega por el camino equivocado.
Diferencia cuatro: cuantos más permisos le das, más claros tienen que estar los límites
Para probar en dispositivo real, dejé que la IA controlara directamente un móvil Android por adb: pulsar botones, escribir texto, hacer capturas para ver el resultado. Así salieron muchos problemas que en el prototipo de escritorio eran imposibles de ver:
| Síntoma | Causa | Solución |
|---|---|---|
| El teclado tapa el campo de entrada | Con edge-to-edge activado, el layout no se apartaba del teclado | Cambiar KeyboardAvoidingView a padding |
| Con la pantalla atenuada, los toques no responden | El primer toque se usaba para despertar la pantalla | Enviar KEYCODE_WAKEUP antes de cada prueba |
| El gesto de deslizar la barra lateral termina nada más empezar | El ScrollView nativo se quedaba con el toque | Cambiar al ScrollView de Gesture Handler y añadir a la izquierda una franja sensible transparente de 36dp |
| Al abrir una conversación larga se queda a medias | Durante la maquetación por lotes, el propio código hacía scroll al final y eso también disparaba el evento de scroll, que se interpretaba como “el usuario ha subido” | Que solo el arrastre con el dedo cambie el estado de “estoy al final” |
| El texto escrito por adb no aparece | El teclado de WeChat interceptaba la entrada | Pulsar una sugerencia para confirmarlo |
Pero también hubo sustos: una vez pulsó el botón de atrás, salió al escritorio del móvil, y los siguientes toques fueron a parar directamente a WeChat y Alipay.
No hubo daños, pero me sirvió de aviso: una IA que solo puede chatear solo puede hablar; una IA conectada a herramientas puede verificar por sí misma, y también liarla por sí misma. El mismo modelo, con o sin herramientas, rinde a niveles completamente distintos. Hasta dónde abres las herramientas, en qué dispositivo prueba y qué apps no puede tocar hay que dejarlo claro de antemano.
Diferencia cinco: dónde validas determina lo que ves
Lo de la fuente de las capturas era en realidad un problema de validación: si miras el resultado en el entorno equivocado, hasta lo que está bien te va a parecer mal.
Con el empaquetado pasa igual. Los APK de Android generados por GitHub Actions se firmaban cada vez con un certificado de depuración distinto, así que para instalar una versión nueva había que desinstalar la anterior. Se resolvió subiendo al repositorio un debug.keystore fijo. Si no lo instalas dos veces en un móvil real, ni te enteras.
Y los recursos para la App Store son puro detalle acumulado:
| Recurso | Tamaño requerido |
|---|---|
| Recurso de cabecera | 5244 × 2950 o 3840 × 1646 |
| Recurso para resultados de búsqueda | 5244 × 2950, 3840 × 2560 o 1920 × 1280 |
| Capturas de iPhone de 6,3 pulgadas | 1206 × 2622 o 2622 × 1206 |
Estos tamaños la IA los clavó a la primera, pero los datos de ejemplo de las capturas los cambió por contenido neutro porque yo se lo pedí después de verlos.
Luego estaba la descripción de la tienda. La escribió a partir de nuestros casos de uso internos reales, con todas las funciones bien detalladas, pero contarlo tal cual tenía muchas papeletas de no pasar la revisión. Eso la IA no lo sabe; yo sí. Al final lo enfocamos como “controlar a distancia desde el móvil y ver las conversaciones de IA del ordenador”, con el subtítulo “Controla y consulta la IA de tu ordenador”.
La IA puede hacer las cosas bien, pero qué cosas bien hechas resultan arriesgadas solo lo sabe quien ya ha pasado por ello.
Diferencia seis: ¿sabes qué preguntar?
Ya avanzado el proyecto, pregunté: “Para cambios pequeños de interfaz en el futuro, ¿no se podría actualizar directamente sin compilar cada vez?”.
Esa pregunta me trajo todo un sistema de actualizaciones en caliente: protocolo expo-updates con los paquetes de actualización alojados en mi propio servidor; runtimeVersion con la estrategia fingerprint, de modo que las versiones que solo tocan JS se actualizan solas al abrir la app, y solo hace falta volver a empaquetar cuando cambia el código nativo.
Si no lo hubiera preguntado, no lo habría hecho por su cuenta. No porque no supiera, sino porque no sabía que para mí era importante.
Igual con la versión para HarmonyOS: empezó porque pregunté “¿se puede compilar nativo para HarmonyOS?”. La escribió en ArkTS, compiló en GitHub Actions y por el camino resolvió varios baches que solo descubres cuando te pones manos a la obra: el repositorio ohpm de Huawei devolvía a menudo 503 a las máquinas de GitHub y hubo que añadir reintentos; imageknife a partir de 3.2.8 exige API 18, así que tocó quedarse en 3.2.7.
La IA llega hasta donde llegan tus preguntas. Quien sabe preguntar, naturalmente, se lleva más.
Diferencia siete: ¿de verdad usáis “el mismo modelo”?
Por último, un hecho que se pasa por alto a menudo: cuando dos personas dicen “uso Opus 5.5”, puede que no estén usando ni de lejos lo mismo.
| Diferencia | En concreto |
|---|---|
| Cliente | Chat web, Claude Code, apps que lo envuelven de mil formas: los prompts de sistema son totalmente distintos |
| Herramientas | Si puede leer archivos, ejecutar en la terminal, controlar el navegador y el móvil |
| Nivel de razonamiento | Niveles de pensamiento, modo rápido: el mismo modelo cambia muchísimo entre alto y bajo |
| Contexto | Contexto de 1M o longitud normal; si las conversaciones antiguas se compactan y qué se pierde al compactar |
| Ruta de acceso | API oficial, proveedor cloud o intermediarios varios: la versión y los límites que hay detrás no tienen por qué coincidir |
Para hacer Ruzai usé Claude Code: puede leer y escribir en todo el repositorio, ejecutar comandos, usar adb y GitHub. Compararlo con la experiencia de pregunta-respuesta en una web ya de entrada no es justo.
Para terminar
Juntando las siete diferencias:
| Se nota “tonta” | Se nota “lista” | |
|---|---|---|
| Estética | Solo decir “es feo” | Dar capturas de referencia y dejar claro lo que no quieres |
| Documento de requisitos | Lo escrito se da por decidido | Las decisiones irreversibles las tomas tú |
| Orden | Ponerse a escribir código de entrada | Primero las causas y la propuesta |
| Permisos de herramientas | No darlos, o abrirlo todo | Dar herramientas y a la vez marcar límites |
| Validación | Mirar capturas en el ordenador | Mirar en dispositivo real, con fuentes reales y datos reales |
| Preguntas | Esperar a que se le ocurra a ella | Saber tú qué preguntar |
| Entorno | Fijarse solo en el nombre del modelo | Fijarse en cliente, herramientas, nivel y ruta de acceso |
En todo el proyecto, el código lo escribió prácticamente entero Opus 5.5, pero cada punto de inflexión fue una decisión humana: abandonar uni-app x, no usar Lynx, quitar los degradados, cambiar el texto de la tienda, añadir actualizaciones en caliente.
Así que la próxima vez que te parezca que la IA “se ha vuelto tonta”, no corras a cambiar de modelo. Repasa primero las instrucciones de trabajo que le diste y pregúntate si no eran ellas las que se quedaban cortas.
Los enfoques más técnicos, como la recuperación de información, la organización del contexto, el presupuesto de razonamiento y la verificación, los expliqué en «Antes de cambiar de modelo, haz que tu IA sea más lista»; se complementan bien.
Si tú también estás usando Claude Code u otra IA para construir tu propio producto, me encantará charlar: linktr.ee/weiyii