$ man how-to/testing-ai-features-recursive-method

Las herramientas de IA lanzan actualizaciones más rápido de lo que puedes aprenderlas. Claude Code, Cursor, ChatGPT, Windsurf - todas lanzan nuevas características semanalmente. A veces diariamente. Y cada característica podría cambiar cómo trabajas. La reacción natural es uno de dos extremos. Ignorar todo y seguir haciendo lo que funciona hasta que se rompa. O perseguir cada actualización y nunca terminar nada porque siempre estás aprendiendo algo nuevo. Ambos pierden. La primera persona se pierde la característica que le habría ahorrado 3 horas al día. La segunda persona nunca entrega porque está perpetuamente en proceso de onboarding. Necesitas un camino intermedio. Una forma sistemática de clasificar, probar e integrar nuevas características sin descarrilar tu trabajo real.

PATTERN

Constrúyelo. Pruébalo. Interrógalo. Codifícalo. Estos cuatro pasos son Recursive Drift aplicado a la evaluación de características. Cada paso produce salida que alimenta al siguiente, y el paso final retroalimenta tu sistema para que la siguiente evaluación empiece más inteligente. Construir: usa la característica de verdad. No leas el changelog y formes una opinión. Abre una terminal y pruébala. Construye algo real con ella, no un ejemplo de juguete. No sabes si una característica funciona hasta que hayas entregado algo con ella. Probar: evalúa lo que construiste. ¿Funcionó? ¿Fue más rápido? ¿Introdujo problemas? Esto no es "¿se ejecuta sin errores?" Esto es "¿hace mi flujo de trabajo existente mejor o peor?" Usa un segundo contexto para evaluar - una terminal diferente, una sesión diferente, una perspectiva fresca. Interrogar: pregúntale a la IA sobre lo que acaba de pasar. ¿Qué hizo realmente la característica por debajo? ¿Cuáles son los casos borde? ¿Qué hizo mal? Copia tu salida de construcción en una nueva sesión y pídele que se critique a sí misma. La autoevaluación de la IA revela limitaciones que el paso de construcción pasó por alto. Codificar: convierte el conocimiento validado en contexto reutilizable. Escribe un skill. Actualiza un flujo de trabajo. Agrégalo a tus archivos de memoria. Si la característica vale la pena usarla, vale la pena documentarla en una forma que tus futuras sesiones puedan acceder automáticamente.

FORMULA

La Terminal 1 es el constructor. La Terminal 2 es el evaluador. Nunca se fusionan. La separación es el método. Cuando construyes y evalúas en la misma sesión, el sesgo de confirmación toma el control. La IA que construyó la cosa defenderá la cosa que construyó. Un contexto fresco no tiene apego a la salida. Flujo de trabajo: 1. Terminal 1: empieza a construir con la nueva característica. Dale una tarea real de tu trabajo actual. 2. Déjala ejecutarse. No interrumpas. 3. Terminal 2: abre una nueva sesión. Pega la salida de la Terminal 1. Pregunta: "¿Qué hace esto bien? ¿Cuáles son las limitaciones? ¿Qué rompería esto?" 4. Toma los hallazgos de la Terminal 2 y pégalos de vuelta en la Terminal 1. Pídele que aborde las preocupaciones. 5. Repite hasta que tengas una imagen clara de lo que funciona y lo que no. Este es el ciclo freefall-break-ask de Recursive Drift, externalizado a través de dos contextos. El constructor hace freefall. El evaluador hace break. El ida y vuelta es el estado ask. La separación fuerza la honestidad.

PRO TIP

El paso de interrogación es donde la mayoría de las personas se detienen demasiado temprano. Prueban la característica, deciden "funciona" o "no funciona," y siguen adelante. Eso es un binario cuando necesitas un espectro. Pregúntale a la IA sobre lo que acaba de construir. No "¿esto funcionó?" sino "¿qué suposiciones hiciste? ¿qué pasaría si la entrada fuera 10x más grande? ¿qué elegiste no hacer?" Copia las salidas de una sesión a otra. La Terminal 2 no tiene el contexto de la Terminal 1, que es el punto. Lee la salida en frío. Atrapa cosas que la ventana de contexto del constructor enterró. El patrón: construye en el contexto A, evalúa en el contexto B, sintetiza en el contexto A. Esta polinización cruzada saca a la superficie casos borde, límites de rendimiento y modos de fallo que te perderías en un flujo de trabajo de un solo contexto. Ejemplo real: probando Agent Teams en Claude Code. La Terminal 1 construyó un equipo, ejecutó tareas, ejercitó el sistema de mensajería. La Terminal 2 recibió la salida completa e identificó que la tarea era en realidad demasiado simple para equipos - los subagentes habrían sido más económicos y rápidos. Esa evaluación se convirtió en el skill de agent-routing. La prueba de la característica produjo la barrera contra su mal uso.

PATTERN

La fase de interrogación produce conocimiento en bruto. La fase de codificación lo convierte en infraestructura. Cuando validas que una característica funciona, tienes tres opciones. Puedes recordarla y olvidarla para la próxima semana. Puedes guardar los docs en marcadores y nunca leerlos de nuevo. O puedes escribirla en tu sistema - un archivo de skill, una regla en CLAUDE.md, un documento de flujo de trabajo, una entrada how-to. La tercera opción es la única que se acumula. Cada característica que codificas hace tu sistema más denso. La siguiente sesión empieza con ese conocimiento ya cargado. No re-aprendes. Construyes sobre lo que la última sesión descubrió. La plantilla de codificación: - Qué hace la característica (una oración) - Cuándo usarla vs cuándo no (la salida de la clasificación) - El flujo de trabajo que funcionó (los hallazgos de las dos terminales) - Limitaciones conocidas (de la interrogación) - Skills relacionados a los que se conecta Esta plantilla es en sí misma un producto del ciclo recursivo. Fue refinada a través de múltiples evaluaciones de características hasta que el patrón se estabilizó.

ANTI-PATTERN

No todas las actualizaciones merecen el ciclo completo. El objetivo es profundidad selectiva, no cobertura exhaustiva. Ejecuta el ciclo completo cuando: - Una característica mapea a un punto de dolor conocido en tu flujo de trabajo. Has estado trabajando manualmente alrededor de algo. La actualización podría automatizarlo. - Una característica cambia el comportamiento del que dependes. Los cambios que rompen cosas necesitan atención inmediata. Tus skills y flujos de trabajo existentes pueden dejar de funcionar. - Una característica habilita algo previamente imposible. Las nuevas capacidades expanden lo que puedes construir. Estas son las evaluaciones de mayor ROI. Omite cuando: - La característica es para un caso de uso que no tienes. No toda actualización es relevante. - El cambio es cosmético o menor. Los ajustes de UI raramente afectan la salida. - Estás a mitad de sprint con una fecha límite. Programa la evaluación, no dejes que interrumpa el trabajo de producción. La clasificación toma 5 minutos. Escanea el changelog. Compara contra tus puntos de dolor activos. Si nada mapea, sigue adelante. Si algo sí, ejecuta el ciclo. Con el tiempo desarrollas un instinto para qué actualizaciones importan. Ese instinto es en sí mismo un skill compuesto construido de ejecutar el ciclo suficientes veces.