Déléguer à l'aveugle

Mardi matin. J’écris un prompt. L’architecture de la DB, les contraintes de perf, le parcours utilisateur, deux ou trois décisions passées qui expliquent pourquoi le code est comme ça. Enter. La machine renvoie 200 lignes. Je review, j’ajuste, je merge.

Au milieu du diff, un truc me frappe. Je ne suis pas en train de coder. Je suis en train de déléguer.

Vingt ans que je suis du côté du comment. Dev, lead, CTO. Les rôles changent, le territoire reste le même. Quelqu’un pose le problème, je trouve comment le résoudre. Même quand j’ai arrêté d’écrire le code moi-même, c’était encore mon monde. Et là, pour la première fois, je délègue le comment à quelque chose qui n’est pas un humain. Qui ne connaît pas le produit, ne connaît pas l’équipe, ne connaît rien d’autre que ce que je mets dans le prompt.

Personne ne m’a appris à faire ça.

Quelqu’un sait, par contre. C’est littéralement son métier.

Un bon PM ne code pas. Ne dicte pas l’implémentation. Pose le pourquoi, le pour qui, les contraintes. Et lâche. Fait confiance à l’équipe pour trouver le comment. Toute la littérature PM tourne autour de cette idée : déléguer l’exécution sans la dicter.

Context, not control. Ne dis pas aux gens quoi faire. Donne-leur assez de contexte pour qu’ils décident bien tout seuls. La stratégie, les contraintes, les erreurs déjà faites. Pas un script. Un cadre.

Un PM fait ça tous les jours. Avec des humains, avec des équipes. Et maintenant, certains le font avec une machine.

Le PM qui délègue à un LLM fait ce qu’il a toujours fait. Il cadre. Le parcours utilisateur·ice, les frustrations, le ton, les contraintes business. La machine produit des flows justes. Des messages qui parlent à quelqu’un. Des empty states chaleureux.

Le cache n’expire jamais. L’API renvoie tout en une requête. Pas d’index.

Le dev qui délègue à un LLM donne autre chose. La structure de la DB, les patterns de l’app, les contraintes de perf. La machine produit du code solide. Bien architecturé. Résilient.

L’état vide affiche “Aucun résultat.” Le tri par défaut est alphabétique. Le message d’erreur parle à personne.

Chacun donne ce qu’il sait. La machine comble le reste avec des défauts. Le PM obtient le bon comportement dans du mauvais code. Le dev obtient du bon code autour d’un produit qui ne comprend pas ses utilisateur·ices.

Chacun est expert de la moitié du problème.

Honnêtement, je n’ai pas de PM dans mon équipe qui ship du code avec un LLM. J’observe de loin. Des posts LinkedIn, des conversations, des démos. Des PM fiers de shipper seuls. Des devs qui promptent comme ils coderaient, ligne par ligne. Tout le monde cherche à supprimer un layer.

Chacun·e pense avoir donné le contexte. Personne ne donne le tout. Des gens capables de donner les deux en même temps, j’en vois peu.

Peut-être que l’asymétrie montre le contraire de ce que LinkedIn raconte. Peut-être qu’enlever une moitié ne rend pas l’autre plus complète, ça rend juste la machine plus aveugle.

Le PM n’écrit plus un ticket, il écrit du contexte produit pour la machine. Le dev n’écrit plus du code, il cadre la machine et corrige ce qu’elle invente. Les rôles changent de surface. Ils ne disparaissent pas.

Et même comme ça, est-ce qu’on a seulement les outils pour transmettre le contexte complet ?

Quand on onboarde un·e développeur·euse, on lui donne du contexte pendant des semaines. Le domaine, les décisions passées, les cicatrices. Du shadowing avec les utilisateur·ices. Des années de méthodologies pour s’assurer que le code reflète le besoin réel. Pour la machine, on a un CLAUDE.md et quelques pages de docs.

L’écart est énorme. Et j’ai pas encore l’impression qu’on sache le combler.

(En attendant, je continue à écrire des prompts de trois paragraphes en espérant que ça suffise. 🙃)