PRD dentro, código fusionado fuera: desplegando una fábrica de software 24/7 en GPT-6 Astra

Una nueva ola de modelos insignia ha reavivado el debate sobre la AGI, y esta sección abre con su versión más ruidosa: una cita de un ejecutivo declarando que la inteligencia general ha llegado. El anfitrión se mantiene escéptico ante el eslogan, pero reporta un cambio genuino a partir de pruebas prácticas — el modelo capta la intención con menos idas y vueltas y hace menos de las suposiciones extrañas que aquejaban a sus predecesores.

Sobre el papel, los dos modelos líderes parecen empatados, con puntuaciones públicas apuntando en la misma dirección. La semana de pruebas comparativas del autor cuenta otra historia, con el recién llegado saliendo adelante en la mayoría de las ejecuciones. Esa brecha entre puntuaciones empatadas y experiencia vivida merece nombrarse con honestidad: es la carga de trabajo de una sola persona, no una medición replicada, y debe leerse así hasta que alguien la repita.

La idea central tiene un nombre memorable: la fábrica de software, también llamada fábrica oscura. Entra una especificación de producto o una issue, y sale código revisado y listo para entregar, con el triaje, la planificación, la implementación, la validación y la revisión gestionados como una tubería. A principios de este año esa promesa parecía irreal; la afirmación del autor es que modelos más potentes más un arnés más sólido la han movido de la fantasía a algo que vale la pena experimentar — admitiendo que está lejos de ser totalmente fiable.

El modelo de despliegue importa más que la metáfora. En lugar de un experimento en un portátil, la fábrica vive en una máquina remota que funciona las 24 horas y acepta trabajo nuevo a cualquier hora. La entrada es siempre la misma — una issue que describe qué construir — y la salida es siempre la misma: una pull request revisada que se fusiona sola o escala a un humano. La visión declarada es que cada individuo y cada empresa eventualmente mantendrán una línea así funcionando en la nube.

Empezar es deliberadamente sin ceremonias: apuntar un agente de codificación al repositorio de la fábrica, pegar el prompt de configuración proporcionado y responder sus preguntas de entrevista. El flujo cubre ambas direcciones — una base de código nueva que comienza su vida como especificación escrita de un producto mínimo viable, y una base de código existente sobre la que se monta la fábrica. Probar primero en local es el hábito recomendado; el despliegue remoto es el destino.

Para la demostración en vivo, el anfitrión elige alojamiento virtual basado en KVM y señala el plan intermedio KVM2 como suficiente, subrayando que cualquier máquina Ubuntu en la nube serviría. El contexto comercial también pertenece al resumen: el segmento de alojamiento está patrocinado y viene con un código de descuento personal, así que la recomendación específica del proveedor debe leerse con ese interés en mente.

El recorrido de configuración se apoya en el agente de codificación para casi todo. El agente comprueba las herramientas locales, pregunta qué servidor virtual es el objetivo, en qué repositorio debe trabajar la fábrica y qué agente debe impulsarla — las dos opciones probadas siendo Claude Code y Codex. Para la demo, el anfitrión conduce desde un agente local familiar mientras la fábrica misma funciona sobre Codex emparejado con el nuevo modelo, aplicado sobre una pequeña app preconstruida de acortador de enlaces para ir rápido.

El plugin de alojamiento es la parte que hace que la configuración remota se sienta fácil. Un comando de instalación más un inicio de sesión en el navegador dan al agente control sobre la cuenta: lista instancias, toma el identificador de la VM y la dirección pública, y procede con el acceso SSH, las reglas de firewall y las instalaciones de aplicaciones. Los límites se declaran claramente — el plugin no puede crear un servidor por sí mismo, así que la máquina debe existir antes de que el agente tome el control.

Luego llega el tramo que ningún agente puede cruzar por ti: las credenciales. El anfitrión abre un shell en el servidor recién creado, lo vincula a GitHub con un código de dispositivo, e inicia sesión en el agente remoto de la misma manera, tras habilitar la autorización por código de dispositivo en los ajustes de seguridad de la cuenta de chat. Un comando de saludo de una línea contra el nuevo modelo sirve como prueba de humo — una respuesta significa que el lado remoto tiene inicios de sesión funcionales tanto para el alojamiento de código como para la inferencia.

A partir de ahí, la instalación toma del orden de ocho minutos: la fábrica misma, el motor de flujos de trabajo Archon por debajo, la copia del repositorio y la configuración. El agente luego hace preguntas operativas — nombre de host, puerto — y propone una primera issue de prueba extraída de la propia lista de tareas del proyecto. Esa issue se archiva desde la línea de comandos, se tria según las reglas de la fábrica, se clasifica y se lleva hasta una pull request validada, con los ajustes de dominio gestionados a través del mismo plugin de alojamiento. Una vez confirmado el ciclo, la sesión local se cierra y la línea queda en marcha, esperando la próxima issue — etiquetada abiertamente como alfa temprana, todavía en refinamiento.