Hace pocos años, escribir código asistido por IA era una curiosidad. Hoy es lo normal: autocompletado que sugiere la función entera, chats que generan un componente en segundos, herramientas que explican un error críptico en lenguaje llano. El cambio es real y no tiene sentido ignorarlo. Pero también ha aparecido un patrón preocupante: gente que pega código generado sin entenderlo, lo pega en producción y descubre el problema cuando ya es tarde.

Este artículo no es un "la IA es mala" ni un "la IA lo hace todo por ti". Es una guía práctica de dónde ayuda de verdad, dónde falla más de lo que parece, y cómo usarla sin que tu curva de aprendizaje se quede plana.

Para qué sirve realmente la IA generativa al programar

Donde más rinde es en tareas repetitivas y bien definidas: generar el boilerplate de un componente, escribir una función de transformación de datos a partir de una descripción clara, convertir un fragmento de código de un lenguaje a otro, o explicar qué hace un bloque de código que no escribiste tú. También es muy buena resumiendo documentación larga o proponiendo varios enfoques distintos para un mismo problema, algo útil cuando no sabes ni por dónde empezar.

Donde falla con más frecuencia de la que la gente asume es en lógica de negocio específica de tu aplicación, en seguridad (sugiere patrones comunes, no necesariamente seguros) y en código que depende de contexto que el modelo no tiene: convenciones internas de tu equipo, decisiones de arquitectura previas, o el estado real de tu base de datos.

El riesgo de copiar sin entender

El problema no es usar código generado por IA. El problema es integrarlo sin haberlo leído de verdad. Mira este ejemplo, una función que un asistente de IA podría sugerir para buscar un usuario por su nombre:

javascript — sugerencia de IA, sin revisar
function buscarUsuario(nombre) {
  const query = `SELECT * FROM usuarios WHERE nombre = '${nombre}'`;
  return db.query(query);
}

Funciona perfectamente en la demo. El problema es que concatena el valor directamente en la consulta SQL, exactamente el patrón vulnerable a inyección que se explica en el OWASP Top 10 explicado para devs. Un modelo de IA no "sabe" que tu aplicación va a exponer ese campo a usuarios no confiables; simplemente genera el patrón más común que ha visto, y ese patrón no siempre es el correcto para tu caso. La corrección es sencilla si sabes qué buscar:

javascript — revisado y corregido
function buscarUsuario(nombre) {
  const query = 'SELECT * FROM usuarios WHERE nombre = ?';
  return db.query(query, [nombre]);
}

Si no conoces el concepto de inyección SQL, es fácil que ese código pase tal cual una revisión superficial. Ahí está la clave: la IA no sustituye el criterio técnico, lo pone a prueba constantemente.

Cómo usarla sin dejar de aprender

Un hábito que marca la diferencia: pídele a la IA que te explique por qué ha escrito el código de esa manera, no solo que te lo dé. La mayoría de asistentes actuales responden bien a "explícame esta función línea por línea" o "¿por qué usaste este enfoque y no otro?". Convertir cada sugerencia en una mini-lección es lo que diferencia a alguien que aprende usando IA de alguien que simplemente delega en ella.

Otro hábito útil es no aceptar código que no podrías reescribir tú mismo, aunque sea más lento, sin mirarlo. Si un fragmento generado usa una técnica que no reconoces, dedica cinco minutos a entenderla antes de integrarla. Esos cinco minutos son la diferencia entre sumar una herramienta a tu caja y sumar una dependencia de la que no puedes depurar nada.

Y, sobre todo, sigue aplicando los mismos criterios de calidad que aplicarías a tu propio código: nombres claros, funciones pequeñas, sin duplicación innecesaria. Los principios de Clean Code no dejan de aplicar porque el primer borrador lo haya escrito una IA; si acaso, revisar ese código con esos criterios es lo que te obliga a leerlo de verdad en lugar de pegarlo directamente.

Cuándo confiar más y cuándo menos

El nivel de confianza razonable no es fijo, depende de tu propia experiencia. Si estás empezando, es fácil sobreestimar el código generado porque "compila y funciona", sin poder juzgar si es la mejor solución. A medida que avanzas hacia perfiles más senior, la relación cambia: usas la IA más para acelerar tareas que ya sabrías hacer tú mismo, y menos para resolver problemas que no entiendes del todo. Esa progresión está muy relacionada con lo que se explica en junior vs senior: qué se espera realmente en cada etapa — la IA no elimina esa curva, solo cambia en qué parte de ella se apoya cada tarea.

Una guía simple: cuanto más crítico sea el código (seguridad, dinero, datos personales) o más específico sea de tu dominio, menos deberías fiarte de una sugerencia sin verificarla a fondo, aunque parezca correcta a primera vista.

La IA no sustituye entender los fundamentos

En una entrevista técnica nadie te va a dejar pegar la solución de un chat de IA; te van a pedir que expliques tu razonamiento, que depures un error en directo o que adaptes tu código a un requisito nuevo sobre la marcha. Si tu única estrategia para programar es "generar y copiar", esa es exactamente la situación en la que se nota. Usar IA para ir más rápido y entender cada vez menos no es progreso, es acumular deuda de conocimiento que tarde o temprano toca pagar.

Ponte a prueba: buenas prácticas con IA generativa

Ponte a prueba

1. Un asistente de IA te sugiere una función que compila y pasa una prueba rápida. ¿Qué deberías hacer antes de integrarla en tu proyecto?

2. ¿Por qué el código generado por IA puede tener fallos de seguridad como la inyección SQL?

3. ¿Cuál es una buena forma de aprender más mientras usas un asistente de IA?

4. En una entrevista técnica te piden depurar un error en directo. ¿Por qué depender solo de "generar y copiar" te perjudica ahí?

5. Vas a integrar código generado que maneja datos personales de usuarios. ¿Qué nivel de revisión deberías aplicar?

JR

Javier Rodríguez Fernández

Programador con Grado Superior en Desarrollo de Aplicaciones Multiplataforma (DAM). Escribe en DevPulso sobre programación aplicada, sin relleno.