En una experiencia anterior con Claude, pedí continuar con el peso de una app móvil. El trabajo compartía espacio con correcciones y preparativos de una salida a producción. Eso hizo que una pregunta aparentemente sencilla —cuánto pesa la app— dependiera también de qué se compilaba, cuándo corría la integración continua y qué artefacto se estaba midiendo.
La conversación conserva una condición explícita: mantener CI en pausa hasta nueva indicación. Más adelante pedí preparar un PR que activara CI y pudiera llegar a producción, además de actualizar los textos de las apps sin hacer capturas nuevas. Ese cambio de instrucciones importa: habilitar otra vez las comprobaciones era parte del encargo, pero publicar en la tienda todavía exigía pasos posteriores.
La decisión que abrió la medición
Claude informó que el último commit llevaba una marca para omitir CI. Según su explicación, esa marca también impediría ejecutar las comprobaciones del PR. Su decisión fue añadir un commit vacío sin esa marca. No cambiaba una pantalla ni una función; cambiaba la posibilidad de obtener resultados del proceso automático.
Después comunicó que estaban corriendo el análisis, las pruebas y una compilación de desarrollo destinada a pruebas. Esta última permitiría medir el APK generado. La consecuencia de aquella decisión era concreta: antes de discutir una reducción, había que conseguir un artefacto y saber de qué proceso provenía.
Al finalizar, Claude reportó que los dos procesos de CI habían terminado correctamente y que el APK de pruebas era más pequeño. Atribuyó buena parte de la reducción a compilar solo para arm64. Lo que tengo documentado es ese reporte del asistente: la muestra conservada no incluye las salidas completas de las herramientas para verificarlo de forma independiente.
El límite de una cifra favorable
El mismo reporte dejó una diferencia decisiva. El APK de pruebas no era el AAB que se mediría al compilar la versión de producción. Tampoco equivalía automáticamente al tamaño que acabaría descargando una persona desde la tienda. Por eso esta experiencia permite hablar de una reducción reportada del paquete de pruebas, sin convertirla en una mejora demostrada de la descarga final.
Esa distinción también afecta los textos de publicación. Pedí actualizarlos, y Claude indicó haberlo hecho. Sin una medición de producción conservada en la evidencia, no puedo usar esa actualización como prueba adicional del resultado. Un texto redactado a partir del trabajo sigue siendo un texto; no reemplaza la comprobación del artefacto al que se refiere.
Lo que seguía después
Claude señaló otro orden necesario: desplegar primero el backend y después fusionar el PR de la app, porque la nueva versión dependía de endpoints que aún no estaban en producción. También dejó pendiente confirmar el disparador de compilación de iOS. Su informe de CI, por tanto, no cerraba toda la entrega.
La muestra termina con esos pasos asignados al humano y una revisión posterior del build de producción todavía por hacer. No conserva confirmación de la fusión, publicación en tienda ni medición del AAB. La lección que extraigo es mantener cada resultado unido a su contexto: qué se midió, con qué configuración y qué faltaba comprobar. Así una mejora reportada ayuda a decidir el siguiente paso sin convertirse en una promesa mayor que la evidencia.