Personne ne monte dans un avion piloté par Claude

Bon, faut que vous raconte.

Je me rappelle la première fois où j'ai eu honte d'avoir codé une feature à Claude.

En gros, la feature, elle était quand même assez complexe.

Et je l'avais fait vite.

Franchement, Claude, il me l'avait pondu en...

Je sais pas, 20 minutes peut-être.

Ça m'aurait dû me prendre 8 heures de le coder.

Et...

Côté usateur c'était une fusée elle marchait bien, franchement les gens étaient bien et sous la gêne moi j'ai dit voilà c'est pas moi c'est Claude qui l'a codé quoi et je me

rappelle que les gens ils étaient déçus.

je pensais que t'étais un hacker de la nuit et que t'avais tout codé toi-même.

Mais en vrai le vrai sujet il est pas là, le vrai sujet c'est qu'en fait au moment où je dis que c'est pas moi qui l'ai codé, le moment où je dis que c'est Claude qui l'a codé, la

confiance elle se déplace.

Avant les gens ils faisaient confiance à la feature parce qu'ils pensaient que je l'avais faite moi-même et j'avais regardé tout le code Maintenant si elle pète en prod il a un

truc qui casse on va dire c'est Claude qui foiré quoi Le problème c'est pas...

Le problème c'est que les gens faisaient confiance à un code produit par un humain les gens faisaient confiance à moi quand je codais mes features mais maintenant en fait les

gens font pas confiance à Claude personne monte dans un avion

Si c'est Claude le pilote, à la limite, s'il a un pilote, un vrai pilote à côté, qui est prêt à reprendre le guidon, je sais pas si c'est un volant ou un guidon dans un avion,

mais voilà, est à reprendre le pilotage à tout moment, ils veulent bien faire confiance à peu près, et encore ils préfèrent être un humain qui pilote tout le temps, mais la

confiance, Claude c'est un tueur de confiance quoi.

Et le problème c'est qu'aujourd'hui Claude il produit plus de codes qu'il ne produit de confiance.

Bon on est reparti dans cet épisode là.

Dans cet épisode je me réponds à moi du passé.

qu'il y a 2-3 mois j'avais fait un épisode qui disait que ce métier est devenu chiant.

Et cet épisode d'ailleurs vous l'avez beaucoup écouté, le temps d'écoute il est pas mal.

Vous êtes à plusieurs centaines d'heures de temps de cerveau perdu dessus.

Donc c'est que l'épisode vous a fait réfléchir et ça me fait plaisir.

ça reste un épisode qui est vraiment noir, franchement je suis un peu déprimé sur le truc, assez négatif.

Et dedans je disais grosso modo que ce qui me fatiguait c'était...

Enfin, qu'en gros avant quand je faisais du code, les tests qui passent au vert, les commits qui passent, le fait de tester la feature en prod etc.

Alors tout ça c'était vraiment beaucoup de dopamine, la boucle de feedback elle était rapide et je travaillais ma développeur experience pour avoir une bonne boucle de

feedback.

Et tout ça, me donnait la dopamine qui continuait.

Aujourd'hui, finalement, c'est Claude qui a tout ce plaisir-là.

Et moi, finalement, je fais que tenir mon code devant les gens.

Donc du coup, fait, finalement, Claude, va...

J'avais l'impression que Claude avait pris tout ce que je kiffais dans le job.

Mais en vrai, il a un twist dans cette histoire.

c'est que, enfin moi vous savez que ça fait 10, 15 ans que je ne plus vraiment développeur au quotidien, je code sur des sites project, je travaille avec des développeurs au

quotidien et je ne plus un full time dev parce que ce qui ne me plaisait pas dans mon job à l'époque c'était de 1, de justifier mon temps H24 de pourquoi j'ai pris du temps pour

faire cette feature là de 2, le job qui est enfin ce qui me et encore en freelance c'était quand même beaucoup moins chiant ça parce que en vrai si j'avais pris du temps sur un truc

c'était juste ok, écoute je ne te facture pas la journée on va faire autre chose avec le budget quoi

Mais c'est surtout que je passais beaucoup moins de temps à parler avec des gens quoi.

Et alors ça en freelance c'était encore pire parce que pour le coup quand j'étais en agence ou en boîte j'avais des devs autour de moi avec qui on pouvait parler, on pouvait

parler de notre code et de ce qu'on avait fait avec notre code.

En freelance, si je sortais pas trois soirs par semaine pour aller voir des meet-ups c'était compliqué parce que j'avais souvent passé 40 heures de ma journée, enfin 40 heures

de ma semaine, si c'est pas 50 ou 60 en plus à l'époque je travaillais beaucoup, je me levais à 4 heures du matin pour bosser.

Tout ça face à mon IDE tout seul, franchement ça c'était vraiment déprimant pour moi à l'époque.

Et je voulais passer du temps avec les autres.

Et le métier de journaliste, ou du moins mon aventure avec We Love Death, ça m'a permis de passer plus de temps à m'intéresser aux autres, à comprendre comment ils font leur métier,

sortir de ma bulle, etc.

Et aujourd'hui, c'est ça qui me fascine, enfin c'est ça qui me motive à continuer à faire le job, même si je le fais autrement qu'avec We Love Death.

C'est parce qu'en fait, ça m'intéresse de savoir comment les gens font, parce qu'il a vraiment beaucoup de diversité, tout monde a des raisons de le faire, etc.

Et c'est hyper intéressant, quoi.

Et puis là on se rend compte aussi quand on fait ça, quand on travaille, on du travail de qualité avec les gens que le standard de l'industrie, ça va pas.

Il a vraiment juste des gens dans des situations précises qui font des choses de manière précise avec une raison de pourquoi.

Et l'argument des décideurs ou des managers quand ils disent oui, tout le industrie fait comme ça, on devrait faire pareil.

Moi, moi me bute toujours parce qu'en fait, il n'est pas explicable, n'est pas discutable, il n'est pas négociable.

Il faut comprendre pourquoi l'industrie fait comme ça.

pour pouvoir dire, bah nous on est dans le même cas que l'industrie donc on va faire pareil quoi.

Mais si on se cale juste sur tout monde fait comme ça, on faire pareil.

Après c'est une économie de choix, c'est une économie de décision, c'est vrai que je l'ai fait beaucoup à certains moments,

Bref, et là récemment, vous avez vu le podcast donc, si vous suivez Pragmatic Engineering, c'est un podcasteur, un newsletter, un auteur, un influenceur tech américain et il reçoit

Kent Beck, alors c'est un peu un régulier pour lui de reçoire Kent Beck, il le reçoit un peu tous les ans, tous les deux ans, sur un gros podcast de fond d'ailleurs, donc c'est un

podcast qui dure une heure et demie et il fait beaucoup de contenu écrit autour de ça, donc des synthèses, etc.

Et le passage qui me percute, vraiment, c'est un passage...

où il parle de ce sujet de la confiance.

Alors si vous connaissez pas Ken Beck, c'est pas un d'influenceur LinkedIn qui sort de là, c'est le mec qui a formalisé l'XP.

D'ailleurs, il explique dans le podcast que c'est pas lui, enfin il a pas inventé l'extrême programming, il a plus l'impression d'avoir pris le temps de formaliser quelque

chose qui était une pratique autour de lui et qu'il avait pris le temps de diffuser quoi.

voilà, il explique bien qu'il n'est pas parti d'une feuille blanche pour écrire c'est quoi l'XP et ensuite le monde l'adopter.

Ça s'est fait dans l'autre sens quoi.

plutôt a été le premier à écrire un bouquin dessus quoi.

Et pareil sur l'Agile, il était dans les gens qui ont écrit le manifeste Agile, il a pas mal de regrets sur ce manifeste Agile, trouvent que le mot est trop large, est trop creux

et on peut lui faire dire ce qu'il veut pas dire alors que l'extrême programming typiquement, bon bah il y a plein de gens qui lui font dire ce qu'il veut pas dire mais

quand on sait de quoi il parle, on sait que c'est pas si extrême que ça quoi, mais on peut pas l'interpréter en tout cas.

Alors que l'Agile...

En vrai à la fin de journée, tous les gens qui disent qu'ils doivent être agiles en fait ils sont pas agiles.

Il a plein gens qui disent qu'il faut être agiles alors qu'ils ont besoin de process.

On finit jamais quoi.

Il dit un truc très simple dans cette partie de l'interview là, c'est que partie où on écrit du code, c'est qu'une partie du développement logiciel, finalement.

Quand on code, on construit aussi notre compréhension du code, on construit la confiance, donc il dit qu'en fait, il a compris le problème du métier, il l'a formalisé, il l'a

représenté dans le code et surtout il a mis des tests pour expliquer le code.

Et ça, franchement, si vous codez avec l'Aude ou quoi, la partie test dans le code, est 20 fois plus importante que l'habitude.

parce que moi clairement le premier truc que je vais regarder c'est à ce que les tests ils sont bien ou pas parce que je veux voir dans les tests si l'oracle il est là

L'oracle c'est vraiment genre est-ce que la feature marche, est-ce que la feature marche pas, est-ce que les hypothèses qu'on a fait pour faire le produit ou la feature sont

bonnes.

Donc ça, je veux voir l'ARD, je voir le PRD, je veux l'écrire d'ailleurs à tout seul moi-même parfois ou je vais l'écrire avec Claude.

Ensuite je lui fais écrire le truc et je vérifie que les tests, il vérifie bien ça.

Et des fois d'ailleurs il m'a flouté, des fois il a fait des tests qui n'étaient pas sur le vrai code, qui étaient sur du mock et derrière je me suis senti flouté quoi.

Donc vraiment les tests sont toujours importants.

Parce que honnêtement tout le monde préfère lire les tests que lire le code quand ils sont bien faits en tout cas les tests quoi.

Et si vous générez des tests à la volée pour avoir une bonne couverture de tests sans lire les tests ensuite, vous apportez encore du chaos dans ce monde, c'est infernal bon après

il des gens qui le font quoi.

Bon et du coup il y a cette phrase là à la fin de son passage qui résume tout ça en disant que ben en fait tout ce travail là qu'on fait faire les tests machin chouette c'est pas

juste

pour faire du beau.

C'est pas un effort cognitif qu'on doit remplacer par Claude qui le fait à notre place.

Tout ça, ça sert à créer de la confiance.

C'est ça qui fait que les gens, ensuite, ils savent qu'on peut reprendre le code ensuite, que si la feature pète, il quelqu'un pour la réparer, etc.

Et toute cette confiance-là, est vraiment importante.

D'ailleurs, si vous avez déjà bossé sur du Legacy...

le legacy tout le monde l'aime pas parce qu'on lui fait pas confiance parce que c'est des couches de couches de codes où les gens qui savent pourquoi ils marchent ils sont plus là

vraiment si on pouvait faire une définition simple du legacy on appellerait ça le code ou plus personne ne sait pourquoi il marche parce tant qu'il a les gens qui sont là pour le

maintenir c'est pas du legacy c'est du vrai code quoi alors ce que ça change dans le débat sur Alias

cette phrase en fait on avait tous l'impression que oui le l'IA va remplacer le code, derrière il a des gens qui ont dit donc Dario c'est enfin voilà bref il a des gens qui ont

dit que pour l'instant il remplace l'activité de coder mais que Claude a remplacé toute l'activité de conception du code et en vrai ça on en reparle à la fin mais

les gens font pas confiance à Claude et les gens ont besoin d'un humain pour faire confiance aux codes et même si un autopilote dans l'avion les gens ils font pas confiance

à l'autopilote de l'avion ils font confiance au pilote de l'avion donc le sujet reste le même c'est à dire que peut-être que demain on va avoir plus de codes mais

Mais le code aujourd'hui on a vraiment tendance à empiler des piles de codes dont personne n'a confiance et qui demain on va considérer comme la dette technique ou du legacy.

Et la quantité de codes qu'on produit aujourd'hui avec l'ODE qui s'empile dans des projets GitHub, ça c'est vraiment juste le pire legacy du monde.

Faut bien le visualiser ce truc là.

Et surtout le code sera devenu l'hégacile plus vite du monde parce que personne ne lui fait confiance.

Il dit un truc intéressant aussi qui est que quand on travaille dans une équipe de développeurs, et ça représente un peu ce truc là où on a l'impression qu'on va plus vite

tout seul que quand on bosse avec une équipe de développeurs, quand on est dans une équipe de dev ou de technique, on a besoin de créer de la confiance avec les autres tech.

Donc les autres dev, les autres tech, ils ont besoin d'avoir confiance dans notre code.

Si vous bossez avec des DevOps, des ingénieurs plateformes, etc.

C'est encore plus fort.

Tu construis des features sur un ElastiCache, t'as intérêt à avoir confiance dans les gens qui y malégent l'ElastiCache.

Et s'ils partent, en fait, relou.

Parce que peut-être que l'ElastiCache s'est juste fait enfonnie par un AWS, mais c'est ces humains-là qui faisaient qu'on avait confiance en ce système-là.

Donc la documentation, c'est important tout ça, mais la confiance, c'est toujours le sujet.

Alors il dit que l'utilisateur a besoin, ouais c'est ça.

Il y a aussi ce truc là, c'est que...

y a les devs mais il aussi le fait que les tests, c'est le reflet du fait que t'aies pris le temps de parler avec des utilisateurs pour comprendre correctement ce qu'ils voulaient

faire.

Et des fois tu arrives en production, l'utilisateur dit ben non t'as pas compris le besoin, etc.

Tu peux regarder tes tests et tes tests ils vont dire ouais effectivement j'avais pas compris le besoin quoi.

Donc on a encore besoin de ce truc là.

En vrai je suis en train de m'en compte, mais si je veux écrire qu'un truc à la main c'est des tests et puis Claude il va faire les features quoi.

Et du coup ça, moi ça me réconcilie un peu avec le métier de développeur et j'ai vraiment envie qu'on parte.

Je vais probablement pas faire de podcast cet été parce que dans deux semaines je vais partir à vélo.

Là je suis entre deux, je suis au mieux de mon repas, la quiche est à côté de moi, je vais la finir après.

Mais gardez...

Le truc est là, c'est que si le métier de développeur c'est ça, c'est de construire la confiance, de s'assurer que les gens ont compris ou faire partie d'un système d'une

organisation de feature team qui fait que les législateurs, ont la future dans ce qu'ils ont besoin et ils ont confiance dans l'équipe parce que c'est elle qui maintient ce bout

de code là, en fait ce métier là il n'est pas remplaçable par Claude, parce que personne ne fait confiance à une IA qui est probabiliste et qui hallucine quoi.

Et du coup, prenons le temps de faire ça.

Justement Claude nous libère du temps.

ben Cloud, n'en profitons pas pour produire plus de codes dans lequel on n'aura pas confiance parce qu'on va juste se retrouver au bout de 6 mois, 1 an avec une code base

avec un ownership insupportable parce que juste personne n'a envie de lire le code qui a été généré par Cloud.

Par contre prendre le temps avec les utilisateurs, prendre le temps avec les collègues pour comprendre, pour être sûr que la feature soit bien comprise, prendre du temps pour

réfléchir à comment ça va se passer les cas limites avec tes collègues, etc.

En fait, c'est pas bullshit, c'est pas de la perte de temps.

Si vous voulez faire des phases de cadrage, en langage corporate, ça me rend fou les phases de cadrage, mais c'est important que tout monde soit dans la pièce, qu'on se parle

et qu'on construise de la confiance.

Vraiment, le rituel que vous avez, s'il sert à construire la confiance, il est indispensable.

C'est juste ça le sujet.

Faire une review du code d'un autre.

c'est construire de la confiance.

Alors vous avez le droit de râler parce que vous envoyez en review un truc que lui-même n'aurait pas relu mais gardez à l'idée que le fait que le code soit revué en prod bah ça

c'est un truc qui construit de la confiance.

Vous avez peut-être pas besoin de ça pour construire de la confiance mais vous avez besoin de la confiance.

Je toujours pas chaud pour rendre les reviews obligatoires par des humains honnêtement c'est vraiment un truc qui m'en fout.

D'ailleurs faire une review automatisée par Claude avant qu'il des humains qui le revue ensuite

peut-être beaucoup plus intelligent que d'écrire du code et de le faire relire à des humains tout de suite quoi.

C'est ça au final, je me dis que moi si j'ai arrêté d'être full time dev c'est parce que c'était peut-être un job qui était trop productif, trop étroit et maintenant le dev, cette

partie est productive, étroite etc, elle est un peu disparue et il faut du coup redonner de la place au temps, redonner de la place à documentation, j'ai mal quoi.

Par contre le truc qui est chaud quand même, c'est...

Parce qu'en fait, alors je sais pas, vous avez déjà peut-être eu ce moment-là où votre...

Alors le feeling of rightness, c'est-à-dire vous relisiez le code et Claude a fait un code qui ressemble pas à ce que vous auriez fait, voilà.

Et du coup vous dites, attends, c'est un peu bizarre et tout.

Là tu demandes à Claude, bah attends, pourquoi tu fais comme ça ?

Et il t'explique qu'en fait, bah c'est une bonne pratique pour l'accessibilité, c'est une bonne pratique, ça rend le plus maintenable, que y a plein gens de l'industrie qui disent

que c'est un standard et ils te donnent des articles qui en parlent.

Et là tu te rends compte que bon, oui, t'es un expert, ça fait 10 ans que tu codes sur cette techno là, t'as donné des conférences sur le sujet, mais...

Putain mais cette façon de faire là, de faire, je sais pas, un tableau, en fait elle est pas hyper up to date, elle est pas optimisée, y a des nouvelles façons qui sont bien

meilleures, et Claude a raison quoi.

En fait Claude t'oblige à faire autrement, que tu...

Donc ça casse en plus ton «fing of rightness», et au bout d'un certain temps tu te retrouves à ne plus savoir faire confiance à ton sentiment de «fing of rightness».

Mais le truc qui me donne le plus le syndrome de l'imposteur...

Parce qu'en fait finalement, Claude il fait un peu le code par petits bouts, par petits bouts, par petits bouts.

D'ailleurs moi je préfère aussi sonner, parce qu'il fait des petits bouts, plutôt que de demander à Opus de faire toute une application, demander à Claude de faire des petits

bouts, tac tac tac, à sonner de faire des petits bouts.

Et ensuite moi je m'assure que tout colle bien ensemble et que tout soit bien compartimenté ensemble.

Et des fois en fait, ouais effectivement je vais demander à Opus si mon architecture elle est bien, etc.

Et en fait je me rends compte que...

Ce que je pensais qui était important en terme de scalabilité, que je pensais qui était important en terme de sécurité, c'était pas exact quoi.

Et il me met une claque dans ces cas-là.

vrai, lui c'est mieux que moi finalement, même sur les sujets d'architecture et de système etc.

parfois il sait des choses que je sais pas ou du moins il me fait me rendre compte que j'avais une vision trop limitée du truc mais en même temps rappelez vous que

l'informatique ça a toujours été comme ça c'est à dire que tous les gens à qui je parle en informatique ils savent des choses que je sais pas alors pour le coup moi il ya quand même

beaucoup de gens qui savent des choses que sais pas parce que j'ai vraiment genre un petit doigt dans chaque petit bain

Mais enfin, c'est tout le monde dans l'informatique à ce sujet là, t'es un dev front, tu parles à un dev iOS, t'es un dev iOS, tu parles à un dev back, t'es un dev back, tu parles

à des gens du stockage.

Enfin vraiment, ça ne finit jamais.

fait, le monde informatique est un monde où la culture informatique, la connaissance informatique est tellement large que personne n'a assez de profondeur sur chacun des

domaines.

On a toujours besoin d'avoir des gens qui ont une forme en T, qui savent rentrer en profondeur sur un sujet pour le creuser, quoi.

Et du coup, c'est chaud, c'est à que...

Imaginez, il y a 3-4 ans, commencés, moi quand j'ai commencé j'étais junior, il y avait des seniors, des architectes qui pouvaient m'expliquer les choses, pourquoi c'était comme

ça etc.

Là maintenant on a un peu enlevé tout ça, imagine que tu junior, t'arrives, on te lâche avec Claude.

Et puis il doit lire la documentation qui n'existe pas, les ennuis les sachants sont plus là.

T'as plus le temps de demander du temps au seigneur, au staff parce qu'ils sont aussi noyés parce qu'ils sont en train de se faire brain...

C'est quoi le mot déjà ?

T'es brain gays, t'es brain cramé là ?

Enfin voilà, ils sont le cerveau cramé parce qu'ils utilisent le visage en clode pour faire 5 features en même temps.

Brain fry, brain fry comme le chicken fry.

Bah je trouve que c'est dur.

Je trouve que c'est dur.

Genre, imaginez du coup, enfin moi je suis ingénieur, j'ai une culture en informatique qui est large, en fait avoir l'impression des fois de manquer de culture gérant en

informatique, l'ai, imaginez ce que c'est un junior qui sort de bootcamp, qui arrive sur le marché aujourd'hui quoi.

Et du coup, enfin, prenez du, prendre du temps pour parler avec des humains autour de vous, de pourquoi le code il est fait comme ça, pourquoi on fait le code comme ça, etc.

Pas forcément, le pair programming a disparu en 2026 j'ai l'impression.

En tout cas les clods, les clods codeurs ne...

se préprogramme pas parce que de toute façon, on se préprogramme eux-mêmes avec Claude.

Mais fait, reprenez ce temps-là, que c'est tellement austère d'être tout seul face à Claude toute la journée.

De temps en temps, avoir un humain qui donne un avis sincère ou qui te un feedback sincère, c'est tellement golden parce que toute la journée, on se fait massacrer la tête

par Claude qui critique le code, qui critique notre travail, De temps en temps, des humains qui viennent nous expliquer les choses un petit peu correctement.

Je trouve que c'est essentiel.

Donc reprenez le temps de faire ça les gars ou les filles d'ailleurs.

Et ouais, j'ai envie de finir un peu sur cette note enthousiaste.

Voilà, c'est bientôt l'été, c'est une note enthousiaste.

Le job en vrai...

un futur qui est cool, si vous lui donnez le temps et la place pour des interactions sociales avec d'autres humains, que ce soit les utilisateurs ou les collègues, les autres

développeurs, les autres tech hosts qui sont dans vos équipes, en fait finalement, chérissez ces interactions-là parce que c'est elles qui construisent la confiance et puis

en vrai, même si toute la journée, ok tu te fais moins de travail à bosser avec tes 10 agents qui font 5 features en un temps, eh bien en fait genre prendre un café avec un

collègue pour parler de comment tu fait ta feature, c'est tellement rafraîchissant quoi.

tellement apprécié du coup prenez le prenez le temps allez en conférence allez en meetup prenez des cafés en loin si vous êtes timide et que les grandes mess ça vous fait peur

franchement voilà et puis ben profitez bien de l'été pour vous reposer le cerveau prédire du temps à ne rien faire quand je fais du vélo bon bah je vous invite vous que des fois

pendant deux heures il en a rien à voir on a le temps de réfléchir à rien donc bah prédire du temps pour ne rien faire pas le téléphone pas dormir

pas regarder la télé, alors regarder la télé si tu voulais, mais prenez le temps à rien faire pour recharger cette charge, enfin décharger cette charge cognitive, regardez

l'horizon, les bateaux qui passent au loin, etc.

On va profiter un peu de ça et puis amusez-vous bien.

Et alors le drapeau pour la fin, vraiment le drapeau pour la fin, c'est ça.

Le futur du développement logiciel, ce n'est pas plus d'humains qui pilotent plus d'agents, enfin moins d'humains et plus d'agents dans tous les sens.

Le futur logiciel, c'est quand même toujours, et ça a toujours été, un logiciel dans lequel on a confiance et la confiance, ça se construit parce que c'est une interaction

sociale.

Donc le futur du logiciel, c'est toujours des humains qui savent ingénier correctement leurs outils, qui savent utiliser leurs outils correctement pour qu'on puisse leur faire

confiance.

Donc peu importe comment on utilise l'IA.

En vrai, l'important c'est comment vous interagissez avec les autres gens autour de vous dans l'équipe.

Et c'est ça le plus important pour tout monde et pour moi.

En tout cas aujourd'hui je pense, je suis toujours pas un prophète qui est absolument raison mais je suis convaincu que ce truc là est à peu près vrai.

Dites moi si vous, quand vous prenez le temps de le faire, vous prenez le temps de faire ces interactions là, est-ce que vous vous sentez mieux ?

Est-ce que c'est mieux après ?

Et je suis convaincu en vrai qu'on va avancer en parlant de ça tous ensemble.

Si vous bossez dans une boite qui n'a pas pris le pas de l'IA, franchement kiffez tant que c'est possible quoi.

Allez, bonne vacances, à bientôt !