La IA escribe el código. ¿Pero quién lo verifica de verdad?
Imagina esto: le das un problema complejo a una IA, y en pocas horas tienes 17 archivos generados, tablas con resultados, gráficos prolijos y código que parece impecable. El code review dice "looks good". El linter no lanza ninguna alerta. Y sin embargo, hay tres bugs críticos escondidos adentro que están arruinando silenciosamente los resultados.
Esto no es un escenario hipotético. Es exactamente lo que documentó el desarrollador Ihsan Kutluk en junio de 2026 mientras trabajaba en un proyecto real de optimización de rutas para una empresa de transporte de efectivo. Y la conclusión que sacó es incómoda pero necesaria: el código puede verse completamente correcto y estar completamente equivocado al mismo tiempo.
En este artículo analizamos los tres bugs que encontró, por qué ninguna herramienta tradicional los hubiera detectado, y qué significa esto para cualquier equipo de desarrollo que hoy usa IA para generar código — que, en 2026, es prácticamente todos.
El proyecto y los números que no cuadraban
El proyecto resolvía un problema de ruteo de vehículos para una empresa de Cash-in-Transit: 20 cajeros automáticos, demanda variable por día, y el objetivo de reducir la tasa de desabastecimiento. El enfoque clásico fallaba en el 42% de los cajeros. Con un modelo de machine learning orientado a decisiones (SPO+), esa tasa bajó al 25%, con una reducción de costos del 51%. Números sólidos.
Pero cuando el equipo le preguntó a la IA qué pasaría si usaban computación cuántica (Q# y QAOA) para atacar el mismo problema, llegó una respuesta que se veía convincente... hasta que la miraron bien. El algoritmo cuántico violaba restricciones de capacidad pero devolvía exactamente la misma energía que la solución clásica óptima. Y dos configuraciones con profundidades de circuito distintas (p=1 y p=3) arrojaban resultados idénticos hasta cuatro decimales. Eso es matemáticamente imposible.
Ahí empezó la cacería.
Tres bugs que ningún linter hubiera encontrado
El primer bug estaba en el peso de penalización del algoritmo cuántico. El parámetro LAMBDA_C estaba configurado en 0.5, cuando la demanda total superaba ampliamente el límite de capacidad. El resultado: la penalización por violar la restricción era apenas el 1.5% del costo de la ruta. El algoritmo literalmente no podía "sentir" que estaba haciendo algo malo. Subir ese parámetro a 40.0 —un valor que supere el costo máximo de ruta— resolvió el problema.
El segundo bug era más silencioso y más peligroso. El modelo de optimización clásica (MILP) tenía dos restricciones que se contradecían entre sí: visitar todos los cajeros y no exceder la capacidad del vehículo. Pero la demanda total (330k TL) ya superaba el límite de capacidad (250k TL), haciendo imposible satisfacer ambas condiciones simultáneamente. El solver devolvió "Óptimo". Sin advertencias. Sin errores. El número apareció en la tabla y nadie lo cuestionó.
El tercer bug explicaba por qué p=1 y p=3 daban resultados idénticos: el código de comparación estaba midiendo la métrica equivocada. En lugar de medir la energía de expectativa del circuito cuántico —que sí cambia con la profundidad—, medía el argmax de la solución bit a bit. Para cualquier valor de p, ese argmax seleccionaba siempre la misma combinación [1,1,1,1,1]. Los circuitos corrían diferente. La medición no podía distinguirlos.
Una vez corregidos los tres bugs, los resultados cuánticos fueron coherentes con la literatura: QAOA funciona, la profundidad del circuito importa, y en este tamaño de problema se queda entre un 2% y un 4% por debajo del óptimo. Eso es exactamente lo que la teoría predice para hardware NISQ actual.
El punto ciego del desarrollo moderno con IA
Lo que hace especialmente relevante este caso es lo que tienen en común los tres bugs: el código era estructuralmente correcto en todos los casos. Sintaxis válida, nombres de variables coherentes, funciones bien conectadas. Un desarrollador revisando el código en un pull request lo hubiera aprobado sin dudar.
El problema era de comportamiento, no de estructura. Y ahí está el punto ciego que la mayoría de equipos todavía no ha resuelto: las herramientas que usamos para verificar código —linters, analizadores estáticos, revisiones de arquitectura, scanners de seguridad— leen el código. No lo ejecutan. No lo comparan contra lo que se supone que debe hacer.
Cuando un desarrollador escribe código línea a línea, suele tener en la cabeza el comportamiento esperado. Cuando la IA genera 17 archivos en dos horas, ese contexto se pierde. El código llega ya formateado, ya comentado, ya con estructura. Se ve terminado. Y precisamente por eso es más fácil que un bug de comportamiento pase desapercibido.
La propuesta que surge de este proyecto es lo que el autor llama Golden Demo: durante la planificación, a partir de los criterios de aceptación del spec, se genera una implementación de referencia ejecutable —pequeña, determinista— que representa el comportamiento esperado. Después de la implementación, se corre esa referencia y el código real contra los mismos vectores de prueba y se comparan las salidas. Si hay diferencia, se genera un reporte de drift. Al momento del merge, se saben dos cosas: ¿el código corre? Y, más importante, ¿hace lo que se dijo que haría?
¿Cómo aplica esto en empresas de Perú y Latinoamérica?
En la región, la adopción de IA para generación de código está creciendo rápido, especialmente en equipos pequeños y medianos que necesitan producir más con menos personas. Eso está bien. El problema es que muchos equipos están adoptando la velocidad sin adoptar los controles que esa velocidad requiere.
En proyectos de desarrollo que involucran lógica de negocio crítica —cálculo de costos, reglas de despacho, integraciones con ERP, reportes financieros— un bug de comportamiento puede costar mucho más que el tiempo que se ahorró generando el código con IA. Y en muchos casos, ese bug no va a aparecer en pruebas básicas. Va a aparecer en producción, con datos reales, en el peor momento.
La lección práctica no es dejar de usar IA para escribir código. Es entender que el trabajo del desarrollador cambia: pasa de escribir código a especificar comportamiento esperado y verificar que el código generado lo cumpla. Eso requiere criterios de aceptación más precisos, vectores de prueba más pensados, y procesos de validación que vayan más allá del "se ve bien" en el code review.
¿Cómo aplica esto en tu empresa?
Si tu equipo ya usa herramientas como GitHub Copilot, Cursor, Claude o cualquier asistente de código, hay tres acciones concretas que puedes implementar ahora mismo:
- Define criterios de aceptación en términos de comportamiento, no de estructura. No "la función debe calcular el costo", sino "dado este input, el output debe ser este valor con esta tolerancia".
- Incluye pruebas de comportamiento en tu definición de "done". El código generado por IA no está terminado cuando compila. Está terminado cuando pasa los casos de prueba que definen el comportamiento esperado.
- Revisa especialmente los parámetros numéricos y las restricciones de negocio. Son exactamente el tipo de detalle que la IA puede configurar con valores plausibles pero incorrectos, sin que ninguna herramienta estática lo detecte.
En Consultoría-Ti trabajamos con equipos que están en esta transición: aprender a sacarle el máximo a las herramientas de IA para desarrollo sin perder el control sobre lo que el código realmente hace. Si estás en ese proceso y quieres conversar sobre cómo estructurar mejor tus flujos de desarrollo con IA, podemos ayudarte.
Conclusión
La IA puede escribir código más rápido de lo que cualquier desarrollador puede revisarlo. Eso no es un problema en sí mismo — es una herramienta poderosa. El problema es asumir que código que se ve correcto es código que funciona correctamente. Esos son dos conceptos distintos, y la diferencia entre ellos puede ser exactamente donde viven los bugs más costosos.
El caso documentado por Ihsan Kutluk en junio de 2026 es un recordatorio concreto y bien documentado de algo que los equipos de desarrollo necesitan internalizar ahora: verificar comportamiento no es opcional cuando la IA escribe el código. Es exactamente lo que hace falta.
¿Tu equipo tiene procesos para validar el comportamiento del código generado por IA más allá del code review? En Consultoría-Ti podemos ayudarte a diseñar flujos de desarrollo que combinen la velocidad de la IA con los controles que tu negocio necesita. Contáctanos aquí y conversamos.
Fuentes y Referencias
Dev.to — AI Writes the Code. But Who Checks It? (ihsan_kutluk, junio 2026)
✨ Contenido generado con ContentFlow — Consultoría-Ti