Et oui, contrairement à toute attente, je code parfois en laissant l’AI faire tout le travail et en ne regardant même pas le code généré.

Il m’arrive parfois de devoir écrire des scripts non liées à la production. Par exemple, j’ai récemment dû faire pas mal de scripting pour fusionner selon certains critères des fichiers csv et JSON que j’avais en local, pour ensuite produire d’autres fichiers. Je me rappelle également d’un autre use case où j’avais téléchargé des traces opentelemetry depuis Grafana Tempo en JSON et où j’avais ici aussi besoin d’écrire des scripts pénibles pour extraire certaines données.

Aujourd’hui, j’utilise quasi exclusivement l’AI pour générer ce type de scripts, et le gain de productivité est énorme. En quelques minutes (voir moins), je sors des scripts que j’aurai mis énormément de temps à écrire à la main (probablement en heures). Claude Code sait de lui même analyser le format et la structure des données en entrée, et produire le script qui va bien, généralement en Python. Encore une bonne raison pour ne plus avoir à apprendre Bash, l’AI le générera pour vous si besoin ;)

Je vibe code également aujourd’hui tout ce qui est interface.
J’ai eu des cas récents où j’avais, encore une fois, des fichiers JSON complexes en local que je voulais pouvoir montrer "de manière jolie". et même partager avec des non-tech. Là aussi, j’ai utilisé Claude Code pour me générer des HTML statiques embarquant les données (généralement je lui demande de me faire un script qui génère ensuite un HTML depuis un fichier en entrée). Cela m’a permis de produire très rapidement des trucs corrects et d’avoir des visualisations de données à montrer.

J’ai régulièrement des cas où je veux créer des interfaces simples pour des API, pour de l’outillage interne où je me fiche un peu de la qualité du code du front. J’utilise énormément l’AI pour ça et cela marche très bien.
Une interface simple avec un menu, des formulaires et des pages pour afficher ou intéragir avec des données, l’AI le génèrera très bien depuis la spec OpenAPI du backend.

Ce dernier exemple m’inspire une nouvelle réflexion: l’AI nous permet d’imaginer un monde "Proof of Concept first" où en quelques heures on peut sortir un produit certe dégueulasse et non maintenable sur le long terme mais qui marche, avec une interface et donc des interactions possibles. A voir si ça vaut toujours le coup mais je trouve l’idée de rapidement itérer sur des interfaces qui tapent de vrais APIs (avec de la vraie donnée) assez intéressante.

J’ai eu récemment à écrire un slackbot en Go. Franchement, le SDK Slack est d’une complexité inimaginable, notamment sur le payload reçu par le bot (des structs Go géantes avec énorméments de champs et d’imbrications où on ne sait pas exactement ce qu’on doit extraire). J’ai donc demandé à mon ami Claude de m’extraire tout ce dont j’avais besoin en fonction du code qui générait l’interaction utilisateur dans Slack, et il m’a one-shot le truc.
Bref, pour des questions très précises, c’est très puissant. Auparavant j’aurai cherché sur Google/Stackoverflow, maintenant l’AI permet d’aller beaucoup plus vite.

L’AI marche également bien pour du bugfix, et j’ai l’exemple parfait (true story).
On utilise Clickhouse pour les traces dans ma boîte. Il y avait un bug dans le plugin Grafana de clickhouse qui empêchait l’affichage des "span events" sur les traces, et c’était super handicapant lorsqu’on investiguait des problèmes en production. Un collègue a donc créé une issue sur le Github du plugin.
Lors de l’investigation d’un incident en Août, je me reprends le bug et je craque: je clone le plugin, je lance Claude Code, je lui mets un prompt similaire à This is the clickhouse datasource for Grafana, fix this bug: https://github.com/grafana/clickhouse-datasource/issues/1262 (c’était vraiment ça, pas plus) et …​ en une minute, il me fix le bug.
On parle ici d’une base de code non triviale, assez complexe et avec une logique particulière (écrire un plugin Grafana, on a déjà connu plus fun). Pourtant, l’AI s’en est sorti du premier coup juste en partant de l’issue Github. Je ne sais franchement pas combien de temps j’aurai mis à trouver ce problème moi même, ou même si j’aurai réussi.

J’écris énormément de Python en ce moment, pour des services backend et des produits liés à la GenAI.
Quand vous avez le traditionnel "database / service / API layer" à écrire, avec les tests associés, l’AI permet de gagner du temps. Je fais moi même la partie SQL (modeling des données, définition des tables SQL…​) et les classes représentant ces données, puis je demande à Claude de me générer le "repository" (les fonctions du type create, get by ID, list, update, delete…​).
Une fois la partie repository terminée, j’utilise toujours l’AI comme assistant pour faire la partie service/domaine puis API, ainsi que pour m’aider à écrire les tests. Comme vous pouvez le voir, je ne génère jamais toute la feature d’un coup, j’itère sur les layers de l’application ou des fichiers spécifiques jusqu’à avoir ce que je veux.

Je relis toujours le code produit et je n’hésite bien sûr pas à faire des ajustements, à la main ou via l’AI selon ce qui est le plus efficace. Mais je suis généralement satisfait de ce que me génère l’AI et j’ai également ici un bon gain de productivité.

L’AI peut aussi aider pour les reviews de pull request, ou même pour explorer une base de code. Il ne faut pas hésiter à l’utiliser comme canard pour comprendre comment quelque chose fonctionne.
Claude Code permet également d’écrire des agents pouvant réaliser des tâches spécifiques. Par exemple, j’ai écrit récemment un agent qui, une fois invoqué, récupère les commentaires sur la pull request associée à ma branche locale, puis modifie le code en fonction.
Si vous (ou vos collègues) avez des tâches répétitives à faire, écrire un agent est également très intéressant.