- Cuando se colabora durante mucho tiempo con LLM como Claude o Codex, la fatiga se acumula y la productividad cae bruscamente
- La caída en la calidad de los prompts por la fatiga empeora la calidad de los resultados, y mientras más se interrumpe o corrige al modelo a mitad del proceso, peor rinde
- Los bucles de retroalimentación lentos y el contexto excesivamente grande dificultan la experimentación repetitiva y reducen la eficiencia del trabajo
- Un enfoque efectivo es mantener el placer de escribir prompts y una conciencia clara del objetivo, y definir el propio bucle lento como el problema para mejorarlo
- La clave para aprovechar los LLM es retroalimentación rápida y criterios de éxito claros; con eso se reduce el tiempo de depuración y se obtienen resultados más inteligentes
Fatiga y velocidad lenta de experimentación
- Cuando se acumula la fatiga mental, baja la calidad de los prompts y, como resultado, también se deteriora la calidad de las respuestas del LLM
- En estado de cansancio, se envían prompts omitiendo contexto clave y, si después se repiten correcciones e interrupciones, los resultados empeoran
- En Claude Code o Codex, este tipo de “intervención a mitad del proceso” rompe la consistencia y produce resultados peores
- También se señala como problema la desaceleración del bucle de retroalimentación
- En tareas que toman mucho tiempo, como el análisis de archivos grandes, volver a ejecutar cada vez es lento y alarga el ciclo de experimentación
- Cuando el contexto está casi saturado, el modelo puede “volverse torpe” o no reflejar bien el contenido de los experimentos más recientes
Ruta para colaborar de forma eficiente con la IA
- Hay que evitar el círculo vicioso causado por malos prompts (“doom-loop psychosis”)
- Si escribir prompts deja de ser disfrutable o se repiten entradas cortas y descuidadas, hace falta descansar
- Esperar que la IA rellene los vacíos sin haber pensado suficientemente el problema es una trampa peligrosa
- Los prompts con objetivos claros y convicción son la clave del éxito
- Los prompts redactados imaginando de forma concreta el resultado deseado llevan a respuestas de alta calidad
- En cambio, cuando se escriben con incertidumbre o apuro, los resultados no suelen ser satisfactorios
Definir el bucle de retroalimentación lento como el problema
- La velocidad misma del bucle de retroalimentación debe fijarse como objetivo de mejora
- Por ejemplo, al abordar un problema de parsing, se puede indicar como meta reducir el tiempo del bucle a menos de 5 minutos y pedir que los casos de falla se reproduzcan rápidamente
- Es un enfoque similar al desarrollo guiado por pruebas (TDD), que acelera la velocidad de la experimentación repetitiva
- Presentar criterios de éxito claros maximiza la eficiencia del LLM
- Si se le da una condición concreta como “reproduce el caso de falla en menos de 5 minutos”, el LLM optimiza la ruta del código y elimina partes innecesarias
- Al asegurar así un bucle de retroalimentación rápido, se reduce el consumo de contexto y el modelo funciona de forma más “inteligente”
Conclusión
- La fatiga que surge al trabajar con LLM a menudo puede ser no un problema técnico, sino un “skill issue”
- La fatiga cognitiva y la externalización de requisitos (cognitive outsourcing) son trampas que reducen la productividad
- Lo recomendable es continuar solo cuando el proceso de escribir prompts resulte disfrutable y exista confianza en estar satisfecho en más de un 95% con el resultado
- Si se percibe avance lento y sobrecarga de contexto, eso mismo debe convertirse en una tarea a resolver junto con el LLM para diseñar una estructura de iteración más rápida
Aún no hay comentarios.