La digue

Bon ok. Je suis assez passionné et fasciné par ce qui se passe avec les LLMs depuis GPT4 (pour ne pas utiliser un autre terme).

Ma position est que les coding assistants développés avec les LLMs vont avoir un impact monstrueux sur notre façon de produire du logiciel. Par monstrueux, j’entends la fin de la pénurie des (bons) développeurs avec une baisse d’au moins 30% des besoins. Pourquoi ce chiffre ? c’est ce que je peux constater sur le gain de productivité d’un développeur qui utilise un outil LLM dans sa production (et c’est la fourchette basse annoncée par tous les Amazon/Google/Microsoft sur leur LLMs spécialisés en code).

Je pense que cet impact va être massif et rapide, sous quelques mois, la variable d’ajustement étant la vitesse d’adoption par les entreprises. Si j’en crois ce que j’entends autour de moi chez des grands comptes français, les commerciaux de Microsoft font le job en proposant Copilot X grands comptes après grands comptes.

Cependant, il y a 3 freins à cette adoption selon moi :

• le mépris individuel
• l’envoi du code à un tiers
• les limitations sur la taille du contexte

Ces freins sont pour moi “la digue” qui empêche la déferlante. 6 mois après le lancement de ChatGPT, l’ouverture des API d’OpenAI et 4 mois après GPT4, je pense que celle-ci va sauter assez rapidement pour les raisons que j’expose ci-dessous.

Le mépris

Je ne me fais pas trop de soucis sur ce frein qui est avant tout individuel. Cela fait plus de 10 ans que l’on court après la moindre personne sachant aligner des lignes de code avec un niveau de qualité acceptable. Forcément, avoir une machine qui remplit 30% de ses tâches, pour la plupart des développeurs, provoque quelques réactions hautaines. Je pense que ce mépris/rejet s’arrêtera après un “Aha moment” d’une utilisation poussée ou quand ils seront obligés de les utiliser car la productivité standard sera évaluée avec un coding assistant. Bref pas le choix de l’utiliser.

L’envoi du code à un tiers

Là, on touche à un frein important qui touche la plupart des organisations. Qui accepterait que son code informatique, un asset important, soit envoyé ailleurs ? La première réaction c’est : personne. La deuxième c’est : “bah on le fait bien avec du cloud public, et puis on utilise Office365, suffit d’avoir les mêmes contrats”. Donc si on peut comprendre le blocage de certaines organisations pour éviter l’utilisation d’un ChatGPT “à la sauvage” avec l’envoi en masse de données confidentielles, la contractualisation avec Microsoft/Amazon/Google va donner des garanties et ce frein va sauter assez facilement. Ce frein est de toute façon caduque à un horizon très proche : chaque organisation, chaque individu, va pouvoir disposer de son propre LLM, “on premise” sans envoi de données à l’extérieur. Des sociétés proposent déjà des LLMs on premise (voir le tableau plus bas). Mais je pense que l’avenir sera plutot aux LLMs opensource, intuition confirmée par ce memo interne de Google qui a fuité. Dans celui-ci, le ou les auteurs pensent que vu la performance actuelle des LLMs opensource, Google comme OpenAI ne disposent en réalité d’aucun avantage concurrentiel.

Limitation du contexte

Conséquence du dernier point, si l’utilisation actuelle des coding assistants est limité par la taille du contexte (ils n’ont pas connaissance de l’entièreté d’une base de code), l’arrivée des modèles opensource facilement déployables, aussi performants qu’un GPT4 et que l’on pourra fine tuné sur son propre code vont régler la question.

Vu sur Linkedin, un post de blog de Gergely Orosz assez intéressant sur les alternatives à Copilot et ChatGPT, avec en particulier ce tableau :

Je note 3 solutions : Tabnine, Codeium et Tabby qui sont selfhostables et qui peuvent fine tuned sur la code base. En revanche, je n’ai pas vu dans les demos de Chat intégré qui permet comme ChatGPT d’expliquer du code.