Una tarea no es un proyecto.
Parece obvio.
Aun así, es uno de los errores más comunes al trabajar con agentes.
La persona empieza pidiendo un análisis.
Luego pide un plan.
Luego una implementación.
Luego un cambio de dirección.
Luego una revisión.
Todo en el mismo lugar.
Al final, la tarea se convirtió en un depósito de decisiones, excepciones y pedidos antiguos.
El agente pierde la referencia.
La persona también.
El problema no es continuar
Continuar una tarea no siempre está mal.
El problema empieza cuando deja de tener un objetivo claro.
Una buena tarea responde a tres preguntas:
- qué se necesita resolver ahora;
- qué se puede cambiar;
- cómo sabremos que terminó.
Sin eso, cada pedido nuevo puede cambiar el sentido de todo lo anterior.
“Ahora también agrega autenticación.”
“Antes, cambia la arquitectura.”
“Olvida el plan y hazlo ya.”
“Vuelve a la idea anterior.”
Cada frase puede ser legítima.
Pero juntas, sin una nueva delimitación, producen ruido.
Muchas iteraciones también aumentan el riesgo de alucinación
Un chat largo no guarda solo decisiones.
Acumula borradores, hipótesis, errores corregidos, instrucciones superadas e información incompleta.
Después de muchas iteraciones, el agente puede tratar una suposición antigua como un hecho.
Puede citar una decisión que nunca fue aprobada.
Puede afirmar que validó algo que solo fue discutido.
Puede llenar un vacío con una respuesta plausible, pero equivocada.
Eso es una alucinación.
No ocurre solo por falta de capacidad.
También ocurre cuando el contexto se volvió confuso.
Cuanto más una tarea mezcla objetivos y versiones de una misma decisión, más difícil es distinguir qué está vigente, qué fue descartado y qué todavía necesita confirmación.
No uses un chat largo como fuente única de verdad.
Las decisiones importantes deben salir de la conversación y entrar en archivos, pruebas, planes o documentación.
Una tarea debe caber en una frase
Si no puedes resumir una tarea en una frase, probablemente es demasiado grande.
Ejemplo malo:
Entiende el proyecto, define la arquitectura, construye el sitio,
escribe el contenido, revisa el diseño y publícalo.Mejores ejemplos:
Analiza la estructura actual del proyecto.
No modifiques archivos.
Enumera riesgos, vacíos y decisiones pendientes.Crea un plan incremental para la internacionalización.
No lo implementes.
Indica archivos probables, dependencias y validaciones.Implementa solo el selector de idioma definido en la etapa 1 del plan aprobado.La diferencia no es burocracia.
Es dirección.
Mezclar fases crea falsas certezas
Cuando descubrimiento, planificación e implementación ocurren en la misma tarea, es fácil confundir una hipótesis con una decisión.
El agente puede empezar a editar antes de entender el problema.
Puede crear una solución para un requisito que todavía cambiará.
Puede seguir una decisión antigua que fue abandonada a mitad de la conversación.
El resultado parece avanzar.
Pero acumula retrabajo.
Separar fases no vuelve lento el proceso.
Evita velocidad en la dirección equivocada.
Divide por el resultado, no por el tamaño del pedido
No basta con dividir un pedido grande en partes aleatorias.
La división debe tener sentido.
Una tarea de diagnóstico entrega comprensión.
Una tarea de planificación entrega una secuencia aprobada.
Una tarea de implementación entrega un cambio verificable.
Una tarea de revisión entrega problemas, riesgos o ajustes.
Cada una tiene una salida diferente.
Diagnóstico → comprensión del estado actual
Planificación → un plan pequeño y verificable
Implementación → un cambio validado
Revisión → una evaluación objetiva del resultadoCuando la salida está clara, es más fácil saber cuándo terminar.
El contexto debe sobrevivir a la tarea
Una tarea termina.
El conocimiento útil no puede terminar con ella.
Las decisiones importantes deben ir a los archivos del proyecto:
AGENTS.mdpara reglas duraderas;README.mdpara contexto general;PLANS.mdpara etapas aprobadas;docs/para decisiones, arquitectura y riesgos;- pruebas y código para comportamiento verificable.
Eso reduce la dependencia de la memoria de una conversación larga.
La siguiente tarea no necesita adivinar qué ocurrió.
Empieza con los registros correctos.
Un flujo simple
Usa una tarea para cada momento.
- Entiende el problema.
- Registra lo que se decidió.
- Planifica una etapa pequeña.
- Implementa solo esa etapa.
- Valida.
- Abre la siguiente tarea con el resultado anterior como contexto.
No es necesario crear una tarea para cada frase.
Es necesario crear una tarea nueva cuando cambia el objetivo.
Esa es la frontera.
Cerrar también es trabajo
Muchas tareas quedan abiertas porque nadie declaró el final.
Al terminar, registra:
- qué se hizo;
- los archivos modificados;
- las validaciones ejecutadas;
- los riesgos restantes;
- el siguiente paso recomendado.
Después, ciérrala.
Una tarea cerrada con claridad es más útil que una tarea interminable con mucho historial.
La regla básica
No intentes conducir un proyecto entero en una sola tarea.
Dale a cada tarea un objetivo, un límite y una salida.
Registra las decisiones que necesitan sobrevivir.
Vibe coding no es una conversación sin fin.
Es una secuencia de decisiones que pueden entenderse, revisarse y continuarse.