Autoriser le travail sans approbations
Les trois degrés entre « demander pour tout » et « ne demander pour rien », comment le bypass s'active et ce qu'on y gagne et y perd.
Par défaut l'Agent demande avant d'écrire dans un fichier ou de lancer une commande. Sur le téléphone cela se traduit par un travail à l'arrêt, qui attend votre appui. C'est voulu — mais il y a des situations où cela gêne plus que cela n'aide.
Trois degrés, pas deux
Entre « demander pour tout » et « ne demander pour rien » il y a encore un degré, qu'on néglige souvent :
- Demander chaque fois
- L'état par défaut. Chaque écriture et chaque commande attend une autorisation. Le plus sûr et le plus lent.
- Autorisation permanente pour un type d'action
- Quand l'Agent demande une autorisation, vous pouvez choisir qu'il ne demande plus pour ce genre d'action. Cela vaut pour ce genre, pas pour tout — l'exécution des tests, vous l'expédiez, la suppression de fichiers non. On peut la retirer à tout moment dans les Réglages.
- Sans approbations (bypass)
- L'Agent ne demande pas du tout. Cela s'active dans la configuration du Serveur, pas depuis le téléphone — une décision consciente à l'ordinateur, pas un appui dans le tram.
Comment activer le bypass
Dans le fichier de configuration du Serveur, celui que vous lui passez via --config:
{
"no_approvals": true
}Cela vaut à partir du prochain démarrage du Serveur. Le téléphone s'en aperçoit tout seul — il cesse de demander.
Ce que vous y gagnez
- Les tâches longues arrivent au bout sans vous. C'est justement le cas où vous confiez du travail et vous partez — avec une question après chaque commande, l'Agent attendrait que vous regardiez.
- Les tests, le formatage et le build passent d'une traite, au lieu de s'arrêter à chaque étape.
- Moins d'appuis sur le téléphone pour des choses que vous autoriseriez toujours de toute façon.
Ce que vous y perdez
- Le frein. L'Agent tourne avec vos droits et, sans approbations, il peut faire sur l'ordinateur tout ce que vous pourriez faire depuis la ligne de commande.
- L'instant de réflexion. La question « puis-je lancer cette commande ? » est souvent l'endroit où vous remarquez que l'Agent a compris la consigne autrement que vous ne le pensiez.
- La vue d'ensemble de ce qui se prépare. Vous voyez toujours les étapes, mais déjà faites, pas comme une proposition.
Quand l'activer et quand non
Activez-le dans un projet qui est en gestion de versions et dont la perte ne vous ferait pas mal — votre propre expérience, un prototype réécrivable, un projet qu'on peut jeter et recloner. Là le bypass est exactement ce qui fait de coden un outil devant lequel vous n'avez pas à rester assis.
Ne l'activez pas là où l'Agent touche à des données de production, déploie, ou travaille dans un répertoire où se trouvent des choses qui n'existent nulle part ailleurs. La frontière entre cela et le paragraphe précédent n'est pas technique, mais la vôtre.
Un compromis pratique : bypass activé, le projet dans git et un commit avant chaque consigne d'ampleur. Revenir en arrière se fait alors d'une commande — et c'est moins cher que d'approuver chaque étape.
Ça a coincé ailleurs que ce qui est ici ? Écrivez à support@coden-app.com.