El problema: la IA no puede ver sus propios bugs
Construir y auditar son estados mentales incompatibles. Cuando la IA está construyendo, es optimista: imagina un único camino feliz y se enfoca en "hacer que funcione". En ese modo es ciega a sus propios errores. Auditar requiere lo contrario: pesimismo, imaginar todas las formas en que algo puede fallar.
Si le pides a la IA que construya y revise a la vez, las dos tareas sufren: construye a medias y audita a medias. La solución no es un prompt más listo — es separar las dos fases en turnos distintos.
Las 3 fases del protocolo
C — Construir. La IA construye con energía creativa: investiga el estándar de la competencia, arquitectura limpia, y se auto-prueba mientras avanza. Al terminar, se detiene y te entrega un reporte (qué hizo, qué decisiones tomó, qué NO hizo y por qué). No audita todavía.
A — Auditar (y aquí está el debug de verdad). En un turno NUEVO (mente fresca, pesimista), la IA relee todo su propio trabajo y hace el debug: caza bugs reales (fugas de memoria, condiciones de carrera, fallos de seguridad, accesibilidad rota) y, sobre todo, corrige los gaps, vacíos e inconsistencias que dejó el modo constructor. No solo "encuentra errores": refina todo y lo deja legendario. Cada hallazgo se arregla con una prueba de regresión que fija el arreglo — sin la prueba, el arreglo no está completo.
R — Reflexionar. La IA escribe las lecciones del audit: qué se le escapó en modo constructor y por qué. Ese documento crece con cada ciclo y se vuelve la memoria institucional del proyecto — la próxima vez ya no comete el mismo error.
El loop completo · cómo se cierra de verdad (no solo C-A-R)
En la práctica, C-A-R no termina en "reflexionar": se cierra alimentando todo tu ecosistema, para que el conocimiento no se pierda y el siguiente ciclo arranque mejor. Este es el loop real, tal como se aplica después de cada buena pasada de desarrollo — y junta todo lo que viste en la serie:
- Construir → la IA crea y te entrega su reporte.
- Smoke test → corres las pruebas que pinean el trabajo; todo en verde antes de seguir.
- Auditar / debug → turno nuevo: cazar bugs, corregir gaps, vacíos e inconsistencias, refinar hasta dejarlo legendario (cada arreglo con su prueba).
- Reflexionar → la IA escribe las lecciones (qué se le escapó y por qué).
- Push a GitHub → guardas el punto bueno en la nube (tu red de seguridad).
- Actualizar el grafo → si usas Graphify, reconstruyes el grafo para que refleje lo nuevo.
- Guardar el protocolo en la memoria → lo dejas en tu
CLAUDE.mdpara que la IA NUNCA lo olvide.
Cómo se aplica, paso a paso
- Pídele a tu IA que construya la funcionalidad y que al terminar te dé un reporte (no que audite todavía)
- Lee el reporte y aprueba
- En un mensaje nuevo, escribe "procede con el audit"
- La IA relee todo con ojos de auditor y arregla cada bug con su prueba
- Te entrega el audit con la lista de hallazgos corregidos
- La IA guarda las lecciones para no repetir los errores
El prompt maestro (cópialo y pégalo)
Pega esto al inicio de tu proyecto (en el archivo de instrucciones de tu IA: CLAUDE.md, .cursorrules, las instrucciones de tu agente en NeuralOS, o simplemente al comienzo del chat). A partir de ahí, tu IA aplicará C-A-R por defecto.
A partir de ahora aplica el protocolo CONSTRUIR-AUDITAR-REFLEXIONAR (C-A-R) en todo trabajo no trivial (features nuevas, refactors, cambios multi-archivo). Solo sáltalo en arreglos triviales de una línea o cuando te lo pida explícitamente. === FASE 1 · CONSTRUIR === Construye con energía creativa. Investiga el estándar de la competencia antes de escribir código. Arquitectura con límites limpios. Auto-pruébate mientras avanzas. Cuando termines, DETENTE y entrégame un reporte: - Archivos creados/modificados y decisiones clave - Qué mejoras añadiste sobre el estándar - Resultados de pruebas (type-check, build, tests) - Qué NO hiciste y por qué (límite de alcance) Luego ESPERA. No audites en este turno. No mezcles el audit con la construcción. === FASE 2 · AUDITAR (turno separado · requiere mi aprobación) === Espera a que yo diga "procede con el audit". Entonces: 1. Relee cada archivo con mente de AUDITOR (fresca, pesimista) 2. Cataloga hallazgos: - CRÍTICOS: bugs reales (fugas de memoria, condiciones de carrera, fallos de seguridad, accesibilidad rota, semántica equivocada, corrupción de datos) - MEJORAS: robustez, rendimiento, pulido de UX 3. Arregla cada hallazgo con una PRUEBA DE REGRESIÓN que lo fije — sin la prueba, el arreglo no está completo 4. Corre pruebas agresivas de casos borde: unicode, valores límite, spam de eventos, operaciones concurrentes, rutas de cancelación 5. Valida cuádruple: type-check + build + tests existentes + tests nuevos, TODO en verde antes de cerrar === FASE 3 · REFLEXIONAR (junto al audit) === Escribe un documento de lecciones: cada hallazgo con su causa raíz (¿qué se me escapó en modo constructor?), meta-lecciones, y un checklist actualizado para la próxima construcción. Este documento crece con cada ciclo y es la memoria del proyecto. REGLAS: - Nunca auditar en el mismo turno que construir. - Nunca afirmar "sin bugs" sin haber corrido un audit real sobre el código nuevo. - Nunca saltarte la prueba de regresión de un arreglo del audit. - Causa raíz, nunca parches. Si un valor llega vacío, encuentra POR QUÉ; no lo tapes con un valor por defecto.
Ensambla TU protocolo según lo que ya tienes
El prompt de arriba es la base. Pero el protocolo se vuelve más potente cuando le sumas las herramientas de la serie. Usa el prompt que corresponda a tu setup — de menos a más completo. La idea: que tu IA cierre el loop con TODO lo que tengas.
=== CIERRE DEL LOOP · GITHUB === Después de que el audit quede en verde (type-check + build + smoke tests todos pasando), antes de dar el trabajo por terminado: 1. Recuérdame correr el smoke test si no lo hicimos. 2. Haz un commit con un mensaje claro que describa lo que logramos. 3. Haz push a GitHub para guardar el punto bueno en la nube. Nunca cierres un ciclo sin dejar el progreso respaldado.
=== CONTEXTO PROFUNDO PARA EL AUDIT === Antes de auditar, consulta el grafo de conocimiento (Graphify) o el RAG del proyecto para entender cómo se conecta lo que toqué con el resto. Audita entendiendo el impacto en TODO el sistema, no solo en el archivo que cambié. Pregúntate: ¿qué otras partes dependen de esto? ¿qué se puede haber roto en cascada? === CIERRE DEL LOOP · FULL-STACK === Cuando el audit quede en verde, cierra el ciclo completo, en este orden: 1. Smoke test → todo en verde. 2. Commit + push a GitHub (guardar el punto bueno). 3. Reconstruye / actualiza el grafo de conocimiento (Graphify) para que refleje los cambios nuevos, así el próximo audit tiene contexto fresco. 4. Guarda las lecciones del audit en el documento de memoria del proyecto. 5. Asegúrate de que el protocolo C-A-R siga escrito en CLAUDE.md para no olvidarlo. Este loop se aplica después de cada sprint o pasada significativa de desarrollo.
¿Qué recursos necesitas para aplicarlo?
- Una IA de construcción de código: Claude Code, OpenAI Codex, Cursor, o NeuralOS (que ya trae agentes y la Forja de Apps integrados)
- Un archivo de instrucciones donde pegar el prompt maestro (
CLAUDE.md,.cursorrules, o las instrucciones del agente) - Disciplina para esperar: aprobar la construcción y pedir el audit en un mensaje aparte
- Opcional pero recomendado: un grafo de conocimiento del proyecto para que el audit tenga contexto completo (ver el recurso de Graphify abajo)
Lleva el audit al siguiente nivel
La fase de auditar es mucho más potente si tu IA entiende cómo se conecta todo el proyecto, no solo el archivo que tocó. Para eso existe Graphify: convierte tu repo en un grafo de conocimiento que la IA consulta antes de auditar.
Constructor de grafos de conocimiento multi-modal para asistentes de IA (Claude Code, Codex, OpenCode). Convierte tu repo entero en un grafo interactivo que explica qué hace el código y por qué se diseñó así.
Graphify · grafos de conocimiento para tu IA (guía completa)Aprende a darle a tu IA un mapa completo de tu proyecto para auditar mejor.