Incluí la versión en miniatura de este aviso aquí porque la serie "Mis Avisos Favoritos" se supone que debe ser compacta, de tamaño reducido y contenerse por sí misma. Pero hoy transformé esto en un sistema verdaderamente loco. No es relevante si estás haciendo otro programa CRUD en React o una lista de tareas, pero si estás haciendo algo bastante complicado en Rust o Golang, o algo que involucra datos complejos, este enfoque es casi aterrador en lo que puede hacer. Es un proceso de 2 rondas. Aquí está la Ronda 1: --- 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. Luego, una vez que hayas hecho un trabajo extremadamente minucioso y meticuloso en todo eso y hayas entendido profundamente todo el sistema existente y lo que hace, su propósito, y cómo está implementado y cómo todas las piezas se conectan entre sí, necesito que investigues, estudies y reflexiones de manera hiperintensiva sobre estas preguntas en relación con este proyecto: ¿Hay alguna otra ineficiencia grave en el sistema central? lugares en la base de código donde 1) los cambios realmente moverían la aguja en términos de latencia/responsividad y rendimiento general; 2) de tal manera que nuestros cambios serían probadamente isomórficos en términos de funcionalidad para que supiéramos con certeza que no cambiarían las salidas resultantes dadas las mismas entradas; 3) donde tienes una visión clara de un enfoque obviamente mejor en términos de algoritmos o estructuras de datos (ten en cuenta que para esto, puedes incluir en tus contemplaciones estructuras de datos menos conocidas y algoritmos más esotéricos/sofisticados/matemáticos, así como formas de reformular el(los) problema(s) para que se exponga otro paradigma, como la lista que se muestra a continuación (Nota: Antes de proponer cualquier optimización, establece métricas de referencia (latencia p50/p95/p99, rendimiento, memoria máxima) y captura perfiles de CPU/asignación/E/S para identificar los verdaderos puntos críticos): - Eliminación del patrón de consulta/fetch N+1 - cero-copia / reutilización de buffers / E/S scatter-gather - costos de formato de serialización (sobrecarga de análisis/codificación) - colas limitadas + presión de retroceso (prevenir explosión de memoria y latencia de cola) - fragmentación / bloqueos en tiras para reducir la contención - memoización con estrategias de invalidación de caché - técnicas de programación dinámica - teoría de optimización convexa - evaluación perezosa / computación diferida - patrones de iterador/generador para evitar materializar grandes colecciones - procesamiento en streaming/chunked para trabajos limitados por memoria - pre-computación y tablas de búsqueda - búsqueda basada en índices vs reconocimiento de escaneo lineal - búsqueda binaria (en datos y en espacio de respuestas) - técnicas de dos punteros y ventana deslizante - sumas prefijas / agregados acumulativos - ordenación topológica y conciencia de DAG para gráficos de dependencia - detección de ciclos - unión-encontrar para conectividad dinámica - recorrido de grafos (BFS/DFS) con terminación anticipada - Dijkstra's / A* para caminos más cortos ponderados - colas de prioridad / montículos - tries para operaciones de prefijo - filtros de Bloom para membresía probabilística - árboles de intervalo/segmento para consultas de rango - indexación espacial (árboles k-d, quadtrees, R-trees) - estructuras de datos persistentes/inmutables - semánticas de copia-en-escritura - agrupamiento de objetos/conexiones - selección de políticas de eliminación de caché (LRU/LFU/ARC) - selección de algoritmos conscientes de lotes - agrupamiento y coalescencia de E/S asíncronas - estructuras sin bloqueo para escenarios de alta contención - robo de trabajo para paralelismo recursivo - optimización de diseño de memoria (SoA vs AoS, localidad de caché) - cortocircuito y terminación anticipada - interning de cadenas para valores repetidos - razonamiento de análisis amortizado teniendo en cuenta estas guías generales donde sea aplicable: VERIFICACIONES DE APLICABILIDAD DP: - ¿Subproblemas superpuestos? → memoizar con clave de estado estable - ¿Particionamiento/agrupamiento óptimo? → sumas prefijas + DP de intervalo - ¿Gráfico de dependencia con recorrido repetido? → DP topológico de paso único VERIFICACIONES DE OPTIMIZACIÓN CONVEXA: - ¿Fuerza bruta de asignación/programación exacta? → LP / flujo de costo mínimo con ruptura de empate determinista - ¿Ajuste de parámetros continuos con pérdida explícita? → cuadrados mínimos regularizados / QP - ¿Gran objetivo convexo descomponible? → ADMM / métodos proximales También ten en cuenta que si hay bibliotecas de terceros bien escritas que conoces y que funcionarían bien, podemos incluirlas en el proyecto). REQUISITOS DE METODOLOGÍA: A) Baseline primero: Ejecuta el conjunto de pruebas y una carga de trabajo representativa; registra latencia p50/p95/p99, rendimiento y memoria máxima con comandos exactos. B) Perfila antes de proponer: Captura perfiles de CPU + asignación + E/S; identifica los 3–5 puntos críticos principales por % de tiempo antes de sugerir cambios. C) Oráculo de equivalencia: Define salidas doradas explícitas + invariantes. Para grandes espacios de entrada, agrega pruebas basadas en propiedades o metamórficas. D) Prueba de isomorfismo por cambio: Cada diferencia propuesta debe incluir un breve esquema de prueba que explique por qué las salidas no pueden cambiar (incluyendo orden, ruptura de empates, comportamiento de punto flotante y semillas de RNG). E) Matriz de oportunidades: Clasifica candidatos por (Impacto × Confianza) / Esfuerzo antes de implementar; enfócate solo en elementos que probablemente muevan p95+ o rendimiento de manera significativa. F) Diferencias mínimas: Un palanca de rendimiento por cambio. Sin refactorizaciones no relacionadas. Incluye orientación de reversión si existe algún riesgo. G) Guardrails de regresión: Agrega umbrales de referencia o ganchos de monitoreo para prevenir regresiones futuras. Usa ultrathink. --- Puedes ejecutar eso una vez en Claude Code con Opus 4.5 y una vez en Codex con GPT 5.2 Codex (empecé a usar solo Alto porque Extra Alto es simplemente demasiado lento para mí a menos que esté a punto de irme a la cama). Después de que terminen, golpea a cada uno con como 5 rondas rápidas de este: "Genial. Revisa todo de nuevo por cualquier descuido, omisión o error obvio, errores conceptuales, meteduras de pata, etc. Usa ultrathink" Luego haz que guarden las salidas así: "OK, guarda todo eso como PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, guarda todo eso como PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Luego en Claude Code, haz: "Compara lo que hiciste con PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md y toma los mejores elementos de eso y entrelázalos en tu plan para obtener un plan híbrido superior de ambos mundos editando tu archivo de plan original en su lugar." Luego esto: Vuelve a leer AGENTS dot md para que siga fresco en tu mente. Ahora lee TODO el PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Luego 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? Queremos un conjunto completo y granular de beads para todo esto con tareas, subtareas y estructura de dependencia superpuestas, con comentarios detallados para que todo sea totalmente autocontenido y autodocumentado (incluyendo antecedentes relevantes, razonamiento/justificación, consideraciones, etc.-- cualquier cosa que quisiéramos que nuestro "yo futuro" supiera sobre los objetivos y las intenciones y el proceso de pensamiento y cómo sirve a los objetivos generales del proyecto). Los beads deben ser tan detallados que nunca necesitemos consultar de nuevo el documento de plan markdown original. ¿Refleja con precisión TODO el archivo de plan markdown de manera integral? Si se justifican cambios, entonces revisa los beads o crea nuevos o cierra los inválidos o inaplicables. ¡Es mucho más fácil y rápido operar en "espacio de plan" antes de que comencemos 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, incluyamos 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 SOLO la herramienta `bd` para crear y modificar los beads y para agregar las dependencias a los beads." Luego unas cuantas rondas de: "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 "espacio de plan" antes de que comencemos 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 los beads incluyamos 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. Usa ultrathink." Luego deja que la multitud se suelte para implementarlo todo. Luego prepárate para la RONDA 2.