Votre assistant de programmation IA n'a pas besoin que vous le surveilliez

Vous avez remarqué quelque chose d'étrange dans la façon dont on utilise l'IA pour coder aujourd'hui ?

Vous ouvrez un terminal, tapez une instruction, puis fixez l'écran en regardant la sortie s'afficher ligne par ligne. Quand c'est fini, vous jetez un œil au résultat et tapez la suivante. Si vous allez chercher un café entre-temps, vous revenez pour découvrir que c'est terminé depuis longtemps et que ça vous attend. Ou pire — ça a dévié, et comme vous ne surveilliez pas, ça a modifié des fichiers qu'il ne fallait pas toucher.

C'est un modèle d'interaction synchrone. Vous et l'IA parlez à tour de rôle, un échange à la fois, personne ne peut partir.

Mais programmer n'a jamais fonctionné comme ça.

Votre façon de travailler n'est pas synchrone

Repensez à votre façon habituelle de travailler. Vous avez probablement trois revues de PR ouvertes simultanément, vous attendez que la CI finisse, vous répondez à des messages Slack entre-temps, et vous passez occasionnellement sur une autre branche pour un hotfix. Votre attention saute entre plusieurs tâches plutôt que de se fixer sur une seule.

Mais quand vous utilisez un assistant de programmation IA, vous êtes forcé de devenir une personne synchrone. Vous devez rester assis devant l'ordinateur, regarder l'IA travailler, attendre ses questions et répondre immédiatement. Si vous êtes en réunion, l'IA attend. Si vous faites la navette, c'est totalement inutilisable.

Ce n'est pas un problème de l'IA. C'est un problème de modèle d'interaction.

Et si vous pouviez lui dire à l'avance quoi faire

Imaginez un scénario différent.

Vous arrivez au bureau le matin, sortez votre téléphone et en cinq minutes, vous listez ce que l'IA doit faire aujourd'hui : d'abord, refactoriser la validation du formulaire de connexion ; ensuite, uniformiser la gestion des erreurs API dans le nouveau format ; enfin, lancer la suite de tests pour voir si quelque chose est cassé.

Trois tâches, en file d'attente, envoyées. Puis vous allez au standup.

Au milieu du standup, votre téléphone vibre. Une notification vous dit que la première tâche est terminée. Vous y jetez un œil — ça a l'air bien, la deuxième a déjà commencé automatiquement.

Après le standup, vous vérifiez votre téléphone. La deuxième est terminée aussi, mais la troisième a rencontré deux tests en échec et l'IA s'est arrêtée en attendant votre confirmation. Vous regardez la cause — le comportement attendu a changé — et lui dites de mettre à jour les assertions. Le téléphone retourne dans la poche.

Avant le déjeuner, les trois tâches sont terminées. Vous ne vous êtes même pas assis devant l'ordinateur de toute la matinée.

Ce n'est pas de l'automatisation — c'est de la délégation

Il y a une distinction importante ici.

L'automatisation signifie définir des règles que la machine exécute exactement, sans jugement. CI/CD, c'est de l'automatisation. Le lint, c'est de l'automatisation.

Mais l'IA qui écrit du code n'est pas de l'automatisation — elle doit exercer son jugement, et son jugement n'est pas toujours juste. Donc vous ne pouvez pas totalement lâcher prise, mais vous n'avez pas non plus besoin de surveiller chaque seconde.

Le modèle plus approprié est la délégation : vous lui dites quoi faire, elle le fait, revient quand quelque chose est incertain, et vous dit le résultat quand c'est fini. Exactement comme confier une tâche à un collègue fiable.

Pour que ce modèle fonctionne, il faut plusieurs choses :

Pouvoir planifier à l'avance. Pas une instruction à la fois, mais plusieurs tâches en file d'attente d'un coup.

Pouvoir corriger le cap en cours de route. Si vous remarquez que l'IA va dans une direction légèrement fausse, vous devriez pouvoir dire « change de direction » sans annuler et recommencer.

Pouvoir voir le plan de l'IA avant qu'elle n'agisse. Surtout pour les gros changements — vous ne voulez pas que l'IA se lance sans prévenir.

Pouvoir savoir ce qui se passe sans être devant l'écran. Tâche terminée, erreur, décision nécessaire — ces informations doivent venir à vous.

Le téléphone est un panneau de contrôle asynchrone naturel

Pourquoi le téléphone ?

Parce que le téléphone est déjà votre appareil pour gérer l'information asynchrone. E-mails, messages, rappels — vous ne les fixez pas constamment, mais ils vous préviennent quand c'est nécessaire. Un assistant de programmation IA devrait fonctionner de la même manière.

L'interaction synchrone ne disparaît pas

Je ne dis pas que le mode synchrone est inutile. Pour un débogage approfondi, pour discuter d'approches avec l'IA, ou pour un travail exploratoire nécessitant un feedback immédiat, le mode synchrone reste le meilleur choix.

Mais tout le travail de programmation ne requiert pas un engagement profond. Souvent, vous savez exactement ce qu'il faut faire — c'est juste fastidieux à exécuter. Ces tâches n'ont pas besoin que vous surveilliez l'IA. Vous avez juste besoin de savoir que c'est fait, et bien fait.

Le mode asynchrone comble cette pièce du puzzle.

C'est ce que fait la version 1.6.5

Les nouvelles fonctionnalités de Tactic Remote 1.6.5 — mode plan, file de prompts, redirection, notifications push — ne sont pas des fonctionnalités indépendantes. Ce sont différentes facettes de la même idée : vous permettre de contrôler votre assistant de programmation IA de manière asynchrone.

Mettez en file d'attente, consultez le plan, confirmez l'exécution, recevez la notification. Puis allez faire quelque chose de plus important.

Votre assistant de programmation IA n'a pas besoin que vous le surveilliez. Il a juste besoin de pouvoir vous joindre quand ça compte.