Je suis plutôt d'accord avec l'article.
Je me sers de l'IA pour des choses que je ne fais quasiment jamais et que je ne ferais jamais à nouveau, écrire un Dockerfile par exemple, tu le fais une fois et si ça marche, tu n'y touches plus.
Je m'en sers aussi dans du python pour me générer la documentation, si la documentation générée est correcte, c'est qu'à priori le code écris est lisible et correct.
Je l'ai utilisé aussi au départ pour m'écrire des tests unitaires pour Django, parce qu'il faut avouer que la syntaxe n'est pas immédiate.
Et sinon j'en ai beaucoup besoin pour mes traductions, l'application étant en plusieurs langues.

Je plussoie l'idée que coder, c'est fun (souvent), et que c'est dommage de s'en priver en le confiant à une ia (ou quelqu'un d'autre d'ailleurs)

Après, on est des privilégiés, je pense que nombre d'ouvriers étaient aussi plutôt content de construire des voitures ou des trucs comme ça, mais on leur a pas posé la question.

J'ai lu un article dernièrement sur les ingénieurs qui Microsoft qui se sont fait virer ces dernières années sous couvert de l'IA.
Leur boulot n'a pas été pris par l'IA, mais des tâches à droite et à gauche ont été remplacées par l'IA (transcription écrite d'une réunion, par exemple) et sous couvert d'IA Microsoft (et d'autres entreprises) ont viré du personnel mais parce qu'ils voulaient virer du personnel.
Les traducteurs et graphistes ont beaucoup souffert de l'IA, traduire des textes simples donnent un très bon résultat rapidement avec l'IA et faire des ébauches graphiques avec l'IA est moins couteux qu'embaucher un graphiste pour toute la conception.

On leur a pas demander leur avis non plus, le traducteur et le graphiste préfèrent surement faire leur truc aussi 🍧😁

J'aime bien l'article. Je pense qu'on est tous un peu dans ce cas, à être partagé entre ce que l'IA apporte parfois d'incroyable et les déceptions qui parfois suivent. Et l'inquiétude de savoir de quel côté la pièce va tomber pour un paquet d'emploi.

Pour apporter l'éclairage inverse, j'ai lu avec intérêt cet article récemment obie.medium.com/what-hap… C'est un spécialiste de XP, en Ruby on rails et lui explique que coder est la partie la moins intéressante. Il utilise l'IA comme s'il pair programmer avec une autre personne et il se focalise sur le senior thinking, qui n'a pas disparu et qui lui plait le plus.

J'ai une expérience mitigée avec copilot. La seule fois où il m'a été utile (c'était lors d'un test sans espoir), j'ai finalement passé plus de temps à relire le code pour le comprendre car mes tests passaient et j'avais l'impression que le code passait à côté de quelque chose. Finalement, un bloc conditionnel avait été bougé indépendamment de la "feature" implémentée et le side effect (on purpose ou pas) fait que ça marche... J'ai passé plus de temps à la relecture que ce que j'aurai fait en codant, sauf que je n'aurai jamais débuté ce travail spontanément (une optimisation de perfs dans des cas extrêmes, changement assez complexe mais sans impact négatif pour les autres cas). J'en tire donc une leçon à la fois positive (me lancer sur quelque chose pour lequel je ne suis pas spécialement enthousiaste) et négative (temps perdu et, soyons honnêtes, aucun sentiment de mériter le résultat). Dans ce cas là, ça s'apparente beaucoup à la gestion de contributions externes faites habituellement par des "vrais" devs.

Sauf qu'avec de vrais devs, on peut tellement dialoguer, et comprendre certains choix (surtout quand ils sont peu logiques mais largement justifiables que ça soit pour la lisibilité, cohérence, élégance ou tout simplement pour préparer le futur à d'autres possibilités. Les ia ne font pas tout ça..)