Hoy casi nadie escribe código sin tener un asistente abierto al lado. Yo también la uso todos los días, en mis proyectos con clientes y cuando preparo material para mis cursos. Pero usar IA para programar no es lo mismo que dejar que la IA programe por ti, y esa diferencia se nota rápido cuando algo falla en producción y tienes que explicar qué hace ese código.

En este artículo te cuento las reglas que sigo para que la IA me haga avanzar más rápido sin volverme dependiente de ella.

Lo que dicen los números

La Encuesta de Desarrolladores 2025 de Stack Overflow tiene una sección completa sobre IA y vale la pena leerla. Algunos datos:

• El 84% de las personas que respondieron usa o piensa usar herramientas de IA en su trabajo de desarrollo, y el 51% de los desarrolladores profesionales las usa a diario.
• Al mismo tiempo, más gente desconfía de la precisión de estas herramientas (46%) que la que confía (33%).
• La frustración más común, con un 66%, son las «soluciones de IA que están casi bien, pero no del todo».

Ese último dato es el que más me identifica. El problema rara vez es que la IA te dé algo absurdo. El problema es que te da algo que parece correcto, compila, y tiene un detalle mal que te cuesta una tarde encontrar.

Regla 1: dale contexto como si fuera un compañero nuevo

Si le preguntas «cómo hago un login en Android», te va a dar una respuesta genérica, quizás con APIs que ya no se recomiendan. Si le das contexto, la respuesta cambia mucho.

Así se ve un prompt que sí me funciona:

Estoy haciendo una app Android con Kotlin y Jetpack Compose.
Uso MVVM, Hilt para inyección de dependencias y Retrofit para la red.
Necesito una pantalla de login con correo y contraseña.
El ViewModel debe exponer el estado con StateFlow.
No uses XML ni LiveData.
Explícame primero la estructura y después muéstrame el código.

Fíjate en tres cosas: digo qué tecnologías uso, digo qué no quiero y le pido que explique antes de escribir código. Esa última parte es la que más te ayuda a aprender.

Regla 2: pide la explicación, no solo el código

Cuando enseño Android, lo que más me preocupa es ver a alguien pegar código que no entiende. Funciona hoy, pero el día que hay que cambiarlo no sabe por dónde empezar.

Un hábito sencillo: después de recibir un bloque de código, pregúntale «¿qué pasaría si quito esta línea?» o «¿por qué usaste esto y no aquello?». Si no puedes explicar con tus palabras lo que hace cada parte, todavía no es tu código.

Si estás aprendiendo, te recomiendo además intentar el problema por tu cuenta primero, aunque sea un rato. Equivocarte y luego comparar con lo que propone la IA te enseña mucho más que copiar la solución desde el inicio.

Regla 3: la documentación oficial manda

Los modelos aprenden de código que ya existe, y mucho de ese código es viejo. Por eso a veces te sugieren funciones que ya fueron reemplazadas o configuraciones de Gradle de hace varias versiones.

Mi regla es simple: si la IA me sugiere una API que no conozco, la busco en la documentación oficial antes de usarla. En Android es developer.android.com; en Kotlin, kotlinlang.org; en Laravel o WordPress, sus propias guías. Toma dos minutos y te evita adoptar algo que ya no se recomienda.

Regla 4: revisa el código como si lo hubiera escrito otra persona

Porque así es. Un ejemplo que he visto más de una vez en código generado es armar consultas SQL pegando el texto que escribió el usuario. En PHP con Laravel se vería así:

// Mal: el valor del usuario va directo dentro del SQL
$clientes = DB::select("select * from clientes where telefono = '$telefono'");

// Bien: el valor se pasa como parámetro
$clientes = DB::select('select * from clientes where telefono = ?', [$telefono]);

La primera versión funciona en tus pruebas y abre la puerta a inyección SQL. La documentación de Laravel explica que el parameter binding te protege de eso. La IA no siempre lo hace mal, pero tampoco puedes asumir que siempre lo hace bien.

Cuando reviso código generado, me hago siempre estas preguntas:

• ¿Valida lo que entra del usuario?
• ¿Qué pasa si la red falla o la respuesta viene vacía?
• ¿Hay credenciales o llaves escritas en el código?
• ¿Agregó una librería que no necesitaba?

Regla 5: pruebas primero, o por lo menos pruebas

Una forma muy buena de usar la IA es pedirle las pruebas unitarias de una función que tú escribiste, o al revés: escribes tú las pruebas y le pides la implementación. En los dos casos tienes una forma objetiva de saber si el código hace lo que debe.

También le puedes pedir casos límite que no se te ocurrieron: listas vacías, números negativos, textos con tildes o con la ñ. Esos detalles aparecen mucho en apps para usuarios de Latinoamérica.

Regla 6: cuidado con lo que pegas

Esto es lo más importante cuando trabajas con clientes. Antes de pegar algo en un chat de IA, piensa si lo pegarías en un foro público. Llaves de API, contraseñas, datos personales de pacientes o alumnos, archivos .env: nada de eso debería salir de tu máquina sin una buena razón y sin saber qué hace el servicio con esos datos.

El Top 10 de OWASP para aplicaciones con LLM incluye la divulgación de información sensible como uno de los riesgos principales. Si tu empresa o tu cliente tiene reglas sobre esto, síguelas. Y si no las tiene, es buen momento para proponerlas.

Dónde la IA para programar sí me ahorra tiempo

Para no quedarme solo en advertencias, estos son los usos donde la IA me ayuda de verdad:

• Código repetitivo: modelos de datos a partir de un JSON, mapeos entre capas, migraciones sencillas.
• Entender código ajeno: pegar una función de un proyecto heredado y pedir que me explique qué hace, paso a paso.
• Mensajes de error: un stack trace largo de Gradle se entiende mucho más rápido con ayuda.
• Primeros borradores: documentación de una API, el README de un repositorio, comentarios de un pull request.
• Practicar: pedirle ejercicios de Kotlin de dificultad creciente, sin pedirle la solución.

En Android Studio tienes además Gemini integrado en el IDE, que conoce el contexto del proyecto. Las mismas reglas aplican: contexto, revisión y documentación.

Mi forma de verlo

La IA es una herramienta más, como lo fue el autocompletado o Stack Overflow en su momento. Te hace más rápido en lo que ya sabes hacer y te puede enseñar lo que no sabes, si se lo pides. Lo que no hace es responder por tu código frente a un cliente.

En mi canal de YouTube explico Kotlin y Compose desde lo básico, justamente para que entiendas lo que escribes, con o sin asistente. Y si usas la IA de una forma distinta a la que te conté, cuéntame en los comentarios cómo te funciona.