No hace falta dominar lenguajes de programación avanzados para construir aplicaciones. La IA ha derribado las barreras del código, permitiendo expresar lo que se quiere en un lenguaje natural.

O al menos, eso parece.

Pero programar no es solo escribir sintaxis. Es pensar en la arquitectura de sistemas, entender cómo usarán realmente una plataforma las personas y asegurar que existan las medidas adecuadas para limitar vulnerabilidades.

Conversé con Gabriela Moreira, CEO de Quint, sobre cómo las personas que usan herramientas de IA para escribir código pueden entender mejor los riesgos asociados y establecer verificaciones y procesos tempranos para evitar código inmaintainable y bugs catastróficos.

¿Puede confiarse en que la IA escriba código listo para producción sin supervisión humana? En caso de no ser así, ¿qué distingue los errores generados por IA de los errores humanos?

La supervisión es necesaria, porque la IA existe para servir a los humanos, y por lo tanto son los humanos quienes deben indicar a la IA qué hacer y evaluar sus resultados.

Ahora, ¿qué tipo de evaluación es la más adecuada? Se puede leer el código línea por línea o enviar a producción y monitorear problemas, para describir dos extremos. Ambos son técnicas ya utilizadas para supervisar código con posible error humano.

Las grandes diferencias que aporta la IA son la cantidad de código potencialmente incorrecto que se genera y la disociación cognitiva de cualquier humano respecto a los elementos de lo que se produce. La revisión del código y el monitoreo se vuelven más difíciles ante esa escala y esa disociación cognitiva.

Qué sistemas centrales de negocio son los más vulnerables a fallos de codificación por IA

Aquellos que son más difíciles de probar, como sistemas concurrentes y distribuidos, o cualquier sistema con alto grado de no determinismo donde hay muchas rutas a considerar.

La IA es una herramienta de generación, que solo es tan buena como nuestra capacidad para decidir si la solución generada es correcta o no. Si tengo buenas pruebas, u otro tipo de verificación en el que confío, puedo aceptar soluciones de IA con menos riesgo. Si un sistema es difícil de probar o verificar, pueden existir demasiados puntos ciegos donde pueden colarse fallos.

Cuáles son los riesgos operativos y de seguridad ocultos de desplegar código generado por IA sin verificación formal

Quizá la mejor forma de pensar el riesgo en 2026 es considerar la asimetría: los defensores deben proteger todas las partes del código, mientras que los atacantes pueden encontrar solo una vulnerabilidad para causar un daño enorme.

Las empresas de IA ya contemplan esta asimetría al decidir entregar un modelo como Mythos solo a compañías que se comprometen a asegurarse, antes de que llegue a manos de posibles atacantes.

La verificación formal es probablemente la herramienta más robusta que conocemos para enfrentar esta asimetría, pero aún existen desafíos que dificultan verificar toda la superficie de código, y pueden aparecer vulnerabilidades en componentes no verificados. No hay solución mágica, y combinar diferentes estrategias es lo más prudente.

Por qué es tan importante detectar a tiempo un fallo de diseño

Antes de que la IA escribiera código, la respuesta a esta pregunta era distinta: porque reescribir código es costoso y propenso a errores si se detecta el fallo después de meses de desarrollo. No creo que ese argumento siga siendo tan fuerte.

Ahora la respuesta es: es mucho más probable encontrar este problema dentro de un diseño que aún puedes razonar que después de que la IA escriba miles de líneas de código con el fallo oculto en alguna de ellas.

Quizá puedas notar el problema mientras escribes el código, pensando “espere, ¡no consideramos este escenario!”. Pero es menos probable que ocurra si la IA escribió el código, así que un diseño más cuidadoso es importante.

Los desarrolladores están acostumbrados a razonar sobre posibilidades y fallos mientras compilan y ejecutan diferentes versiones de código, por lo que me preocupa enormemente que el proceso de diseño dependa de archivos markdown que no se pueden compilar ni ejecutar, ni interactuar con ellos de ninguna manera aparte de leerlos.

Qué comprobaciones simples, herramientas y redes de seguridad pueden implementar los equipos de desarrollo para verificar el código generado por IA antes de que llegue a producción

Primero, pruebas. Pero pruebas que realmente sirvan para generar confianza, no cualquier prueba generada por IA que haga afirmaciones arbitrarias y que deba actualizarse constantemente.

Me gusta pensar en las pruebas en términos de qué comportamientos ejercen y qué tipos de regresiones evitan. Si controlar la calidad de las pruebas se vuelve un reto, los modelos formales pueden ayudar generando escenarios a probar o validando que las pruebas existentes aseguren comportamientos interesantes.

Además, la “mutación de pruebas” es muy útil para medir la calidad de las pruebas, evaluando cuántas regresiones diferentes pueden detectar.

Qué nivel de supervisión humana recomiendas para equilibrar velocidad de desarrollo con calidad y confiabilidad del código

Esto depende mucho del contexto y de los riesgos. Lo mejor que puedo recomendar es hacer lo que permita desplegar con la suficiente confianza y sentirse capaz de realizar cambios sin temor a romper lo que ya funciona.

El peor escenario siempre es ser hackeado o que se filtren datos de otras personas. El segundo peor es llegar a un estado en el que hay muchas cosas mal con el software, pero intentar arreglarlo termine rompiéndolo aún más, quedando atascados.

Creo que es bastante fácil que el código generado por IA termine en ese estado. Curiosamente, veo que la forma de salir de él es muy similar a cómo manejamos el código heredado que se volvió difícil de mantener: primero añadir suficientes pruebas para estar seguros de que la supervisión es suficiente, y luego cambiarlo.