¿Es necesario probar aún más el código generado por la IA?

¿Es necesario seguir probando el código generado por la IA?

Las herramientas impulsadas por IA para escribir código, como GitHub Copilot, son cada vez más populares en el desarrollo de software. Estas herramientas prometen aumentar la productividad, pero algunos también afirman que democratizan la programación al permitir que los no programadores escriban aplicaciones.

Pero, ¿cómo sabemos realmente si el código escrito por una herramienta de IA es adecuado para su propósito?

A continuación, aprenderás qué significa realmente “adecuado para su propósito” y qué herramientas puedes utilizar para evaluarlo. Veremos que las herramientas impulsadas por IA para escribir código no pueden garantizar nada en cuanto a la corrección funcional y la seguridad del código que sugieren. Sin embargo, también veremos que existen herramientas de IA que pueden ayudarte a responder a la pregunta anterior.

Retrocediendo en el Tiempo

Vale la pena comenzar retrocediendo un poco en la historia porque esta pregunta no es para nada desconocida: siempre nos hemos preguntado, “¿Cómo sabemos realmente que el código escrito por los humanos es adecuado para su propósito?” Las personas han estado rascándose la cabeza durante décadas para encontrar soluciones a este problema fundamental en la ingeniería de software.

• Google DeepMind presenta Lyria un innovador generador de música de inteligencia artificial y un parque de juegos creativo.
• Cómo SnapLogic creó una aplicación de texto a tubería con Amazon Bedrock para traducir la intención empresarial en acción
• Explorando la convolución punto a punto en las CNN reemplazando las capas completamente conectadas

Desde los primeros días de los sistemas informáticos programables, los ingenieros se llevaron sorpresas desagradables cuando los programas no hacían lo que pretendían. En aquel entonces, los ciclos de prueba y error para que los programas funcionaran correctamente eran muy costosos. El código de bajo nivel necesitaba ser hecho a mano y perforado en tarjetas. La principal medida para evitar ciclos innecesarios era la revisión de código. La revisión de código implica que un experto lee y trata de entender qué hace el código para señalar errores y brindar sugerencias de mejora, una técnica exitosa que todavía se practica ampliamente hoy en día. Sin embargo, la efectividad de las revisiones y el esfuerzo para llevarlas a cabo de manera exhaustiva disminuyen drásticamente a medida que los costos aumentan con el crecimiento en tamaño y complejidad de los programas.

Pronto surgió la pregunta de cómo se puede determinar de manera más rigurosa si un programa hace lo que se supone que debe hacer. El desafío es cómo expresar lo que se supone que el programa debe hacer. De alguna manera, es necesario comunicar a la máquina lo que el usuario realmente desea. Este es un problema altamente desafiante que todavía está esperando ser resuelto por completo hoy en día.

El problema es común en la ingeniería de productos en todas las disciplinas, y se divide en dos pasos, que generalmente se formulan como las preguntas:

1. ¿Hemos construido el producto correcto?
2. ¿Hemos construido correctamente el producto?

Validación y Verificación

Evaluar si se ha construido el producto correcto se conoce como validación. En última instancia, los usuarios validan si el producto cumple su propósito previsto. La verificación parte de una especificación de requisitos, que sirve como un medio de comunicación entre los constructores del producto y el usuario o cliente. Se supone que las especificaciones deben ser comprendidas por ambas partes: el usuario (un experto en el dominio) y el ingeniero (que puede no ser un experto en el dominio). La verificación consiste en evaluar si la implementación del producto se ajusta a la especificación de requisitos. La validación es claramente el problema más difícil. Lo que es un “producto correcto” es altamente subjetivo y difícil de automatizar.

La buena noticia es que la parte de verificación se puede automatizar por completo: en principio, hasta límites computacionales y teóricos de complejidad. En pocas palabras, se puede demostrar matemáticamente que una implementación satisface la especificación. Esta disciplina se conoce como métodos formales o verificación formal y se basa en formalismos basados en lógica para escribir especificaciones y razonamiento automatizado para realizar las pruebas.

Por prometedor que parezca, el problema principal es, una vez más, quién escribe las especificaciones. Requiere a alguien que sea un experto en el dominio y un experto en la escritura de especificaciones formales – personas así son difíciles de encontrar y muy costosas. Incluso cuando has encontrado a esa persona y has logrado verificar tu implementación, aún queda la parte de validación del problema, es decir, si la especificación describe realmente el producto correcto desde el punto de vista del usuario.

Se ha observado comúnmente que las especificaciones a menudo son “más incorrectas” que la implementación debido a que es extremadamente difícil obtener especificaciones formales correctas. El enorme desafío sigue siendo escalar el razonamiento automatizado a sistemas grandes. En la práctica, la verificación formal ha encontrado su lugar en software comparativamente pequeño, complejo y crítico (seguridad, finanzas), desde el control integrado, la criptografía y los núcleos del sistema operativo hasta los contratos inteligentes.

Una Perspectiva Diferente

En la década de 1970 surgió otra idea para abordar el problema desde un ángulo diferente, llamada programación en N versiones. La idea básica es que, dado que es tan difícil obtener programas e incluso sus especificaciones correctas, se deben implementar el sistema varios equipos independientes y luego votar sobre el resultado. La suposición subyacente es que diferentes equipos cometen diferentes errores; también pueden tener diferentes interpretaciones de la especificación de requisitos. Por lo tanto, en general, se espera que el resultado sea “más correcto” que una implementación única en términos de verificación y tal vez incluso validación. Sin embargo, resultó que la suposición era incorrecta: investigaciones posteriores mostraron que incluso los equipos independientes cometen los mismos errores.

Un legado de este enfoque es que la verificación puede ser vista como programación de 2 versiones: la especificación de requisitos y la implementación son dos caras de la misma moneda. Describen el mismo sistema de diferentes maneras, utilizando diferentes formalismos y puntos de vista. Además, a menudo son escritos por personas o equipos diferentes. Ni la especificación es “más correcta” que la implementación, ni viceversa. Esta forma de pensar puede guiarnos a una visión realista de lo que se puede lograr en la práctica.

Entonces, ¿por qué nos molestamos en tener tanto especificaciones como implementaciones? El beneficio proviene de la programación de 2 versiones: comparar dos descripciones del mismo sistema nos permite ganar confianza cuando están de acuerdo entre sí y encontrar errores cuando no lo están, lo que nos permite reflexionar sobre ambas descripciones y, en última instancia, llegar a descripciones “más correctas”.

La Prueba es una Técnica de Verificación

Ahora, algunos lectores pueden interrumpir: No tenemos especificaciones, así que no podemos hacer eso. ¿Cómo nos afecta esto? Es posible que no tenga una especificación de requisitos sólida, pero puede probar su software. Es cierto, no hemos hablado sobre las pruebas todavía. ¿Qué hace realmente la prueba en el contexto de nuestra discusión?

La prueba es una técnica de verificación. Las pruebas verifican su implementación y las afirmaciones en sus pruebas son, como ya habrá adivinado, la especificación. ¿Cuántas veces le ha sucedido que el error no estaba en la implementación, sino en las pruebas? Esto no es sorprendente, ya que las pruebas son simplemente programación de 2 versiones. Entonces, tener una buena práctica de pruebas con pruebas de extremo a extremo para los requisitos de alto nivel y pruebas unitarias exhaustivas para los de bajo nivel realmente aumenta la confianza en la entrega del producto correcto. Y ¿qué pasa con la ingeniería basada en modelos? Sí, también es programación de 2 versiones con las mismas propiedades.

¿Entonces tenemos que probar más el código escrito por IA?

Evaluar si una aplicación escrita por una herramienta de IA es realmente adecuada para el propósito es tan difícil como hacer lo mismo para el código escrito por humanos, aunque las herramientas de creación de código de IA generativas requieren necesariamente una revisión por parte del desarrollador. La parte difícil es responder a la pregunta de validación: la persona que realiza esta evaluación debe ser un experto en el dominio de la aplicación.

Una herramienta para escribir pruebas automáticamente te ayuda en este proceso, ya que las pruebas que crea te brindan una vista de entrada-salida del comportamiento del código. Por ejemplo, soy coautor de una solución de escritura automática de pruebas llamada Diffblue Cover. No hace conjeturas, te dice de manera directa lo que el código está realmente haciendo y, por lo tanto, te ayuda a evaluar las preguntas de validación y verificación. Las pruebas sirven como punto de referencia para las pruebas de regresión cuando realizas cambios en el código a futuro, independientemente de si fue escrito por un humano o una máquina.

Es muy probable que los no programadores que son expertos en su dominio de aplicación se beneficien de las herramientas de IA para la programación de aplicaciones. Sin embargo, deben ser conscientes de que las implementaciones escritas por herramientas como GitHub Copilot no son correctas por construcción; la corrección funcional y las propiedades de seguridad no están incorporadas en los modelos subyacentes que utilizan. Incluso si se entrenan con código “correcto” (ahora sabemos cuánto significa esto, ya que ningún desarrollador empresarial enviaría código generado por IA a producción sin revisarlo cuidadosamente) y código seguro, estas propiedades no se conservan durante el entrenamiento y la evaluación del modelo.

IA para Rescatar a la IA

Las herramientas impulsadas por IA hacen que programar aplicaciones que hagan algo sea fácil. Sin embargo, se espera que el código de la aplicación sufra problemas similares al código escrito por humanos. Por lo tanto, debes emplear el mismo rigor en las pruebas y el aseguramiento de la calidad que se utiliza para el código escrito por humanos. La confianza en estos procesos puede aumentarse en combinación con una herramienta de IA para escribir pruebas automáticamente que pueda garantizar que las pruebas que produce describan el comportamiento real del código.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!