Factory en la práctica: revisiones, tests y tareas pendientes

👁 117 lecturas

Factory aporta más valor a equipos donde el trabajo importante de programación espera en cola porque siempre hay algo más urgente: revisiones de código, tests, corrección de bugs menores, refactorización de código antiguo. Hemos recopilado los casos de uso donde los agentes Droid quitan más trabajo al equipo.

Cómo instalar Droid y configurar la revisión de código lo explicamos en el tutorial de Factory.

Por dónde empezar en el equipo

El primer paso más seguro es la revisión automática de pull requests. No cambia ningún código, solo añade comentarios, así que el equipo puede evaluar la calidad del trabajo del agente sin riesgo. Después de dos semanas se ve si los comentarios son acertados. El segundo paso son bugs menores de la lista de tareas pendientes, asignados uno a uno y revisados como cambios de un compañero. Solo después, tareas más grandes en modo especificación.

Es importante que todo el equipo conozca las reglas: quién asigna tareas al agente, quién revisa sus cambios y qué áreas del código el agente no toca sin permiso.

Revisión automática de cada pull request

La implementación más sencilla y a menudo la más notable. Droid revisa cada pull request antes de que lo vea una persona y comenta líneas concretas. Se centra en errores, no en estilo. El revisor humano recibe el cambio con los problemas obvios ya detectados y puede centrarse en la lógica y la arquitectura.

Revisión antes de enviar

El comando para revisar cambios locales permite al programador comprobar el código antes de que nadie lo vea. Menos rondas de correcciones en el pull request significa fusión más rápida y menos cambios de contexto entre tareas.

Corrección de bugs menores

En cada proyecto hay una lista de bugs pequeños que nadie tiene tiempo de arreglar. Describes el bug, Droid encuentra la causa y propone una corrección que revisas como cualquier otro cambio. La lista de tareas pendientes disminuye sin quitar tiempo al desarrollo de nuevas funcionalidades.

Tests para código que no los tiene

Los módulos más antiguos a menudo no tienen tests, así que cualquier cambio en ellos es arriesgado. Droid escribe tests para código existente y tú compruebas si testean lo que realmente importa. Después de unas semanas, los cambios en código antiguo dejan de ser una lotería.

Migraciones y cambios grandes con plan

Actualización de biblioteca, cambio de estructura de base de datos, migración a nueva versión del lenguaje. El modo especificación primero examina el proyecto y presenta un plan, y el equipo lo aprueba antes del primer cambio. La documentación de Factory recomienda este modo precisamente para migraciones y cambios sensibles a la seguridad.

Tareas en scripts y CI

Cuando algún trabajo con Droid funciona bien, se puede ejecutar sin ventana interactiva, por ejemplo en el pipeline de CI. Tareas repetibles, como revisión o generación de informe de cambios, ocurren automáticamente en cada despliegue.

Trabajo en tu editor favorito

Droid funciona en VS Code, Cursor, Windsurf, editores JetBrains y Zed. El equipo no tiene que cambiar de herramientas, y en VS Code el agente ve el archivo abierto y los errores del editor.

Ejemplo: una semana con deuda técnica

Un equipo de cuatro programadores tiene en la lista treinta bugs menores y un módulo de pagos sin tests. El lunes activan la revisión automática de pull requests. Cada programador asigna diariamente a Droid dos bugs menores y revisa las correcciones. El miércoles planifican en modo especificación los tests del módulo de pagos, y el viernes los fusionan tras revisión. La lista de bugs baja a la mitad sin cancelar el trabajo en la nueva funcionalidad.

Lo clave es que el equipo no canceló el trabajo en la nueva funcionalidad. El agente asumió tareas que de todos modos esperaban en cola, y las personas se ocuparon de revisar sus cambios, lo que lleva menos tiempo que escribir las correcciones uno mismo. Vale la pena mantener una regla: cada cambio del agente tiene un propietario en el equipo que lo revisó y aprobó. Así nadie pierde conocimiento sobre qué ha cambiado en el código.

A qué prestar atención

• Revisa cada cambio del agente como el cambio de una persona.
• La revisión automática no sustituye al revisor en decisiones arquitectónicas.
• Aumenta la autonomía del agente gradualmente, cuando sepas cómo se desenvuelve con el proyecto.

Cómo comprobar si vale la pena

Medid lo que realmente duele al equipo. Tiempo desde la apertura del pull request hasta la fusión, porque la revisión automática debería acortarlo. Número de bugs en la lista de tareas pendientes al principio y después de un mes. Cobertura de tests en módulos que no tenían tests.

Si después de un mes ninguna de estas cifras se ha movido, el problema normalmente no está en la herramienta, sino en que nadie tiene tiempo de revisar los cambios del agente. Entonces vale la pena designar un momento fijo en la semana para revisar lo que ha preparado.

También vale la pena anotar qué tipos de tareas ejecuta mejor el agente. Después de un mes el equipo sabe qué asignar directamente y qué es mejor hacer uno mismo, y deja de perder tiempo intentando delegar al agente tareas que requieren conocimiento fuera del código, por ejemplo acuerdos con el cliente.

// sigue leyendoCursor en la práctica: 6 tareas donde ahorra más tiempoRevistaFactory y Droid paso a paso: instalación y revisión de códigoRevistaHiggsfield en la práctica: anuncios, personajes y efectosGuías

Kinetyra