Ética y buenas prácticas en el desarrollo de software con IA

Los asistentes de código basados en IA dejaron de ser una curiosidad. Hoy escriben funciones completas, proponen pruebas, explican errores y, en algunos equipos, generan la mayor parte del código nuevo. El problema no es la herramienta: es que muchas organizaciones la adoptaron sin cambiar nada más. Se mantiene el mismo proceso de revisión, el mismo criterio de calidad y la misma idea de quién responde cuando algo falla.

Este artículo no trata de si conviene usar IA para programar. Trata de cómo usarla sin perder el control del código, sin arrastrar riesgos legales y sin que el equipo deje de entender lo que mantiene. La ética, en este contexto, es sobre todo una cuestión de responsabilidad y de criterio profesional.

La responsabilidad no se delega en la herramienta

El primer malentendido es creer que, si el código lo escribió un asistente, la responsabilidad se diluye. No ocurre así. Quien firma un commit, quien aprueba un pull request y quien pone el sistema en producción responde por lo que ese código hace, sin importar qué parte se generó automáticamente.

De ahí se desprende una regla simple y difícil de sostener en la práctica: nadie debería aprobar código que no entiende. Si un fragmento generado resulta opaco para quien lo revisa, el problema no es menor. Un código que nadie comprende es un código que nadie puede depurar a las tres de la mañana.

• El autor del commit es responsable del contenido, aunque lo haya redactado una IA.
• El revisor debe poder explicar qué hace el cambio y por qué es correcto.
• Si nadie en el equipo puede explicarlo, el cambio no está listo para producción.

Vale la pena decirlo explícitamente en las políticas internas. Cuando la expectativa no está escrita, cada persona improvisa y la calidad del resultado depende del criterio individual de quien esté ese día frente al teclado.

Verificar antes de confiar: alucinaciones, dependencias y licencias

Los modelos generan código plausible, no necesariamente correcto. Inventan métodos que no existen en la versión de la librería que usamos, proponen paquetes con nombres que suenan razonables pero que no son los oficiales, y a veces sugieren configuraciones que funcionan en un ejemplo y fallan en producción.

El caso de las dependencias merece atención especial. Un paquete sugerido por un asistente puede no existir, estar abandonado o, peor, haber sido registrado por alguien con intenciones de suplantación. Antes de añadir una dependencia conviene comprobar quién la mantiene, cuándo fue la última publicación, cuántas descargas tiene y si el nombre coincide exactamente con el del proyecto oficial.

El otro frente es la licencia. El código generado puede reproducir fragmentos con condiciones de uso que no son compatibles con el proyecto. En equipos que distribuyen software a terceros o que trabajan con componentes de código abierto, esto no es un detalle teórico: es un riesgo que se descubre tarde, cuando ya hay clientes usando el producto.

• Contrastar cada API sugerida con la documentación de la versión que realmente usamos.
• Revisar el origen de cualquier dependencia nueva antes de incorporarla.
• Mantener un inventario de dependencias y sus licencias, y revisarlo cuando entra algo nuevo.
• Tratar el código generado como código de terceros: se lee, se prueba y se adapta.

Datos sensibles y confidencialidad

Una de las decisiones más delicadas es qué se pega en la ventana del asistente. Código propietario, credenciales, cadenas de conexión, datos de clientes, esquemas de bases de datos con información real: todo eso puede salir de la organización sin que nadie lo note.

La pregunta que hay que responder antes de adoptar cualquier herramienta es dónde se procesan los datos, si se almacenan, durante cuánto tiempo y si se usan para entrenar modelos. La respuesta cambia según el proveedor y según el plan contratado, y no siempre es la misma para la versión gratuita que para la empresarial.

En la práctica, esto se resuelve con reglas claras y con hábitos:

• Definir qué entornos y qué repositorios pueden usar asistentes externos.
• Prohibir pegar credenciales, datos personales o extractos de bases de datos reales.
• Anonimizar o sustituir datos antes de pedir ayuda con un error que incluye registros reales.
• Preferir herramientas con acuerdos de tratamiento de datos y retención configurable cuando se trabaja con código de clientes.

También conviene revisar qué extensiones del editor tienen acceso al código. Un asistente instalado sin criterio puede tener más permisos de los necesarios y enviar más contexto del que suponemos.

Calidad, pruebas y deuda técnica

La IA acelera la escritura de código, no la comprensión del problema. Cuando el volumen de código crece más rápido que la capacidad del equipo para revisarlo, aparecen patrones que se repiten: funciones duplicadas que resuelven lo mismo de tres maneras, abstracciones innecesarias, dependencias añadidas para ahorrar veinte líneas y pruebas que verifican el comportamiento del código generado en lugar del comportamiento esperado del sistema.

El antídoto es el de siempre, aplicado con más disciplina: pruebas que describan el comportamiento requerido, revisiones con criterio, y una definición de terminado que no se negocie por haber ido más rápido.

• Escribir primero la prueba o, al menos, el criterio de aceptación; después generar el código.
• Rechazar en revisión el código que no se puede explicar, aunque funcione.
• Vigilar la duplicación: es el síntoma más frecuente de generación masiva sin consolidación.
• Reservar tiempo explícito para refactorizar; la velocidad de escritura no elimina esa necesidad.

Hay un indicador útil y poco usado: cuánto tarda alguien nuevo en entender un módulo. Si ese tiempo crece, el equipo está acumulando deuda aunque las métricas de entrega se vean bien.

Transparencia con el equipo y con el cliente

La transparencia tiene dos destinatarios. Hacia dentro, el equipo necesita saber cuándo un cambio fue generado con asistencia, no para penalizarlo, sino para revisarlo con más atención y para que quien lo mantenga después sepa qué esperar. Una línea en la descripción del pull request suele bastar.

Hacia fuera, la conversación depende del tipo de producto. En sistemas donde las decisiones afectan a personas —evaluación de solicitudes, priorización de casos, atención automatizada—, el cliente y el usuario final tienen derecho a saber qué papel juega la automatización y qué revisión humana existe. Documentar esas decisiones no es burocracia: es lo que permite responder cuando alguien pregunta.

También es sano acordar qué usos están fuera de discusión. Por ejemplo, generar código para un módulo de cálculo de nómina sin revisión especializada, o automatizar decisiones que tienen efectos legales sobre una persona. Tener esa lista escrita evita discusiones improvisadas bajo presión de plazos.

Un punto de partida para el equipo

No hace falta un manual de cien páginas. Sirve más una guía breve, acordada y revisable, que responda cinco preguntas: quién responde por el código generado, qué datos no salen de la organización, cómo se revisa lo que no se entiende, qué pruebas se exigen antes de integrar y en qué casos se avisa al cliente.

La IA es una herramienta potente y, bien usada, mejora el trabajo diario. Pero el criterio profesional sigue siendo humano: decidir qué se acepta, qué se prueba y qué se documenta. Un equipo que conserva ese criterio puede adoptar cualquier asistente sin perder el control de su software.