De escribir en Kotlin a dirigir agentes: el nuevo rol del ingeniero móvil
Cómo los agentes de programación transforman el trabajo de un ingeniero de Android hacia las especificaciones, el contexto, las restricciones arquitectónicas y la verificación, y qué principios fundamentales son más importantes que nunca.
Los agentes de programación ya no se limitan a completar la línea de código. Exploran un repositorio, planean cambios, editan varios archivos, ejecutan el proceso de compilación, leen los errores y lo intentan de nuevo. Esto plantea una pregunta complicada para un ingeniero móvil: si el agente escribe la mayor parte del código en Kotlin, ¿sigue siendo desarrollo para Android o se ha convertido silenciosamente en la redacción de instrucciones dentro de un IDE? Este artículo sostiene que ninguna de estas etiquetas es adecuada y explica en qué se convierte en realidad el rol: redactar especificaciones precisas, diseñar el contexto en el que trabaja el agente, codificar la arquitectura como restricciones y verificar resultados que no se han escrito manualmente.
Los ejemplos son específicos de Android, pero el razonamiento es aplicable directamente a React Native, así como a los equipos de desarrollo web y backend que utilizan el mismo tipo de herramientas.
Hasta dónde han llegado los asistentes de programación
El flujo de trabajo clásico en Android es conocido: abrir Android Studio, crear una clase, escribir código en Kotlin, lidiar con Gradle, rastrear errores a través de Logcat, probar en un dispositivo y abrir una solicitud de integración.
La asistencia basada en IA se fue incorporando gradualmente a ese flujo de trabajo. Primero completó líneas individuales, luego funciones enteras y finalmente clases completas. Las herramientas actuales funcionan como agentes. En el momento de redactar este texto, varios productos describen explícitamente esta capacidad:
- Gemini Agent Mode en Android Studio acepta un objetivo de desarrollo de alto nivel, elabora un plan, invoca herramientas, edita varios archivos, construye el proyecto e itera cuando algún paso falla.
- Cursor's Agent explora un código base, modifica varios archivos, ejecuta comandos de terminal y corrige errores mientras realiza una tarea en lugar de solo proponer la siguiente línea de código.
Las capacidades de los productos en esta área cambian rápidamente, por lo que consulte la documentación actual de la herramienta que utilice su equipo. Sin embargo, la dirección es clara.
El trabajo avanza hacia arriba en la jerarquía
Un modelo mental útil es una escalera de actividades de ingeniería, que va desde las más mecánicas en la parte inferior hasta las que requieren más juicio en la parte superior:
Write code
↓
Understand code
↓
Design architecture
↓
Define requirements
↓
Make engineering decisions
↓
Validate behavior
↓
Own the product
Los agentes son cada vez más hábiles en las tareas de nivel básico. Eso no hace que la escritura y lectura de código sean inútiles, pero sí cambia el valor de esas habilidades. Una implementación estándar de repositorio que toma media hora a mano puede generarse en segundos. Es tedioso escribir manualmente diez pantallas Compose casi idénticas; un agente puede acceder a los archivos relevantes y generar las partes repetitivas. Un simple error de compilación puede consumir varios minutos del tiempo del usuario, mientras que un agente lee el mensaje, encuentra el código problemático, lo corrige, vuelve a compilar y pasa al siguiente paso.
El efecto neto es que un ingeniero dedica menos tiempo a crear código y más tiempo a decidir qué código debería existir en primer lugar.
Un buen prompt es, en realidad, una especificación
Tomemos una solicitud típica de producto: agregar una cola de descargas a la aplicación. Un ingeniero experimentado en Android expande mentalmente esa frase en un diseño por capas:
Database
↓
Repository
↓
Use Cases
↓
ViewModel
↓
UI State
↓
UI
↓
Background execution
↓
Notifications
Un desarrollador ahora puede implementar gran parte de esa estructura, pero la calidad del resultado depende en gran medida de lo que se solicitó. Comparemos una instrucción de tres palabras (“agregar cola de descargas”) con algo como esto:
Crea una cola que pueda ejecutar varias descargas y mantener su estado entre reinicios, respaldada por Room junto con WorkManager para realizar el trabajo. Registra el progreso en memoria en lugar de guardar cada actualización en la base de datos. Cuando se termine el proceso, vuelve a cargar las descargas pendientes y activas. El ViewModel debe publicar un StateFlow de solo lectura. No se deben utilizar tipos del framework de Android en la capa de dominio. Cubre los cambios en el estado de la cola y la recuperación ante fallos con pruebas unitarias. No modifiques las entidades de Room que no tengan relación alguna con las descargas.
Llamar a la segunda versión un “prompt mejor” le resta importancia. Se trata de una especificación técnica: menciona la tecnología de persistencia, el mecanismo de ejecución en segundo plano, una decisión relacionada con el rendimiento (no guardar cada actualización de progreso en disco), un requisito de resiliencia (sobrevivir a la finalización del proceso), un contrato API (StateFlow inmutable), una regla de estratificación, el alcance de las pruebas y un radio de impacto explícito. Cada una de estas cláusulas refleja conocimientos sobre Android que el agente no puede deducir simplemente de la instrucción “añadir cola de descargas”.
La conclusión es que el ingeniero no desaparece; más bien se convierte en la persona capaz de transformar una solicitud vaga del producto en una descripción precisa de un sistema técnico.
Prompting versus ingeniería
Estos dos roles plantean preguntas diferentes. Quien se enfoca en la generación de prompts pregunta cómo hacer que el modelo produzca un resultado determinado. Un ingeniero, en cambio, quiere saber qué construir, por qué motivo, bajo qué restricciones y cómo se podrá comprobar que funciona.
Supongamos que un agente le entrega este ViewModel:
class DownloadViewModel(
private val repository: DownloadRepository
) : ViewModel() {
val downloads = repository.downloads
}
Se compila y se lee sin problemas. Sin embargo, un desarrollador experimentado en Android aún tiene una lista de preguntas antes de aceptarlo:
- ¿Es
downloadsunFlowestático o unStateFlow, y qué activa cada colector? - ¿Dónde se encuentra la única fuente de verdad para el estado de las descargas?
- ¿Qué sobrevive a la finalización del proceso?
- ¿Cada actualización de progreso desencadena una escritura en Room?
- ¿Qué ocurre cuando dos descargas finalizan al mismo tiempo?
- ¿Cómo se modela la cancelación?
Generar la clase es fácil. Interrogar al sistema en torno a ella es la parte difícil, y resulta mucho más complicado automatizarlo.
El ciclo de desarrollo basado en agentes
El ciclo tradicional mantiene al desarrollador en la ruta crítica de cada paso:
Requirement
↓
Developer writes code
↓
Build
↓
Error
↓
Developer investigates
↓
Fix
↓
Test
↓
PR
Con un agente en medio, el ciclo cambia. El desarrollador establece la meta al principio y se encarga de la revisión y validación al final, mientras que el agente gestiona los ciclos de exploración, edición y corrección entre ambos:
Developer defines goal
↓
AI Agent explores codebase
↓
AI creates plan
↓
AI modifies files
↓
AI runs build/tests
↓
AI observes result
↓
AI fixes problems
↓
Developer reviews
↓
Developer validates behavior
↓
Ship
La documentación del proveedor describe el mismo patrón. El Modo Agente de Android Studio se presenta como una fase de planificación, herramientas para realizar llamadas, modificar archivos e iterar sobre los resultados. Cursor describe a su agente como un modelo que razona, herramientas que le permiten buscar y editar archivos o ejecutar comandos de terminal, y un bucle en el que el agente observa los resultados y elige el siguiente paso. Esto ya no es autocompletado; está más cerca de delegar una tarea de ingeniería.
El IDE como capa de orquestación
Ese cambio modifica la función de un IDE. Antes era un banco de trabajo para un único desarrollador. En el momento de escribir esto, las herramientas de IA de Android Studio ofrecen funcionalidades como:
- Modo Agente
- Varias conversaciones paralelas con agentes
- Conexiones al servidor MCP
- Instrucciones a nivel de proyecto en
AGENTS.md - Acceso a conocimientos específicos de Android
Google presenta Agent Mode como capaz de manejar tareas de desarrollo en múltiples etapas y ofrece servidores MCP y AGENTS.md como formas de ampliarlo y dirigirlo. El IDE deja de ser solo el lugar donde se escribe Kotlin para convertirse en el lugar donde se ejecuta y se supervisa un entorno de ingeniería asistido por IA.
Los fundamentos son aún más importantes
Sería natural suponer que si los agentes escriben el código, los ingenieros pueden saber menos. Lo cierto es lo contrario: los agentes hacen que sea fácil crear implementaciones incorrectas rápidamente, por lo que se necesitan fundamentos más sólidos para detectarlas.
Kotlin
Aún es necesario tener un dominio firme de las características del lenguaje que con mayor frecuencia ocultan errores sutiles:
Flow
StateFlow
SharedFlow
coroutines
structured concurrency
inline functions
sealed classes
value classes
delegation
generics
null safety
El objetivo no es escribir cada línea por sí mismo. Se trata de detectar cuándo el Kotlin generado tiene errores sutiles, como por ejemplo un flujo en tiempo real donde se necesitaba uno en tiempo lento, o una corutina iniciada fuera del marco de concurrencia estructurada.
La plataforma Android
Es en el comportamiento de la plataforma donde el código generado suele parecer correcto pero falla en producción:
Lifecycle
Process death
Configuration changes
Services
WorkManager
Room
Navigation
Permissions
Storage
Background execution
Notifications
Compose
Views
Performance
Un agente puede generar una clase Worker en segundos. Eso no indica si dicho worker respeta el ciclo de vida de la aplicación, ni los requisitos de reintentos y restricciones.
Arquitectura como restricciones del agente
El conocimiento en arquitectura adquiere un nuevo propósito. Patrones como MVI y MVVM, Arquitectura Limpia, límites de módulos, repositorios, DI, manejo de estado y separación del dominio no son solo formas de organizar el código; se convierten en las restricciones que le impones a un agente. En lugar de “crear una funcionalidad”, puedes indicar:
Crea esta funcionalidad siguiendo nuestra arquitectura MVI existente. Repite los patrones utilizados en la Funcionalidad A y la Funcionalidad B. No introduces nuevas dependencias. Las reglas de negocio deben encontrarse en la capa del dominio.
Hacer referencia a funcionalidades existentes es especialmente efectivo, ya que orienta al agente hacia ejemplos concretos y revisados en el código, en lugar de depender de su idea genérica de “MVI”. La arquitectura pasa a formar parte del lenguaje que utilizas para dirigir a los agentes.
Instrucciones a nivel de repositorio con AGENTS.md
Muchos equipos se encuentran repitiendo los mismos recordatorios en cada sesión: el proyecto utiliza Kotlin y Hilt, la lógica de negocio debe permanecer fuera de los Composables, el estado se expone mediante StateFlow, se aplican convenciones de nomenclatura, son necesarias pruebas y los archivos generados están prohibidos.
Esas expectativas pueden estar incluidas en el propio repositorio. En el momento de escribir esto, la herramienta Gemini de Android Studio lee los archivos AGENTS.md en los que se registran dichas preferencias, de modo que el agente las considera como contexto del proyecto. Otros agentes leen archivos similares; la misma idea se explica en profundidad en un playbook práctico para escribir un archivo CLAUDE.md efectivo.
Es un cambio pequeño con grandes consecuencias. Tradicionalmente, un repositorio contenía:
source code
configuration
tests
documentation
Ahora también puede contener:
AI engineering instructions
La base de código comienza describiendo tanto el propio software como la forma en que un agente debe operar sobre él. Trate esas instrucciones como código: revise los cambios en ellas, manténgalas breves y específicas, y elimine las reglas que ya no son aplicables.
MCP conecta el agente con el resto de la cadena de herramientas
El Protocolo de Contexto del Modelo permite a los sistemas de IA conectarse con herramientas y servicios externos, lo que significa que el agente ya no está limitado a un panel de chat. A través de los servidores MCP, puede llegar potencialmente a:
GitHub
Databases
Design tools
Documentation
Issue trackers
CI systems
Cloud services
Internal APIs
La herramienta de IA de Android Studio actualmente admite la conexión a servidores MCP, incluidos los remotos. Considere una única solicitud que pida al agente que cree una nueva pantalla de Perfil basada en un archivo Figma, reutilice los tokens de diseño existentes, conecte la pantalla al endpoint del perfil, gestione los estados de carga y error, agregue pruebas y prepare una solicitud de pull request. Cumplir con esto implica interactuar con muchos sistemas al mismo tiempo:
Developer
↓
AI Agent
├── Figma
├── Codebase
├── Documentation
├── API
├── Tests
├── Git
└── CI
Una vez que una herramienta coordina archivos de diseño, código, documentación, APIs, pruebas, Git y CI, la descripción “generador de código” es inadecuada. Se trata de un agente de ingeniería, y su alcance es también la razón por la cual las permisos y las revisiones son importantes: cada sistema conectado es algo que el agente puede leer o modificar.
La trampa: dependiente pero no capaz
Esta nueva configuración presenta un modo de fallo característico. Un desarrollador puede volverse dependiente de la IA sin llegar a dominarla. Es totalmente posible generar código que utilice todos estos elementos:
Flow
StateFlow
SharedFlow
CoroutineScope
SupervisorJob
Channel
sin comprender qué función cumple cada uno de ellos. Todo se compila, el trabajo parece rápido, pero meses después la producción sufre una condición de carrera relacionada con la cancelación del ciclo de vida que nadie en el equipo puede explicar.
La IA aceleró la escritura; no mejoró al desarrollador. Por eso, revisar lo que produce la IA se está convirtiendo, sin duda, en algo más valioso que la capacidad de generarlo. Una regla práctica para los equipos: nadie debe fusionar código generado que no pueda explicar línea por línea durante la revisión.
El contexto es el verdadero factor determinante
Los agentes de codificación dependen en gran medida del contexto que reciben. La documentación de Cursor, por ejemplo, describe un sistema de agentes en términos de contexto, herramientas, instrucciones y modelos. Eso sugiere una relación multiplicativa aproximada:
Agent Quality
=
Model
× Context
× Tools
× Instructions
× Verification
La multiplicación es la parte importante. Un modelo sólido que funciona con un contexto deficiente produce software de mala calidad, ya que un factor cercano a cero arrastra hacia abajo todo el producto. Un modelo decente que opera en un repositorio bien estructurado, con arquitectura clara, pruebas sólidas, documentación útil e instrucciones precisas puede rendir mucho mejor. La habilidad clave que se debe desarrollar es la ingeniería de contexto, de la cual la redacción de prompts es solo una parte.
Por qué “ingeniería de prompts” es demasiado limitada
La diferencia se puede ver fácilmente comparándolos lado a lado. Un prompt simple se ve así:
"Create a login screen."
Una solicitud diseñada con ingeniería de contexto se ve así:
Here is our architecture.
Here are our design rules.
Here is the API contract.
Here are existing authentication patterns.
Here are the tests.
Here are the project constraints.
Here is the expected behavior.
Now implement the feature and verify it.
La segunda versión le proporciona al agente la arquitectura, las reglas de diseño, el contrato de API, los patrones de autenticación existentes, las pruebas, las restricciones y el comportamiento esperado, y luego le pide que los implemente y verifique. Eso está mucho más cerca de cómo se informaría a un nuevo colega, y la instrucción es solo uno de los elementos. Cuando un agente se comporta incorrectamente, resulta útil preguntar qué capa faltó; nuestra guía sobre depuración de agentes de IA por capas explica detalladamente ese proceso de diagnóstico.
El ingeniero diseña todo el ciclo
El cambio más significativo puede estar en quién tiene la responsabilidad. La relación anterior era directa:
Developer → Code
La nueva relación pasa por varias etapas, y el ingeniero es responsable de todas ellas:
Developer
↓
Specification
↓
Agent
↓
Tools
↓
Code
↓
Tests
↓
Verification
Tener el control del bucle implica saber qué instrucción requiere una situación determinada:
- "Hágalo", cuando la tarea está bien definida y tiene bajo riesgo.
- "Planifíquelo primero", cuando el cambio abarca varios módulos.
- "Deje el código por ahora y estudie la arquitectura primero", cuando se necesita comprenderlo antes de realizar ediciones.
- "Reproduzca el error", antes de aceptar cualquier solución.
- "Deténgase; su suposición es incorrecta", cuando el agente avanza con confianza en la dirección equivocada.
Esa última intervención puede resultar ser una de las habilidades más valiosas de todas, y depende por completo de conocer bien la plataforma para detectar la suposición errónea.
Ni desarrollador de Android ni ingeniero de prompts
Ninguna de estas etiquetas describe por sí sola ese rol. Un desarrollador de Android que solo escribe código en Kotlin a mano se quedará atrás en términos de eficiencia. Quien pueda solicitar ayuda a una IA para escribir en Kotlin pero carezca de conocimientos sobre la arquitectura de Android, tarde o temprano se encontrará atascado. La combinación óptima es la siguiente:
Android Engineering
+
AI Agent Skills
+
System Design
+
Context Engineering
+
Verification
=
AI-Augmented Android Engineer
En la práctica, eso significa mantener los conocimientos sobre Android, profundizar en la comprensión de su arquitectura, aprender a comunicar los requisitos con precisión a las máquinas, y familiarizarse con los agentes, sus herramientas, MCP, las instrucciones de repositorio y las verificaciones automatizadas. Sobre todo, implica saber reconocer cuándo la IA se equivoca. Un agente puede generar con confianza dos mil líneas de código; sin embargo, se necesita a un ingeniero para determinar si esas líneas realmente deben existir.
El futuro más realista no es que la IA reemplace a los desarrolladores, sino que aquellos que trabajan bien con agentes sustituyan a los flujos de trabajo que no lo hacen. Un ingeniero con conocimientos sólidos y una configuración adecuada de agentes puede lograr lo que antes requería mucho más esfuerzo manual. La ingeniería no desaparece; pasa a un nivel superior, donde el razonamiento, la definición de restricciones y la validación de resultados son más importantes que las pulsaciones en el teclado, y donde la arquitectura funciona como un mapa que evita que los agentes se desvíen.
Puntos clave
- Trate las instrucciones para un agente como especificaciones: indique las tecnologías, las decisiones de rendimiento, los requisitos de resiliencia, los contratos, el alcance de las pruebas y lo que no debe cambiar.
- Revise el código generado analizando el sistema en su conjunto (propiedad del estado, ciclo de vida, finalización de procesos, concurrencia, cancelación), y no solo verificando si se compila.
AGENTS.md, y cuídelos como si fueran código.