À force de sur-déléguer à l'IA, on tue son propre poste

J'aime beaucoup cet article AI Is Breaking This Thing We Call Trust.

En bref, quand quelqu'un t'envoie un PR ou une doc, tu ne pars plus du principe qu'il a compris ce qu'il produit. Tu te demandes d'abord s'il assume vraiment ce qu'il envoie.

Si on pousse un cran plus loin, le vrai risque, pour un développeur, ce n'est pas que l'IA écrive du code.

C'est de se vider de ce qui justifie encore sa place.

Tu ne portes pas la trajectoire produit. C'est le Product Owner. Tu n'écris plus vraiment le code. C'est l'IA. Tu ne le reviewes pas vraiment non plus. C'est le lead.

À ce stade, ta valeur ajoutée est moindre que celle d'un agent.

La sur-délégation a un côté confortable. Tu livres plus vite. Tu as l'air productif. Le ticket passe.

Mais tu te retires progressivement du jeu : moins de compréhension, moins de jugement, moins de responsabilité. Et un jour, la question n'est plus "est-ce que l'IA peut faire mon travail ?" Elle devient "qu'est-ce que j'apporte encore que l'IA ne fait pas déjà ?"

La confiance dont parle l'article, c'est le symptôme. Le fond, c'est le dev qui scie la branche sur laquelle il est assis.

Si tu veux rester pertinent, il faut garder la main sur au moins une chose difficile : le produit, le code, l'architecture, la revue. Idéalement plusieurs d'entre elles, à des doses variables. Mais pas zéro.

Sinon tu n'es plus un développeur. Tu es un intermédiaire entre un ticket et un LLM.

Spoiler : le métier de prompt engineer dont tout le monde parlait il y a 3 ans et demi n'existera finalement pas.