Marcin Moskała auditó GeminiAI: lo que reveló sobre las corrutinas y la arquitectura de Android

GeminiAI, un proyecto Android de código abierto concebido como un cliente completo de Gemini que replica la interfaz original, superó una auditoría línea por línea de Marcin Moskała, autor de libros sobre Kotlin y formador certificado por JetBrains. La revisión no puso el foco en el aspecto visual de la aplicación. Lo que se examinó fue la solidez con la que están construidas las corrutinas, la structured concurrency y el control del ciclo de vida de las tareas.

Cómo nació GeminiAI

Todo empezó con una observación bastante simple: en GitHub apenas había clientes completos de Gemini que pudieran estudiarse como un proyecto Android serio con una arquitectura bien pensada, y no como un simple conjunto de llamadas a la API. El autor del artículo decidió cubrir ese hueco y crear una aplicación open source que, además de conectarse al modelo, mostrara cómo puede ser un cliente de IA moderno sobre el stack móvil. El objetivo era doble: replicar la UI del Gemini original y, al mismo tiempo, levantar una base técnica que pudiera analizarse capa por capa.

GeminiAI se construyó finalmente sobre Navigation3, Jetpack Compose, Dagger-Hilt, Room, Kotlin Coroutines y Flow. Pero la prioridad nunca fue hacer un escaparate de tecnologías, sino lograr que la aplicación se comportara bien bajo carga: streaming de respuestas, gestión del contexto de la conversación, cancelación correcta de operaciones y ausencia de fugas de memoria. Para el autor también supuso un reto de ingeniería personal tras varias entrevistas de trabajo complicadas, en las que las preguntas de arquitectura pesaban con frecuencia más que la capacidad de programar rápido una funcionalidad en pantalla.

La auditoría de Moskała

La siguiente fase resultó mucho más exigente que una revisión de código habitual. En diciembre de 2025, el proyecto llegó a un workshop de Marcin Moskała en el que se analizó literalmente línea a línea. Este formato tiene un valor claro: deja al descubierto muy rápido la diferencia entre el código que simplemente funciona y el que aguanta el crecimiento, las cancelaciones de tareas y los escenarios asíncronos complejos. En una aplicación de IA esto resulta especialmente crítico: los errores en corrutinas no siempre se ven de inmediato, pero acaban convirtiéndose en peticiones colgadas, estados sobrantes y bugs difíciles de rastrear en la UI.

Según el autor, la auditoría no se quedó en una comprobación formal. Marcin fue añadido a los contributors del repositorio, y el proyecto recibió una valoración como ejemplo didáctico de calidad sobre corrutinas para el desarrollo Android. Es una señal relevante para la comunidad open source: el valor de GeminiAI no reside en reproducir la interfaz conocida de un chatbot. Reside en la disciplina de ingeniería que demuestra allí donde muchos proyectos se limitan a un envoltorio de demostración sobre la API.

«El código ha quedado robusto y bien estructurado: es un buen ejemplo para aprender corrutinas en

Android».

Qué se revisó exactamente

El tema central del análisis fue la structured concurrency, un enfoque en el que cada operación asíncrona vive dentro de un ámbito de responsabilidad claro y no se pierde al cerrar la pantalla o cancelarse la tarea padre. El artículo lo vincula a una idea más amplia: lanzar operaciones en segundo plano sin control es tan peligroso para una aplicación moderna como los saltos interminables con GOTO lo eran para el código antiguo. Si las tareas no tienen límites de vida claros, la aplicación acaba pagándolo en memoria, recursos y previsibilidad.

• Herencia de contexto: las corrutinas hijas reciben los parámetros del padre, incluidos el dispatcher y las reglas de ejecución.
• Espera de finalización: el parent scope no se cierra hasta que terminan todos los launch y async que contiene.
• Cancelación automática: ante un error o la detención del padre, el árbol de tareas se colapsa sin limpieza manual.
• Límite de responsabilidad: la lógica pesada se traslada a ChatRepository, mientras que el control de la cancelación sigue en el ViewModel.
• Comportamiento en la UI: al cerrar la pantalla, las peticiones a la API y a la base de datos deben finalizar correctamente, sin operaciones colgadas.

Tras el trabajo en el proyecto, el tema trascendió un único repositorio. El autor preparó un texto sobre structured concurrency basado en las ideas de Edsger Dijkstra sobre lo perjudiciales que resultan los saltos no estructurados, y trasladó ese debate al mundo de las corrutinas. En desarrollo móvil, este puente entre la informática teórica y la práctica tiene una utilidad concreta: permite justificar las decisiones de arquitectura con la lógica básica de gestión de la complejidad, y no con los gustos del equipo. De paso, demuestra por qué la cancelación de tareas forma parte de la arquitectura y no es un detalle menor de implementación.

Qué significa

El caso de GeminiAI deja una lección sencilla: en las aplicaciones de IA no basta con ser el más rápido en conectar el modelo; también gana quien construye con cuidado la arquitectura en torno al streaming, la cancelación de tareas y el ciclo de vida de la interfaz. Para los desarrolladores Android es una buena señal: incluso un proyecto que empezó como una copia de Gemini puede convertirse en referencia si de verdad tiene bien pensadas las corrutinas, los límites de responsabilidad y el comportamiento de la aplicación en escenarios reales. Son precisamente estos detalles los que separan un proyecto personal de aprendizaje de un código que puede tomarse como base en producción.