Un artículo reciente en Fast Company afirma: “Gracias a la IA, el Coder ya no es el rey. Todos saluden al ingeniero de control de calidad”. Vale la pena leerlo y su argumento probablemente sea correcto. La IA generativa se utilizará para crear cada vez más software; La IA comete errores y es difícil prever un futuro en el que no lo haga; por lo tanto, si queremos un software que funcione, los equipos de Garantía de Calidad cobrarán importancia. «Salve al ingeniero de control de calidad» puede ser un cebo para hacer clic, pero no es controvertido decir que las pruebas y la depuración aumentarán en importancia. Incluso si la IA generativa se vuelve mucho más confiable, el problema de encontrar el “último error” nunca desaparecerá. Sin embargo, el auge de la garantía de calidad plantea una serie de preguntas. En primer lugar, una de las piedras angulares del control de calidad son las pruebas. La IA generativa puede generar pruebas, por supuesto; al menos puede generar pruebas unitarias, que son bastante simples. Las pruebas de integración (pruebas de múltiples módulos) y las pruebas de aceptación (pruebas de sistemas completos) son más difíciles. Sin embargo, incluso con las pruebas unitarias, nos topamos con el problema básico de la IA: puede generar un conjunto de pruebas, pero ese conjunto de pruebas puede tener sus propios errores. ¿Qué significa «probar» cuando el propio conjunto de pruebas puede tener errores? Las pruebas son difíciles porque las buenas pruebas van más allá de simplemente verificar comportamientos específicos. Aprende más rápido. Excavar más hondo. Ver más lejos. El problema crece con la complejidad de la prueba. Encontrar errores que surgen al integrar varios módulos es más difícil y se vuelve aún más difícil cuando se prueba la aplicación completa. Es posible que la IA necesite usar Selenium o algún otro marco de prueba para simular hacer clic en la interfaz de usuario. Sería necesario anticipar cómo los usuarios podrían confundirse, así como cómo los usuarios podrían abusar (intencional o no) de la aplicación. Otra dificultad con las pruebas es que los errores no son sólo descuidos y descuidos menores. Los errores más importantes son el resultado de malentendidos: no comprender correctamente una especificación o implementar correctamente una especificación que no refleja lo que el cliente necesita. ¿Puede una IA generar pruebas para estas situaciones? Una IA podría ser capaz de leer e interpretar una especificación (particularmente si la especificación estuviera escrita en un formato legible por máquina, aunque esa sería otra forma de programación). Pero no está claro cómo una IA podría evaluar la relación entre una especificación y la intención original: ¿qué es lo que realmente quiere el cliente? ¿Qué se supone que debe hacer realmente el software? La seguridad es otra cuestión más: ¿puede un sistema de inteligencia artificial crear un equipo rojo para una aplicación? Admito que la IA debería ser capaz de hacer un excelente trabajo de confusión, y hemos visto a la IA en los juegos descubrir «trampas». Aún así, cuanto más compleja sea la prueba, más difícil será saber si está depurando la prueba o el software que se está probando. Rápidamente nos topamos con una extensión de la Ley de Kernighan: depurar es dos veces más difícil que escribir código. Entonces, si escribe código que está en los límites de su comprensión, no es lo suficientemente inteligente como para depurarlo. ¿Qué significa esto para el código que no has escrito? Los humanos tienen que probar y depurar código que no escribieron todo el tiempo; eso se llama «mantener el código heredado». Pero eso no lo hace fácil ni (de hecho) agradable. La cultura de la programación es otro problema. En las dos primeras empresas en las que trabajé, el control de calidad y las pruebas definitivamente no eran trabajos de alto prestigio. Ser asignado a control de calidad era, en todo caso, una degradación, generalmente reservada para un buen programador que no podía trabajar bien con el resto del equipo. ¿Ha cambiado la cultura desde entonces? Las culturas cambian muy lentamente; Lo dudo. Las pruebas unitarias se han convertido en una práctica generalizada. Sin embargo, es fácil escribir un conjunto de pruebas que brinde una buena cobertura en papel, pero que en realidad pruebe muy poco. A medida que los desarrolladores de software se dan cuenta del valor de las pruebas unitarias, comienzan a escribir conjuntos de pruebas mejores y más completos. Pero ¿qué pasa con la IA? ¿Cederá la IA a la “tentación” de escribir pruebas de bajo valor? Quizás el mayor problema, sin embargo, es que priorizar el control de calidad no resuelve el problema que ha afectado a la informática desde el principio: los programadores que nunca entienden suficientemente bien el problema que se les pide que resuelvan. En respuesta a una pregunta de Quora que no tiene nada que ver con la IA, Alan Mellor escribió: Todos empezamos a programar pensando en dominar un lenguaje, tal vez usando un patrón de diseño que sólo las personas inteligentes conocen. Entonces, nuestro primer trabajo real nos muestra una perspectiva completamente nueva. El lenguaje es la parte fácil. El dominio del problema es difícil. He programado controladores industriales. Ahora puedo hablar de fábricas, control PID, PLC y aceleración de mercancías frágiles. Trabajé en juegos de PC. Puedo hablar de dinámica de cuerpos rígidos, normalización de matrices, cuaterniones. Un poco. Trabajé en automatización de marketing. Puedo hablar sobre embudos de ventas, doble suscripción, correos electrónicos transaccionales, feeds por goteo. Trabajé en juegos móviles. Puedo hablar sobre diseño de niveles. De sistemas unidireccionales para forzar el flujo de jugadores. De sistemas de recompensa escalonados. ¿Ves que tenemos que aprender sobre el negocio para el que codificamos? El código es literalmente nada. Idioma nada. La tecnología no acumula nada. A nadie le importan los monos. [sic]todos podemos hacer eso. Para escribir una aplicación real, debes comprender por qué tendrá éxito. Qué problema resuelve. Cómo se relaciona con el mundo real. En otras palabras, comprender el dominio. Exactamente. Esta es una excelente descripción de de qué se trata realmente la programación. En otro lugar, escribí que la IA podría hacer que un programador sea un 50% más productivo, aunque esta cifra probablemente sea optimista. Pero los programadores sólo dedican alrededor del 20% de su tiempo a codificar. Recuperar el 50% del 20% de tu tiempo es importante, pero no es revolucionario. Para que sea revolucionario, tendremos que hacer algo mejor que dedicar más tiempo a escribir conjuntos de pruebas. Ahí es donde la visión de Mellor sobre la naturaleza del software es tan crucial. Generar líneas de código no es lo que hace que el software sea bueno; esa es la parte fácil. Tampoco lo es la creación de conjuntos de pruebas, y si la IA generativa puede ayudar a redactar pruebas sin comprometer la calidad de las mismas, sería un gran paso adelante. (Soy escéptico, al menos por el momento). La parte importante del desarrollo de software es comprender el problema que se intenta resolver. Elaborar conjuntos de pruebas en un grupo de control de calidad no ayuda mucho si el software que estás probando no resuelve el problema correcto. Los desarrolladores de software deberán dedicar más tiempo a las pruebas y al control de calidad. Eso es un hecho. Pero si todo lo que obtenemos de la IA es la capacidad de hacer lo que ya podemos hacer, estamos perdiendo. La única manera de ganar es hacer un mejor trabajo para comprender los problemas que necesitamos resolver.