Ce que les agents IA ne devraient jamais faire seuls

se concentre sur ce qu’ils peut faire.

L’autonomie est présentée comme un objectif : leur donner outilsdonne-leur accéderlaissez-les courir.

Plus il y a de liberté, meilleur est le rendement.

Ce cadrage est pour l’essentiel précis. J’utilise des agents quotidiennement. Ils ont véritablement augmenté ma production. Je suis croyant !

Et j’ai aussi perdu deux heures de travail à cause d’un agent qui faisait exactement ce que je demandais.

Je travaillais sur une fonctionnalité bifurquer nettoyage.

La description de la tâche indiquait « supprimez les fichiers inutilisés et nettoyez le dépôt ». L’agent a interprété « inutilisé » largementj’ai supprimé un répertoire de configuration que je n’avais pas touché depuis des mois mais toujours référencé dans le script de déploiement, et j’ai continué.

Je l’ai attrapé lors de l’examen des différences. La configuration n’était pas dans le contrôle de version. Deux heures pour le reconstruire à partir de la mémoire et de l’historique git.

La tâche était claire et l’agent suivait les instructions, le seul problème était que rien ne lui disait où aller. arrêt.

Savoir quelles sont les tâches à grille fait bien partie du bon fonctionnement des agents. Donnez-leur toute liberté sur la mauvaise catégorie et vous passerez l’après-midi à défaire ce qui leur a pris trente secondes.

---

Salut! Mon nom est Sara Nobrega et je vous apprends comment devenir un utilisateur expérimenté de l’IA sur Apprendre l’IA. Inscription gratuite !

---

Ce que l’agent ne doit jamais toucher seul

Certaines tâches sont réversible. Par exemple, une fonction refactorisée peut être annulée ou un nouveau test unitaire peut être supprimé. Le coût d’une erreur est faible.

Récupération coût varie selon tâche. Une fonction refactorisée prend quelques secondes pour revenir en arrière ; vous annulez simplement la validation, mais une table de production abandonnée peut prendre toute une semaine, si la récupération est même possible.

La question avant d’exécuter une tâche : est-ce possible défait?

Si oui, laissez l’agent bouger. Si non, ajoutez un point de contrôle avant son exécution.

Voici le matrice d’autorisation Je travaille de :

Les catégories qui devraient toujours nécessiter un humain

Certaines catégories nécessitent un point de contrôle humain quelle que soit la précision de la tâche.

Le risque d’un erreur est trop élevé et le récupération coût trop élevé pour laisser un agent décider seul.

1. Opérations de fichiers destructrices

`rm -rf`, `git clean -fd`, `git reset --hard`.

Ces supprimer ou jeter un travail qui n’est peut-être pas récupérable.

Un agent les exécutera si la description de la tâche implique un nettoyage.

J’ai eu une course `git clean -fd` au milieu d’un refactor parce que la tâche disait « nettoyer les fichiers temporaires ».

Mon travail non engagé avait disparu. Il n’y a eu aucun dysfonctionnement, car l’agent a fait exactement ce que les mots disaient. La sauvegarde est une liste de blocage explicite avec une étape de confirmation, ne faisant pas confiance à l’agent pour déduire où se termine le « nettoyage ».

2. Écritures et migrations de bases de données

N’importe lequel DELETE sans un WHERE clause, n’importe quelle DROP ou TRUNCATEtoute migration de schéma touchant production données.

UN faute de frappe dans un WHERE La clause peut effacer une table. Une migration dans le désordre peut corrompre des données impossibles à reconstruire. Vérifiez toujours avant de courir.

3. Infrastructure cloud

`terraform apply`, `kubectl delete`, `aws iam *`, `gcloud iam *`.

Infrastructure les changements affectent les systèmes en direct et souvent d’autres équipes. Les modifications d’autorisations sont particulièrement dangereuses car les dégâts peuvent être invisibles jusqu’à ce que quelque chose échoue.

4. Déploiements de production

N’importe lequel déploiement à un production L’environnement doit passer par une étape de révision humaine, même si le code a été généré par un agent.

Les pipelines CI/CD peuvent exécuter automatiquement la sortie de l’agent, et c’est très bien. La décision de déployer en production vous appartient.

Vous savez ce qui se passe en vol, quels incidents sont ouverts, quelle maintenance est programmée. L’agent n’a aucun de ces contextes et il ne peut pas le demander en cours de traitement.

5. Logique d’authentification et de sécurité

Flux d’authentification, règles d’autorisation, gestion des jetons, gestion des sessions.

Insectes ici, n’apparaissent pas dans les tests unitaires, ils apparaissent dans les rapports d’incidents, parfois des mois plus tard.

Un agent écrivant une logique d’authentification produira quelque chose qui semble correct et qui suit le bon chemin.

Les cas dangereux sont les conditions limites : un jeton qui n’expire pas sous une séquence spécifique d’appels d’API, une route qui contourne le middleware lorsqu’un paramètre est manquant.

C’est exactement ce que les tests unitaires manquent et ce que l’examen de sécurité détecte. Chaque changement d’authentification a besoin d’un humain qui recherche spécifiquement ces lacunes, et non d’un humain qui est satisfait que le chemin heureux soit parcouru.

6. Secrets, fichiers `.env`, clés API

Un agent lisant ou écrivant des informations d’identification crée une exposition risque. Gardez cette catégorie interdite par défaut et gérez-la manuellement.

git push --force se situe dans sa propre catégorie car il réécrit l’histoire sur la télécommande. Une fois poussées, les branches locales des autres contributeurs divergent. La guérison est douloureuse et parfois impossible.

Les humains doivent également faire attention à toutes ces commandes. Les agents facilitent simplement leur déclenchement par accident, enfouis dans une séquence plus longue d’étapes autrement sûres.

AGENTS.md : rédiger le contrat

Donner aux agents spécifique structure dès le départ. Un AGENTS.md Le fichier à la racine de votre dépôt indique à l’agent ce qu’est le projet, comment l’exécuter et ce qu’il n’est pas autorisé à toucher sans demander.

UN vague<strong> </strong>AGENTS.md vous obtenez un agent qui comble les lacunes avec des suppositions. J’ai appris cela sur une base de code qui n’avait aucun AGENTS.md.

La tâche consistait à « organiser la structure du projet ». L’agent déplaçait les fichiers entre des répertoires en fonction de conventions de dénomination qui lui paraissaient logiques. Tout ce qui faisait référence à ces chemins s’est brisé.

La tâche prenait vingt minutes à l’agent ; le nettoyage m’a pris deux heures. Trois lignes de contraintes de portée l’auraient complètement empêché.

Voici le modèle que j’utilise :

# AGENTS.md

## Project

[Brief description of the project and tech stack]

## Setup

\`\`\`bash

# Install

npm install  # or pip install -r requirements.txt

# Run

npm run dev

# Test

npm test

# Lint

npm run lint

\`\`\`

## Coding rules

- Make minimal changes. Don't refactor unrelated code.

- If behavior changes, add or update tests.

- Don't touch files outside the scope of the task.

- Keep diffs readable. One concern per commit.

## Safety rules

Ask before running any command in blocked_commands.md.

If you're unsure whether a command is safe, stop and ask.

## Definition of done

- Tests pass

- Diff is explainable in one sentence

- Final report provided (see below)

## Final report format

After every task, provide:

1. Summary of changes

2. Files changed

3. Tests run and result

4. Risks or assumptions

5. Anything not completed

```

Le fichier compagnon, blocked_commands.mdrépertorie exactement ce qui nécessite l’approbation humaine avant d’être exécuté :

# blocked_commands.md

## Destructive file operations

- rm -rf

- git clean -fd

- git reset --hard

## Git operations

- git push --force

- git push --force-with-lease

## Database operations

- DROP TABLE

- TRUNCATE TABLE

- DELETE without WHERE clause

- Any migration that alters a production schema

## Cloud / infrastructure

- terraform apply

- kubectl delete

- aws iam *

- gcloud iam *

## Secrets

- Any command reading or writing .env files

- Any command touching API keys or credentials

Quand le AGENTS.md est vague, devine l’agent. Lorsqu’il est précis, l’agent exécute, et le fichier constitue donc votre contrat. Écrivez-le avant de commencer la tâche, pas après une panne.

---

Vérifiez mes deux derniers articles où tu peux apprendre comment donner à votre IA un accès illimité contexte et explorez six points communs dur décisions Les ingénieurs en IA doivent travailler en production.

---

La boucle à deux agents

Pour tout ce qui est de complexité moyenne ou supérieure, n’utilisez pas un seul agent, utilisez-en deux.

L’agent 1 met en œuvre. Avis de l’agent 2. Ensuite, l’agent 1 applique uniquement les commentaires critiques.

Invite du responsable de la mise en œuvre:

You are a senior software engineer implementing a specific task.

Task: [describe the task]

Context: [link to AGENTS.md or paste relevant sections]

Rules:

- Make minimal changes.

- Stay in scope.

- Don't refactor unrelated code.

- Add tests if behavior changes.

- When done, provide a final report: summary, files changed,

  tests run, risks, anything incomplete.

Invite du réviseur :

You are a code reviewer with no attachment to the implementation.

Review this diff: [paste diff]

Check for:

- Bugs and edge cases

- Missing tests

- Security issues

- Unintended behavior changes

- Anything outside the stated scope

Output:

- Critical issues (must fix)

- Minor issues (optional)

- Anything you'd flag for a human

Do not rewrite the code. Flag, don't fix.

L’agent réviseur n’a aucun investissement d’ego dans le code. Il recherche les bogues, les cas extrêmes, la couverture des tests et les problèmes de sécurité sans essayer de refaire le travail.

La révision du code est la façon dont vous détectez ce que vous avez manqué. La boucle à deux agents est le même processus, automatisé.

Le rapport final

Exiger un rapport final pour chaque tâche d’agent :

1. Résumé des changements

2. Fichiers modifiés

3. Tests exécutés et résultat

4. Risques ou hypothèses

5. Tout ce qui n’est pas terminé

Cela rend l’agent responsable. S’il ne peut pas résumer ce qu’il a fait en termes clairs, c’est le signe que la tâche n’était pas propre.

Il crée également de la documentation sans que vous l’écriviez manuellement. Les rapports s’empilent. Lorsque quelque chose se brise une semaine plus tard, vous pouvez retracer exactement ce qui a changé et pourquoi.

Le travail peu glamour

Le battage médiatique autour des agents IA est là pour rester, et en grande partie mérité. Ils augmentent votre sortir.

Les praticiens qui en tirent le meilleur parti sont ceux qui ont effectué le travail de configuration : a écrit le AGENTS.mdréfléchi aux niveaux d’autorisation, construit la liste des commandes bloquées, mis en place la boucle à deux agents.

Les agents travaillent bien lorsqu’ils ont des instructions claires. Cette partie vous incombe.

Merci d’avoir lu!

---

Vous pouvez me trouver sur LinkedIn et Sous-pileoù je partage plus de détails sur l’IA et le LLM.