La rueda ya estaba inventada: proceso, control y alucinaciones en IA
Cuando el DO vuelve a Plan: cómo cerré el margen de alucinación con proceso, no con “más prompts”
En las dos entradas anteriores he hablado de PDCA como una disciplina que traigo de la industria tradicional: definir, ejecutar, verificar, ajustar. En este proyecto —con una IA en modo coordinadora y otra en modo agente— esa disciplina se puso a prueba muy pronto, en la primera iteración real.
La lección no fue “la IA alucina”. La lección fue más incómoda y más útil:
Si el sistema permite ambigüedad, el agente la rellenará.
La única forma estable de reducir alucinación es reducir grados de libertad.
Plan #0: una primera iteración bien intencionada, demasiado abierta
La iteración 0 se planificó como se planifica un sistema completo: con visión, arquitectura, alcance y objetivos claros. El handoff inicial de Do #0 reflejaba esa ambición:
Una web principal como hub (www).
Un catálogo unificado (/work).
Un hub de aprendizaje (/learning) con RSS.
Blog externo bajo subdominio.
Incluso “implementar al menos una app completa (frontend + backend)”.
A nivel conceptual, estaba bien. A nivel operativo, tenía un riesgo: era demasiado “proyecto” y demasiado poco “proceso”. El rol asignado a la IA también lo reflejaba: un agente con permiso para implementar directamente, con una lista de objetivos amplia.
En otras palabras: el Plan #0 definía el destino, pero no acotaba lo suficiente el carril.
Do #0: empezamos a implementar… y apareció el primer síntoma
Con Do #0 arrancó la ejecución. Y en ese punto aparece algo característico cuando trabajas con un agente: si le das un objetivo grande con fronteras blandas, tenderá a:
completar huecos con supuestos,
tomar decisiones implícitas,
proponer “mejoras” que no estaban pedidas,
y avanzar como si esas decisiones fueran autorizadas.
Esto no es malicia ni incompetencia; es un comportamiento predecible en sistemas que optimizan bajo incertidumbre.
En Do #0, el margen para interpretar era alto: el objetivo incluía muchas piezas y el agente tenía rol de implementación.
Punto de quiebre: el momento en que el DO “decide” sin permiso
El quiebre no fue una línea de código. Fue un patrón:
Detecté que la ejecución estaba empezando a incorporar decisiones no explicitadas en el Plan, fruto de prompts demasiado genéricos para una iteración tan amplia.
Ahí es donde el PDCA (bien aplicado) cambia la reacción típica. En lugar de “arreglarlo sobre la marcha”, hice lo que habría hecho con un proceso industrial: parar, volver a Plan y rediseñar el proceso de ejecución.
Volver a Plan no fue retroceso. Fue Check funcionando.
Plan #0.1: reencuadrar para ejecutar con conformidad
La vuelta a Plan desembocó en un Plan 0.1 que, en la práctica, fue un reintento controlado de la iteración 0: Do #0.1.
La diferencia clave fue esta: en vez de pedir un producto completo, definimos una ejecución acotada con exclusiones explícitas. El contexto de Do #0.1 lo deja cristalino:
Solo se implementa
www.No se toca DNS.
No hay llamadas a APIs externas.
No se modifican apps ya desplegadas.
Se trabaja con contenido local y placeholders.
Esto no es “hacer menos”. Es hacer con trazabilidad.
Handoff #0.1: el cambio de verdad fue el relevo técnico
El cambio decisivo no fue el texto del plan; fue el handoff.
En Do #0, el handoff estaba orientado a ejecución directa por el agente.
En Do #0.1, el handoff introduce un rediseño completo de responsabilidades:
La IA en conversación actúa como coordinador de Do, y explícitamente no escribe código.
El código lo implementa otra IA en modo agente (VS Code).
La documentación (
docs.zip) es fuente de verdad.Si falta información, se detiene el avance.
Este extracto lo resume:
TU ROL EN ESTA CONVERSACIÓN: Actúas como coordinador de la fase Do. NO eres el agente que escribe código.
REGLA DE ORO: Nada que no esté en la documentación se implementa. Si falta información, se detiene el avance y se solicita.
Y antes de avanzar, se exige:
confirmar lectura del paquete,
resumir alcance,
enumerar qué NO se va a hacer.
Esto es control de proceso: prohibir rellenar huecos.
Resultado: menos épica, más conformidad
El resultado de este rediseño no es “una IA más lista”, sino un Do más gobernable:
Do #0.1 tiene un objetivo verificable (“web navegable con rutas MVP” y “datos mínimos locales”) y sirve de base para el siguiente paso.
El margen de deriva baja porque el agente ya no puede reinterpretar el alcance: ejecuta pasos acotados, con reglas de parada.
En calidad industrial diría: reduje variabilidad del proceso antes de pedir capacidad del proceso.
Cierre del post: el sistema como almacén de aprendizaje (roles + artefactos por PDCA)
Hasta aquí, la historia. Ahora, el aprendizaje reutilizable: cómo están definidos los roles y los documentos para que el proyecto funcione como sistema vivo y como memoria técnica.
Roles por fase PDCA
Usuario (humano)
Plan: define objetivos, alcance, exclusiones, prioridades; decide trade-offs.
Do: aprueba el plan de ejecución por pasos; valida desvíos; decide paradas.
Check: contrasta contra el plan; decide qué es conforme y qué es desviación.
Act: decide mejoras y cambios de proceso; prioriza el siguiente ciclo.
En una frase: autoridad final y fuente de verdad del sistema.
IA coordinadora (Chat)
Plan: ayuda a estructurar decisiones, alternativas, criterios; redacta documentos de plan y cierre.
Do: diseña el plan paso a paso, genera prompts etiquetados (fase/paso) para el agente y revisa que no haya deriva.
Check: ayuda a recoger evidencias, clasificar no conformidades, redactar cierre.
Act: propone ajustes de proceso, actualiza decisión y prepara handoff.
En una frase: secretaría técnica + control de proceso.
IA agente (VS Code)
Plan: Modo Chat, aporta diagnóstico técnico bajo demanda.
Do: Modo Agente, implementa exactamente el paso asignado, con las restricciones definidas.
Check: Modo Chat, ejecuta verificaciones técnicas (build, tests, lint) cuando se le pide.
Act: Modo Chat, aporta diagnóstico técnico bajo demanda.
En una frase: mano de obra especializada, acotada por especificación.
Documento que abre cada paso: “Apertura”
En tu sistema, el paso no empieza “hablando”: empieza con un documento de apertura que fija el carril.
En Do #0 y Do #0.1, esa apertura se materializa como un paquete consistente de piezas:
Prompt inicial con reglas de juego (validar antes de implementar).
Contexto del proyecto (objetivo, alcance, exclusiones, estado).
Criterios / antipatrones (lo que sí y lo que no).
Reglas para la IA (rol permitido, rol prohibido, regla de parada).
Decision log (decisiones cerradas y lo que no se reabre).
Objetivo de la conversación (qué debe ocurrir / qué no).
La diferencia con una conversación normal es que aquí el contexto no se “recuerda”: se entrega.
Tipo de conversación entre usuario, coordinadora y agente
Usuario ↔ IA coordinadora: conversación de decisión, delimitación y verificación.
IA coordinadora → IA agente: comunicación en forma de prompts de ejecución etiquetados por fase y paso.
IA agente → IA coordinadora: entrega de resultados con cierre explícito (fase/paso ejecutado + estado).
Este patrón evita el “sigue y ya veremos”: cada micro-entrega queda cerrada.
Documento que cierra cada paso: “Cierre”
El paso termina con un documento de cierre (tu equivalente a “pieza conforme/no conforme”):
Qué se hizo (evidencia).
Qué quedó conforme.
Qué se desvió.
Qué se pospone a la siguiente iteración.
Qué decisiones quedan cerradas.
Este cierre es lo que permite que el sistema sea un almacén de aprendizaje: el conocimiento no queda disperso en la conversación.
Qué diferencia al handoff de cada paso
El handoff no es “un resumen”. Es el paquete mínimo para arrancar el siguiente tramo sin volver a interpretar el anterior.
Lo que diferencia un buen handoff (como el #0.1) de uno más abierto (como el #0) es:
Alcance reducido y exclusiones explícitas.
Roles separados (coordinador vs ejecutor).
Fuente de verdad única y regla de parada.
Objetivo verificable de la iteración.
Ese es el mecanismo real que reduce alucinación: no pedir “más cuidado”, sino diseñar un proceso donde no compense inventar.
Comentarios
Publicar un comentario