Los riesgos de la programación de caja negra con la IA

En QA y en testing es habitual hablar de pruebas de caja negra o pruebas de caja blanca. Las pruebas de caja negra se hacen cuando no conoces el funcionamiento interno del sistema y pruebas su funcionalidad. Las pruebas de caja blanca se hacen cuando conoces el funcionamiento o estructura interna del sistema y se configuran las pruebas para probar los diferentes posibles casos que contempla el código.

Con las herramientas de inteligencia artificial está surgiendo lo que podríamos llamar programación de caja negra. El usuario le especifica a la IA lo que quiere funcionalmente de una aplicación y la IA se lo genera.
El usuario no conoce cómo funciona internamente su aplicación, no le interesa, o no es capaz de comprender las implicaciones de cómo se ha implementado la solución.
Este sería un caso de uso típico de herramientas como Lovable y algunas otras que están empezando a surgir, pero también podría considerarse caja negra la aceptación de código generado por IA sin revisar y sin comprender.

En contraposición a la programación de caja negra también existe la programación de caja blanca con IA. En este caso hay un responsable técnico que decide la arquitectura, como implementar la solución y se ayuda de la IA para implementarla más rápido. En función del contexto y de la capacidad de comprensión los trozos que se delegan en la IA son mayores o menores.
El desarrollador del producto cambia su labor, en vez de escribir líneas de código diseña/dirige, orquesta y revisa, siendo completamente responsable del cómo. Por ello mi recomendación es que los fragmentos solicitados a la IA sean pequeños y concisos como para poder revisarlos, comprenderlos, y asumir su mantenimiento posterior (mi recomendación nada más grande que una pull request que vayamos a revisar y comprender). Aunque el conocimiento completo es inabarcable, y existen varios tonos de blanco, la programación de caja blanca consiste en entender la solución lo más completamente posible, no se trata de dividir una caja negra grande en una multitud de cajas negras más pequeñas.

Aunque obviamente tengo mi preferencia, no es que una forma sea buena o mala per se, simplemente hay que entenderlas, ver sus pros y sus contras y sobre todo entender sus riesgos.

En el caso de la programación de caja negra los riesgos que a mi entender habría que valorar serían:

Riesgo 1: La falta de responsabilidad. Como ya comentaba en un artículo anterior la IA no puede devenir en una dilución de la responsabilidad. Si el software generado no funciona correctamente, tiene problemas de rendimiento, seguridad, estabilidad o efectos secundarios impredecibles, el responsable debe estar claro. No entender ni el cómo ni el porqué de esos problemas hace más complicado la asunción de la responsabilidad.
Riesgo 2: El descontrol de la calidad. No saber cómo se ha generado el software nos hace desconocer si se ha generado un producto de calidad o no. Esto no es nuevo, la mayoría de los stakeholders quieren que el software funcione, sin importar si se ha generado con calidad. Pero los que trabajan y conocen la arquitectura de software saben que si falta calidad, si hay deuda técnica, se acaba pagando: Dificultad de mantenimiento, errores, lentitud, complicación y en última instancia, necesitando rehacer todo el software de nuevo.
Riesgo 3: Desconocimiento de la arquitectura del software: Desconocer la arquitectura del software implica desconocer sus fortalezas y sus debilidades, desconocer qué parte va a hacer falta reforzar o incluso por donde puede o debe evolucionar. Desconocer cuales son sus dependencias y sus potenciales vulnerabilidades.
Riesgo 4: Rendimiento: El rendimiento de una aplicación está íntimamente relacionado con su arquitectura. Podemos hablar de problemas de escalabilidad o “simplemente” de un uso ineficiente de recursos, pero sin entender cómo está hecha una aplicación es imposible, no ya que lo hagamos, si no que planteemos optimizaciones.
Riesgo 5: Conocimiento implícito: Cuando definimos e implementamos existe un contexto y un conocimiento implícito de cada uno de los actores que aporta valor. Por ejemplo un arquitecto o desarrollador software aportará conocimiento sobre arquitectura, patrones de diseño, seguridad de datos, y también cuestiones funcionales basadas en experiencias e implementaciones previas. Al ser implícito mucho de este conocimiento no se traslada ni se requiere que lo aplique a la IA, obteniendo una solución de menor calidad que si hubieran intervenido varios actores con diversidad de conocimiento en su generación.
Riesgo 6: Evolución vs revolución (refactor vs replatform): Tenemos que tener en cuenta que el desarrollo de software es un proceso iterativo. No se hace una aplicación y ya está. Se tiene que evolucionar, arreglar, mejorar, etc…Al no conocer el cómo se ha hecho no se puede especificar la evolución de determinados aspectos, sino que se añaden nuevas especificaciones de alto nivel, existiendo un riesgo muy grande de que la IA rehaga lo existente para cumplir las nuevas especificaciones, dejando de cumplir anteriores, volviendo a cometer errores, y en general apareciendo todos los problemas que surgen al rehacer software en vez de refactorizarlo.
Riesgo 7: Pérdida de oportunidades por falta de conocimiento: Existen casos donde el conocimiento de cómo está hecho, de las capacidades tecnológicas genera oportunidades de negocio, nuevas opciones funcionales, etc.. Es el llamado desarrollo de producto “down to top”. Al obviar este conocimiento y estos actores que conocen el cómo está hecho se pierde esta capacidad creativa.

Conociendo estos riesgos hay que tener cuidado con las implicaciones de la programación de caja negra. No obstante, como comentábamos antes, no es que sea una forma mala, existen casos donde este tipo de programación puede resultar interesante, ya que implica menor consumo de recursos humanos (en consumo de tokens ya no entro).

Por ejemplo pruebas de concepto, pilotos o prototipos puede ser interesante, ya que son casos donde el rendimiento y la estabilidad productiva no son tan necesarias como la velocidad y la capacidad de probar conceptos, además de no pretender generar un software que permanezca, mejore y evolucione.

En resumen, cuando programamos con IA, al igual que si encargamos un software a una consultora, debemos plantearnos las implicaciones de desconocer dicho código, los riesgos que supone y cómo lo vamos a mantener. Tenemos que plantearnos si encargamos el software para la solución a un problema o si queremos implementarlo.