¿Qué errores cometen los desarrolladores al codificar con asistentes de IA?
Un análisis práctico de las formas más comunes en que los desarrolladores hacen un mal uso de los asistentes de codificación con IA, y cómo evitar enviar bugs y vulnerabilidades.
Los asistentes de IA como Copilot, Claude y los modelos integrados en Cursor han cambiado la velocidad a la que se escribe código. No han cambiado cuán cuidadosamente necesita ser revisado. La mayor parte del daño que he visto por codificación asistida por IA viene de un puñado de hábitos repetibles, no de los modelos en sí.
Aceptar sugerencias sin leerlas
La más importante es aceptar una completación con tab porque se ve plausible y compila. Plausible no es correcto. He visto una consulta SQL sugerida eliminar silenciosamente una cláusula WHERE durante un refactor, y la persona la aceptó porque los nombres de las variables coincidían. Si no estás leyendo cada línea que te entrega un asistente a la misma velocidad que leerías un pull request de un compañero de trabajo, vas a enviar algo que no entiendes. Trata cada sugerencia como un primer borrador de un desarrollador junior que es rápido pero no tiene memoria de las convenciones de tu base de código.
Confiarle código sensible a la seguridad
Los asistentes de IA están entrenados con enormes cantidades de código público, y mucho de ese código tiene problemas de seguridad incorporados. Pide un manejador rápido de carga de archivos y a menudo obtendrás algo sin verificación de extensión, sin límite de tamaño, y una ruta construida por concatenación de strings en lugar de os.path.join o una llamada a una librería segura. La misma historia con auth: los asistentes adoran sugerir guardar JWTs en localStorage, o comparar secretos con == en lugar de una comparación de tiempo constante. Nada de esto es malicioso, es solo estadísticamente común en los datos de entrenamiento. Para cualquier cosa que toque autenticación, I/O de archivos, deserialización o SQL, escribe la lógica tú mismo o pasa el resultado del asistente de IA a través de las mismas preguntas de modelado de amenazas que harías con cualquier código nuevo: qué pasa con entrada hostil, qué pasa si esta llamada falla, quién más puede alcanzar este endpoint.
Dejarle inventar dependencias y APIs
Los modelos alucinen nombres de paquetes y firmas de funciones con total confianza. Este es el problema del "slopsquatting" — los atacantes registran los nombres de paquetes falsos que los modelos frecuentemente sugieren, así que un pip install o npm install sin verificar puede descargar algo que no es tu librería de logging en absoluto. Antes de agregar cualquier dependencia que un asistente recomiende, verifica que realmente exista en PyPI o npm, comprueba su conteo de descargas y fecha de publicación, y examina el código si es lo suficientemente pequeño. La misma precaución aplica a las llamadas a API: si el asistente hace referencia a un método que no reconoces, verifica la documentación real antes de asumir que existe.
Perder el modelo mental de tu propio código
Cuando escribes código tú mismo, construyes un mapa mental de por qué cada pieza existe. Cuando aceptas grandes bloques de código generado por IA a lo largo de una sesión, ese mapa se adelgaza rápidamente. Luego un bug aparece tres semanas después y estás debugueando código que nunca escribiste realmente y no recuerdas completamente. La solución no es evitar código generado por IA, es ir más lentamente lo suficiente para explicarte cada bloque a ti mismo, o a un compañero de trabajo, antes de fusionarlo. Si no puedes explicar qué hace una función y por qué lo hace de esa manera, no la fusiones todavía.
Saltarse pruebas porque el código
Escrito con asistencia de IA, revisado y publicado por Michal Pilch (CISSP), Korra Studio.
Esta es una nota de la base de conocimiento de Korra Studio — la plataforma combina cada tema con mentoría 1 a 1.
Empezar gratisarrow_forward