Ce que fait vraiment un LLM reste à déterminer, justement. Un LLM prédit un mot en fonction des mots précédents et de la probabilité maximale que le suivant génère un sentiment positif ou familier chez l’utilisateur.

On ne cherche ni vérité ni exactitude ni précision. C’est d’ailleurs ici que s’insère le prompt engineering.

Si tu arrives à faire passer le message dans ton prompt qu’un type de réponse te rendra plus heureux qu’un autre, ça change ce graphe de probabilités. Ce sont les milliards de données qui font que ces réponses probabilistes sont absolument confondantes.

Quand tu demandes à un LLM de coder, il n’y a pas de compréhension du sujet, ni d’incitation à le traiter. Ce n’est pas un paramètre de succès pour ce type d’IA. Du coup, on a une approximation de ce que d’autres devs ont pu publier sur GitHub comme réponse.

Et pour des problèmes très simples, ou très souvent exposés, c’est là aussi confondant. Dès que le problème se complexifie ou demande de la créativité, les deux piliers du LLM s’effondrent : l’approche probabiliste mot à mot fonctionne peu, il faudrait une approche plus globale.

Et le critère de succès pour construire le modèle ne devrait pas être la satisfaction directe de l’utilisateur mais l’adéquation de la réponse au résultat attendu.

On peut imaginer entraîner une IA avec comme facteur de succès des tests d’intégration fournis qui passent (je raconte n’importe quoi pour l’exemple : on donne le sujet, on donne les tests à exécuter, ils doivent être verts. Et on nourrit avec du code + specs + tests pour l’entraînement). Ou on peut avoir une solution totalement différente !

Mais les LLM ne peuvent pas intrinsèquement remplacer le dev. Ils peuvent réduire son équipe à beaucoup moins peut-être, ceci dit. Ils peuvent déjà être meilleurs qu’un junior parfois 😆.