Factory y Droid paso a paso: instalación y revisión de código
Factory ofrece agentes de programación llamados Droid que trabajan en el terminal, el editor y GitHub: leen el proyecto, proponen cambios y revisan pull requests.

👁 114 lecturas
Factory ofrece agentes de programación llamados Droid que trabajan en el terminal, el editor y en GitHub: leen el proyecto, proponen cambios, escriben código y revisan pull requests. Este tutorial te guía desde la instalación hasta la revisión automática de código, siguiendo la documentación oficial de Factory.
Antes de empezar: prepara tu proyecto
Droid trabaja sobre tu repositorio, así que conviene tener algunas cosas en orden antes de la primera tarea. Un estado limpio en el sistema de control de versiones, para que cada cambio del agente sea visible por separado y fácil de revertir. Tests funcionales y comandos para ejecutarlos, porque un agente que puede verificar su propio trabajo comete menos errores. Una descripción breve del proyecto en un archivo del repositorio: cómo ejecutarlo, dónde están los módulos principales, cuáles son las normas del equipo.
Si el proyecto tiene zonas que el agente no debe tocar, por ejemplo la configuración de producción, especifícalo claramente en las directrices.
Paso 1. Instalación
Instalas Droid con un solo comando. En macOS y Linux es un comando que descarga el instalador desde el sitio de Factory, en Windows un comando en PowerShell, y si tienes Node.js, puedes instalarlo mediante npm. Para utilizarlo necesitas una cuenta de Factory, y en el primer arranque inicias sesión a través del navegador.
Después entras en el directorio del proyecto y ejecutas Droid con el comando droid.
Paso 2. Primera tarea
La guía oficial muestra cómo Droid lee el proyecto, propone cambios y espera tu aprobación antes de modificar cualquier archivo. Para empezar, funcionan mejor las tareas pequeñas: explica la estructura del proyecto, encuentra dónde se gestiona el login, añade validación a este formulario.
Paso 3. Modo especificación para cambios grandes
Para tareas más grandes existe el modo especificación. Droid primero examina el proyecto y planifica, y solo después escribe código. La documentación lo recomienda para cambios de arquitectura, migraciones, trabajo sensible en seguridad y cualquier tarea en la que quieras ver el plan antes de editar archivos. Lo activas con el atajo Shift + Tab en la línea de comandos.
Después de proponer el plan, puedes aprobar cada cambio manualmente, dar a Droid mayor autonomía o seguir refinando el plan.
Paso 4. Nivel de autonomía
Independientemente del modo, configuras cuánta autonomía puede tener Droid. El atajo Ctrl + L alterna entre niveles desde desactivado hasta alto. Al principio, mantén el nivel bajo hasta que sepas cómo se desenvuelve Droid con tu proyecto.
Paso 5. Editor
Droid funciona en el terminal de cualquier editor, y en VS Code y editores de esa familia puede instalar una extensión que le transmite el archivo abierto, la selección y los errores del editor, y muestra los cambios en la vista nativa de comparación. Puedes comprobar el estado de la integración con el comando /ide. Para JetBrains y Zed la documentación describe conexiones específicas.
Paso 6. Revisión de código antes de enviar
El comando /review verifica los cambios locales antes de que los envíes. Es un buen hábito antes de cada pull request: Droid busca errores evidentes antes de que los vea alguien del equipo.
Paso 7. Revisión automática en GitHub
El comando /install-code-review configura la revisión automática de pull requests en GitHub o GitLab. Droid analiza los cambios y añade comentarios en líneas concretas. Se centra en errores y omite estilo y optimizaciones menores. Tus propias normas de revisión para el repositorio las añades en el archivo de directrices del directorio de configuración de Factory.
Ejemplo: primer día en el equipo
Instalas Droid, pides que explique la estructura del proyecto y que señale tres lugares que cambian con más frecuencia. Luego, en modo especificación, planificas una función pequeña, apruebas el plan y cada cambio manualmente. Antes de enviar ejecutas /review, y al final del día configuras la revisión automática para todo el repositorio.
Este primer día tiene otra ventaja: enseña al equipo a leer el trabajo del agente. Después de unas cuantas tareas se ve en qué es fuerte Droid, por ejemplo en cambios repetitivos en muchos archivos, y dónde necesita indicaciones más precisas, por ejemplo en lógica de negocio. Estas observaciones conviene anotarlas en las directrices del proyecto, porque cada nueva persona en el equipo empezará entonces desde la experiencia de los anteriores, no desde cero.
Errores más frecuentes
- Alta autonomía al principio, antes de conocer al agente.
- Tareas grandes sin modo especificación.
- Tratar la revisión automática como sustituto de una persona.
Cómo evaluar la primera semana
Después de una semana, cuenta dos cosas. Cuántas tareas completó Droid de forma que aceptaste el cambio sin correcciones, y cuántas requirieron tu intervención. Con un proyecto bien preparado, la primera cifra crece rápidamente. Revisa también los comentarios de la revisión automática: si señalaban errores reales o principalmente ruido. Si predomina el ruido, añade directrices de revisión para tu repositorio, para que el agente sepa a qué prestar atención y qué omitir.
Solo cuando los resultados sean buenos, aumenta el nivel de autonomía del agente.
Si trabajas solo y no en equipo, las mismas reglas funcionan a menor escala: encarga al agente tareas que puedas verificar rápidamente, y revisa cada cambio antes de fusionarlo, aunque nadie más vaya a verlo.
More on this from FULGOR
revista·Ideogram AI: Ideogram 4.5, test de edición, precios y promptsAnalizamos Ideogram 4.5 frente a 7 modelos: edición secuencial con SSIM de 0,95, textos complejos, precios en fal.ai y 57 imágenes con prompt.

