Ajouter une fonction ou corriger un défaut suit en général le même chemin : ouvrir l'éditeur, trouver le fichier, modifier, lancer les tests. Pour qui travaille toute la journée dans un terminal, ce chemin a une couture gênante au milieu. La conversation avec l'assistant se tient dans une fenêtre, le コード réside dans une autre, et le va-et-vient coûte plus d'attention que les deux tâches n'en méritent.

Aider déplace la conversation dans le terminal. On entre dans le dossier du projet, on lance l'outil, puis on décrit ce qu'on veut comme on le décrirait à un collègue : ajouter une vérification des paramètres à cette fonction, extraire la logique commune de ces trois classes. Il lit le コード, modifie les fichiers, lance les tests et termine, sans que l'éditeur apparaisse jamais. Des dizaines de milliers de personnes qui le suivent et des millions d'installations suggèrent que la couture valait la peine d'être retirée.

Chaque changement est validé, revenir coûte une commande

Le choix de conception auquel on s'attache est simple : chaque modification apportée au dépôt est validée dans la gestion de versions avec un message écrit. L'état du コード avant et son état après reposent tous deux dans l'historique. Il existe donc toujours un chemin de retour propre. Si un changement est mauvais, les outils habituels montrent la différence et l'annulent, et plus personne ne discute des fichiers touchés.

L'auteur a porté ce principe à travers tout le projet, ce qui explique une bonne part de sa réputation chez les développeurs. C'est aussi un petit morceau de discipline qui change la psychologie du travail : confier une tâche à un エージェント cesse de ressembler à un pari et commence à ressembler à une branche.

Une carte avant de toucher à quoi que ce soit

Face à un gros dépôt, l'outil analyse d'abord l'ensemble avec un analyseur de syntaxe et en produit une carte : quels fichiers, quelles classes, quelles fonctions, et comment elles s'appellent mutuellement. Tout le コード n'est pas remis au modèle. Le modèle voit d'abord la charpente du projet, puis choisit précisément les fichiers dont il a besoin.

Voilà ce qui rend les grands projets praticables plutôt que théoriques. Un second mode sépare la réflexion de l'exécution : un modèle plus fort planifie le changement, un modèle plus rapide exécute le plan. De la qualité là où le jugement est nécessaire, de la vitesse là où il ne l'est pas, et un coût qui reste proportionné à la difficulté.

N'importe quel modèle, et plus de cent langages

Aucun fournisseur n'est privilégié. Des modèles commerciaux se raccordent, ou bien un modèle tournant sur votre machine, auquel cas le コード ne la quitte jamais. Les recommandations des mainteneurs incluent des combinaisons choisies pour le rapport qualité-prix plutôt que pour la notoriété, position qui devrait aller de soi et qui est rare.

Côté langages, la couverture dépasse la centaine, des langages de スクリプト et de système évidents à ceux qu'on emploie dans les arrière-plans web et les systèmes d'entreprise anciens. Vérification et test font partie de la même boucle : l'outil lance lui-même le vérificateur et la campagne de tests et répare ce qu'il trouve avant de rendre le travail. On peut même énoncer la demande à voix haute et la faire écrire, ce qui ressemble à un gadget jusqu'à la troisième utilisation.

Construit avec lui-même

Le détail qui convainc les sceptiques tient à la façon de développer : le projet s'auto-héberge. L'auteur a écrit environ quatre-vingt-huit pour cent de l'outil avec l'outil, et plus de trois mille validations de l'historique portent une ligne de coauteur qui le désigne. Un outil utilisé à ce point sur lui-même avance un argument de qualité qu'aucun comparatif n'égale, et qui en doute n'a qu'à lire l'historique.

Le projet est entièrement libre sous une licence permissive et ne facture rien pour lui-même ; vous ne payez que les appels au modèle réellement effectués. Il gère aussi le cas d'un modèle qui n'existe que dans une fenêtre de navigateur, supprimant le copier-coller que cette disposition imposait auparavant.

À qui cela s'adresse

Les développeurs qui vivent déjà dans un terminal et trouvent le passage à l'éditeur pénible en tireront le plus, mais l'attrait est plus large. Ce qu'Aider offre vraiment est une manière de travailler où chaque essai est enregistré, chaque erreur réversible, et où le modèle est un participant du dépôt plutôt qu'une fenêtre de discussion à côté. C'est une différence étonnamment grande pour un si petit déplacement.