Antes de que quemes muchos tokens con un gran enjambre de agentes en un nuevo proyecto, el viejo dicho de la carpintería "¡Mide dos veces, corta una vez!" merece ser revisado como "Revisa tus beads N veces, implementa una vez," donde N es básicamente tantas veces como puedas soportar. He encontrado que sigues obteniendo más y más mejoras, incluso si son sutiles, cuantas más veces ejecutes esto en fila con Opus 4.5 (ten en cuenta que el siguiente aviso es solo para usar DESPUÉS de que ya hayas convertido tu plan inicial en markdown en beads usando el otro aviso que te di recientemente en mi reciente y muy largo post sobre mis flujos de trabajo): "Vuelve a leer AGENTS dot md para que aún esté fresco en tu mente. Revisa cada bead con mucho cuidado-- ¿estás seguro de que tiene sentido? ¿Es óptimo? ¿Podríamos cambiar algo para que el sistema funcione mejor para los usuarios? Si es así, revisa los beads. ¡Es mucho más fácil y rápido operar en el "espacio de planificación" antes de que empecemos a implementar estas cosas! ¡NO SIMPLIFIQUES EN EXCESO LAS COSAS! ¡NO PIERDAS NINGUNA CARACTERÍSTICA O FUNCIONALIDAD! Además, asegúrate de que como parte de estos beads, incluimos pruebas unitarias completas y scripts de prueba e2e con un gran registro detallado para que podamos estar seguros de que todo está funcionando perfectamente después de la implementación. Recuerda usar SOLAMENTE la herramienta `bd` para crear y modificar los beads y para agregar las dependencias a los beads. Usa ultrathink." Solía ejecutar eso solo una o dos veces antes de comenzar la implementación, pero experimenté recientemente ejecutándolo más de 6 veces, y seguía haciendo refinamientos útiles. Si comienza a estabilizarse en términos de mejoras incrementales en los beads, podrías intentar comenzar una nueva sesión de CC, comenzándola con: "Primero lee TODOS los archivos AGENTS dot md y README dot md con mucho cuidado y entiende TODO de ambos. Luego usa tu modo de agente de investigación de código para entender completamente el código, la arquitectura técnica y el propósito del proyecto. Usa ultrathink." Y luego seguir con el mismo aviso que se muestra arriba, pero precedido por: "Recientemente transformamos un archivo de plan en markdown en un montón de nuevos beads. Quiero que revises y analices esto con mucho cuidado usando `bd` y `bv`." Cuanto más complejo e intrincado sea tu plan en markdown, más relevante es esta técnica. Si tienes un plan pequeño y trivial y un proyecto muy simple, esto es obviamente excesivo. Pero en ese caso, probablemente verás poco en términos de ganancias/cambios incrementales con cada ronda, así que debería ser bastante obvio cuándo es el momento de detenerse. Solo recuerda: los tokens de planificación son mucho menos y más baratos que los tokens de implementación. Incluso un plan en markdown muy grande y complejo es más corto que unos pocos archivos de código sustantivos, y mucho menos que un proyecto completo. Y los modelos son mucho más inteligentes al razonar sobre un plan que es muy detallado y desarrollado pero aún trivialmente pequeño como para caber fácilmente dentro de su ventana de contexto (esta es realmente la clave detrás de mi enfoque obsesivo en la planificación y por qué pasé más del 80% de mi tiempo en esa parte). Y si te apoyas en GPT Pro con Razonamiento Ampliado en la aplicación web para la planificación inicial como yo abogo firmemente (es decir, para crear y mejorar tu plan en markdown que eventualmente conviertes en beads), básicamente obtienes eso en una base de todo lo que puedas comer con un plan Pro, ¡así que aprovecha al máximo eso! Ningún otro modelo puede tocar Pro en la web cuando se trata de entradas que encajan fácilmente en su ventana de contexto. Es verdaderamente único. ...