Convierte el backlog en ramas mientras construyes la siguiente función

Lanza Codex o Claude Code con un script sobre una lista de issues en un Compute que nunca duerme. Cada arreglo tiene su test y su propia rama, y tu portátil sigue siendo tuyo. Pro cuesta $75 al mes.

Quiero mi Compute Ver los planes

Desde $39 al mes · Docker y sudo incluidos · Cancela desde el panel cuando quieras

dev@pr-mill:/work/app$ for n in 412 415 418; do codex exec "fix issue #$n, add a test, push fix/$n"; done

▸ #412 reading src/cart/total.ts

▸ #412 npm test ✓ 318 passed

▸ #412 git push -u origin fix/412

▸ #415 reading src/auth/session.ts

▸ #415 npm test ✓ 319 passed

▸ #415 git push -u origin fix/415

▸ #418 reading src/search/query.ts

▸ #418 npm test ✓ 321 passed

✓ three branches pushed: fix/412 fix/415 fix/418

Cuarenta bugs pequeños, y cada uno cuesta un cambio de contexto

Cada arreglo de una línea implica una rama, un test, un push y veinte minutos de tu atención. Cuarenta de ellos son una semana perdida.

Los runners de CI alojados están hechos para tests. Un agente necesita una hora, una base de datos, cachés calientes y credenciales para terminar el trabajo.

Una pasada por el backlog

10:00
Escribe el bucle una vez
Un bucle de shell pasa cada issue a codex exec o claude -p con las mismas instrucciones: arréglalo, añade un test, sube una rama.
10:02
Déjalo en una pestaña
El bucle corre dentro de una sesión de tmux. Cierra la pestaña; sigue recorriendo la lista.
11:30
El stack sigue arriba
Postgres y MinIO corren en Docker en tu Compute para cada issue, así que cada arreglo se prueba contra los mismos servicios.
16:00
Revisa ramas terminadas
Abre las ramas subidas como pull requests y revisa cada diff como el de un compañero.

El agente vacía el backlog

Tu backlog, convertido en ramas
Cada issue termina como una rama con su test. Revisas diffs en lugar de escribirlos.
Agentes headless con casa propia
codex exec y claude -p corren sin interfaz. Los checkouts y el historial de cada agente se quedan en el proyecto entre ejecuciones.
La décima ejecución arranca en caliente
Contenedores, dependencias y cachés de compilación se quedan en el terminal que ejecuta el bucle, así que el décimo issue arranca tan rápido como el segundo.
Cada noche, o con cada issue nuevo
El bucle es un script de shell en el proyecto. Edítalo en el terminal y arráncalo. Añade cron para una ejecución cada noche, o un receptor de webhooks para lanzar ejecuciones desde eventos.

El tamaño para este trabajo

Pro · $75

Las 4 vCPU de Pro mantienen ocupados la suite de tests y los contenedores mientras el siguiente issue ya está en marcha.

Manifiestodetachbox · node 1

Compute: pr-mill
Proyectos: /work/app
Plan: Pro · 4 vCPU · 8 GB · 100 GB · $75/mes
Agente: Codex
Pestañas: 3
Servicios: postgres:18 · minio
Funciona: Día y noche, con la tapa cerrada

Pro

Nuestra elección para agentes

$75al mes

5 agentes y los servicios Docker contra los que prueban

vCPU: 4
RAM: 8 GB
disco: 100 GB
Internet: 100 Mbit
Terminales a la vez: 5

Quiero mi Compute

Preguntas sobre esto

¿Puedo lanzar ejecuciones desde un webhook o un cron?

Sí. Cada terminal es Linux con sudo, cron y systemd, y todo corre mientras el terminal siga vivo. Instala ahí un cron o tu propio runner, o pon un receptor de webhooks en un puerto público, y lanza agentes desde ahí.

¿Dónde viven las credenciales de git del agente?

En la carpeta personal del proyecto, en tu Compute, que ningún terminal de otro proyecto puede ver. Dale al agente una deploy key o un token de permisos granulares limitado a los repos en los que trabaja.

¿Y si una ejecución lo deja todo hecho un desastre?

Cada terminal es su propio sistema Linux, así que una mala ejecución se queda en su terminal. Finalízalo y el siguiente arranca limpio; git restaura la carpeta del proyecto.

Lo que usa este trabajo

Más trabajos que la gente ejecuta