Elige una primera tarea útil con IA

Selecciona una tarea que puedas verificar

La primera tarea útil debe enseñarte cómo funciona la herramienta en tu entorno. También debe producir un resultado que puedas inspeccionar. Una pequeña corrección de un defecto conocido suele cumplir ambas condiciones.

No elijas una tarea solo porque vaya a dar una demostración vistosa. Un rediseño amplio puede producir muchos cambios visibles y ocultar supuestos incorrectos. Una tarea pequeña permite observar si el agente lee las instrucciones, respeta el alcance e informa con precisión de las comprobaciones fallidas.

No necesitas elegir la tarea más fácil posible. Elige una en la que el equipo pueda reconocer un resultado correcto y explicar por qué lo es.

Compara las tareas candidatas

Considera tres peticiones ficticias para una aplicación de informes.

La tarea de explicación ayuda a inspeccionar el razonamiento y sus pruebas. La prueba de regresión añade una acción controlada. La tarea de arquitectura puede ser valiosa más adelante, pero necesita instrucciones y un proceso de revisión mucho más sólidos.

Para un primer ejercicio, elige la prueba de regresión. Usa fechas inventadas y una rama local. Indica que quedan fuera de alcance el acceso a producción, las actualizaciones de dependencias y las refactorizaciones ajenas a la tarea.

Escribe la condición de finalización

«Mejora el tratamiento de fechas» deja demasiado margen de interpretación. Usa una condición concreta: «Cuando la entrada contenga una fecha de calendario inválida, devuelve un error de validación. Conserva la salida documentada para las fechas válidas».

Añade ejemplos de entradas válidas e inválidas. Identifica el comando de pruebas existente. Pide al agente que inspeccione el comportamiento actual antes de cambiar archivos. Exige una explicación breve del defecto y de las pruebas obtenidas después del cambio.

Separa el resultado de una tarea de la actividad realizada. «El agente escribió una prueba» describe una actividad. «La prueba rechaza el defecto conocido» describe una prueba de funcionamiento. Una prueba que pasa tanto con el código correcto como con el incorrecto no demuestra la protección prevista.

Observa el proceso de trabajo

Durante el ejercicio, anota dónde necesita contexto adicional el agente. Comprueba si lee las instrucciones pertinentes del repositorio. Observa si cambia archivos fuera del alcance o repite un enfoque fallido sin pruebas nuevas.

No corrijas de inmediato cada decisión menor. Deja que complete el trabajo autorizado y reversible para poder evaluar el resultado. Intervén cuando la siguiente acción cruce un límite o cuando continuar dependa de un requisito sin resolver.

Al terminar, revisa el diff y ejecuta las comprobaciones pertinentes. Anota tanto el tiempo del agente como tu tiempo de preparación y revisión. Estas observaciones ayudan a elegir la siguiente tarea y a mejorar las instrucciones de trabajo.

Amplía un límite cada vez

Si el ejercicio sale bien, aumenta una dimensión de complejidad. Puedes pasar de una función a dos módulos relacionados. Puedes añadir una integración documentada. Mantén explícitos los permisos y los requisitos de verificación.

Si el ejercicio falla, identifica la causa antes de ampliar el alcance. La falta de contexto, un requisito poco claro, un entorno de pruebas no disponible y una limitación del modelo necesitan correcciones distintas. Más autonomía no resuelve los cuatro problemas.

Si un prototipo sigue en uso, asigna una persona responsable de su mantenimiento. La aparición de nueva información sobre vulnerabilidades puede exigir actuar sin que haya cambiado el código. Consulta la gestión continua de vulnerabilidades.