La plupart des discussions sur le développement logiciel autonome commencent par des agents qui écrivent du code. Un agent récupère un ticket, implémente une fonctionnalité, ouvre une pull request. La démo fonctionne. Les gens s'enthousiasment.
Avant qu'une livraison autonome puisse fonctionner de manière fiable, quelqu'un doit concevoir le système d'ingénierie dans lequel l'autonomie va opérer. La structure du projet, les choix technologiques, les limites architecturales, l'orientation du design, les conventions d'ingénierie, les mécanismes de validation, les rôles spécialisés, les limites d'approbation. Rien de tout cela ne devrait émerger d'une collection d'agents indépendants qui devinent en parallèle.
Mon approche commence par une répartition différente des responsabilités. Les humains conçoivent le système d'ingénierie. Des agents spécialisés exécutent le travail. Des boucles asynchrones orchestrent quand ce travail a lieu et ce qui vient ensuite.
L'objectif n'est pas de supprimer les humains du développement logiciel. C'est de concentrer l'implication humaine sur les décisions qui nécessitent du jugement, du contexte et une compréhension du produit, tout en construisant un environnement où une plus grande partie de l'exécution peut se poursuivre d'elle-même.
Voici les six étapes que je suis chaque fois que je commence un projet destiné à fonctionner sans que je le surveille.
Étape 1 : l'humain conçoit le système d'ingénierie
Lorsque je commence un projet, je ne demande pas à un agent autonome d'inventer ses fondations.
Je décide d'abord des parties importantes : comment le dépôt doit être organisé, quelles technologies utiliser, comment fonctionnent les principales limites architecturales, quelle est l'orientation du design, quelles conventions d'ingénierie doivent être respectées, et où l'autonomie doit s'arrêter. Ces décisions deviennent le fondement de tout ce qui suit.
Ensuite, j'utilise opencode-onboard pour les encoder dans le dépôt.
/make-engineer crée les ingénieurs IA spécialisés dont le projet a besoin. Frontend, backend, infrastructure, test, sécurité, données, mobile, tout ce que le produit exige. Ce ne sont pas des agents génériques avec des étiquettes différentes. Chacun a une spécialisation définie, un ensemble de capacités et une place claire dans le flux de travail d'ingénierie.
/make-architecture capture la structure technique et les limites dans ARCHITECTURE.md. /make-design capture le langage visuel, les tokens de design et les patterns de composants dans DESIGN.md. /make-guardrails convertit toutes ces décisions en règles concrètes que chaque agent doit respecter. Limites architecturales, conventions de nommage, attentes de test, style de code, contraintes de sécurité, pratiques Git. Elles cessent d'être des connaissances détenues uniquement par le développeur d'origine et deviennent partie intégrante de l'environnement opérationnel.
Le dépôt finit par contenir plus que de la documentation. Il contient une organisation d'ingénierie encodée et une source de vérité partagée pour chaque agent qui y travaillera.
L'humain définit d'abord le système. Ce n'est qu'ensuite que l'exécution autonome devient utile.
Étape 2 : la base interactive vient avant l'autonomie
Une fois le système d'ingénierie défini, je construis la base initiale du projet de manière interactive.
J'utilise normalement /plan-quick et /plan-apply à ce stade. /plan-quick analyse un objectif ciblé et le transforme en une séquence concrète et ordonnée de tâches. Il est intentionnellement plus léger qu'un flux de spécification complet. Je l'utilise lorsque le travail est clair et que je veux avancer rapidement sans perdre en visibilité ni en contrôle. /plan-apply implémente ces tâches et vérifie le résultat.
C'est ainsi que j'établis l'infrastructure de base du projet. Structure du dépôt, squelette de l'application, configuration de la base de données, fondations de l'authentification, système de design, infrastructure de test, configuration CI/CD, fondations du déploiement.
Les premières étapes d'un projet contiennent des décisions qui affectent tout ce qui est construit par la suite. Une abstraction faible, une structure de dossiers incohérente, une stratégie de test peu claire. N'importe laquelle peut être reproduite des centaines de fois une fois que les agents autonomes commencent à travailler. Je l'ai vu arriver. Ce n'est pas joli.
Pour cette raison, cette phase reste rapide et assistée par IA, mais supervisée.
Le but n'est pas de maximiser l'autonomie le plus tôt possible. Le but est de rendre le projet suffisamment stable, compréhensible et prévisible pour que l'autonomie puisse ensuite y opérer en toute sécurité.
Étape 3 : l'implication humaine devient une politique de projet
Une fois les fondations prêtes, je décide du degré d'autonomie que le système de livraison doit avoir.
Ce n'est pas un choix binaire entre développement manuel et automatisation complète. L'implication humaine peut exister à différents points du cycle de vie, et la bonne configuration dépend du projet.
Un projet entièrement supervisé peut exiger qu'un humain affine le ticket, approuve le plan d'implémentation, relise la pull request, approuve la fusion et autorise le déploiement.
Un projet partiellement autonome peut laisser l'IA affiner et implémenter, tandis que les humains répondent aux questions non résolues, relisent les pull requests importantes ou conservent le contrôle sur la fusion finale.
Un projet hautement autonome peut laisser le système affiner, implémenter, relire et fusionner les modifications automatiquement lorsque les garde-fous, tests et contrôles qualité requis sont satisfaits.
Un nouveau produit avec des exigences instables nécessite une participation humaine plus importante qu'un outil interne mature. Un système réglementé exige des points d'approbation explicites qui seraient inutiles pour une petite expérience. Et le même projet peut devenir plus autonome au fil du temps à mesure que son architecture, ses tests et ses mécanismes de livraison maturent.
Le point important est que l'autonomie est définie intentionnellement. Affinement du ticket, résolution des questions, approbation du plan, relecture de la pull request, approbation de la fusion, approbation du déploiement. Ce ne sont pas des interruptions accidentelles. Ce sont des points de contrôle configurables dans le système d'ingénierie.
Chaque projet choisit un niveau d'autonomie différent, et ces limites évoluent avec lui.
Étape 4 : les idées deviennent des éléments de backlog durables
La console interactive reste l'endroit où j'explore les idées.
Lorsqu'une idée est incomplète, j'utilise /plan-explore. Ce n'est pas une commande d'implémentation. C'est un processus d'exploration collaborative. L'agent examine le dépôt, cartographie les composants pertinents, identifie les patterns existants, remet en question les hypothèses, trace les dépendances, considère les risques et aide à déterminer ce qui doit réellement être construit.
De nombreux problèmes de développement ressemblent initialement à des tâches de codage, mais sont en réalité des problèmes de compréhension. Envoyer une idée floue directement dans un flux de travail d'implémentation autonome produit généralement une implémentation floue. L'exploration donne à l'idée suffisamment de structure pour devenir exploitable sans s'engager prématurément sur une solution.
Une fois la direction claire, j'utilise /ops-backlog pour créer un élément de travail structuré dans GitHub, Azure DevOps ou Jira. L'élément de travail devient la passerelle durable entre la réflexion interactive et l'exécution asynchrone. Il peut contenir le contexte, le périmètre, les critères d'acceptation, les risques, les questions non résolues et les dépendances nécessaires aux étapes suivantes du flux de travail.
À ce stade, le backlog n'est plus seulement un endroit où les tâches sont stockées. Il devient la couche de coordination partagée entre les humains, les agents et les boucles.
Les humains créent des idées, répondent aux questions et prennent des décisions. Les boucles observent les états des tickets et sélectionnent le travail éligible. Les agents reçoivent des tâches ciblées avec le contexte nécessaire pour les exécuter.
Le backlog transforme une conversation interactive en un travail durable qui se poursuit après la fin de cette conversation.
Étape 5 : loop-task orchestre le travail asynchrone
Une fois le projet, les ingénieurs, les garde-fous, le backlog et la politique d'approbation prêts, je configure loop-task sur une machine locale ou une VM.
loop-task exécute les boucles d'orchestration externes. Ces boucles inspectent en continu le backlog, identifient le travail éligible, invoquent le flux de travail d'ingénierie approprié et mettent à jour l'état de chaque ticket.
Une boucle d'affinement peut sélectionner un nouveau ticket, l'étudier, améliorer sa spécification et ajouter des questions lorsque des informations manquent. Lorsqu'une décision humaine est requise, le ticket passe en état d'attente. Une personne répond quand elle est disponible, et la boucle reprend lorsque les informations apparaissent.
Une fois le ticket suffisamment clair, il passe en état prêt à être implémenté. La boucle d'implémentation le prend en charge et invoque le flux de travail d'ingénierie autonome.
Une boucle de relecture peut inspecter les retours sur la pull request, coordonner les corrections, relancer le flux de travail nécessaire et faire avancer la modification vers l'acceptation. Une boucle de finalisation peut fusionner le travail accepté, clore le ticket associé et permettre au prochain élément éligible d'entrer dans le système.
Les boucles n'ont pas besoin de communiquer directement entre elles. Elles se coordonnent via des états de backlog durables. Un ticket typique passe par un cycle de vie comme celui-ci :
Nouveau, En cours d'affinement, En attente de réponses, Prêt à implémenter, En cours d'implémentation, Pull request, En cours de relecture, Terminé.
Les humains peuvent entrer dans le processus chaque fois que la politique du projet l'exige, mais le système ne dépend pas de quelqu'un qui surveille en continu un terminal. Même lorsque le développeur est hors ligne, la VM continue de vérifier le backlog et de faire avancer le travail éligible.
C'est la distinction au cœur de l'ingénierie des boucles :
Les agents exécutent le travail. Les boucles décident quand le travail existe, quand il doit commencer, quel flux de travail doit l'exécuter et ce qui se passe ensuite.
Étape 6 : /plan-goal exécute un ticket de bout en bout
Lorsque la boucle d'implémentation trouve un ticket prêt, elle invoque /plan-goal.
Cette commande n'est pas responsable de la décision de la direction du produit ni de l'invention de l'architecture du projet. Ces décisions ont déjà été prises et encodées dans le dépôt. Sa responsabilité est d'exécuter un élément de travail suffisamment affiné au sein du système d'ingénierie existant.
/plan-goal lit le ticket, explore les parties pertinentes de la base de code, crée une proposition OpenSpec, génère des tâches structurées, identifie les lacunes de spécification ou de test, sélectionne les ingénieurs spécialisés appropriés, attribue les niveaux de modèle, calcule les dépendances et organise le travail d'implémentation en vagues d'exécution parallèles.
Les tâches qui sont indépendantes et modifient des zones distinctes du dépôt peuvent être attribuées à différents ingénieurs simultanément. Les tâches qui dépendent d'un travail antérieur ou touchent les mêmes fichiers sont exécutées dans l'ordre requis.
L'agent principal coordonne le travail, collecte chaque résultat, crée des commits ciblés, exécute les tests, le linting, la vérification de type et les builds. Il s'arrête plutôt que de livrer la modification lorsque la vérification ne peut pas être effectuée avec succès.
Lorsque l'implémentation est valide, la branche est poussée et une pull request est créée avec le contexte et les preuves nécessaires.
La politique de projet configurée détermine ensuite ce qui se passe. Un humain peut relire la pull request. Un autre système d'IA peut effectuer la relecture. Un projet hautement autonome peut fusionner automatiquement lorsque tous les contrôles requis sont passés. Dans d'autres projets, la décision finale reste explicitement humaine.
Cela révèle les deux couches d'orchestration du système. loop-task est la couche d'orchestration externe. Elle gère le cycle de vie du backlog et décide quand l'affinement, l'implémentation, la relecture ou la finalisation doivent avoir lieu. /plan-goal et les autres commandes opencode-onboard forment le flux de travail d'ingénierie interne. Ils comprennent comment explorer, planifier, attribuer, implémenter, vérifier et livrer une modification spécifique.
Un système qui survit à la conversation
L'une des limites du développement basé sur des invites est que trop d'état réside dans une conversation temporaire.
L'architecture doit être expliquée à nouveau. Les décisions précédentes sont oubliées. Une implémentation interrompue est difficile à reprendre. Un développeur doit rester présent pour décider ce que l'agent doit faire après chaque étape.
Ce flux de travail déplace cet état dans des systèmes durables. Le dépôt contient l'architecture, les règles de conception, les ingénieurs et les garde-fous. OpenSpec contient la modification planifiée et ses tâches. Git contient l'historique d'implémentation et les points de reprise. Le backlog contient l'état de livraison et les décisions humaines. La machine locale ou la VM fournit l'environnement persistant dans lequel les boucles continuent de s'exécuter.
Le résultat n'est pas un seul agent autonome qui tente de se comporter comme une organisation logicielle entière. C'est un système coordonné dans lequel différents composants ont des responsabilités différentes.
Les humains définissent la direction, les contraintes et les limites de responsabilité. Des agents spécialisés exécutent un travail d'ingénierie ciblé. Les boucles coordonnent le cycle de vie de manière asynchrone. Le backlog les relie.
Le changement le plus important n'est pas que les agents puissent générer plus de code. Le passage plus large va des interactions isolées avec l'IA vers des systèmes d'ingénierie persistants.
Au lieu d'expliquer le dépôt avant chaque tâche, le projet porte sa propre architecture et ses propres garde-fous. Au lieu de demander à un agent générique d'implémenter tout, le travail est attribué à des spécialistes. Au lieu de décider manuellement ce qui doit se passer après chaque étape, les boucles réagissent à des états de flux de travail durables. Au lieu de garder tout le processus à l'intérieur d'une conversation, la progression survit dans les tickets, les spécifications, les commits, les pull requests et l'état local.
Le rôle humain ne disparaît pas. Il se déplace vers la conception de l'environnement dans lequel l'exécution autonome est autorisée à opérer.
C'est le modèle que je suis en train de construire : un SDLC IA conçu par l'humain, où le développeur établit d'abord l'environnement d'ingénierie et les limites d'autonomie, puis des boucles asynchrones coordonnent des agents spécialisés à travers un cycle de vie de livraison piloté par le backlog.
Du zéro aux boucles qui tournent toutes seules. Six étapes, chacune construite sur la précédente, chacune déplaçant un peu plus d'état de la conversation vers des systèmes qui n'oublient pas.
PS : Vous pouvez trouver loop-task, opencode-onboard et le reste de ces outils sur ckgrafico.com
