La malédiction du Firefox mobile : pourquoi le code de Qwen n'est que le début

Beaucoup semblent croire que les modèles de langage modernes comme Qwen ou GPT-4 ont transformé la programmation en une simple promenade. Vous écrivez une requête, le réseau de neurones crache du code, vous le collez dans l'éditeur et voilà — votre jeu de cartes est prêt. Cette lune de miel illusoire dure exactement jusqu'au moment où le projet rencontre des utilisateurs réels ou, pire encore, des navigateurs mobiles. L'histoire d'un enthousiaste qui a décidé de terminer un jeu en JavaScript pur illustre parfaitement la nouvelle réalité du développement : l'IA vous donne des ailes, mais ne promet pas qu'elles ne fondront pas en s'approchant du soleil.

Tout a commencé de manière optimiste. L'auteur a posé la tâche à Qwen et en seulement trois ou quatre itérations, il avait un framework fonctionnel en main. C'est ce moment de triomphe où il semble que des années d'étude de la syntaxe et des algorithmes ont été gaspillées. Le code fonctionnait partout sauf en un seul endroit spécifique — la version mobile de Firefox. Ici, la loi de Pareto est entrée en jeu, souvent oubliée dans l'enthousiasme des réseaux de neurones : les premiers 80% des résultats proviennent de 20% du temps, mais les 20% restants de polissage consommeront 80% de vos ressources et de vos nerfs.

Le problème résidait dans l'implémentation de la fonction drag-and-drop. Le réseau de neurones, entraîné sur des millions d'exemples de code standard, a proposé une solution classique pour faire glisser les cartes sur la table de jeu. Cependant, Firefox mobile a depuis longtemps la réputation d'être un navigateur au tempérament particulier, et les événements de drag-and-drop standard y fonctionnent, pour le dire doucement, de manière imprévisible.

L'IA ne peut pas connaître de tels endroits 'maudits' si vous ne le lui demandez pas directement. En conséquence, le développeur a dû construire un hybride complexe : conserver le familier drag-and-drop pour les ordinateurs de bureau et implémenter un click-touch conservateur pour le capricieux Firefox mobile. Cette solution est moins spectaculaire, mais fonctionne sans faille.

La chose la plus intéressante ici n'est pas le bug du navigateur, mais la transformation du processus créatif lui-même. À un moment donné, le processus d'écriture de code s'est transformé en un processus d'apprentissage. Si auparavant l'auteur pouvait se permettre de ne pas regarder le contenu des fichiers, en comptant sur la magie de Qwen, alors la collision avec la réalité l'a forcé à comprendre chaque fonction.

Et ici, l'IA s'est révélée sous un autre aspect. Quand il s'agit d'expliquer les nuances et de trouver les causes d'erreurs spécifiques, les réseaux de neurones n'ont vraiment pas d'égal. Au lieu d'une copie aveugle, un dialogue a commencé qui a mené à une compréhension beaucoup plus profonde de la façon dont le produit créé fonctionne exactement.

Nous entrons dans une ère où le rôle du programmeur change de 'rédacteur de code' à 'architecte et filtre'. L'IA produit une solution moyennée, statistiquement correcte, qui ignore souvent les cas limites et les bugs spécifiques aux plates-formes. Si vous ne comprenez pas exactement ce que vous avez copié d'une conversation avec un réseau de neurones, vous serez impuissant face au premier bug sérieux. Mais si vous utilisez l'IA comme un mentor infiniment patient, même un projet amateur peut devenir un produit professionnel. L'essentiel est de ne pas croire complètement à la magie et de toujours avoir un Firefox mobile à portée de main pour vérifier la réalité.

L'essentiel : l'IA accélère le prototypage par des ordres de grandeur, mais la responsabilité du 'dernier kilomètre' et de la stabilité entre navigateurs incombe toujours aux humains. Pourrons-nous un jour confier complètement aux réseaux de neurones le débogage dans les conditions de fragmentation des logiciels?