Ejecutando Claude Code como un Motor de Juicio Puro a lo Largo de Todo el SDLC

Un desarrollador en r/ClaudeAI detalló su configuración de varios meses usando Claude Code (el runtime con uso de herramientas y bucle multi-turno) en todo el ciclo de vida del desarrollo de software — tickets, implementación entre repos, revisión de código, MRs y una capa de conocimiento persistente.

Decisión arquitectónica clave: Mantener a Claude Code fuera de la orquestación. Python simple maneja todo el trabajo mecánico: llamadas a la API de Jira, operaciones de git, ejecución de pruebas, lint, movimientos de archivos. Claude Code solo se invoca para juicio — escribir código, evaluar hallazgos de revisión, elegir entre opciones arquitectónicas. El autor encontró que mezclar ambos (dejar que el agente orqueste mediante uso de herramientas) hacía la primera versión lenta, costosa y no determinista.

Ciclo de vida concreto de un ticket:

• Orquestador Python: Obtiene el ticket de Jira, busca en la wiki local decisiones arquitectónicas relacionadas, configura un worktree en una rama nueva, arma un resumen de implementación de 30–50 líneas (criterios de aceptación, archivos objetivo, llamadores de funciones compartidas modificadas, estándares relevantes). Genera un paquete JSON.
• Claude Code: Lee el resumen y escribe el código. Este es el único paso con consumo significativo de tokens.
• Python + subagente de revisión: Ejecuta pruebas, lint, formato. Si falla, devuelve al agente de implementación (máximo 3 reintentos). Luego envía un subagente de revisión de código configurado sin permisos de Edición ni Escritura — solo puede leer e informar hallazgos.
• Python: Crea una propuesta en un tablero. Tras aprobación manual, el orquestador hace push y crea el MR.

Técnicas específicas de Claude Code que importaron:

• Aislamiento de subagentes. El agente de revisión se ejecuta en su propia ventana de contexto con una lista de denegación (Editar, Escribir). Separar revisión e implementación detectó cambios de comportamiento en código compartido que el agente de implementación pasaba por alto.
• Resúmenes preensamblados superan a la exploración dinámica. Al principio, dejar que Claude Code explorara el código base antes de la implementación consumía notablemente más tokens que pasarle un resumen enfocado ensamblado por Python (obtención de Jira, búsqueda en wiki, análisis de dependencias).
• Enrutamiento de habilidades/comandos mediante YAML en lugar de dejar que el agente decida. El mapeo de /ticket, /review, /standup, etc. a orquestadores es explícito, por lo que las capacidades son inspeccionables en lugar de emergentes.
• Los hooks limitan los commits. Un hook pre-commit ejecuta lint y formato antes de cualquier commit que intente Claude Code. Las violaciones bloquean el commit; el agente debe corregirlas.

Capa wiki: Páginas Markdown con tres niveles de confianza (verificado, inferido, proporcionado por humanos) y umbrales de obsolescencia a nivel de campo. Sin la jerarquía, los agentes tratan sus propias inferencias pasadas como verdad y combinan alucinaciones en conocimiento de apariencia autorizada.

Dificultades aún en proceso:

• Funcionalidades entre repos: el agente pierde coherencia cuando una funcionalidad abarca múltiples servicios, incluso con seguimiento estructurado de conjuntos de cambios.
• Tickets vagos: el agente produce implementaciones razonables pero a menudo incorrectas a partir de especificaciones ambiguas. El autor ahora marca los tickets ambiguos como bloqueantes.
• Expansión del alcance: el instinto de sobreingeniería requiere calibración constante mediante estándares y el agente de revisión.
• Sesiones largas: el contexto anterior sale de la atención efectiva; la reinicialización al inicio de la sesión mitiga pero no elimina el problema.