Contratos de esquema para que el agente no se desvíe al escribir código
Un usuario de Reddit describe por qué los planes en texto no limitan a un agente en la fase de codificación y publica design-harness, una skill que obliga a generar un ADR y un mapa de componentes antes de tocar archivos.
El flujo de cuatro fases para agentes de código —explorar requisitos, planificar, escribir archivos y auditar con linters y tests— se rompe siempre en el mismo punto: el paso de la planificación a la escritura. Lo cuenta un usuario en r/PromptEngineering a raíz de su propia experiencia, y su diagnóstico es que el plan en texto no restringe nada. El plan se ve perfecto en la ventana del chat; en cuanto el modelo empieza a modificar ficheros, se va por donde quiere.
El autor da tres motivos. El primero es la ambigüedad: una línea como "refactoriza los permisos de usuario para comprobar roles vía middleware" es inequívoca para una persona, pero deja al modelo libertad total sobre firmas de funciones, ubicación de imports y tipos de retorno. El segundo es la compactación de contexto: si la conversación de planificación duró 15 turnos, ese plan se resume antes de generar código y por el camino se pierden justo las restricciones técnicas que se habían acordado. El tercero es que un plan en el chat no impone fronteras: nada impide que el agente toque archivos fuera del alcance pactado.
El artefacto intermedio
La solución que propone es meter un artefacto legible por máquina entre las fases de planificación y codificación. Antes de conceder permisos de escritura, el agente debe producir un Architecture Decision Record (ADR) y un mapa visual de componentes. El ADR tiene que detallar tres cosas: las rutas de archivo exactas que se pueden editar, las interfaces TypeScript de entrada y salida de las funciones nuevas, y qué paquetes tienen prohibido importarse.
El autor ha publicado una skill para esto, design-harness, en el repositorio tigerless-labs/design-harness. Se engancha a Claude Code, convierte las especificaciones generadas en la fase de exploración en registros markdown y en un lienzo visual interactivo, y bloquea el paso a la modificación de código hasta que los límites entre componentes se confirman de forma visual. La idea de fondo es convertir el plan en un contrato verificable en lugar de un texto que el modelo interpreta a su manera.
Qué falta por comprobar
El argumento técnico es razonable: si el agente no tiene una representación estructurada de dónde puede escribir, cualquier instrucción en lenguaje natural es una sugerencia, no un límite. Dicho eso, la pieza viene de un post autopromocional en Reddit, sin demo pública ni datos de un tercero que respalden que el método reduce las desviaciones. El propio autor cierra preguntando a otros cómo fuerzan el cumplimiento de las fronteras arquitectónicas una vez que el agente empieza a escribir, lo que sugiere que el problema no está resuelto del todo. Para quien tenga agentes tocando repositorios en producción, la parte aprovechable hoy es la idea de exigir rutas permitidas e interfaces explícitas antes de dar permiso de escritura, se use esta herramienta o una propia.
