Je n'utilise pas un seul assistant IA. Je fais rouler une petite équipe d'ingénierie faite d'agents.
J'écris le ticket. Un coding agent le prend, fait le travail et ouvre une pull request. Un reviewer agent la review. Je lis le résultat et j'approuve ce qui part en production. Mon temps va à décider quoi construire et à juger le résultat, pas à taper chaque ligne.
Deux pièces font marcher ça : T3 Code comme endroit où le coding se passe, et Grok Bots comme équipe qui le pilote.
L'équipe
Chaque rôle est un bot avec une job :
- Des leads qui coordonnent le travail,
- des coders qui roulent les threads de coding,
- un reviewer qui vérifie chaque pull request avant que je la voie,
- des ticket writers qui préparent le travail,
- un sync Linear qui garde le tracker à jour,
- un inbox et un daily prep qui me gardent orienté.
Découper le travail en rôles compte plus que n'importe quel prompt. Un bot qui fait juste de la review est un meilleur reviewer qu'un bot qui a aussi écrit le code. Et quand quelque chose va mal, je sais quel rôle corriger.
Où le code s'écrit
T3 Code est une app open source pour faire rouler des coding agents comme Codex et Claude Code. Le travail se fait dans des threads, les threads appartiennent à des projets, et un projet est un dossier sur ma machine. Les agents roulent là où mon code, mes outils et mes credentials se trouvent déjà.
Les bots n'ont jamais besoin de savoir comment T3 Code fonctionne à l'interne. Ils passent par sa ligne de commande.
Le contrat : t3 thread
Une équipe de bots a besoin d'une surface petite et stable, et la ligne de commande t3 en a déjà une :
t3 thread start --json . "Implement the ticket and open a pull request"
t3 thread show --messages 3 <thread-id>
t3 thread send <thread-id> "Address the review comments"
t3 thread list --project .Quelques détails de cette surface en font un bon choix pour des agents qui en pilotent d'autres.
send n'interrompt jamais. Si un coding agent est occupé, le message devient son prochain tour. Un bot lead ne peut pas annuler un travail à moitié par accident.
--wait a des exit codes honnêtes. Il sort avec 1 quand le run échoue et avec 2 quand l'agent attend une réponse. « A besoin d'une réponse » est son propre état, et l'équipe le traite comme tel au lieu de rapporter un succès.
--json donne de la donnée, pas de la prose. L'état revient structuré, donc personne n'a à scraper du texte écrit pour des humains.
--worktree isole un run. Un thread peut démarrer dans un git worktree neuf à partir d'une branche, donc les tickets en parallèle ne se marchent pas dessus.
Comme chaque action est une commande, je peux rouler n'importe quelle étape à la main. Quand l'équipe fait quelque chose de surprenant, je tape la même commande et je vois exactement ce que le bot a vu.
Où je reste dans la boucle
L'étape d'approbation est à moi. Tout ce qui vient avant peut être automatisé : le ticket, le code, la review. Tout ce qui vient après est une décision avec des conséquences, donc ça m'attend.
Cette séparation est ce qui rend le setup digne de confiance. Les agents sont rapides et infatigables, et ils ont aussi parfois tort avec beaucoup d'assurance. Un deuxième agent en attrape une bonne partie. J'attrape le reste.
Un bot public
J'ai publié un Grok Bot public qui fait rouler T3 Code depuis le chat, sur tes propres ordinateurs, grâce à la ligne de commande t3. Il démarre et vérifie des threads de coding agents et s'occupe du setup de projet. C'est la version la plus simple de l'idée : un bot, une machine, une fenêtre de chat.
Ce que j'ai appris
Les rôles battent un gros assistant. De petits bots avec des jobs étroites sont plus faciles à croire et plus faciles à corriger.
Utilise le seam qui existe déjà. La ligne de commande a été faite pour des scripts, et un bot est un script avec du jugement.
Prévois l'état « attend une réponse ». Un run d'agent finit dans trois états : terminé, échoué ou en attente d'un humain. Un système qui ne distingue pas le troisième état fait perdre du temps à l'humain.
Garde l'humain sur la décision. Automatise tout jusqu'au bouton d'approbation, et rien après.