Un cycle d’agent de codage local : Aider, Ollama, les arbres de travail Git et un mécanisme de retrait facile.

Commencez par le chemin du retour et choisissez le modèle plus tard. Un agent de codage local gagne sa place lorsqu’il parvient à terminer une petite boucle bien définie : localiser un défaut, apporter une modification modeste, exécuter la vérification correspondante, et laisser un diff qui peut être commité ou jeté.

La pile conservatrice pour cette boucle suppose qu’un répertoire est déjà sous Git, avec une commande de test ciblée :

• Agent : Aider
• Durée d’exécution du modèle : Ollama, qui sert un modèle sur la machine locale
• Isolement : un worktree Git
• Recherche : rg, exécuté depuis la racine du répertoire
• Validation : n’importe quelle commande de test ciblée déjà présente dans le répertoire
• Récupération : git diff, suivi soit d’un commit, soit de git restore

Seuls l’agent et l’environnement d’exécution local sont nouveaux. Tout le reste relève des outils habituels de gestion de dépôts, et la configuration ne doit pas se transformer en une deuxième plateforme de développement.

Les rôles sont simples. Ollama sert le modèle. Aider fonctionne à l’intérieur d’un dépôt Git. Un worktree permet d’obtenir une copie propre de la tâche, généralement sur une branche dédiée, et git restore peut restituer des modifications non commitées dans des fichiers spécifiques. Ce modèle est délibérément restreint, conçu pour des travaux sur des dépôts qui doivent rester auditable et réversibles. Il ne s’agit pas d’un critère de référence, ni d’une affirmation selon laquelle ces outils surpassent systématiquement les alternatives. Les commandes, les noms des modèles et le comportement d’approbation varient également en fonction des versions installées et de la configuration locale.

Un cycle que quelqu’un peut examiner

La sortie de l’agent doit représenter une petite étape de progression que le développeur peut vérifier. Un accès large et non surveillé à une machine est l’opposé de cela.

La séquence :

1. Créer un arbre de travail isolé.
2. Identifier l’implémentation et son test existant.
3. Définir un résultat attendu ainsi que ses limites.
4. Demander un plan avant toute modification.
5. Approuver le plan ou l’affiner.
6. Lire la différence apportée.
7. Exécuter la vérification du projet.
8. Commiter ou restaurer les modifications.

Les contrôles importants sont de nature procédurale : rien n’est modifié avant l’approbation du plan, et aucune modification n’est conservée tant que la différence et le test n’ont pas été lus. On ne les qualifie de contrôles techniques que si l’agent installé et la configuration du hôte peuvent réellement les appliquer. La vitesse n’a de sens que lorsque les résultats restent faciles à vérifier et à annuler.

Un exemple : noms d’affichage vides

Imaginons un service TypeScript qui accepte des noms d’affichage vides, alors que l’API devrait les refuser. Le répertoire contient un fichier de test ciblé ainsi que des scripts npm pour la validation.

La tâche n’a pas pour but de nettoyer les validations. Elle est formulée comme suit :

Rejeter les noms d’affichage composés uniquement d’espaces, mettre à jour le fichier de test existant, conserver l’API publique inchangée, et exécuter le test ciblé.

Cela définit pour l’agent un comportement, des limites et une vérification.

Faire effectuer un contrôle distinct pour ce changement

A partir du processus de contrôle principal :

git worktree add -b fix/display-name-validation ../service-display-name-fix
cd ../service-display-name-fix

Un worktree est un deuxième répertoire de travail associé au même dépôt. La commande ci-dessus crée ../service-display-name-fix sur la branche fix/display-name-validation et laisse le répertoire principal disponible pour d’autres travaux.

Désormais, les modifications, les résultats des tests et le diff en attente restent séparés du répertoire principal. Si l’expérience s’avère inutile, ses fichiers peuvent être restaurés, ou le worktree supprimé après vérification de son état.

Trouver d’abord le code et les tests

Utilisez le vocabulaire propre au dépôt pour définir la portée :

rg -n "displayName|display name" src test

Supposons que la recherche renvoie :

src/users/validateProfile.ts
test/users/validateProfile.test.ts

La frontière est désormais claire. L’agent a besoin de ces deux fichiers ainsi que de la commande qui les valide, et une invitation vague à explorer l’ensemble du répertoire n’ajoute rien.

Démarrer Aider sur le modèle local Ollama

Au préalable, assurez-vous que Git, Aider, Ollama et rg sont installés, ainsi que que le runtime Ollama est disponible sur cette machine. Le modèle choisi doit également fonctionner avec les versions installées d’Aider et d’Ollama. Aider documente les fournisseurs Ollama : vérifiez que le modèle souhaité existe bien dans Ollama, puis lancez Aider depuis le répertoire de travail en utilisant le préfixe ollama_chat/ avant le nom du modèle.

ollama pull <installed-model>
aider --model ollama_chat/<installed-model>

Remplacez <installed-model> par l’élément que Ollama détient réellement. Le même élément apparaît dans les deux commandes, car Ollama sert ce modèle et Aider le sélectionne par son nom.

Aider peut suivre ses modifications via Git. Lancez-le dans le worktree, lisez la différence après chaque modification, et laissez la décision de commit entre les mains d’un humain.

Il inclut également des commandes en direct, une carte du répertoire, des options de configuration et des contrôles de limite de contexte. Ceux-ci aident à la navigation, mais aucun ne définit l’étendue du travail ni ne prouve que une correction est valide.

Faire du premier tour un plan

Restreignez le contexte de l’agent aux fichiers pertinents, en utilisant la méthode d’ajout de fichiers décrite pour la version d’Aider installée, et non le staging Git. Ensuite, fournissez une instruction contenant le résultat attendu, les chemins autorisés et une commande de validation :

Task: Fix whitespace-only display names being accepted.

Files in scope:
- src/users/validateProfile.ts
- test/users/validateProfile.test.tsConstraints:
- Preserve the public API.
- Do not edit generated files, lockfiles, deployment configuration, or unrelated tests.
- First, explain the current behavior, name the files you would change, and propose the smallest fix.
- Do not edit files until I approve the plan. Treat this as a required review step, and use any available approval controls in your local agent configuration to enforce it where possible.Validation:
- Run: npm test -- validateProfile
- Report the exact command run, files changed, test result, and any unresolved assumption.

Une telle demande permet d’éviter plusieurs échecs courants : des tâches qui prennent des proportions démesurées, des modifications effectuées en dehors des chemins prévus, ainsi que des correctifs pour lesquels il n’existe aucune méthode de validation clairement indiquée.

Réfuser rapidement les plans trop larges

Une bonne première réponse ressemble à ce plan :

1. Inspect src/users/validateProfile.ts to confirm how displayName is validated.
2. Inspect test/users/validateProfile.test.ts for the existing validation-test pattern.
3. Add a failing test for a whitespace-only displayName.
4. Make the smallest validation change required to reject that input.
5. Run npm test -- validateProfile.

Avant d’approuver toute modification, demandez :

• Le plan précise-t-il l’implémentation et les tests prévus ?
• S’agit-il uniquement d’un comportement spécifique ?
• Indique-t-il quelles modifications de validation il propose ?

Arrêtez-vous si le plan mentionne une migration de schéma, une installation de dépendance, une mise à jour d’un fichier de verrouillage ou des modifications d’extrémités non liées. Restreignez plutôt la tâche au lieu d’approuver une extension qui semble seulement raisonnable.

Le diff et le résultat du test constituent le produit final

Une fois le plan approuvé, répétez toujours la même séquence d’examen.

Consultez uniquement les fichiers convenus

git diff -- src/users/validateProfile.ts test/users/validateProfile.test.ts

Ici, le résultat attendu est un seul nouveau test pour une entrée vide, ainsi qu’un ajustement d’implémentation permettant de le satisfaire. La forme exacte de cet ajustement dépend du contrat de validation existant dans le répertoire, il convient donc de vérifier que seules les entrées complètement vides après suppression des espaces en trop sont rejetées et que les noms d’affichage valides passent sans modification.

Recherchez ce qu’un résumé de session peut cacher :

• l’API publique modifiée bien que la consigne l’interdise
• des fichiers modifiés en dehors de la liste prévue
• un reformatage sans rapport avec le bug
• un nouveau test qui passe sans jamais reproduire le comportement cible
• un ajustement de validation qui rejette également des noms légitimes

Le diff et le résultat du test constituent les éléments à livrer. Le résumé fourni par l’agent sert de guide pour la lecture, mais il ne prouve rien quant à la correction.

Exécuter la vérification ciblée

<repository-focused-test-command>

Remplacez le symbole de remplacement par la syntaxe de commande et de sélection de fichier réellement utilisée dans le dépôt.

Aider peut analyser et tester automatiquement après les modifications de code. Cela peut raccourcir les cycles de retour d’information, mais la commande propre au dépôt reste la source officielle.

Conserver ou supprimer délibérément la modification

Si le diff et le résultat du test semblent corrects :

git status
git add src/users/validateProfile.ts test/users/validateProfile.test.ts
git commit -m "Reject whitespace-only display names"

S’ils ne le font pas :

git restore src/users/validateProfile.ts test/users/validateProfile.test.ts

En l’absence de source indiquée, git restore restaure les deux fichiers nommés depuis HEAD, en supprimant uniquement les modifications non commitées sur ces fichiers. Vérifiez git status pour connaître les changements mis en stage, les fichiers non suivis ou d’autres modifications avant de considérer l’expérience comme abandonnée.

Lorsque toute la branche est jugée inutilisable, supprimez le worktree une fois son état vérifié et tout ce qui mérite d’être conservé enregistré :

git worktree remove ../service-display-name-fix

Git gère les répertoires de travail liés à l’aide de ses commandes worktree. La récupération constitue une procédure normale, et c’est ce qui permet de répéter en toute sécurité des expériences menées par un petit agent.

Limites : système de fichiers, permissions, contexte

Démarrage depuis la racine du répertoire de dépôt

Exécutez l’agent dans le répertoire du projet ou dans son worktree dédié. Partir d’un répertoire personnel en espérant que l’invite de commande imposera des limites ne fonctionne pas.

Le répertoire de travail fournit une portée par défaut, mais il ne met rien en œuvre pour la faire respecter. Ce à quoi l’agent peut réellement accéder est déterminé par les permissions du système d’exploitation, les paramètres de l’outil ainsi que par le sandbox en place.

Autoriser délibérément les effets secondaires

Les écritures de fichiers, l’installation de dépendances, l’accès aux identifiants, l’utilisation du réseau ainsi que les modifications de l’infrastructure doivent toutes faire l’objet d’une approbation délibérée. Lorsque l’agent ou l’hôte ne peut pas en assurer le contrôle, considérez cela comme une étape d’examen manuel et ne le présentez pas comme un mécanisme de contrôle technique. Vérifiez quels contrôles existent avant de vous y fier.

OWASP cite l’injection de commandes comme un risque pouvant amener une application utilisant des LLM à effectuer des actions indésirables ou à divulguer des informations.

Un point de référence pratique :

• Permettre la lecture des fichiers uniquement dans le répertoire prévu.
• Exiger une approbation avant toute écriture.
• Exiger une approbation avant l’exécution de commandes shell ayant des effets secondaires.
• rendre l’accès au réseau facultatif.
• conserver les secrets en dehors du contexte normal de l’agent.

Cela permet de limiter l’impact potentiel. Il n’y a aucune évaluation quant à la fiabilité de l’agent.

Conservez une configuration simple et visible

Aider lit les configurations YAML, les fichiers d’environnement et les paramètres de clé API. La configuration des projets partagés doit être visible, minimale et séparée des secrets ; les identifiants ne doivent en aucun cas figurer dans un fichier d’instructions de répertoire. Il est préférable d’éviter les piles de paramètres par défaut globaux que personne ne peut examiner ni expliquer ultérieurement.

Fournir le contexte nécessaire à la tâche

La carte du répertoire aide Aider à comprendre la structure du codebase, tandis que le contexte limite la quantité d’informations pouvant être traitées dans une seule demande. Pour une correction ciblée, fournissez la tâche, les fichiers pertinents, la commande de validation ainsi que toutes les règles du projet applicables au changement. Inclure des fichiers générés, tous les documents ou des commits anciens et non liés ajoute principalement du désordre.

Un contrat de projet pour les travaux récurrents

Lorsque le même flux de travail se reproduit à plusieurs reprises, stockez un fichier d’instructions enregistré, une prompt réutilisable ou un modèle de tâche à côté du code :

Project contract

Goal:
- [Describe one bounded outcome.]Scope:
- You may edit: [paths]
- Do not edit: [paths, generated files, secrets, deployment configuration]Conventions:
- Follow: [formatter, naming, architecture rules]
- Preserve: [public APIs, compatibility constraints]Validation:
- Run: [exact test, lint, type-check, or build command]
- Report: commands run, files changed, failures, and unresolved assumptionsDefinition of done:
- The requested behavior is implemented.
- Relevant checks have run, or the reason they could not run is stated.
- The final response summarizes the diff and any follow-up work.

Le format n’a pas d’importance. Ce qui compte, c’est que les contraintes soient visibles.

Modes de défaillance et prochaines étapes à petite échelle

Recherche trop large. Arrêtez, raccourcissez la liste de fichiers et recommencez en utilisant des chemins ou des symboles issus d’une recherche effectuée manuellement.

Proposition de refacteurisation trop ambitieuse. Divisez la demande en points testables. Un seul test qui échoue, un seul comportement ou une seule frontière de refacteurisation valent mieux qu’une exigence architecturale globale.

Modifications en dehors du périmètre. Rejetez le correctif, restaurez les fichiers non concernés et indiquez les chemins interdits dans la prochaine demande.

Demande de commande non sécurisée. Demandez ce que cela change et pourquoi c’est nécessaire avant d’approuver.

Vérification qui échoue. Demandez un diagnostic avant d’autoriser davantage de modifications, et exigez que soit indiqué l’échec, sa cause probable ainsi que la prochaine expérience à petite échelle.

Inference locale lente. Réduisez d’abord la tâche et le contexte. Évaluez un autre modèle ou une autre configuration de temps d’exécution uniquement par la suite. Aucune comparaison de performances n’est effectuée ici, et toute comparaison ultérieure doit enregistrer la latence mesurée, le modèle, le temps d’exécution et le matériel.

Un agent plus rapide qui génère des différences plus importantes et plus difficiles à examiner n’améliore pas le flux de travail.

Ajustez une chose à la fois

Lorsque la recherche, la planification, les comparaisons de différences, les tests et le rétablissement se comportent de manière prévisible, ajustez une seule variable par étape. Modifiez le modèle si la qualité de sortie constitue le goulot d’étranglement. Modifiez la stratégie de contexte si du code pertinent continue d’être ignoré. Assouplissez les paramètres par défaut d’approbation uniquement après que plusieurs tâches petites et bien délimitées aient montré que le prompt ne protégeait en réalité rien, et même dans ce cas, conservez les différences, les tests et la possibilité de revenir en arrière. Ajoutez l’automatisation en dernier, une fois que la commande de validation peut être considérée comme fiable.

La configuration d’Aider est sensible à la version, il convient donc de vérifier ses pages de configuration et d’historique des mises à jour avant de l’utiliser à nouveau. Comparez chaque commande, identifiant de modèle et option de configuration avec les versions d’Aider et d’Ollama réellement installées sur la machine concernée.

La règle de décision est simple : conserver un outil ou une configuration uniquement s’il améliore l’achèvement des tâches, la reproductibilité ou la capacité de récupération.