El 27 de enero de 1967, Gus Grissom, Ed White y Roger Chaffee estaban sujetos en el Apollo 1 sobre la plataforma de lanzamiento 34. Era una prueba rutinaria sin combustible, sin despegue. A las 6:31 de la tarde, una chispa encendió la atmósfera de oxígeno puro dentro de la cabina. En 17 segundos, los tres astronautas estaban muertos.

La NASA se detuvo. Por completo.

La junta de investigación que se reunió en los días siguientes incluía ocho especialistas y un astronauta: Frank Borman. Era la única persona que había volado en una nave de la era Apollo, y el primer ser humano en entrar en la cápsula quemada tras el incendio. Lo que vio allí, el velcro fundido, el cableado carbonizado, la evidencia de un sistema que había crecido demasiado rápido y demasiado ciego a lo que no sabía, se quedó con él.

Cuando terminó la investigación, Borman no volvió al entrenamiento. Lo enviaron a Downey, California, a la fábrica de North American Aviation donde se construían los módulos de mando, con un único mandato: nada sale de este edificio sin que yo lo diga. Se convirtió en el director in situ del rediseño más exhaustivo de la historia de los vuelos espaciales. Una verificación sistemática de que cada cambio era trazable a un fallo identificado, revisado por las personas correctas, firmado antes de continuar.

Lo describió él mismo tiempo después: «Tuve que ser firme. Nadie podía entrar allí sin la aprobación de Low, Slayton o yo.»

Frank Borman, director residente del programa Apollo — NASA

Dieciocho meses después del incendio que mató a tres astronautas, Frank Borman, Jim Lovell y Bill Anders se subieron a un Apollo 8 completamente reconstruido y viajaron a la Luna. La Nochebuena de 1968, Borman leyó el Génesis ante una audiencia televisiva de quinientos millones de personas. Un desconocido le envió un telegrama después. Decía: «Gracias, Apollo 8. Salvasteis 1968.»

La misión no tuvo éxito porque la NASA fuera rápida. Tuvo éxito porque, tras el peor fracaso de su historia, alguien tuvo la disciplina de verificar todo antes de que volara.

El mismo error, cincuenta años después

En mi último artículo describí Problem-Driven AI, una metodología construida alrededor de una convicción: el cuello de botella nunca fue la construcción. Siempre fue entender el problema con la profundidad suficiente para merecer una solución.

Ese artículo generó la mayor respuesta que he tenido. Muchos de vosotros escribisteis variaciones de la misma pregunta: esto tiene sentido como filosofía, pero ¿cómo se hace cumplir cuando los equipos están bajo presión para entregar?

La respuesta es: construyes una barrera. Lo mismo que Borman construyó en Downey. No una ralentización. Un sistema de verificación que se ejecuta antes de que la máquina construya, comprueba que lo que está a punto de construirse es trazable a un problema real y a una decisión real, y no deja pasar nada que no lo sea.

La brecha de la que nadie habla

Cuando un equipo usa IA para construir, hay un momento preciso en que el pensamiento humano termina y la ejecución de la máquina comienza. Ese traspaso es el momento más peligroso del proceso.

No porque la IA cometa errores. Sino porque no los comete. Ejecuta con perfecta fidelidad lo que recibe. Un problema mal definido, un supuesto tratado como un hecho, una solución que nadie validó con nadie: la IA construye todo eso. Con precisión. A escala. Sin aviso.

Los equipos hablan del modelo, del prompt, de la velocidad. De lo que casi nunca hablan es de si el pensamiento que hay detrás del prompt fue revisado por alguien antes de llegar a la máquina. Si la investigación que hicimos realmente sustenta lo que decidimos construir. Si lo que acordamos en la sala es coherente con lo que le estamos pidiendo al sistema que produzca.

Esa es la brecha de verificación. La misma brecha que mató a Grissom, White y Chaffee. No por malicia. No por incompetencia. Por la ausencia de una comprobación sistemática entre lo que el equipo creía que era verdad y lo que realmente era verdad, antes de activar el sistema.

Problem-Driven AI no es una metodología sobre el papel

Problem-Driven AI nunca pretendió ser un framework que se lee y se archiva. Su ambición es ser un proceso de diseño real: uno donde el pensamiento humano hace el trabajo que solo los humanos pueden hacer, y la IA ejecuta al máximo de su potencial. La metodología tiene cinco fases.

Las tres primeras, Problem Discovery, Solution Alignment y Context Engineering, son enteramente humanas. Investigación con las personas que viven el problema. Decisiones sobre qué construir y por qué. Traducción de ese pensamiento a algo que la IA pueda procesar con fidelidad. Las dos últimas, AI Build y Market Iteration, son donde la máquina construye y el sistema aprende.

La pregunta que muchos de vosotros planteásteis era buena. Entre el pensamiento humano y la ejecución de la máquina, ¿quién comprueba que el traspaso se hizo bien?

El PDA Toolkit

El PDA Toolkit es la respuesta open source. Un sistema de cuatro agentes que se sitúa exactamente en ese traspaso y hace cumplir una regla que Borman habría reconocido de inmediato: nada avanza hasta que pasa la verificación.

Los primeros tres agentes actúan antes de que la IA construya nada. Son controles de calidad del pensamiento, no de la producción.

• /pda-problem es el primer control. Antes de hacer nada, el equipo tiene que haber investigado el problema real con las personas que lo viven y documentarlo. Este agente lee ese documento y comprueba que cada afirmación tiene evidencia detrás, que lo que no se ha verificado está marcado como suposición, y que no hay contradicciones internas sin resolver. No sugiere mejoras. No reescribe. Solo pasa o falla, y cuando falla, dice exactamente por qué.
• /pda-solution entra cuando el equipo ha decidido qué construir y por qué. Comprueba que cada parte de la solución responde a algo concreto del problema investigado. Si hay funcionalidades que el equipo quiere añadir pero que no se remontan a ninguna necesidad real detectada, el agente las señala como especulación. No como una mala idea. Como algo que nadie validó.
• /pda-context verifica el documento técnico que describe cómo construir la solución. Comprueba que las decisiones de ingeniería son coherentes con las decisiones de diseño y producto tomadas antes. Este control existe por una razón concreta: una IA que recibe instrucciones incompletas no se detiene a preguntar. Inventa lo que falta. Y lo inventa con total seguridad, que es exactamente el tipo de error más difícil de detectar después.
• /pda-ai-build se ejecuta solo cuando los tres controles anteriores han pasado. En ese momento, la IA tiene todo lo que necesita para construir: el problema definido, la solución acordada, las instrucciones técnicas. No le queda ninguna decisión importante por tomar. Los humanos ya las tomaron. La IA ejecuta.

Los tres primeros agentes son validadores, no generadores. Si la IA escribe la investigación del problema, el equipo se salta el trabajo más difícil y más valioso del proceso de diseño. Si la IA define la solución, se salta el segundo. Los agentes no reemplazan ese trabajo. Garantizan que se hizo.

Qué viene después

El toolkit está en Beta. No es una advertencia, es un principio de diseño. Problem-Driven AI está construida para evolucionar desde el uso real, no desde la anticipación. Los cuatro agentes actuales cubren el ciclo de verificación central y son completamente funcionales hoy. Las versiones futuras profundizarán en los controles a medida que los proyectos reales revelen dónde están los siguientes gaps.

El pensamiento es tuyo. La IA ejecuta al máximo de su potencial. La verificación es lo que garantiza que los dos estén realmente conectados.

Esa es la barrera que construyó Borman. La que la metodología necesita, y lo que el toolkit garantiza.