Una fábrica de software, en el sentido en que Ivy Tendril utiliza el término, es una secuencia fija de etapas con puntos de control que transforma tickets en pull requests. Entra un ticket o una idea. Un agente redacta un plan. Un humano revisa y aprueba el plan. Los agentes lo ejecutan en árboles de trabajo (worktrees) aislados de Git. La verificación automatizada ejecuta pruebas, linter e inspección de diferencias (diff). Un humano revisa el diff resultante. Se abre un pull request. La secuencia es idéntica para cada tarea, mientras que el agente y el modelo pueden cambiar según la necesidad. Hay exactamente dos puntos de control humanos —en el plan y en el diff— y nada se fusiona sin aprobación explícita.
Las etapas
Crear plan
La entrada puede ser una frase escrita en Tendril, una incidencia de GitHub o un informe de errores de jam.dev recibido a través de un webhook, una nota de voz transcrita con Whisper o archivos arrastrados al prompt. El promptware CreatePlan lee el código base y redacta un plan: qué cambiar, dónde hacerlo y cómo verificarlo.
Borrador
El plan se almacena en Borradores. Todavía no se ha ejecutado nada. Espera allí hasta que una persona lo revise.
Revisión del plan
Este es el primer punto de control. El revisor lee el plan y realiza una de cinco acciones: lo aprueba, ejecuta ExpandPlan para obtener más detalles, ejecuta SplitPlan para dividir un plan grande en varios pequeños, ejecuta UpdatePlan para modificarlo o añade comentarios en el borrador, tras lo cual el plan se reescribe. Un plan que no deba ejecutarse ahora pasa al Icebox.
Ejecución en worktrees
Tras la aprobación, el promptware ExecutePlan inicia el agente seleccionado —Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode o cualquier otro agente de línea de comandos— en su propio git worktree en su propia rama. La guía Git worktrees para agentes de IA paralelos explica por qué este aislamiento hace seguro ejecutar múltiples planes a la vez. Múltiples planes se ejecutan en paralelo. La vista Jobs transmite la salida de cada agente en tiempo real. La rama principal (main) nunca se modifica directamente.
Verificar
Pruebas, linter y una inspección de diff se ejecutan en el worktree, y los resultados se adjuntan al plan. Esto es integración continua aplicada por plan en lugar de por rama. Qué verificaciones corresponden a este paso se detalla en puertas de verificación para código generado por IA. En Pro y Enterprise, los resultados de verificación también se pueden importar de CI, ya sea GitHub Actions u otro ejecutor.
Revisión del diff
Este es el segundo punto de control. La vista Review muestra el diff en una pestaña y los resultados de verificación en otra. El revisor aprueba, o actualiza el plan y lo ejecuta de nuevo.
Pull request
El promptware CreatePr abre un pull request en GitHub con una descripción detallada del cambio. La fusión se realiza en GitHub como de costumbre. El consumo de tokens y el coste del plan se registran en el panel de control.
Por qué dos puntos de control humanos y no cero o diez
Cero puntos de control significa que un agente envía commits directos a main. Los errores se descubren tras afectar a otros desarrolladores, y revertir un cambio fusionado es más costoso que haberlo revisado. También significa que nadie asumió la responsabilidad de haber leído el código.
Diez puntos de control significa aprobar cada modificación de archivo o llamada a herramienta. El humano se convierte en el cuello de botella, los agentes esperan clics, la ejecución en paralelo pierde su valor y los revisores acaban aprobando por inercia sin leer.
Dos puntos de control colocan a la persona donde su juicio tiene el mayor impacto: En el plan es donde los malentendidos son más baratos de corregir: aún no existe código. En el diff es donde se confirma la exactitud: las verificaciones han concluido, el cambio está completo y un humano decide si se fusiona. Todo lo que ocurre entre ambos puntos está automatizado. La documentación del ciclo de vida describe cada transición.
Qué cambia para un equipo
Rendimiento. Dado que los planes se ejecutan en paralelo y la intervención humana se limita a dos momentos clave, la capacidad del equipo está delimitada por la velocidad de revisión y no por la de escritura. Ivy informa que su propio equipo pasó de unos 10 a más de 100 pull requests diarios tras adoptar este flujo.
Previsibilidad. Cada tarea pasa por las mismas etapas, de modo que el estado significa lo mismo en todo momento. El panel de control muestra cuántos planes hay en cada fase, coste por plan, gráficos de tendencias y actividad de Git.
Conocimiento acumulativo. Cada etapa está gestionada por una unidad de promptware: un Program.md con instrucciones, un directorio Memory/ con aprendizajes, Tools/ con permisos acotados y Logs/ de cada ejecución. Tras finalizar, los agentes escriben lo aprendido sobre el código en la memoria. El décimo plan se beneficia del conocimiento acumulado de los anteriores. Más detalles en promptware: agentes que mejoran sus propias instrucciones.
Qué no es una fábrica de software
- No es autocompletado. El autocompletado sugiere la siguiente línea; una fábrica toma un ticket y entrega un pull request revisado.
- No es una ventana de chat. Un chat no tiene cola de tareas, aislamiento, fase de verificación ni memoria persistente.
- No es un agente desatendido que comete a main. Nada se fusiona sin supervisión humana.
- No reemplaza la revisión de código. La estructura en los dos momentos de mayor impacto.
- No es un servicio en la nube que retiene su código. Tendril funciona de forma local en su máquina: código, planes, memoria y registros se quedan en su entorno.
- No está atado a un único proveedor de modelos.
Los ocho niveles
Los "8 niveles de desarrollo asistido por IA" de Steve Yegge (2025) son una referencia útil. La mayoría de los equipos se encuentran en los niveles 2 a 3: un asistente en el editor y un chat individual. La orquestación con agentes paralelos, memoria y puertas de revisión corresponde al nivel 8.
| Nivel | Lo que el equipo utiliza en la práctica |
|---|---|
| 1 | Sin IA. Los desarrolladores escriben y revisan todo a mano. |
| 2 | Autocompletado en el editor, aceptado línea por línea. |
| 3 | Asistente de chat en el IDE. Una conversación, un desarrollador, una función a la vez. |
| 4 | Un agente en el IDE que edita varios archivos a partir de una solicitud. |
| 5 | Un agente de terminal (CLI) que ejecuta una tarea de forma autónoma. |
| 6 | Varios agentes CLI en terminales separadas con coordinación manual. |
| 7 | Agentes con flujo de trabajo estructurado y puertas de revisión, habitualmente herramientas internas. |
| 8 | Orquestación: agentes paralelos en worktrees aislados, memoria persistente, dos puertas de revisión y cola de planes. Esto es Ivy Tendril. |
Cómo empezar
Instale Tendril en macOS o Linux:
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
O en Windows:
irm https://cdn.ivy.app/install-tendril.ps1 | iex
Conecte un repositorio de GitHub, configure una clave de API y elija un agente. Cree un plan a partir de un ticket pequeño, apruebe el borrador y revise el diff tras la verificación. La guía de instalación describe cada paso.
Preguntas frecuentes
¿Elimina una fábrica de software la revisión de código?
No. Concentra la revisión en dos puntos definidos (plan y diff) y coloca las evidencias de verificación junto al diff para que el revisor cuente con datos objetivos.
¿Qué agentes son compatibles?
Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode y cualquier otro agente CLI. Puede alternar agentes y modelos por plan.
¿Es Ivy Tendril gratuito?
Sí. La aplicación es gratuita y de código disponible bajo licencia FSL-1.1-ALv2. Pro (59 $ por usuario/mes) añade funciones de equipo, alojamiento local, SSO e importación de verificaciones de CI. Consulte los precios.
Empiece hoy con Ivy
¿Preparado para evolucionar desde los frameworks convencionales a aplicaciones full-stack preparadas para agentes autónomos?
- Explore el código: Inspeccione Ivy Tendril en GitHub (código abierto).
- Consulte la documentación: Revise las guías técnicas en tendril.ivy.app.
- Hable con un ingeniero: Escriba a renco@ivy.app para reservar una sesión de arquitectura de 30 minutos.