Transformez le backlog en branches pendant que vous codez la fonctionnalité suivante

Faites traiter une liste de tickets à Codex ou Claude Code par un script sur votre Compute toujours allumé. Chaque correctif a son test et sa branche, et votre portable reste à vous. Pro coûte $75 par mois.

Obtenir mon Compute Voir les offres

À partir de $39 par mois · Docker et sudo inclus · Résiliable à tout moment depuis le tableau de bord

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

Quarante petits bugs, et chacun coûte un changement de contexte

Chaque correctif d’une ligne, c’est une branche, un test, un push et vingt minutes de votre attention. Quarante d’entre eux, c’est une semaine perdue.

Les runners CI hébergés sont faits pour les tests. Un agent a besoin d’une heure, d’une base de données, de caches chauds et d’identifiants pour finir le travail.

Un passage sur le backlog

10:00
Écrivez la boucle une fois
Une boucle shell confie chaque ticket à codex exec ou claude -p avec la même consigne : le corriger, ajouter un test, pousser une branche.
10:02
Laissez-la dans un onglet
La boucle tourne dans une session tmux. Fermez l’onglet ; elle déroule la liste.
11:30
La stack reste debout
Postgres et MinIO tournent dans Docker sur votre Compute pour chaque ticket : chaque correctif est testé sur les mêmes services.
16:00
Relisez les branches terminées
Ouvrez les branches poussées en pull requests et relisez chaque diff comme celui d’un collègue.

L’agent vide le backlog

Votre backlog, en branches
Chaque ticket finit en branche avec un test. Vous relisez des diffs au lieu de les écrire.
Des exécutions headless qui gardent leur historique
codex exec et claude -p tournent sans interface. Les checkouts et l’historique de chaque agent restent dans le projet d’une exécution à l’autre.
La dixième exécution démarre à chaud
Conteneurs, dépendances et caches de build restent dans le terminal qui fait tourner la boucle : le dixième ticket démarre aussi vite que le deuxième.
Chaque nuit, ou à chaque nouveau ticket
La boucle est un script shell dans le projet. Modifiez-la dans le terminal et lancez-la. Ajoutez cron pour un passage chaque nuit, ou un récepteur de webhooks pour lancer les exécutions sur événement.

La taille pour ce travail

Pro · $75

Les 4 vCPU de Pro font tourner la suite de tests et les conteneurs pendant que le ticket suivant est déjà en cours.

Manifestedetachbox · node 1

Compute: pr-mill
Projets: /work/app
Offre: Pro · 4 vCPU · 8 GB · 100 GB · $75/mois
Agent: Codex
Onglets: 3
Services: postgres:18 · minio
Tourne: Jour et nuit, écran rabattu

Pro

Notre choix pour les agents

$75par mois

5 agents et les services Docker sur lesquels ils testent

vCPU: 4
RAM: 8 GB
disque: 100 GB
Internet: 100 Mbit
Terminaux à la fois: 5

Obtenir mon Compute

Questions sur ce sujet

Puis-je lancer des exécutions depuis un webhook ou une tâche cron ?

Oui. Chaque terminal est un Linux avec sudo, cron et systemd, qui tournent tant que le terminal tourne. Installez-y une tâche cron ou votre propre runner, ou servez un récepteur de webhooks sur un port public, et lancez les agents depuis là.

Où vivent les identifiants git de l’agent ?

Dans le dossier personnel du projet, sur votre Compute, qu’aucun terminal d’un autre projet ne voit. Donnez à l’agent une deploy key ou un token à permissions fines limité aux dépôts sur lesquels il travaille.

Et si une exécution laisse du désordre ?

Chaque terminal est son propre système Linux, donc une mauvaise exécution reste dans son terminal. Terminez-le et le suivant démarre propre ; git remet le dossier du projet en état.

Ce que ce travail utilise

D’autres travaux qu’on y fait tourner