Desarrollamos 10 veces más rápido. ¿Estamos también acelerando los errores?

En los últimos meses se ha consolidado una línea de pensamiento en torno al desarrollo de software asistido por IA, y apunta en la dirección correcta. El término Loop Engineering surgió de la práctica (Boris Cherny, creador de Claude Code, y Peter Steinberger lo pusieron en el mapa, y Andrew Ng luego lo sistematizó en sus tres loops para construir productos de 0 a 1) y reemplaza el paradigma inicial del surgimiento de GenAI, el de "un prompt, una respuesta", por ciclos donde el agente planifica, implementa, prueba, evalúa y reintenta. Liu Shangqi, de Thoughtworks, articuló el Spec-Driven Development: la calidad del software ya no depende solo del código, sino de la calidad de las especificaciones que recibe el agente. Y Sunit Parekh, también de Thoughtworks, propuso los cinco bloques de la ingeniería AI-native (Agent, Model, Methodology, Spec y Context): la idea de que improvisar prompts ya no basta; hay que orquestar todo el entorno en el que trabaja el agente.

Todo esto apunta en la dirección correcta. Pero para mí todavía falta algo, y vale la pena mirar más de cerca esos cinco bloques, porque en mi humilde opinión son el mapa más completo que existe hoy: Agent es quién ejecuta, Model es con qué capacidad se desarrolla, Methodology es bajo qué proceso, Spec es qué se le pide al agente, y Context es con qué conocimiento previo puedo crear más rápido el nuevo conocimiento, aplicación, modelo o lo que sea que esté construyendo. Los cinco gobiernan los inputs y la ejecución. Ninguno gobierna el output como conocimiento: ninguno pregunta si lo que el agente produjo es correcto en términos del dominio de conocimiento en el que se está desarrollando, o de los subdominios que ese desarrollo involucra.

Tras varios meses desarrollando modelos híbridos de machine learning, IA y software guiados o acelerados por agentes para distintas industrias (salud, ingeniería, minería) con agentes como Claude Code y Codex, entre otros, junto con la colaboración de sus entornos tradicionales, y teniendo en cuenta que cada uno tiene su campo en el que es mejor que los demás, estoy convencido de que hay piezas del rompecabezas en esta nueva forma de crear conocimiento y valor que se nos están escapando y que no todos están viendo.

Casi toda la conversación está orientada a acelerar la generación de software, o incluso de conocimiento. Pero muy poca a validar el conocimiento que producen los agentes, la validez de su razonamiento, el juicio que asume los criterios éticos y científicos.

Los errores costosos son cada vez menos de programación

En mi experiencia, los errores que más cuestan ya no son bugs. Son más sutiles, y por lo tanto más peligrosos, porque dependen de conocimiento real y profundo; en los últimos meses he visto que, usando Spec-Driven Development, aparecen problemas sutiles y difíciles de ver:

• Interpretaciones incorrectas del objetivo del problema, o una mala comprensión del problema.
• Aplicación de métodos matemáticos o estadísticos inapropiados o equivocados.
• Supuestos implícitos que nunca se pidieron.
• Comprensión parcial del contexto del dominio.
• Soluciones técnicamente impecables… a un problema distinto del que queríamos resolver.
• Afirmaciones persistentes a las que los modelos se aferran hasta que se les demuestra lo contrario.

En machine learning e IA esto ocurre con una frecuencia sorprendente, y con una sutileza que solo se distingue cuando uno ha aprendido desde la base matemática de los problemas, o porque el conocimiento experto sugiere que algo está mal.

Un agente puede implementar correctamente un algoritmo y, al mismo tiempo, optimizar la métrica equivocada, introducir data leakage, malinterpretar un análisis de feature importance, proponer un esquema de validación metodológicamente incorrecto o asumir una restricción que nunca existió. El código compila, los tests pasan, y sin embargo la conclusión (científica, clínica, de negocio) puede estar equivocada. ¿Y quién la revisa? ¿Quién la audita?

Ninguna suite de tests atrapa eso. Los tests verifican que el código hace lo que dice que hace. No verifican que lo que dice que hace sea lo correcto.

Los agentes no hacen lo que pides, con una frecuencia que suele pasar inadvertida

Hay un fenómeno que observo una y otra vez, y que está en la raíz de casi todos esos errores.

Los agentes no hacen lo que pediste. Hacen lo que entendieron que pediste.

La diferencia parece sutil, pero en proyectos complejos puede cambiar el resultado por completo. El código puede ser impecable y aun así responder a otra interpretación de la intención original. Y como el artefacto que recibes (el código, el gráfico, el número) parece terminado, la brecha entre lo que se pidió y lo que se entendió queda oculta hasta que alguien con conocimiento del dominio la detecta. A veces mucho después.

Este es exactamente el punto ciego que los cinco bloques anticipaban. Spec mejora la calidad de lo que entra. Context mejora la calidad del conocimiento previo. Methodology y Loop Engineering mejoran la calidad del proceso. Todos trabajan sobre los inputs y la ejecución. Ninguno valida el output como conocimiento: si el razonamiento es correcto, si el método es el apropiado, si los supuestos son admisibles, si el problema resuelto es el problema real.

El siguiente paso: un Expert Validation Loop

Por eso creo que el próximo avance no consiste solo en mejorar los agentes. Consiste en incorporar un Expert Validation Loop: un ciclo explícito donde expertos del dominio (científicos, ingenieros, médicos, estadísticos, arquitectos o especialistas de negocio) revisan no solo el código, sino el razonamiento, los supuestos, las decisiones metodológicas y la comprensión del contexto, antes de aprobar un resultado. Dicho simplemente, el conocimiento formal aprendido en las universidades, el que construye pensamiento crítico, razonamiento abstracto e intuición, empieza a importar más que antes. Porque el conocimiento más general ya está al alcance de casi todos, pero el otro no.

No es un code review con otro nombre. Es una capa distinta, con preguntas distintas:

• ¿El objetivo que el agente optimizó es el objetivo real, o uno cercano que se le parece?
• ¿El método estadístico es apropiado para la estructura de estos datos, o solo para datos bien comportados?
• ¿Qué supuestos se introdujeron sin pedirlos, y siguen siendo válidos?
• ¿La conclusión resiste el juicio de alguien que conoce el dominio, o solo el criterio de que "el código corre"?

El experto no reemplaza al agente. Cierra el loop que el agente no puede cerrar por sí mismo, porque un modelo no sabe lo que no sabe sobre el dominio. En la práctica, el Expert Validation Loop convierte al especialista de "revisor final ocasional" en parte estructural del ciclo de desarrollo, tan estructural como los tests, y por las mismas razones: porque lo que no se valida explícitamente, se asume.

Y sin embargo: mejor software no es más valor

Aquí vale la pena subir un nivel. Toda la conversación (Spec-Driven Development, Context Engineering, Loop Engineering, incluso este Expert Validation Loop) se centra en producir inteligencia de mayor calidad a través de agentes, y a una velocidad varias veces mayor que la que nos habíamos acostumbrado a tener en los últimos años. Pero producir mejor software, o más rápido, no garantiza por sí solo producir más valor para una organización.

Desde la perspectiva que vengo desarrollando en AI Value Realization Theory (AVRT), la IA no crea valor directamente: genera potencial de inteligencia. El valor aparece solo cuando esa inteligencia se convierte en mejores decisiones, esas decisiones en mejores acciones y esas acciones en resultados medibles. Es precisamente en esa conversión donde muchas iniciativas de IA tienen éxito técnico y fracasan en la creación de valor, y, más allá de eso, podrían producir problemas que hasta ahora la madurez del desarrollo tecnológico ya había superado.

Y aquí se encuentran las dos ideas. Si el valor nace de convertir inteligencia en decisiones, entonces convertir inteligencia incorrecta más rápido no es progreso: es riesgo acelerado. Un pipeline que genera modelos diez veces más rápido, sin una capa que valide que esos modelos responden a la pregunta correcta, no acelera la creación de valor: acelera la propagación de conclusiones equivocadas hacia decisiones reales. El Expert Validation Loop es, en el lenguaje de AVRT, la compuerta que asegura que la inteligencia que entra en la cadena de conversión es correcta antes de convertirse en acción.

Las piezas encajan así:

• Spec-Driven Development (Liu Shangqi) mejora la calidad de las especificaciones.
• Context Engineering mejora la calidad del contexto.
• Loop Engineering (Ng, sobre Cherny y Steinberger) mejora la calidad de la iteración.
• Los cinco bloques AI-native (Sunit Parekh) orquestan el entorno de ejecución.
• Expert Validation Loop mejora la calidad del conocimiento generado.
• AI Value Realization Theory (AVRT) explica cómo toda esa inteligencia se convierte, o no, en decisiones, acciones y valor.

La hipótesis

La IA ha reducido drásticamente el costo de construir. Lo que antes tomaba semanas o meses ahora toma horas. Cuando construir deja de ser el cuello de botella, el cuello de botella pasa a ser otra cosa: la velocidad a la que una organización puede validar lo que construyó y aprender de ello. Eso reordena mucho de lo que dábamos por sentado, desde los ciclos Agile hasta la cadencia de los OKR, y es un tema que merece su propia discusión. Porque ahora desarrollar en Agile, o trabajar con OKR, en materias que requieren desarrollo de software ya no es más costoso; cerrar en ciclos cortos se vuelve cada vez más real, pero requiere un doble clic.

Quizás el mayor impacto de la IA no sea escribir software más rápido. Quizás sea acelerar la capacidad de una organización para aprender, decidir mejor y convertir ese aprendizaje en valor, y eso exige, antes que velocidad, una forma explícita de validar que lo aprendido es verdadero.

Esa, al menos, es una hipótesis que creo que vale la pena explorar.

Referencias

• Liu, Shangqi (2025). Spec-driven development. Thoughtworks, 10 de diciembre de 2025.
• Parekh, Sunit (2026). Beyond vibe coding: The five building blocks of AI-native engineering. Thoughtworks Insights, 18 de marzo de 2026.
• Ng, Andrew (2026). Loop Engineering — three loops for building 0-to-1 products. LinkedIn. Ng atribuye el origen del término a Boris Cherny (creador de Claude Code) y Peter Steinberger.
• Barrientos, Claudio (2026). AI Value Realization Theory (AVRT). Serie en LinkedIn.