Pourquoi certains devs snobent l'IA pour coder à l'ancienne ?
Pourquoi certains devs snobent l'IA pour coder : le retour au manuel
L'industrie tech vit un buzz fou autour de l'intelligence artificielle. Chaque keynote vend la révolution du code. Chaque pitch startup balance "boosté par des LLMs". C'est excitant. Mais pas pour tous.
Une bande de développeurs solides fait marche arrière. Ils se posent la question qui fâche : Et si on n'en avait pas besoin ? On décortique ici pourquoi ces pros choisissent le clavier pur et dur. Et ce que ça dit de nos outils de dev.
Le coût des abonnements sans fin
Commençons par le portefeuille.
Les outils IA pour coder tournent à l'abonnement. Tu paies tous les mois pour de l'aide dans ton IDE. Sympa sur le papier. Sauf que ça engage à vie pour un truc utilisé à la marge.
Beaucoup reviennent à leur éditeur texte basique. Le calcul est clair : si l'IA sert 10 % du temps – genre générer du boilerplate ou de la doc rapide – l'abo vaut-il le coup ? Surtout avec des outils gratuits ou one-shot qui traînent depuis des lustres.
Les vieux de la vieille savent de quoi ils parlent. Ils ont vu les no-code promettre la fin du code. Les low-code envahir le marché, puis semer leur dette tech. Chaque vague "révolutionnaire" apporte du gain. Mais jamais au niveau annoncé.
Le doute n'est pas contre l'IA. C'est contre les outils qui prétendent tout simplifier. Souvent, ils ratent la vraie cible.
Complexité : celle qu'on subit vs celle qu'on doit vaincre
Allons plus profond.
Fred Brooks, le boss d'IBM sur le System/360, l'a dit dans "No Silver Bullet" : toute complexité n'est pas pareille. Lecture obligatoire avant d'acheter un outil IA.
La complexité accidentelle : les galères du code pur. Gestion mémoire. Boilerplate. Chercher une API. C'est chiant, pas rocket science.
La complexité essentielle : le cœur du problème. Comprendre les besoins business. Choisir l'architecture. Gérer l'état en distribué. Débugger les interactions foireuses. Ça reste, en Assembly ou en Python.
Langages et frameworks modernes ont déjà terrassé l'accidentel. Fini le machine code. Bibliothèques standard au lieu de réécrire du tri. Package managers, linters, tests auto.
Vérité qui dérange : les IA codent surtout l'accidentel, déjà résolu.
Demander un endpoint REST ou un test unitaire à un LLM ? C'est du déjà-vu, documenté. Le vrai frein aujourd'hui ? Savoir quoi coder et comment structurer.
La tour d'abstractions qui vacille
Imagine ton stack dev. Une ligne Python = des millions d'opérations en bas. Langage haut niveau, bytecode, interpréteur, OS, CPU, silicium.
L'IA rêve d'ajouter une couche : agents autonomes qui codent seuls. Fini le dev dans l'équation.
Mais chaque couche ajoute des bugs invisibles. Quand ça pète en profondeur, tu descends inspecter. Le debug efficace demande de plonger bas.
Code généré par IA ? Nouvelle couche opaque entre ton idée et le résultat. Bugs arrivent. Tu reverse-engineers l'IA pour comprendre. Pas du gain. Du fardeau masqué en magie.
L'expérience, ce super-pouvoir
Générationnel, le truc.
Le secteur adore la jeunesse et la vitesse. Cinq ans = senior. Pourtant, les devs aux décennies d'ancienneté ont un savoir priceless. Échecs vus. Risques sentis. Cycles tech survivus.
Pas de mépris pour les jeunes ou les fans d'LLM. Mais la vue d'ensemble post-Java, Ruby, Node, blockchain, serverless forge un scepticisme sain.
Pas anti-progrès. Anti-buzz.
Ce que ça change pour les users de NameOcean
Chez NameOcean, on croit à l'IA pour le dev. D'où notre franchise sur ses limites.
Sur Vibe Hosting, l'IA aide là où ça compte : choix infra, optimisation deploy, analyse scaling. Problèmes cadrés, gains mesurables.
On ne remplace pas le dev. On vire les frottements inutiles : infra, deploy, monitoring perf.
Sceptique sur les IA codeuses ? Bonne signe. Tu pèses le pour et le contre. Utilise-les pour le chiant. Ignore-les pour le stratégique.
L'avenir ? Enlever les distractions. Laisser les humains briller sur l'essentiel.