Zheat Logo
    RadjivRadjivSenior Software Engineer

    Application perpétuelle : Grok Bot déclenche les agents Composer, Rocky et No More Slop tiennent les gates

    Une application perpétuelle est un produit live qui se maintient en production après le lancement. Gates branchables (Appzi, Clarity, Ahrefs). Grok Bot organise. Cursor Composer construit les agents locaux. Rocky et No More Slop tiennent la perf et la revue.

    Suivre sur LinkedIn

    Une application perpétuelle est un produit live qui se maintient en production après le lancement. Elle lit de vrais signaux, livre des correctifs, et attend un humain avant d'inventer des features. Ce n'est pas un bot qui code toute la nuit et appelle ça une roadmap.

    Ce papier est la carte. Les notes de terrain pour un cas live (Order of Battle) sont dans Pourquoi j'ai donné à Grok Bot un bot Routine. Les deux outils qui tiennent la boucle sous charge sont Rocky et No More Slop.

    URL canonique : https://www.zheat.xyz/fr/insights/perpetual-application/

    Sommaire

    1. Qu'est-ce qu'une application perpétuelle ?
    2. Quelles gates peut-on ajouter ?
    3. Grok Bot écrit-il le code ?
    4. À quoi sert Cursor Composer ?
    5. Comment Rocky gère les gates ?
    6. Comment No More Slop revoit le code ?
    7. Pourquoi Rocky et No More Slop font la perf ?
    8. Comment la boucle fonctionne ?
    9. FAQ
    10. Suite

    Qu'est-ce qu'une application perpétuelle ?

    Une application perpétuelle est un produit live organisé pour que des agents le gardent sain après le lancement : signaux utilisateurs et production en entrée, correctifs en sortie, features en hold tant qu'un humain n'a pas demandé.

    Une démo livrée une fois, c'est un projet. Un produit qui a encore des liens morts, des crashes et des utilisateurs perdus trois mois plus tard, c'est le vrai job.

    Une application perpétuelle est organisée pour que :

    • Les correctifs puissent tourner à l'horaire. Clarity, Sentry, erreurs de crawl, UX cassée.
    • Les features attendent une voix humaine. Un feedback vide n'est pas un backlog.
    • Vous possédez le code. Les agents travaillent dans votre repo, derrière vos gates, sur votre infra.

    Une app perpétuelle qui livre des features fantômes est juste occupée. Le hold, c'est la règle produit, pas un manque d'agents.

    Quelles gates peut-on ajouter ?

    Les gates sont les signaux que vous branchez dans la boucle. On les ajoute par produit. Pas besoin de tout le premier jour.

    GateCe qu'elle dit à la boucleQui s'en occupe dans l'équipe Grok Bot
    AppziCe que les utilisateurs ont vraiment dit : bugs, friction, enviesLe PO lit. Les features restent en hold tant qu'il n'y a pas de volume.
    ClarityRage-clicks, abandons, UI morteRoutine tient la revue quotidienne. Le Developer reçoit le clip, pas une rumeur.
    AhrefsCe que le crawl et la search voient après une livraisonLe PO regarde quand la trouvabilité compte (sitemap, 3XX, URLs mortes).
    Sentry (si elle est dans la stack)Crashes et stacksMême boucle quotidienne que Clarity.

    Vous pouvez en ajouter plus tard (Vercel, GitHub, un second outil de feedback). L'architecture ne change pas. Une nouvelle gate est une nouvelle entrée. Ce n'est pas un nouvel agent de code.

    Le PO distribue. Routine vérifie que le planning tourne encore. Ni l'un ni l'autre ne patche le repo.

    Grok Bot écrit-il le code ?

    Non. Grok Bot n'écrit pas le code. Si vous faites tourner une équipe Grok Bot, traitez-la comme l'org externe, pas comme l'IDE.

    Sur Order of Battle, les rôles publics restent petits exprès :

    RôleJobNe fait pas
    RoutineS'assurer que le travail planifié part vraiment (Clarity / Sentry / la boucle du jour)Décisions produit. Périmètre de feature. Écrire le patch.
    POLire Appzi. Regarder Ahrefs quand la découverte compte. Distribuer le travailLivrer du code.
    Developer (Grok Bot)Transformer un ticket en hit : réveiller l'agent local avec un briefInventer la roadmap. Être l'éditeur qui tape le diff.

    Grok Bot hit l'agent. L'agent qui écrit, teste et ouvre la PR est un agent local. Avec cette équipe, cet agent local est Cursor. Le Developer Grok Bot est le dispatcher. Cursor, c'est là que sont les mains.

    À quoi sert Cursor Composer ?

    Cursor Composer est la façon dont on crée ces agents locaux.

    On définit le worker dans Composer : quel repo, ce qu'il a le droit de toucher, quel MCP il doit utiliser. Cet agent vit dans Cursor (l'autre app). On le marie ensuite à un rôle Grok Bot.

    • Grok Bot PO / Routine / Developer : organiser, planifier, hit.
    • Agent Composer : exécuter dans le repo.

    Le hit, c'est un brief. Des étapes de repro. Un clip Clarity ou une stack Sentry quand ça existe. La couverture d'abord. Ensuite l'agent Composer travaille dans Rocky, pas dans un chat libre qui colle tout l'arbre dans le contexte.

    Voilà le match : équipe Grok Bot d'un côté, agents Cursor faits dans Composer de l'autre. Même produit. Deux apps. Une boucle.

    Comment Rocky gère les gates ?

    Rocky est la couche MCP sur l'agent local. Il ne remplace pas Composer. C'est ce qui garde l'agent Composer dans un workflow senior :

    • Découverte graphify d'abord, pas 20 lectures de fichiers
    • Handbook (agents, skills, rules) au lieu d'un nouveau prompt chaque nuit
    • Un gateway devkit au lieu d'un tas de schémas d'outils bruts
    • Un gate pre-PR avec un verdict clair ready / not_ready

    Quand le Developer Grok Bot hit l'agent local, Rocky empêche ce hit de devenir du code agent bâclé sur main.

    C'est aussi là que vivent les gates d'ingénierie en plus : lint, tests scopés, check d'architecture. No More Slop escalade vers Rocky quand le reste n'est pas une réécriture de style. Voir le handoff No More Slop → Rocky.

    Sur une tâche React monorepo mesurée, Rocky a fait passer les tokens de milieu de session d'environ 255k à environ 89k. C'est l'histoire de perf du gate, pas l'idée que Grok Bot chat plus vite.

    Comment No More Slop revoit le code ?

    No More Slop est la skill de revue sur le même agent local. Rocky demande : est-ce prêt pour un humain ? No More Slop demande : est-ce que ça se lit encore comme du code d'agent ?

    Elle score deux couches (slop regex et slop structurel), réécrit vers le style voisin, et rescore. Commentaires, boilerplate motion, noms verbeux, coquilles copiées-collées. Quand le reste c'est lint, tests ou architecture, elle arrête de faire semblant et passe la main à Rocky.

    Sans cette passe, une boucle perpétuelle dépose juste des diffs en forme d'IA chaque matin. Le produit bouge. Le codebase empire.

    Pourquoi Rocky et No More Slop font la perf ?

    Grok Bot et Composer sans Rocky et No More Slop, c'est un calendrier qui ouvre des PR bruyantes. La vitesse, ici, ce n'est pas « le modèle tape plus vite ». C'est moins de sessions gâchées.

    OutilJob dans l'app perpétuelleCe qui casse si vous le sautez
    RockyGère les gates d'ingénierie. Découverte, handbook, verdict pre-PR.Brûlage de tokens, tests oubliés, PR « ça a l'air fini » qui ne le sont pas.
    No More SlopRevoit le code généré pour qu'il ressemble au repo.Slop de commentaires, shells dupliqués, diffs qu'un humain ne voudra pas maintenir.
    Grok BotHit le bon agent au bon moment.Le travail ne démarre pas, ou un bot veut être à la fois l'org et l'IDE.
    Composer / CursorL'agent local qui édite vraiment le repo.Rien n'arrive dans git.

    Rocky garde le hit dans un petit contexte. No More Slop garde le diff mergeable. L'humain merge encore.

    Comment la boucle fonctionne ?

    La boucle d'une application perpétuelle : les gates que vous ajoutez, l'équipe Grok Bot organise et hit, un agent local Composer travaille dans Cursor derrière Rocky et No More Slop, un humain merge sur main.

    Appzi, Clarity, Ahrefs, Sentry     (gates que vous ajoutez)
        |
        v
Équipe Grok Bot                    (Routine / PO / Developer)
  organiser, planifier, HIT
        |
        v
Agent local Composer dans Cursor   (fait le travail)
        |
        +--> Rocky                 (gates d'ingénierie, ready / not_ready)
        +--> No More Slop          (revue de code / score de slop)
        |
        v
PR --> gate humain --> main
        |
        v
le produit reste en production     (application perpétuelle)

    Les correctifs peuvent tourner tous les jours. Les features attendent Appzi (ou un autre signal humain). Même règle que les notes Grok Bot. Ce papier nomme seulement la machine derrière le hit.

    FAQ

    Qu'est-ce qu'une application perpétuelle ? Une application perpétuelle est un produit live organisé pour que des agents le gardent sain après le lancement : signaux utilisateurs et production en entrée, correctifs en sortie, features en hold tant qu'un humain n'a pas demandé. Ce n'est pas un bot qui code toute la nuit et appelle ça une roadmap.

    Grok Bot écrit-il le code ? Non. L'équipe Grok Bot organise et hit. L'agent local (Cursor, construit dans Composer) écrit dans le repo, via Rocky.

    À quoi sert Cursor Composer ? Cursor Composer est la façon dont on crée les agents locaux. On marie ensuite chaque agent à un rôle Grok Bot. Grok Bot ne devient pas l'éditeur.

    Quelles gates je peux ajouter à une application perpétuelle ? Partez de ce que vous avez déjà. Appzi pour la voix, Clarity pour le comportement, Ahrefs pour le crawl et la search, Sentry pour les crashes. Une nouvelle gate est une nouvelle entrée pour le PO ou Routine. Ce n'est pas un nouveau modèle de code.

    Pourquoi Rocky et No More Slop ensemble ? Rocky gère si le changement a le droit de partir. No More Slop gère si le changement ressemble encore à votre codebase. La boucle ne performe que si les deux tournent sur l'agent Composer.

    Les features partent-elles dans la nuit ? Non. Une application perpétuelle qui invente des écrans à partir d'un feedback vide est occupée, pas perpétuelle. Les correctifs peuvent tourner à l'horaire. Les features attendent une voix humaine.

    Suite

    ← Tous les insights