Pensar en modo agéntico
Antes de los comandos está el método. En este módulo aprendes a guiar a un agente como a un colaborador operativo: le das un resultado observable, le permites solo las acciones necesarias y revisas las evidencias antes de aceptar el trabajo.
Qué trabajarás, paso a paso
De respuesta a ciclo de trabajo
En el Módulo 0 has visto quién propone y quién actúa. Ahora damos un paso más: ¿qué pasa cuando el primer intento no funciona? No se empieza de nuevo a ciegas. Se usa lo que acaba de ocurrir para elegir el paso siguiente.
Un chatbot produce sobre todo una respuesta. En cambio, un agente de código puede leer archivos, formular un plan, aplicar cambios y ejecutar comprobaciones. La diferencia importante no es cuánto texto genera, sino el ciclo observable que recorre.
El ciclo útil es: observa el estado real, planifica un cambio limitado, actúa, verifica el resultado e informa de pruebas y límites. Si falta la observación inicial, el agente adivina. Si falta la verificación final, una respuesta convincente puede ocultar un error.
- Observa archivos, límites y síntoma real.
- Planifica el cambio más pequeño que pueda resolver el problema.
- Actúa dentro de los archivos y permisos autorizados.
- Verifica con tests, salida o comparación reproducible.
- Informa qué cambió y qué sigue siendo incierto.
Importas un archivo con tres títulos y una línea vacía. Task Notes crea cuatro tareas, una de ellas sin título.
- Observa: reproduce con el mismo archivo e identifica el parser, es decir, la parte del programa que lee cada línea y la transforma en una tarea.
- Planifica: propone ignorar solo las líneas que, una vez quitados los espacios, quedan vacías; no cambies el formato guardado.
- Actúa y verifica: añade primero un test con la línea vacía, aplica el parche mínimo y vuelve a ejecutar los tests de importación.
- Informa: muestra el diff, el resultado antes y después y especifica que no se han comprobado formatos de importación distintos del que se ha probado.
Resultado: El bug no queda solo «resuelto»: es reproducible, está vinculado a una causa, protegido por un test y acompañado por un límite declarado.
El encargo operativo
Un encargo operativo no es un prompt largo: es un acuerdo que te permite a ti y al agente reconocer el mismo resultado. La información útil es la que, si faltara, podría cambiar la solución.
Una solicitud eficaz contiene cuatro elementos: el resultado deseado, el contexto necesario, los límites de la acción y la prueba de finalización. No hace falta escribir una novela; hace falta eliminar las ambigüedades que cambiarían la solución.
Con Task Notes, «arregla la importación» es demasiado abierto. En cambio, «las líneas vacías no deben crear actividades; modifica solo el parser, conserva el formato de los datos y ejecuta los tests de importación» establece un contrato controlable.
Task Notes importa fechas en formato `AAAA-MM-DD`, pero un valor como `2026-19-40` genera un error poco comprensible.
- Defines el resultado: la línea no válida se rechaza y el mensaje indica número de línea y formato esperado.
- Proporcionas el contexto: el parser está en `importer.py` y los registros válidos ya guardados no deben cambiar de formato.
- Fijas el límite: modifica parser y tests de importación, sin migrar la base de datos ni reescribir la interfaz.
- Defines la prueba: añade un caso no válido y uno válido; muestra que el primero produce el mensaje esperado y el segundo sigue importándose.
Resultado: El agente puede elegir la técnica de validación, pero no puede declarar éxito sin proteger tanto el comportamiento nuevo como el existente.
Autonomía proporcionada al riesgo
Antes de conceder autonomía, hazte tres preguntas muy concretas: si sale mal, ¿a quién afecta? ¿Puedo deshacerlo? ¿La acción sale de mi ordenador? Las respuestas te dicen dónde el agente puede avanzar y dónde, en cambio, hace falta un sí explícito por tu parte.
Leer una carpeta local y publicar una app no tienen el mismo impacto. La autonomía debe concederse según la reversibilidad, el alcance y el destino de la acción. Un cambio local bajo Git es más fácil de controlar que un envío a clientes o un borrado remoto.
El principio del mínimo privilegio reduce el radio del error: acceso en solo lectura durante el análisis, escritura solo en los archivos acordados y aprobación humana antes de acciones externas o irreversibles.
Quieres comprobar la nueva plantilla en tres direcciones de prueba. El servicio conectado también contiene la lista real de clientes.
- El agente lee la plantilla local y genera una vista previa con datos ficticios, sin acceder a la lista de clientes.
- Autorizas un envío solo al entorno de pruebas y a tres direcciones listadas explícitamente.
- Compruebas asunto, enlaces y renderizado del correo recibido; el agente registra los resultados sin ampliar los destinatarios.
- El envío a la lista real sigue bloqueado detrás de un nuevo checkpoint humano, con un resumen del número de destinatarios y del contenido final.
Resultado: El agente puede completar la preparación y las pruebas con autonomía, mientras la consecuencia externa más amplia sigue bajo control explícito.
Las evidencias pesan más que la seguridad del tono
La frase «hecho» es un resumen, no una prueba. Para aceptar un trabajo debes conectar cada promesa con una evidencia que observe precisamente ese comportamiento; de lo contrario estás midiendo una cosa y concluyendo sobre otra.
Un agente puede decir «hecho» incluso cuando solo ha modificado el código. La conclusión solo es fiable si va acompañada de una prueba adecuada: un test que antes fallaba y ahora pasa, un diff limitado, una salida reproducible o una comprobación visual pertinente.
La comprobación debe corresponder a la promesa. Una comprobación de sintaxis no demuestra que la app funcione en el navegador; un test del parser no demuestra que los datos se muestren correctamente. Pregunta siempre qué evidencia sostiene qué conclusión.
El agente cambia el texto de un botón e informa de que la build, la comprobación que verifica si el proyecto compila, ha salido bien. En el navegador, sin embargo, un panel invisible sigue tapando el botón.
- El diff prueba que la etiqueta se ha modificado en el componente correcto y que no se han tocado otros archivos.
- La build en verde demuestra que el proyecto compila, pero no simula el clic ni observa los elementos superpuestos.
- Un test de navegador abre la página, localiza el botón e intenta hacer clic; el test falla porque otro elemento intercepta la acción.
- Tras un parche separado, ese mismo test pasa y una comprobación visual confirma texto, posición e interacción en la pantalla prevista.
Resultado: Cada evidencia sostiene una conclusión precisa: el alcance del diff, la compilación, la interacción y el renderizado visual ya no se mezclan.
De solicitud vaga a misión verificable
Task Notes genera una actividad vacía cuando el archivo contiene una línea en blanco.
Objetivo: ignora las líneas vacías durante la importación.
Alcance: modifica solo parser.py y los tests relacionados.
Límites: no cambies el formato JSON guardado.
Verificación: reproduce el bug, añade un test y muestra el diff final.