Programar con inteligencia artificial: 10 errores frecuentes y cómo evitarlos

Programar con inteligencia artificial puede ahorrar trabajo al preparar una función, explorar una API o proponer pruebas. El error aparece cuando una respuesta plausible se convierte directamente en código de producción. GitHub recuerda en su guía de uso responsable que las sugerencias pueden ser incorrectas o inseguras y que quien las incorpora debe revisarlas y probarlas. Estos diez fallos frecuentes tienen una prevención concreta: requisitos claros, cambios pequeños y verificación independiente.

1. Pedir «hazme la aplicación» sin definir el resultado

Un encargo abierto deja demasiadas decisiones al asistente: qué datos acepta, cómo maneja errores, qué permisos necesita y cómo sabrás que funciona. La respuesta puede parecer completa mientras resuelve un problema distinto del tuyo. Antes de pedir código, escribe una mini especificación: comportamiento esperado, entradas, salidas, casos límite y restricciones del proyecto. Si no sabes aún qué interfaz usar, pide primero alternativas y sus consecuencias. Después elige una y solicita un cambio limitado que puedas revisar. Esto reduce el área en la que la IA tiene que adivinar.

2. Dar contexto incompleto y aceptar supuestos ocultos

Una solución para una versión de biblioteca puede no valer para la instalada. Lo mismo ocurre con la versión del lenguaje, la base de datos, el sistema operativo o las convenciones del repositorio. Incluye archivos relevantes, versiones reales y un ejemplo representativo, sin entregar secretos. Pide al asistente que enumere sus supuestos y que marque qué puntos requieren consulta a la documentación oficial. Luego verifica esas afirmaciones: una función con nombre convincente puede no existir o comportarse de otra manera. En tareas grandes, empieza por un archivo o módulo y revisa el resultado antes de ampliar el alcance.

3. Confundir una respuesta que compila con una que cumple

Que el código se ejecute no demuestra que haga lo correcto. Puede devolver una respuesta válida para el ejemplo feliz y fallar con entradas vacías, permisos insuficientes, duplicados o errores de red. Define criterios de aceptación antes de generar la implementación. Por ejemplo: «si falta el identificador, devuelve un error claro sin escribir en la base de datos». Revisa cada criterio contra el comportamiento real, no contra la explicación de la IA. Un diff pequeño permite detectar condiciones omitidas con más facilidad. La guía de desarrollo seguro del NIST sitúa la revisión y la verificación dentro del proceso, independientemente de quién escribió el código.

4. Publicar sin pruebas relevantes

Pedir «añade tests» puede producir pruebas que repiten la misma suposición equivocada de la implementación. Formula casos desde los requisitos y los fallos que te importan: resultado normal, límite, dato inválido, fallo externo y permiso denegado. Ejecuta las pruebas en tu entorno, interpreta los fallos y comprueba que un test fallaría si el comportamiento se rompiera. Las pruebas automáticas no sustituyen una revisión de flujo completo, pero hacen visible una parte del contrato. Si el cambio modifica una interfaz, prueba también a quien la consume; si cambia una migración, prepara un plan de reversión antes de aplicarla.

5. Copiar dependencias sugeridas sin comprobarlas

Una respuesta puede añadir un paquete innecesario, citar una versión inexistente o introducir una biblioteca abandonada. Antes de instalar nada, comprueba el registro oficial del lenguaje, la documentación del proyecto y el archivo de bloqueo. Pregunta qué capacidad aporta la dependencia y si la biblioteca estándar o una ya instalada resuelve el problema. Revisa licencia, mantenimiento y avisos de seguridad. GitHub describe cómo los avisos de Dependabot ayudan a localizar vulnerabilidades conocidas en dependencias, pero esas alertas no avalan por sí solas la calidad ni la pertinencia de cada paquete. Mantener un inventario de dependencias facilita futuras actualizaciones.

6. Ignorar límites de confianza y datos sensibles

Un asistente no necesita una clave real, datos personales completos ni un volcado de producción para escribir una función. Sustituye los valores sensibles por ejemplos ficticios y revisa las políticas de la herramienta y de tu organización antes de compartir código privado. Tampoco aceptes código que incruste contraseñas o tokens. Usa los mecanismos de secretos previstos por tu plataforma y limita los permisos. La documentación de GitHub sobre secretos explica por qué se separan las credenciales del código. Si una credencial ya se expuso, ocultarla en el siguiente commit no basta: GitHub aconseja revocarla o rotarla como primer paso.

7. Dar por segura una ruta porque «la IA la revisó»

Las salidas pueden omitir validación de entradas, controles de acceso o límites de uso. Para una ruta que lee datos, comprueba quién puede pedirlos y qué campos devuelve; para una que escribe, revisa autorización, validación y manejo de errores. Pasa las herramientas habituales de análisis del proyecto y solicita revisión humana cuando el riesgo sea alto. La propia guía de GitHub advierte que el código generado puede parecer correcto sin ser seguro. Un comentario tranquilizador escrito por la IA no es evidencia. Lo que importa es una comprobación reproducible sobre el cambio concreto.

8. Aceptar un diff enorme imposible de entender

Una petición pequeña puede terminar reescribiendo archivos, cambiando nombres y alterando configuraciones. Si no puedes explicar cada cambio, será difícil detectar efectos laterales. Divide la tarea en pasos: primero interfaz, luego implementación, después pruebas y documentación. Pide que justifique cada archivo nuevo y elimine lo que no esté relacionado. Compara el diff con el estado anterior y revisa especialmente permisos, configuración, dependencias y borrados. Si aparece una modificación inesperada, detén esa parte y averigua por qué está ahí. La velocidad de generación solo ayuda cuando la revisión sigue siendo posible.

9. Olvidar procedencia, licencias y mantenimiento

Que el código aparezca en una conversación no significa que sea original, adecuado para tu licencia ni mantenible. En su documentación, GitHub señala la posibilidad de coincidencias con código público y recomienda las mismas precauciones que con material ajeno. Si la sugerencia contiene un fragmento sustancial reconocible, comprueba procedencia y condiciones antes de incorporarlo. Escribe nombres comprensibles y explica decisiones que no se deduzcan del código. Dentro de unos meses alguien deberá depurar esa función sin tener a la vista la conversación que la generó; el repositorio tiene que contener el contexto necesario.

10. Delegar la última decisión de publicación

Un asistente puede proponer una corrección y ejecutar pruebas, pero no conoce por sí solo todos los riesgos del servicio, los datos o los usuarios. Antes de desplegar, revisa criterios de aceptación, pruebas, cambios de configuración, migraciones y plan de vuelta atrás. Si el código toca pagos, autenticación o datos sensibles, ajusta la profundidad de la revisión al daño posible. Nuestro artículo sobre permisos y controles para agentes de IA desarrolla esa parte operativa; aquí el foco está en el código. La responsabilidad de aprobar el cambio debe tener un nombre y una evidencia, no un «parece bien».

Un flujo de trabajo breve que evita varios errores a la vez

1. Describe el comportamiento y tres casos límite antes de pedir implementación.
2. Proporciona versiones y archivos relevantes, con datos ficticios.
3. Pide un cambio pequeño y los supuestos que lo sostienen.
4. Comprueba APIs y dependencias en sus fuentes oficiales.
5. Revisa el diff, ejecuta pruebas propias y analiza la seguridad según el riesgo.
6. Documenta la decisión y aprueba solo lo que puedes explicar.

La IA es útil para explorar soluciones y acelerar trabajo repetitivo; no ofrece un atajo para saltarse el criterio técnico. Si el producto es una web, la evaluación final incluye rendimiento, accesibilidad y comportamiento real además de que «se ve bien». En cómo evaluar una web hecha con IA o a mano ampliamos esa comprobación. No hemos medido aquí una herramienta concreta ni probado que un flujo reduzca errores en un porcentaje determinado: la propuesta es un método verificable para revisar cada cambio.

Sobre la imagen de portada: Ilustración conceptual original generada con IA para Gaia Genius Hub; el código y la interfaz son ficticios y no documentan una auditoría real.

Fuentes primarias consultadas el 16 de octubre de 2026: GitHub: uso responsable de Copilot Chat; NIST: Secure Software Development Framework SP 800-218; GitHub: alertas Dependabot; GitHub: tipos de secretos; GitHub: eliminación de datos sensibles y rotación de credenciales. No se han ensayado asistentes ni medido ganancias de productividad. Las prácticas de revisión se ajustan al riesgo y a las políticas del proyecto; no sustituyen una auditoría de seguridad.