¿CON QUÉ IA?
Lo contó A quién le sirve. Programadores y fundadores técnicos que pagan una suscripción de Claude o Codex y la dejan sin gastar al final de la semana. Si no programas, no es para ti.
Qué hicieron
El fundador apunta RemainderBot a un archivo de objetivos y a fuentes de listas de tareas. Se ejecuta a mano o como tarea programada. En modo programado mira cuánta cuota de la suscripción queda y cuánto falta para el reinicio semanal, elige una tarea, trabaja en una rama nueva y abre una solicitud de cambios (PR) en GitHub. Él revisa las PR allí, y sus comentarios y decisiones de aceptar o no orientan las tareas siguientes.
Cómo salió
Produjo 111 PR, entre ellas preparación de llamadas con clientes, un recuento de los archivos de configuración de agentes de 31 organizaciones de GitHub y prototipos aislados para demostraciones. No da cifras de acierto y el autor pide que le avisen de errores.
Conviene saber
Necesita git, la herramienta de línea de comandos de claude o codex y gh con sesión iniciada. Una ejecución pequeña con un plazo de 20 minutos cuesta unos pocos puntos porcentuales de la cuota semanal.
Qué necesitas
- Una suscripción a Claude o Codex con su herramienta de línea de comandos (claude o codex) instalada.
- git (el sistema que guarda el historial de cambios del código) y gh (la herramienta de GitHub para la línea de comandos), con la sesión iniciada.
- Un archivo con tus objetivos y una fuente de tareas pequeñas y bien definidas.
- Un repositorio de GitHub (el lugar donde vive el código) donde abrir las solicitudes de cambios (PR).
- Un ordenador que pueda ejecutar una tarea programada (cron, el programador de tareas del sistema).
Cómo hacerlo tú, paso a paso
- Escribe un archivo con tus objetivos y reúne una lista de tareas pequeñas y bien definidas.
- Comprueba que git, la herramienta claude o codex y gh funcionan con tu sesión iniciada.
- Escribe el encargo, como el RemainderBot del autor: leer objetivos y lista, elegir tareas pequeñas, trabajar cada una en su propia rama (una copia de trabajo aparte del código) y abrirla como PR con una descripción breve.
- Ejecútalo primero a mano con un plazo corto (el caso hizo una prueba de 20 minutos) para ver cuánta cuota consume.
- Cuando te convenza, prográmalo para que se ejecute cuando suele sobrar cuota, por ejemplo cerca del reinicio semanal.
- Revisa las PR en GitHub: acepta, rechaza o comenta. Esas decisiones orientan las tareas siguientes.
- Pon un límite de tareas por ejecución y vigila el consumo.
Lee mis objetivos en [ruta del archivo de objetivos] y mi lista de tareas en [ruta o enlace de la lista]. Elige hasta [número] tareas pequeñas y bien definidas en las que me puedas ayudar, como notas de preparación de llamadas, prototipos o arreglos menores. Haz cada una en su propia rama y ábrela como solicitud de cambios en [repositorio] con una descripción breve de lo que has hecho y por qué. No aceptes ninguna. Habrás terminado cuando hayas abierto las solicitudes y me hayas dado la lista.
Consejos
- Empieza con tareas de bajo riesgo, como notas de preparación o prototipos aislados, no con código en producción.
- Revisa cada PR tú mismo. Que nada se acepte solo.
- Una ejecución pequeña de 20 minutos cuesta unos pocos puntos de la cuota semanal. Prueba antes de programar muchas.
Preguntas frecuentes
¿Pierdo dinero si lo dejo funcionando solo?
Gasta la cuota de la suscripción que ya pagas, no una factura nueva, siempre que no uses una clave de API (un código para usar el modelo que se paga según el uso). Comprueba qué cuenta usa antes de programarlo.
¿Qué pasa si una PR rompe algo?
No se acepta sola. Las PR se revisan antes de unirse a tu rama principal, y si no te convence, la rechazas y el código sigue como estaba.
Fuentes
En el directorio desde el 13 de octubre de 2026.
@Ducktumay en X
naw103/foremerge en GitHub