Asistentes de código: cómo encuadrar bien una tarea

Un desarrollador autónomo le pide a su asistente de código: «Añade una exportación CSV de las facturas». Veinte minutos después, la herramienta ha tocado once archivos, ha añadido una biblioteca, ha reformateado dos módulos que no tenían nada que ver y ha escrito una exportación que se olvida de las facturas rectificativas. No hay nada roto a simple vista, y aun así hay que releerlo todo.

Los asistentes de código actuales ya no se limitan a completar una línea. Leen el proyecto, modifican varios archivos, lanzan comandos y pruebas. Cuanto más actúa la herramienta por su cuenta, más debe parecerse tu petición al brief que se le da a un proveedor al que no vas a ver hasta la entrega.

Qué contiene un brief de tarea

En la mayoría de los casos bastan cinco elementos.

1. El objetivo, expresado como resultado: qué podrá hacer el usuario o el sistema después.
2. El alcance: los archivos o carpetas afectados, y lo que no hay que tocar.
3. Las restricciones: tecnologías obligatorias, convenciones, dependencias prohibidas.
4. El criterio de éxito: cómo sabrás que está terminado, preferiblemente un comando o una prueba.
5. La forma de trabajar: proponer un plan antes de modificar, o avanzar en pasos pequeños.

Este es el brief del desarrollador, puesto en limpio:

Objetivo: añadir una exportación CSV de las facturas de un mes dado, accesible desde la página Facturación.

Alcance: puedes modificar el módulo facturacion/ y la página Facturación. No toques los demás módulos ni la configuración del proyecto.

Restricciones: ninguna dependencia nueva, usamos el módulo CSV de la biblioteca estándar. Mismo estilo que las exportaciones existentes (mira export_clientes).

Reglas de negocio: la exportación contiene las facturas y las facturas rectificativas del mes. Las rectificativas van en negativo. Los importes están en céntimos en la base de datos y en euros con dos decimales en el archivo.

Criterio de éxito: las pruebas existentes pasan, y añades una prueba que verifique un mes con una factura y una rectificativa.

Antes de modificar nada, descríbeme tu plan en cinco líneas como máximo y espera mi visto bueno.

La última frase es la más rentable. Un plan equivocado se corrige en diez segundos; un código equivocado se corrige en diez minutos.

Lo que la herramienta no puede adivinar

Las reglas de negocio no están escritas en ningún lugar del código, o lo están de forma indirecta. Que las facturas rectificativas entren en la exportación, que los importes estén en céntimos, que la página se llame Facturación: el asistente puede recuperar una parte leyendo el proyecto, pero tú tardas menos en escribirlas. Más vale decir una cosa evidente de más que obtener una exportación errónea pero verosímil.

Todo lo que repites de una tarea a otra (convenciones, comandos de prueba, carpetas que evitar) puede ir en un archivo de instrucciones que la herramienta lea automáticamente. El nombre del archivo y su ubicación dependen del asistente que uses. El artículo sobre las instrucciones para agentes de IA explica cómo redactarlo sin convertirlo en una novela.

Un cambio cada vez

La tentación, cuando la herramienta es rápida, es apilar peticiones: la exportación, luego un filtro, luego un rediseño de la página, todo en la misma sesión. Cada añadido hace el resultado más difícil de revisar. Acostúmbrate a dividir, como en una cadena de prompts:

• una tarea, un objetivo, un resultado verificable;
• una copia de seguridad de tu trabajo (un commit) antes de cada tarea, para poder volver atrás;
• una sesión nueva cuando cambia el tema, porque la conversación se hace pesada y la herramienta acaba perdiendo detalles del principio.

Si la tarea es demasiado grande para un brief de una página, pide primero que la dividan:

Quiero migrar la autenticación de la aplicación a [NUEVO MÉTODO]. De momento no modifiques nada. Recorre el proyecto, enumera los archivos afectados y propón una división en pasos independientes, cada uno comprobable por separado. Para cada paso, indica el riesgo principal.

Después eliges el paso que vas a lanzar y escribes su brief.

Revisar el resultado

El trabajo no termina cuando la herramienta dice «hecho». Cuatro controles, en este orden.

Primero el diff. Mira la lista de archivos modificados antes de abrir uno solo. Si incluye archivos fuera del alcance, pregunta por qué, o deshaz el cambio.

Después las pruebas, ejecutadas por ti si es posible. Un asistente puede afirmar que las pruebas pasan sin haberlas ejecutado bien, o modificar una prueba para que pase. Comprueba que las pruebas existentes no se hayan cambiado sin motivo.

Los casos límite. Retoma las reglas de negocio de tu brief y pruébalas a mano: el mes sin facturas, la rectificativa mayor que la factura, el valor cero.

Los añadidos discretos. Una dependencia nueva, un archivo de configuración, la eliminación de un trozo de código que le parecía inútil: pide a la herramienta que los enumere si no lo ha hecho.

Resume lo que has modificado, archivo por archivo, en una línea cada uno. Indica lo que has eliminado, añadido como dependencia o cambiado fuera del alcance pedido. Enumera después los casos límite que no has probado.

Este resumen no sustituye tu revisión del diff, porque la herramienta puede olvidarse de mencionar una modificación. Solo te indica dónde mirar.

Cuando no funciona

Si el asistente da vueltas en círculo, corrige la causa en lugar de repetir la petición. A menudo es un contexto que falta o una instrucción contradictoria en el brief. Empieza de nuevo en una sesión limpia con un brief corregido, en lugar de añadir «no, así no» veinte veces. Para las tareas de revisión, depuración o generación de pruebas fuera de este marco, el artículo sobre los prompts para desarrolladores ofrece otras plantillas, y el de GitHub Copilot detalla el trabajo dentro del editor.

Y conserva el control sobre lo que la herramienta puede hacer: ejecutar comandos, borrar archivos, acceder a la red. Lee lo que tu asistente te pide autorizar antes de aceptar, y evita abrirle el acceso a claves o a bases de datos de producción para una tarea que no lo necesita.

Qué hacer antes de tu próxima tarea

Elige una tarea que vayas a encargar al asistente esta semana. Escribe las cinco líneas del brief, incluido el comando que demostrará que está terminada. Si no sabes escribir ese comando, la tarea todavía no está lo bastante clara, y es el momento de descubrirlo.