Cet article a été traduit du néerlandais. Les liens peuvent pointer vers des sources en néerlandais.

Dans un article précédent, nous avons discuté de manière générale du potentiel de l’IA générative dans le Software Development Lifecycle. Examinons maintenant la question du point de vue du développeur : quel est l’état d’avancement de la génération de code et que devons-nous encore prendre en compte ? Pour faire court : les assistants IA ou les plugins pour IDE sont une aubaine pour ceux qui savent en faire bon usage, mais comme tous les systèmes d’IA, ils présentent aussi des inconvénients.

Avant-propos

Une partie de cette hype en termes d’IA générative est propulsée par des modèles de langages puissants – les grands modèles de langue ou LLM. Depuis la sortie du GPT-3 en 2020, ces modèles parviennent à écrire des textes normaux d’une certaine longueur. De là, il n’y a qu’un pas vers les langages de programmation. En effet, ils ont aussi une syntaxe et une sémantique.

Dans la pratique, il existe de nombreuses variantes de modèles de langue, chacun ayant ses forces et ses faiblesses, en fonction des choix faits par les créateurs pour les entraîner, et en fonction des données d’entraînement qui les sous-tendent. Testez vous-même certains des modèles open source existants sur votre propre ordinateur via l’outil GPT4All (voir également notre quick review de cet outil).

Le code informatique consiste en une collection de fichiers texte. Rien n’empêche un modèle de langue d’essayer de prédire les différents tokens (= unités grammaticales) qui composent le code, plutôt que des mots. Cependant, contrairement au texte brut, le code a beaucoup moins de tolérance à l’erreur : la moindre faute d’orthographe ou la plus petite variation peut invalider un morceau de code ou lui faire exécuter quelque chose de complètement différent.

Pourtant, aujourd’hui, les plus grands modèles de langue, tels que GPT-3.5 et les versions ultérieures, peuvent produire d’eux-mêmes des morceaux de code informatique tout à fait corrects en réponse à une requête. Cette fonctionnalité est due à la quantité massive de textes sur lesquels ils sont formés, notamment de nombreux tutoriels, articles de blog, questions et réponses provenant de forums de développeurs populaires tels que StackOverflow, et code documenté provenant de repositories de code publics tels que Github.

Canards en plastique bavards

Depuis Socrate, le dialogue est un moyen efficace de parvenir à de nouvelles perspectives. Ce n’est pas pour rien que le rubber ducking est une méthode de correction de bugs qui revient dans tous les cours de génie logiciel. Il existe entre-temps plusieurs plugins qui mettent à disposition une interface de chat alimentée par l’IA dans l’IDE même (par exemple ceux pour VS Code, beaucoup d’autres peuvent être trouvés via les marketplaces pour VS Code ou IntelliJ IDEA). Si ces plugins utilisent un service cloud externe, il vous suffit d’entrer votre propre clé API.

Un cadre de dialogue avec une dynamique de questions-réponses peut être bien utilisé pour générer des morceaux de code relativement autonomes, sans trop de dépendances externes. En général, pour obtenir le meilleur résultat, il faut pouvoir énoncer facilement toutes les conditions préalables et les hypothèses nécessaires dans le dialogue lui-même, de manière à ce qu’il s’inscrive dans la fenêtre contextuelle du modèle de langue. Les use cases comprennent entre autres :

• La génération from scratch d’une version initiale du code ou d’un fichier de configuration
• La génération de fonctions ou de procédures relativement courtes à partir d’une description
• La génération de code snippets autonomes : requêtes SQL, expressions régulières…
• Demande de modification d’un morceau de code ou d’un fichier de configuration
• Correction de bugs : recherche d’erreurs dans un code qui ne fonctionne pas, poser des questions sur une erreur
• Faire expliquer ce qu’un morceau de code fait

Les plus grands modèles de langue disposent de fenêtres contextuelles de plusieurs milliers de mots dans lesquelles il est possible d’insérer toutes les informations nécessaires. Un modèle de langue open source plus petit, installé localement sur du matériel moins puissant, sera sans aucun doute moins performant. Voici quelques exemples de conversations avec GPT-4 d’OpenAI, qui montrent qu’il est possible d’aller très loin avec quelques questions bien ciblées (cliquez sur l’image pour obtenir la pleine résolution) :

Complétion de code sous stéroïdes

Au cours du développement, un développeur travaille sur de nombreux fichiers dans un IDE. À des endroits aléatoires de ces fichiers, le code doit être modifié, supprimé ou écrit. L’édition de code existant de cette manière n’a pas grand-chose à voir avec le dialogue ; en fait, nous préférerions utiliser l’auto-complétion avancée dans ce cas. Les modèles de langue peuvent également faire l’affaire, mais les modèles les plus appropriés sont plutôt ceux formés aux tâches de “remplir au milieu” – et qui peuvent donc prendre en compte le code présent avant et après l’endroit que l’on édite.

Après la sortie de GPT-3, OpenAI a travaillé avec Microsoft (qui possède Github) pour créer un modèle de langue spécialisé, formé exactement pour ce use case. Cette variante a été nommée Codex, et le premier outil à l’utiliser a été Github CoPilot. Depuis, nous en sommes à plusieurs versions, mais les plugins pour VSCode et IntelliJ fonctionnent toujours de la même manière : via un raccourci clavier dans l’éditeur, on peut utiliser CoPilot pour récupérer diverses suggestions, générées par Codex, qui pourraient correspondre à l’endroit où se trouve le curseur.

D’après notre expérience actuelle, le contexte pris en compte est généralement limité au contenu (partiel) du fichier édité. Cela implique évidemment le téléchargement vers le modèle de langue – veillez donc à respecter les directives en matière de confidentialité lorsque vous utilisez un service externe. Pour l’instant, nous semblons obtenir de meilleurs résultats dans les projets de programmation composés de quelques gros fichiers, tels que les pages web avec JavaScript en ligne, ou Jupyter Notebooks en Python, où il y a souvent un gros fichier à parcourir qui contient à la fois la documentation, le code et l’output. En revanche, dans les projets comportant de nombreux petits fichiers, il semble plus difficile de générer de bonnes suggestions, et il est plus important de disposer d’une documentation supplémentaire dans le fichier édité afin que le modèle de langue puisse puiser dans suffisamment d’informations contextuelles.

L’une des alternatives les plus intéressantes au modèle commercial Github CoPilot est StarCoder, un modèle open source issu de l’initiative BigCode HuggingFace et ServiceNow. Bien que la performance soit moindre que CoPilot, ils font la différence dans de nombreux autres domaines qui peuvent être des obstacles dans des contextes commerciaux ou publics :

• Entraînés sur un dataset public : The Stack. Bien qu’il ait été collecté par scraping, il ne contient que du code avec des licences logicielles permissives, et les développeurs peuvent, s’ils le souhaitent, toujours faire retirer leur code du dataset.
• Comprend un outil de vérification de plagiat, qui permet de vérifier que les suggestions générées n’ont pas été copiées mot pour mot à partir des données d’apprentissage (éventuellement protégées par des droits d’auteur).
• Pourvu d’un filtre d’informations sensibles, qui détecte les adresses électroniques, les clés API et les adresses IP (pas exact à 100 %).
• Contient des instructions pour installer localement, ainsi qu’un plugin VSCode. Un plugin IntelliJ a entre-temps également été développé par un tiers.
• Le modèle standard a une taille de 15 milliards de paramètres et nécessite au moins 60 GB de RAM ou autant de mémoire GPU (en fonction de l’utilisation ou non d’un GPU) pour être utilisé. Il existe également de plus petits modèles à 7, 3 ou 1 milliard de paramètres, ainsi que des versions quantisées utilisant des types de données à 4 bits, sans grande perte de précision.

Plusieurs autres systèmes ont vu le jour cet été et ont obtenu de bons résultats dans de nombreux benchmarks : WizardLM et sa variante spécifique WizardCoder, qui est désormais considéré comme le nec plus ultra de l’open source, et PanGu-Coder, avec lequel Huawei s’est également lancé dans le monde des assistants IA pour le code. 

Au cœur de l’action

Le StarCoder paper offre un bel aperçu du fonctionnement d’un modèle de langue pour le code.
Ce n’est certainement pas comme si vous pouviez “brancher” votre propre codebase pour obtenir des suggestions adaptées. Si vous voulez vraiment affiner le modèle (et vous ne ferez cet énorme effort que si vous n’y arrivez pas avec des modifications astucieuses du prompt), il y a beaucoup de choses à faire, du prétraitement des données d’entraînement au post-traitement de l’output brut du modèle de langue. Ne vous attendez pas non plus à ce que le réglage fin soit trop élevé : StarCoder l’a fait pour Python, mais n’a obtenu que quelques points de pourcentage d’amélioration par rapport au modèle global qui pourrait traiter tous les langages de programmation. Le peaufinage est difficile et il n’y a aucune garantie de succès ; il y a même un risque d’overfitting, ce qui pourrait dégrader les résultats.

L’étape la plus importante est probablement la collecte et le nettoyage des données. Ces données sont constituées de code, mais tous les codes ne sont pas inclus : vous devez également être autorisé à utiliser le code (licences) et, de préférence, l’avoir aussi correct que possible et écrit dans le langage de programmation que vous souhaitez soutenir. Le code est également collecté à partir des issue trackers et du commit history. En outre, un filtrage additionnel peut être effectué pour supprimer les (quasi-)doublons, et des pondérations peuvent être attribuées ici et là pour maintenir l’équilibre : un peu moins de poids pour le code “boilerplate”, et/ou un peu plus pour les repositories très populaires qui sont susceptibles d’être de meilleure qualité. Le code source peut contenir des informations sensibles qui doivent être rendues anonymes ou supprimées au préalable, pour éviter qu’elles ne soient divulguées ou suggérées (adresses IP, mots de passe, identifiants, adresses électroniques, coordonnées…). Tout cela, bien sûr, de préférence aussi automatiquement que possible.

Le code source se compose non seulement de code, mais aussi de descriptions, de commentaires et d’autres informations. Dans une étape de formatage, le code est donc enrichi par l’ajout de métadonnées et de tokens supplémentaires qui rendent explicites certaines structures implicites. Cela peut avoir des conséquences : si tout ce prétraitement a été effectué sur l’ensemble des données d’apprentissage, le modèle résultant ne fonctionnera correctement sur de nouvelles données que s’il a subi le même prétraitement. Ainsi, les plugins éditeur qui souhaitent utiliser un tel modèle peuvent, pour obtenir un bon résultat, devoir d’abord effectuer un prétraitement similaire sur le code qu’ils souhaitent envoyer au modèle de langue.

Exactitude et autres benchmarks

Comme c’est le cas pour les LLM, il ne peut y avoir de garantie concluante de l’exactitude ou de l’exhaustivité de ce qu’un tel plugin présente, tant sur le plan syntaxique que sur le plan sémantique. Cette précision est évidemment importante : un morceau de code généré ne doit pas seulement être syntaxiquement correct et compiler sans faille, mais aussi être sémantiquement significatif et s’exécuter correctement. La métrique “pass@x” est devenue une mesure importante à cet égard. Elle exprime en pourcentage si un modèle de langue pour une mission donnée peut passer avec succès les tests correspondants après X tentatives. “pass@1” est le pourcentage pour lequel le modèle de langue utilisé pour la première fois a pu générer la bonne réponse, “pass@10” est le pourcentage pour lequel au moins 1 tentative sur 10 a été correcte.

Dans le monde de l’IA générative, il existe un besoin général de pouvoir comparer les nouveaux modèles, qui apparaissent désormais presque quotidiennement, avec le meilleur de la technologie. Il n’y a donc pas de pénurie de benchmarks, et de nouveaux modèles plus importants apparaissent régulièrement. Des résumés utiles sont les “leaderboards”, qui montrent en temps réel quels modèles représentent l’état actuel de la technique selon une série de benchmarks. L’étape peut changer chaque semaine. Voici quelques leaderboards généraux intéressants :

• Papers with Code : l’état de l’art dans diverses tâches d’intelligence artificielle, avec des documents d’accompagnement.
• Stanford HELM : analyse comparative d’un large éventail de tâches en se focalisant sur le “human reasoning” (raisonnement humain).
• LMsys.org FastChat : se concentre sur les capacités chatbot.
• HuggingFace OpenLLM leaderboard.
• LLM-Leaderboard.

En ce qui concerne le code, il existe des benchmarks qui fonctionnent plus ou moins comme un concours de programmation. L’idée est de confier un ensemble de tâches au modèle de langue, d’évaluer les résultats automatiquement et de mesurer le “pass@1” et, si possible, d’autres paramètres. Souvent, il s’agit de “remplir la fonction” : à partir d’une description de l’input, de l’output et d’un function header, le contenu de la fonction doit être généré. L’inconvénient est que ce type de problème n’est parfois pas très représentatif de celui auquel est confronté le développeur lambda. Parmi les initiatives intéressantes, on peut citer :

• HuggingFace Big Code Models leaderboard (uniquement LLM publics).
• Microsoft CodeXGLUE : évaluation de diverses sous-tâches selon des méthodes connues de Natural Language Processing. Ce leaderboard semble dépendre de contributions volontaires et est quelque peu incomplet.
• Papers with Code a des sections séparées pour la génération de code, la création de documents, la synthèse de programmes entiers et la correction de bugs.
• Le HumanEval dataset et MBPP dataset : problèmes de programmation typique (Python).
• Le DS-1000 dataset : ensemble de problèmes de data processing / data science concrets.
• HumanEval-X ou MultiPL-E : versions multilingues de HumanEval, mesurant les performances dans plusieurs langages de programmation.

Bien entendu, le fait qu’un morceau de code généré survive aux tests ne signifie pas qu’il s’agit d’un code sécurisé ou qu’il respecte les “best practices”. Entre-temps, il existe de nombreux exemples connus de code généré qui s’avère sensible aux “buffer overflows”, à l’injection SQL et à d’autres risques classiques. Le benchmark de sécurité “Asleep at the Keyboard” consiste en 89 scénarios de génération de code basés sur la liste MITRE top-25 vulnerability. Starcoder paper montre que même les meilleurs modèles génèrent encore du code non sécurisé dans 40 % de ces scénarios. En outre, il ne semble guère y avoir de différence entre les meilleurs modèles et les autres – le choix d’un meilleur modèle semble garantir des résultats syntaxiquement plus corrects, mais pas encore un code plus sûr. Il est donc possible que nous devions nous pencher sur les données d’apprentissage elles-mêmes, où le code non sécurisé devrait être encore mieux filtré. Quoi qu’il en soit, il convient de rappeler que l’utilisation de code généré dans un projet doit impérativement s’accompagner d’une solide politique de test et d’acceptation.

Performance

En ce qui concerne plus particulièrement les exigences computationnelles, le leaderboard Huggingface OpenLLM-perf et les benchmarks sur le site web TextSynth Server constituent des sources intéressantes. Ce dernier montre quelques chiffres de performance utiles pour ceux qui envisagent un hébergement par leurs propres moyens. Ceux qui n’ont pas de GPU peuvent compter sur une vitesse de 12 tokens par seconde avec le modèle LLaMa2 de 13 milliards de paramètres, avec un processeur de serveur EPYC 7313 relativement haut de gamme. Dans un code informatique, un token ne représente parfois qu’un seul caractère, de sorte qu’à cette vitesse, il faut parfois attendre une dizaine de secondes pour obtenir une suggestion de complétion de code. La dernière carte graphique RTX-4090 peut le faire 7 fois plus vite, mais pas encore au point de l’exprimer en millisecondes.

Les besoins en mémoire sont proportionnels au nombre de paramètres d’un modèle, et la vitesse de génération inversement proportionnelle. À titre d’approximation, on peut supposer qu’un modèle comportant 13 milliards de paramètres doit également effectuer 13 milliards de calculs pour chaque token de sortie, même s’il ne comporte qu’un seul caractère. En outre, si chaque paramètre est un nombre de 32 bits, il faut au moins 52 Go de stockage et autant de mémoire (V)RAM. Une “quantization“, arrondissant les paramètres à 8 bits ou même à 4 bits, peut réduire proportionnellement ce besoin en mémoire.

GPT4All permet de l’essayer sur votre propre matériel. Cela donne une idée de l’énorme puissance de calcul qu’OpenAI, Microsoft Azure ou Amazon AWS déploient pour que leurs modèles, dont beaucoup sont encore plus grands que les LLM disponibles en libre accès, fonctionnent aussi vite qu’ils le proposent. On parle d’investissements de milliards de dollars en matériel informatique, si importants qu’ils déstabiliseraient le marché mondial.

Même les solutions open source sont loin d’être légères, en dépit des grandes initiatives d’optimisation. On peut en tout cas supposer que le déploiement local n’est possible que sur du matériel récent et puissant. Actuellement, on ne peut pas s’attendre à ce qu’une installation locale sur un ordinateur portable de bureau moyen offre une expérience fluide à l’utilisateur.

Productivité

Internet regorge de contes de fées sur le développeur 10x, et les gourous de l’IA générative aimeraient vous faire croire que cette technologie peut élever n’importe quel programmeur à ce niveau. La réalité est plus nuancée. Les développeurs ne passent pas 100 % de leur temps à écrire du code, pas plus que les médecins ne passent 100 % de leur temps à rédiger des ordonnances. La majorité des développeurs passe moins d’une heure par jour à coder. Le reste de leur temps est consacré à l’analyse, à la lecture, à l’apprentissage, aux tâches de maintenance, à la communication, etc. Jusqu’à présent, cette réflexion et cette consultation avec les collègues ne sont pas comprimées par l’emploi de LLM.

Il est difficile de trouver des chiffres précis sur la productivité parce qu’elle est difficile à définir et donc à mesurer. Une première estimation utile provient de Google même, qui a examiné le temps d’itération (de la connaissance du problème à la solution). Avec une première version de son propre assistant de complétion de code par l’IA, l’entreprise a pu constater un gain de temps de 6 %. Github affirme que le codage pur peut être environ 55 % plus rapide avec son CoPilot – bien qu’il précise dans le même temps que l’intervalle de confiance à 95 % de sa mesure est de [21 %-89 %]. En outre, l’adoption d’un outil n’apporte aucune valeur ajoutée si elle n’est pas accompagnée d’un parcours pour apprendre à l’utiliser de manière optimale (tout comme aujourd’hui encore, de nombreux employés de bureau perdent du temps avec Office en raison d’une connaissance ou d’une expérience insuffisante de tous les types de références, de formules et de raccourcis).

Le code généré fournit une solution initiale rapide, mais cette solution doit encore être comprise par le programmeur. Un score “pass@1” de 50 % signifie que la moitié des bouts de code générés nécessitent encore des ajustements manuels avant de passer les tests unitaires – sans parler de l’optimalité ou de la sécurité. Le code généré peut être complexe et utiliser des constructions qui dépassent le niveau de connaissance du programmeur. Le code généré est donc plus difficile à maintenir et à corriger que le code écrit manuellement. Un code généré qui n’a pas été correctement examiné et testé ajoute une dette technique considérable à un projet.

L’utilisation de plugins qui vont jusqu’à générer des blocs entiers de code et de documentation en un claquement de doigts (ou un peu plus lentement) n’est une bonne idée que si plusieurs autres aspects du processus d’ingénierie logicielle sont en ordre : des normes élevées doivent être maintenues dans tous les domaines en termes de stratégie de test, de code reviews, de documentation de code et de savoir-faire des développeurs.

Confidentialité

Les entreprises et les gouvernements ont rarement le luxe d’utiliser n’importe quel modèle de langue. Il existe non seulement des barrières contractuelles, mais aussi des questions de confidentialité, en particulier lors de l’utilisation du cloud. Après tout, on n’obtient une bonne suggestion de modèle de langue qu’en introduisant suffisamment d’informations au préalable. Ne pas tout mettre en place en interne implique inévitablement de donner à un tiers l’accès à vos données.

Le degré d’ouverture et de licence peut varier considérablement – à un extrême, tout est en “boîte noire” et uniquement accessible via le cloud/API (c’est là que vous trouverez OpenAI, Anthropic, Cohere et la plupart des autres start-ups établies). Celles-ci promettent dans les versions Enterprise parfois plus de garanties – mais vous n’avez pas d’autre choix que de les croire sur parole. À l’autre extrême, tout est en “open access” (libre accès) et sous licence permissive. Entre les deux, une entreprise peut également construire un modèle de langue en libre accès sur un dataset fermé. Au moins un de ces datasets a depuis été divulgué comme contenant des ebooks illégalement copiés et protégés par le droit d’auteur, ce qui constituera sans aucun doute un argument de poids dans le recours collectif intenté contre Meta sur ce sujet. Les ensembles de données des Code LLM Salesforce CodeGen et Tsinghua CodeGeeX ne sont pas non plus publics.

Transparence, licences, options de déploiement, prix, taille et scalabilité… l’importance relative de toutes ces caractéristiques dictera les outils que vous pourrez utiliser. Ceux qui souhaitent une transparence maximale seront souvent limités aux LLM en Open Access. Certaines licences ouvertes limitent en outre l’utilisation à des fins non commerciales. La nécessité d’accéder à des données de formation ou la facilité d’héberger soi-même une instance sur site limitent davantage les choix.

Conclusion

Les outils basés sur le dialogue (chatGPT et autres) peuvent vous être utiles en tant que développeur pour, entre autres, les tâches suivantes :

• Initialiser un projet/fichier/classe/configuration : créer une première version de quelque chose
• Correction de bugs et modification sous forme de questions-réponses
• Morceaux de code relativement indépendants

Les outils qui complètent le code ou remplissent le code manquant (type Github Co-Pilot) sont utiles, entre autres, pour :

• Compléter du code à partir d’exemples déjà réalisés
• Documenter le code
• Apporter des modifications au milieu d’un fichier plus volumineux

Pour un développeur, l’environnement de développement optimal est quelque chose de tout à fait personnel et chacun aura sa propre préférence. À notre avis, ces deux façons d’obtenir des suggestions de code sont quelque peu complémentaires, et une combinaison intelligente des deux peut permettre d’obtenir les meilleurs gains de productivité. Dans le même temps, nous tenons à dire qu’une gestion de projet saine, avec une attention portée à la qualité du code, aux tests, aux révisions, à la documentation, etc. est indispensable.

Le monde de l’IA est en pleine effervescence. De nouveaux modèles d’IA pouvant servir de base aux plugins IDE sont ajoutés avec une grande régularité. Pour les industries où la confidentialité du code est importante, les variantes open source sont très intéressantes. Même si les benchmarks montrent qu’ils sont encore moins performants aujourd’hui que les dernières initiatives commerciales basées sur le cloud, nous pouvons nous attendre à ce que de meilleures versions apparaissent à l’avenir. De nombreux efforts sont déjà déployés pour créer des modèles pouvant fonctionner sur du matériel grand public (certes haut de gamme).

P.S.

Quelques heures après la publication de cet article, HuggingFace annonce la venue de SafeCoder : une solution d’entreprise pour les assistants de codage basés sur LLM qui peut être déployée sur site. Huggingface fournit le tout dans des conteneurs qui peuvent être installés dans un data center propre et fournir des endpoints privés, ainsi que des plugins compatibles avec les principaux IDE. D’autres frameworks de déploiement général existent depuis un certain temps, notamment Seldon, BentoML et KServe, qui peuvent également héberger des LLM, TextSynth Server et GPT4All peuvent fonctionner comme des endpoints d’API. Cependant, vous avez toujours besoin de plugins pour les utiliser dans l’IDE lui-même, et pour effectuer les traitements préalables et postérieurs nécessaires – et s’ils ne sont pas fournis, vous devez en créer un vous-même ou modifier un plugin existant.

P.P.S.

Ces derniers mots à peine écrits, Meta a lancé CodeLLama, une variante de LLaMa 2 spécifiquement entraînée pour le code. Les médias sociaux suggèrent qu’il est possible de faire tourner la version originale avec 34 milliards de paramètres sur un ordinateur équipé de 4 GPU RTX3090 avec 24 GB de VRAM chacun, générant environ 20 tokens par seconde. Il est sans doute plus facile d’essayer la version de chat en ligne. Les versions quantisées suivront sans doute très prochainement, et nous attendons les premiers benchmarks sur les différents leaderboards.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

In een vorig artikel bespraken we op algemene wijze het potentieel van generatieve AI in de software development lifecycle. Laat ons nu eens kijken vanuit het standpunt van de developer: wat is de stand van zaken wat betreft het genereren van code, en waar moeten we nog rekening mee houden? Lang verhaal kort: AI-assistenten of -plugins voor IDEs zijn een zegen voor wie ze goed kan aanwenden, maar komen, zoals alle AI-systemen, ook met de nodige caveats.

Vooraf

De hype qua generatieve AI wordt onder andere gestuwd door krachtige taalmodellen – Large Language Models of LLMs. Zeker sinds GPT-3 uitkwam in 2020, slagen die erin om normaal uitziende teksten te schrijven van enige lengte. Van daar is het maar een korte sprong naar programmeertalen – die hebben immers ook een syntax en semantiek.

In de praktijk bestaan er talloze varianten van taalmodellen, die elk hun sterktes en zwaktes hebben, al naargelang de keuzes die de makers hebben gemaakt bij het trainen ervan, en al naargelang de trainingsdata die eraan ten grondslag liggen. Probeer bijvoorbeeld zelf enkele van de bestaande open source modellen uit op je eigen computer via de tool GPT4All (zie ook onze korte review van deze tool).

Computercode bestaat uit een collectie van tekstbestanden. Niets verhindert dat een taalmodel, in plaats van woorden, de verschillende tokens ( = grammaticale eenheden) waaruit code bestaat, probeert te voorspellen. In tegenstelling tot gewone tekst is er bij code echter veel minder ruimte voor fouten: de kleinste spelfout of variatie kan een stuk code ongeldig maken of iets helemaal anders laten uitvoeren.

Toch kunnen de allergrootste taalmodellen, zoals GPT-3.5 en later, vandaag uit eigen beweging vrij correcte stukken computercode produceren in een antwoord op een vraag. Deze functionaliteit is het gevolg van de massieve hoeveelheid tekst waarop ze getraind zijn, waaronder talloze tutorials, blogartikels, vragen en antwoorden uit populaire developerfora zoals StackOverflow, en gedocumenteerde code uit publieke code repositories zoals Github.

Babbelende badeentjes

Al sinds Socrates is de dialoog een beproefde manier om tot nieuwe inzichten te komen. Niet voor niets is rubber ducking een methode voor debugging die ter sprake komt in elke cursus software engineering. Er bestaan ondertussen verschillende plugins die een AI-powered chat-interface in de IDE zelf beschikbaar stellen (bvb deze voor VS Code , vele andere kunnen gevonden worden via de marketplaces voor VS Code of IntelliJ IDEA). Als die gebruikmaken van een externe cloud-dienst moet je daarbij enkel nog je eigen API-key ingeven.

Een dialogerende setting met een vraag-antwoord dynamiek kan goed aangewend worden voor het genereren van relatief op zichzelf staande stukken code, zonder te veel externe afhankelijkheden. In het algemeen kan je stellen dat je, voor het beste resultaat, alle noodzakelijke randvoorwaarden en aannames gemakkelijk in de dialoog zelf moet kunnen vermelden, zodat het binnen het context-venster van het taalmodel past. De use cases omvatten onder andere:

• From scratch genereren van een eerste versie van code of een configuratiebestand
• Genereren van relatief korte functies of procedures aan de hand van een beschrijving
• Genereren van op zichzelf staande code snippets: SQL queries, reguliere expressies, …
• Vragen om een aanpassing aan een stuk code of een configuratiebestand
• Debugging: fouten zoeken in niet-werkende code, vragen stellen over een error
• Laten uitleggen wat een stuk code doet

De grootste taalmodellen hebben ondertussen contextvensters van duizenden woorden waarin je alle nodige informatie kwijt kan. Een kleiner open-source taalmodel, lokaal geïnstalleerd op minder krachtige hardware, zal ongetwijfeld minder goed presteren. Enkele voorbeelden van conversaties met OpenAI’s GPT-4 staat hieronder – hieruit blijkt dat je al heel ver kan geraken met een paar welgemikte vragen (klik voor de volledige resolutie):

Code completion on steroids

Tijdens het ontwikkelen werkt een developer aan talloze bestanden in een IDE. Op willekeurige plekken in die bestanden moet er code aangepast, verwijderd of geschreven worden. Het bewerken van bestaande code op deze manier heeft weinig te maken met dialogeren, eigenlijk willen we hier eerder een geavanceerde auto-complete inzetten. Ook dat kunnen taalmodellen goed, maar de meest geschikte modellen zijn eerder diegene die getraind zijn op “fill in the middle” taken – en die dus rekening kunnen houden met de aanwezige code voor én na de plek die men aan het bewerken is.

Na het uitbrengen van GPT-3, werkte OpenAI samen met Microsoft (dat Github bezit) aan een gespecialiseerd taalmodel dat voor exact deze use case werd getraind. Deze variant werd Codex genoemd, en de eerste tool die ervan gebruikmaakte was Github CoPilot. Ondertussen zijn we al enkele versies verder, maar de plugins voor VSCode en IntelliJ werken nog op dezelfde manier: via een sneltoets in de editor kan men via CoPilot verschillende suggesties opvragen, gegenereerd door Codex, die zouden kunnen passen op de plek van de cursor.

Voor zover onze ervaring vandaag reikt, is de context die daarbij in rekening wordt genomen vandaag meestal beperkt tot (stukken van) de inhoud van het bewerkte bestand. Daarbij wordt uiteraard code geüploaded naar het taalmodel – let dus zeker op richtlijnen qua confidentialiteit bij gebruik van een externe dienst. Vooralsnog lijken we betere resultaten te krijgen bij programmeerprojecten die bestaan uit weinig grote bestanden, zoals webpagina’s met inline JavaScript, of Jupyter Notebooks in Python, waarbij vaak sprake is van 1 groot bestand dat doorlopen wordt waarin zowel de documentatie, de code als de output staat. In projecten met vele kleine bestandjes daarentegen, lijkt het moeilijker om goede suggesties te genereren, en is het belangrijker dat er extra documentatie aanwezig is in het geëditeerde bestand zodat er voldoende contextuele informatie is die het taalmodel kan aangrijpen.

Een van de interessantere alternatieven voor het commerciële Github CoPilot is StarCoder, een open source model van het BigCode initiatief van HuggingFace en ServiceNow. De performantie is weliswaar minder dan CoPilot, maar zij maken op vele andere vlakken, die mogelijk dealbreakers zijn in commerciële of publieke context, het verschil:

• Getraind op een open dataset: The Stack. Deze is weliswaar via scraping verzameld, maar bevat alleen code met permissieve softwarelicenties, en developers kunnen desgewenst alsnog hun code eruit laten verwijderen.
• Bevat een plagiaat-check tool, waarmee je kan controleren of de gegenereerde suggesties niet verbatim uit de (mogelijk copyrighted) trainingsdata zijn overgenomen.
• Voorzien van filter van gevoelige informatie, die emailadressen, API keys en IP adressen detecteert (niet 100% accuraat).
• Voorzien van instructies om het lokaal te installeren, evenals een VSCode plugin. Een IntelliJ plugin werd ondertussen ook ontwikkeld door een derde partij.
• Het standaardmodel is 15 miljard parameters groot en vergt minstens 60GB RAM of evenveel GPU memory (afhankelijk van of een GPU benut wordt of niet) om te kunnen gebruiken. Ondertussen bestaan ook kleinere modellen met 7, 3 of 1 miljard parameters, evenals “quantized” versies die gebruikmaken van 4bit datatypes zonder veel accuraatheidsverlies.

Deze zomer zagen nog enkele andere systemen het licht die goed scoren op vele benchmarks: WizardLM en de specifieke variant ervan WizardCoder, dat ondertussen wordt beschouwd als de open source state-of-the-art, en PanGu-Coder, waarmee ook Huawei zich heeft gelanceerd in de wereld van AI-assistants voor code. 

Achter de schermen

De StarCoder paper geeft een goed zicht op de werking van een taalmodel voor code. Het is zeker niet zo dat je je eigen codebase kan “inpluggen” om suggesties te krijgen die daarop zijn toegespitst. Als je echt zou willen finetunen (en die enorme inspanning doe je in principe alleen maar als je er niet raakt met slimme aanpassingen aan de prompt), komt er heel wat bij kijken, van preprocessing van de trainingsdata tot postprocessing van de rauwe output van het taalmodel. Leg de verwachtingen van finetuning ook niet te hoog: StarCoder deed het voor Python, maar haalde hooguit enkele procentpunten verbetering in vergelijking met het algemene model dat met alle programmeertalen overweg kon. Finetunen is moeilijk en er is geen garantie op succes; er bestaat zelfs een risico op overfitting wat tot slechtere resultaten kan leiden.

De belangrijkste stap daarbij is waarschijnlijk het verzamelen en schoonmaken van data. Die data bestaat uit code, maar niet alle code komt in aanmerking: je moet de code ook mogen gebruiken (licenties), en je hebt ze liefst zo correct mogelijk en geschreven in de programmeertaal die je wenst te ondersteunen. Code wordt ook verzameld uit issue trackers en commitgeschiedenis. Daarnaast kan je nog extra filteren om (bijna-)duplicaten te verwijderen, en wil je misschien hier en daar gewichten toekennen om de balans te bewaren: wat minder gewicht voor boilerplate code, en/of wat meer voor erg populaire repositories die waarschijnlijk van hogere kwaliteit zijn. Broncode kan gevoelige informatie bevatten die eerst geanonymiseerd of verwijderd moet worden, om te voorkomen dat die lekt of wordt gesuggereerd (IP adressen, paswoorden, identifiers, emailadressen, contactgegevens, …). Dit alles natuurlijk liefst zo automatisch mogelijk.

Broncode bestaat niet alleen uit code maar ook uit beschrijvingen, commentaren en andere informatie. In een formatteringsstap wordt de code daarom nog verrijkt, door het toevoegen van metadata en bijkomende tokens die bepaalde impliciete structuren expliciet maken. Dit kan implicaties hebben: als al deze preprocessing op de hele trainingsdataset is gebeurd, dan zal het resulterende model pas goed werken op nieuwe data als die dezelfde preprocessing heeft ondergaan. Het is dus mogelijk dat editorplugins die willen gebruikmaken van zo’n model, om een goed resultaat te bekomen, eerst gelijkaardige preprocessing moeten uitvoeren op de code die ze naar het taalmodel willen sturen.

Correctheid en andere benchmarks

Typisch voor LLMs, kan er geen sluitende garantie worden gegeven op de correctheid of volledigheid van wat zo’n plugin je voorschotelt, zowel syntactisch als semantisch. Die correctheid is uiteraard van belang: een stuk gegenereerde code moet niet alleen syntactisch correct zijn en foutloos compileren, maar ook semantisch betekenisvol zijn en goed runnen. De “pass@x” metriek is daarbij uitgegroeid tot belangrijke graadmeter. Ze drukt uit als een percentage, of een taalmodel voor een bepaalde opdracht na X pogingen de bijhorende testen succesvol kan passeren. “pass@1” is het percentage dat het taalmodel van de eerste keer het juiste antwoord heeft kunnen genereren, “pass@10” is het percentage waarbij minstens 1 van 10 pogingen correct was.

Er is een algemene nood in de wereld van generatieve AI om nieuwe modellen, die ondertussen bijna dagelijks verschijnen, te kunnen vergelijken met de state-of-the-art. Aan benchmarks is er dus geen gebrek, en er verschijnen er geregeld ook nieuwe en grotere. Handige samenvattingen zijn de “leaderboards”, die real-time tonen welke modellen de huidige state-of-the-art vertegenwoordigen volgens een waaier aan benchmarks. Het podium kan wekelijks veranderen. Enkele interessante algemene leaderboards zijn:

• Papers with Code: state-of-the-art in verschillende AI taken, voorzien van begeleidende papers
• Stanford HELM: benchmarkt een breed scala aan taken met focus op “human reasoning”
• LMsys.org FastChat: focus op chatbot-vaardigheden
• HuggingFace OpenLLM leaderboard
• LLM-Leaderboard

Specifiek voor code zijn er benchmarks die min of meer werken zoals een programmeerwedstrijd. Het idee is om een set opdrachten te geven aan het taalmodel, de resultaten automatisch te evalueren, en de “pass@1” en zo mogelijk enkele andere metrieken te meten. Vaak neemt dat een “fill in the function”-vorm aan: gegeven een beschrijving van input en output en een functieheader, moet de inhoud van de functie gegenereerd worden. Een nadeel is dat dit soort problemen soms weinig representatief is voor dat waarmee de doorsnee developer wordt geconfronteerd. Interessante initiatieven zijn onder andere:

• HuggingFace Big Code Models leaderboard (enkel open LLMs)
• Microsoft CodeXGLUE: evaluatie van verschillende subtaken volgens methodes bekend uit Natural Language Processing. Hun leaderboard lijkt af te hangen van vrijwillige contributie en enigszins onvolledig.
• Papers with Code heeft aparte secties voor genereren van code , genereren van documentatie, synthese van hele programma’s en bugfixing
• De HumanEval dataset en MBPP dataset: typische programmeerproblemen (Python)
• De DS-1000 dataset: een set van concrete data science / data processing problemen
• HumanEval-X of MultiPL-E: multi-language versies van HumanEval, meet performantie in meerdere programmeertalen

Dat een gegenereerd stuk code de testen overleeft betekent natuurlijk nog niet dat het ook veilige code is of “best practices” volgt. Er zijn ondertussen voorbeelden genoeg bekend van gegenereerde code die vatbaar blijkt te zijn voor buffer overflows, SQL injection, en andere klassieke risico’s. De “Asleep at the Keyboard” security benchmark bestaat uit 89 code generation scenario’s gebaseerd op de MITRE top-25 vulnerability lijst. Uit de Starcoder paper blijkt dat zelfs de beste modellen in 40% van deze scenario’s toch nog onveilige code genereren. Ook lijkt er nauwelijks verschil te merken tussen de beste modellen en de rest – een beter model kiezen lijkt wel te zorgen voor syntactische correctere resultaten, maar vooralsnog niet voor veiliger code. Mogelijk moet daarom eens gekeken worden naar de trainingsdata zelf, waar onveilige code nog beter uitgefilterd zou moeten worden. In ieder geval moeten we op dit moment adviseren: het gebruik van gegenereerde code in een project moet absoluut gepaard gaan met een robuust beleid inzake testing en acceptatie.

Performantie

Specifiek wat betreft computationele vereisten, zijn het Huggingface OpenLLM-perf leaderboard en de benchmarks op de website van TextSynth Server interessante bronnen. Die laatste toont enkele cijfers over performantie, die handig zijn voor wie met het idee speelt om het zelf te gaan hosten. Wie het zonder GPU doet, kan met het LLaMa2 model van 13 miljard parameters rekenen op een snelheid van 12 tokens per seconde, gegeven een relatief high-end EPYC 7313 serverprocessor. Een token in computercode is soms maar 1 karakter, dus aan dat tempo moet je soms een tiental seconden wachten op een code completion suggestie. De recentste RTX-4090 grafische kaart kan het 7x sneller, maar nog steeds niet zo snel dat je het in milliseconden zou uitdrukken.

De geheugenvereisten zijn evenredig met het aantal parameters van een model, en de generatiesnelheid omgekeerd evenredig. Als een grove benadering mag je aannemen dat een model van 13 miljard parameters, ook 13 miljard berekeningen moet maken voor elk output token, zelfs al is het maar 1 karakter lang. Daarnaast vereist het, als elke parameter een 32-bit getal is, minstens 52GB opslagruimte en evenveel (V)RAM-geheugen. Een “quantization“, die de parameters afrondt naar 8-bit of zelfs 4-bit, kan die geheugenvereiste evenredig doen dalen.

GPT4All laat toe het zelf eens te proberen op je eigen hardware. Dit geeft een idee van de enorme rekenkracht die OpenAI , Microsoft Azure, of Amazon AWS inzetten om hun modellen, die veelal nog groter zijn dan de beschikbare Open Access LLMs, zo snel te kunnen doen draaien als zij dat aanbieden. Er wordt gesproken van investeringen van miljarden dollars in hardware, zodanig groot dat ze de wereldwijde markt destabiliseren.

Zelfs open source oplossingen zijn allesbehalve lightweight te noemen, ondanks verregaande initiatieven tot optimalisatie. Je mag er alleszins van uitgaan dat het lokaal deployen alleen maar haalbaar is op recente en krachtige hardware. Een vlotte user experience kan je momenteel nog niet verwachten van een lokale installatie op de doorsnee kantoorlaptop.

Productiviteit

Het internet staat vol sprookjes over de 10x developer, en goeroes van generatieve AI zouden u graag doen geloven dat deze technologie elke programmeur tot dat niveau kan verheffen. De realiteit is hardnekkiger. Developers spenderen om te beginnen geen 100% van hun tijd aan het schrijven van code, net zomin als dokters 100% van hun tijd voorschriften schrijven. Het merendeel van developers spendeert minder dan 1 uur per dag aan het effectief schrijven van code. De rest van de tijd gaat naar analyseren, lezen, leren, onderhoudstaken, communicatie,… Dat denkwerk en het overleg met de collega’s wordt vooralsnog niet gecomprimeerd door LLMs in te zetten.

Het is moeilijk om harde cijfers te vinden over productiviteit omdat het moeilijk te definiëren en dus te meten is. Een nuttige eerste schatting komt van Google zelf, die de iteratietijd (van kennisname van het probleem tot oplossing) onder de loep nam. Met een eerste versie van hun eigen AI code completion assistent, konden zij 6% tijdswinst noteren. Github zelf beweert dat het pure codeerwerk zo’n 55% sneller kan met hun CoPilot – al zeggen ze er in één adem bij dat het 95%-confidence interval van hun meting [21%-89%] is. De adoptie van een tool brengt bovendien geen meerwaarde als ze niet gepaard gaat met een traject om ze optimaal te leren benutten (net zoals vandaag nog vele kantoormedewerkers tijd verliezen met Office door onvoldoende kennis of ervaring met alle types van referenties, formules en snelkoppelingen).

Gegenereerde code biedt wel snel een eerste oplossing, maar die oplossing moet nog steeds begrepen worden door de programmeur. Een “pass@1” score van 50%, betekent dat de helft van de gegenereerde code snippets nog manuele aanpassingen behoeft voordat ze de unit tests passeert – en dan spreken we nog niet over optimaliteit of veiligheid. Gegenereerde code kan complex zijn en gebruikmaken van constructies die boven het kennisniveau van de programmeur liggen. Dat maakt gegenereerde code moeilijker om te onderhouden en te debuggen dan code die manueel geschreven is. Gegenereerde code die onvoldoende werd gereviseerd en getest, voegt aanzienlijke technical debt toe aan een project.

Het gebruik van plug-ins die zo ver gaan dat ze hele blokken code en documentatie met een vingerknip (of iets trager) kunnen genereren, is slechts een goed idee wanneer verschillende andere aspecten van het software engineering proces op orde zijn: er moeten over de hele lijn hoge standaarden aangehouden worden wat betreft teststrategie, code reviews, documenteren van code en kenniscompetenties van de developers.

Vertrouwelijkheid

Bedrijven en overheden hebben zelden de luxe om eender welk taalmodel te benutten. Er zijn niet alleen contractuele drempels, maar ook vragen over confidentialiteit, zeker bij gebruik van de cloud. Een goede suggestie van een taalmodel krijg je immers alleen door eerst voldoende informatie te uploaden. Als je niet alles in-house opzet, impliceert dat onvermijdelijk dat je een derde partij inzage geeft in jouw gegevens.

De mate van openheid en licentiëring kan aanzienlijk verschillen – in het ene uiterste is alles “black box” en enkel via cloud/API toegankelijk (hier vind je OpenAI, Anthropic, Cohere en de meeste andere gevestigde startups). Deze beloven in Enterprise versies soms meer garanties – maar je hebt nog steeds geen andere optie dan ze daarin te geloven op hun woord. In het andere uiterste is alles “open access” en permissief gelicentieerd. Daartussenin kan een bedrijf ook een Open Access taalmodel bouwen op een gesloten dataset. Van minstens 1 zo’n dataset is ondertussen uitgelekt dat ze illegaal gekopieerde auteursrechtelijk beschermde ebooks bevat, wat ongetwijfeld een sterk argument wordt in de class action lawsuit over het thema tegen Meta. De datasets van de code-LLMs Salesforce CodeGen en Tsinghua CodeGeeX zijn evenmin publiek.

Transparantie, licentiëring, deployment mogelijkheden, prijszetting, grootte en schaalbaarheid,… het relatief belang van al deze kenmerken zal dicteren welke tools je kan gebruiken. Wie maximale transparantie wil, zal sowieso vaak beperkt zijn tot Open Access LLMs. Sommige open licenties beperken het gebruik daarnaast tot niet-commerciële doeleinden. Een noodzaak tot inzage in de trainingsdata of gemakkelijke voorzieningen om zelf on-premise een instantie te kunnen hosten, beperkt de keuzemogelijkheden nog verder.

Conclusie

Dialoog-gebaseerde tools (chatGPT en aanverwanten) kan je als developer nuttig inzetten bij o.a.:

• Het initialiseren van een project/bestand/klasse/configuratie: maak een eerste versie van iets
• Het debuggen en aanpassen op vraag-antwoord-wijze
• Relatief onafhankelijke snippets van code

Tools die code aanvullen of ontbrekende code invullen (type Github Co-Pilot) komen dan weer goed van pas bij o.a.:

• Het vervolledigen van code aan de hand van eerder voorkomende voorbeelden
• Het documenteren van code
• Het maken van veranderingen midden in een groter bestand

De optimale ontwikkelomgeving is voor een developer iets vrij persoonlijks en iedereen zal een eigen voorkeur hebben. In onze ogen zijn deze twee manieren om codesuggesties te krijgen enigszins complementair, en het slim combineren van de twee kan voor de meeste productiviteitswinst zorgen. In één adem willen we daarbij wel zeggen dat een gezond projectmanagement, met aandacht voor codekwaliteit, testing, reviews, documentatie, … daar wel onontbeerlijk bij hoort.

De AI-wereld is in volle beweging. Er komen met de regelmaat van de klok nieuwe AI-modellen bij die kunnen dienen als back-end voor IDE-plugins. Voor industrieën waar vertrouwelijkheid van code belangrijk is, zijn de open-source varianten erg interessant. Zelfs al tonen benchmarks dat die vandaag nog minder performant zijn dan de laatste commerciële cloud-based initiatieven, kunnen we verwachten dat daar in de toekomst ook betere versies van zullen verschijnen. Er zijn alvast veel inspanningen om modellen te maken die op (weliswaar high-end) consumentenhardware kunnen draaien.

P.S.

Enkele uren na het publiceren van dit artikel, kondigt HuggingFace SafeCoder aan: een enterprise-level oplossing voor LLM-gebaseerde coding assistants die on-premise uitgerold kan worden. Huggingface voorziet alles in containers die in het eigen datacenter geïnstalleerd kunnen worden en private endpoints voorzien, én voorziet compatibele plugins voor de belangrijkste IDEs. Andere algemene deployment frameworks bestaan al langer – o.a. Seldon, BentoML en KServe kunnen LLMs hosten, ook TextSynth Server en GPT4All kunnen functioneren als API endpoint. Je hebt echter nog steeds plugins nodig om er gebruik van te kunnen maken in de IDE zelf, en om de nodige pre- en postprocessing te doen – en als ze niet voorzien worden, moet je er zelf eentje maken of een bestaande plugin aanpassen.

P.P.S.

Deze laatste woorden waren nog niet koud of Meta lanceerde Code LLama , een LLaMa 2 variant specifiek getraind voor code. Op sociale media wordt vermeld dat het mogelijk is de originele versie met 34 miljard parameters te draaien op een computer uitgerust met 4 RTX3090 GPUs met elk 24GB VRAM, waarmee ongeveer 20 tokens/seconde gegenereerd kunnen worden. Gemakkelijker is misschien de online chat-versie uit te proberen. Quantized versies zullen ongetwijfeld erg snel volgen, en we verwachten de eerste benchmarks eerstdaags op de verschillende leaderboards.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

De moderne “stack” voor applicaties in de Cloud, van IaaS (Infrastructure as a Service) over PaaS (Platform as a Service) tot SaaS (Software as a Service), is stilaan een gekend plaatje. Maar de strikte scheiding tussen het virtualiseren van infrastructuur, het automatiseren van middleware en het aanbieden van applicaties, en dit alles “als een dienst”, hoeft soms helemaal niet zo strikt te zijn.

In de Application Platform as a Service (aPaaS) branche, die reeds in een vorige blogpost uit de doeken werd gedaan, kan men bijvoorbeeld verschillende soorten aPaaS onderkennen, die variëren van een dunne schil boven IaaS, tot een soort van “Applicatie-Ontwerp-SaaS” oplossingen. In deze blogpost een korte verkenning van deze wondere wereld.

1. Vlak boven de infrastructuur

Sommige PaaS platformen bieden geen ingebouwde applicatieserver of database aan, maar vormen een laag bovenop de infrastructuur die het gebruikers makkelijker maakt om de nodige technologie geïnstalleerd en geconfigureeerd te krijgen op (niet noodzakelijk) virtuele servers.

Een voorbeeld is Cloudify. Bij deze aPaaS kan men als gebruiker een applicatie definiëren aan de hand van een recept. Dit recept stuurt men dan naar een Cloud met Cloudify ondersteuning, waardoor het platform de nodige “ingrediënten” van het recept in gebruik zal nemen. Het grote voordeel, zo stelt Cloudify, is dat recepten niet Cloud-specifiek zijn, en dat ze dus op de meeste Cloud systemen kunnen werken. Dit is b.v. nuttig voor het migreren van applicaties van de ene Cloud naar de andere.

2. Middleware als dienst

De bekendste aPaaS platformen bieden doorgaans een sterke integratie met web- en applicatieservers, en met diensten voor gegevensopslag. Sommige focussen zich op ondersteuning van een welbepaalde technologie, andere op het werken met zoveel mogelijk van de populairdere frameworks van het moment.

Een belangrijk kenmerk van platforms op dit niveau, en voor mij één van doorslaggevend belang, is dat er abstractie wordt gemaakt van de onderliggende infrastructuur. Niet langer moet je rekening houden met op welke server wat komt te staan: je deployt naar een platform, en dit platform kiest transparant welke delen van jouw applicatie op welke resources terecht komen. Welke en hoeveel infrastructuur onderliggend zijn aan het platform, daar hoef je als ontwikkelaar dan minder wakker van te liggen. Bovendien is er bij platformen met deze eigenschap doorgaans enige ondersteuning voor failover, elastisch schalen en multi-tenancy (voor ontwikkelaars).

Architectuur in een Openshift Node

Dit keer kiezen we Red Hat OpenShift als voorbeeld. Dit aPaaS platform bestaat zowel in de publieke cloud, als in een “on premise” installeerbare versie, waardoor je het dus kan gebruiken voor een private Cloud. De basis van het platform is open source.

Wanneer we op deze PaaS inloggen, krijgen we een web console te zien met behulp van dewelke we applicaties kunnen deployen in de Cloud. We moeten daarbij kiezen uit welke “cartridges” een app bestaat. Cartridges kan men beschouwen als een technologisch afgezonderde module, e.g. een MySQL cartridge. daarnaast kiezen we ook hoeveel “gears” de applicatie krijgt, en of ze schaalbaar zal zijn. Gears (letterlijk vertaald: tandwielen of radartjes) zijn eenheden van computatie, ze stellen een bepaalde hoeveelheid processorkracht, geheugen en opslag voor, los van de onderliggende infrastructuur. De cartridges van de applicatie komen dan terecht op de gears en die laatste worden transparant gedeployed op het platform.

3. (Semi-)Grafisch Applicaties ontwikkelen

Dichter bij de SaaS-laag van Cloud platformen, vinden we producten terug die doorgaans gespecialiseerd zijn in slechts enkele onderliggende implementatie-, server- en database-technologieën. Deze specialisatie laat echter wel verregaande automatisatie toe, waardoor het mogelijk wordt om eenvoudige tot matig complexe applicaties te ontwikkelen zonder code te schrijven, of dit slechts in beperkte mate te doen.

Zoho Creator is bijvoorbeeld zo’n platform. Het richt zich vooral op applicaties die sterk gericht zijn op online databases. Zo kan men via drag and drop webformulieren aanmaken, waarvan de data dan in zo’n database zal terechtkomen en eventueel in een complexe workflow. Voorts kan men acties en triggers voorzien rond data-access. Verder kan men bepaalde taken automatiseren, zoals het versturen van emails en genereren van rapporten. Html pagina’s kan men dan verder aanpassen m.b.v. html en het zogenaamd “Deluge Script”, een taal eigen aan het platform.

 Besluit

Deze 3 voorbeelden van een genuanceerdere definiëring van wat aPaaS nu eigenlijk inhoudt, zijn, opnieuw, niet te beschouwen als de enige correcte onderverdeling. In de software-industrie zijn er ondertussen tientallen producten die zichzelf volgens de definitie PaaS mogen noemen, en nog veel meer die zichzelf de noemer geven zonder het strikt genomen te zijn, allemaal met hun eigen specifieke invulling van de term. Al deze producten staan allicht net iets verder of net iets minder ver van IaaS/SaaS dan de voorbeelden hier omschreven.

Dit is voor ontwikkelaars zowel een voordeel als een nadeel: Aan de ene kant biedt het voor elk wat wils, en voor elke applicatie die moet worden geschreven kan men het “ideale platform” vinden. Anderzijds kan dit standaardisatie tegenwerken, en laat dat nu net één van de kenmerken zijn die een aPaaS platform nuttig maken.

Over aPaaS verschenen onlangs een Research Note en Presentatie.

Wat is PaaS?

Productiviteitsverhoging is nu precies de focus van Platform as a Service (PaaS). Een PaaS is een verzameling van diensten voor de infrastructuur van applicaties. In het cloudverhaal kan men PaaS situeren tussen Software as a Service (SaaS – applicatielaag) en Infrastructure as a Service (IaaS – hardwarelaag). De aangeboden diensten zijn onder andere: het applicatieplatform, integratie, databases en business process management. Vandaag wordt er vooral geconcentreerd op de meer specifieke aPaaS: application Platform as a Service.

aPaaS platformen ondersteunen de ontwikkeling en in-productiestelling van applicaties in de cloud. Ze zijn als het ware een uitgebreide applicatieserver in de cloud en ondersteunen multi-tenancy en elastische, horizontale schaalbaarheid van applicaties. aPaaS-platformen bieden bijgevolg nieuwe mogelijkheden aan developers om makkelijker en sneller applicaties te ontwikkelen.

In eerste instantie lag de focus van PaaS-oplossingen op het aanbieden van platform services in de public cloud. Al snel werd duidelijk dat dezelfde technologie toegepast kan worden binnen een organisatie zelf, in een private cloud. Het private aspect is onder andere belangrijk vanwege de confidentialiteit van de gegevens.

Wat zijn de beoogde voordelen?

PaaS-platformen beloven om een aantal obstakels weg te nemen die beletten om productiever toepassingen te ontwikkelen. Ze zijn zo ontworpen dat ontwikkelaars zich kunnen focussen op de toepassingscode en zich niet moeten bezighouden met het opzetten en configureren van servers, storage en middleware stacks. Die worden immers aangeboden “als een service”.

Dit zijn een aantal beoogde voordelen van PaaS:

• Via self-service kunnen ontwikkelaars on-demand een application stack deployen. Met andere woorden, de provisioning van alle nodige componenten (frameworks, middleware, etc.) gebeurt automatisch.
• Toepassingen kunnen automatisch geschaald worden bij een toenemende belasting.
• De huidige deployment methodologie op basis van verschillende omgevingen (ontwikkeling, test, acceptatie, productie) kan worden behouden, maar de overgang tussen de verschillende omgevingen verloopt veel vlotter omdat elke omgeving gebaseerd is op dezelfde application stack, en men dus een homogenere infrastructuur bekomt.
• Indien gewenst kan een toepassing eenvoudig overgezet worden van de ene cloud naar de andere. Zo kan een prototype van een applicatie die ontwikkeld is op een public cloud infrastructuur overgezet worden naar een private infrastructuur of kan een toepassing die gehost is op een private infrastructuur gebruik maken van een public cloud infrastructuur om bijkomende load op te vangen.

Veel van de beoogde voordelen steunen op doorgedreven automatisatie en standaardisatie van het ontwikkelings- en deploymentproces.

Bepaalde PaaS-oplossingen bieden daarnaast ook ondersteuning voor verschillende programmeertalen en frameworks. Architecten en ontwikkelaars kunnen dan de meest aangepaste programmeertaal en framework kiezen voor het type toepassing dat moet ontwikkeld worden, wat de productitiveit ten goede kan komen. Alhoewel het geen algemene eigenschap is van PaaS, is dit toch de moeite waard om te vermelden.

Welke uitdagingen kunnen we verwachten?

Uiteraard brengen PaaS-oplossingen ook een aantal uitdagingen met zich mee. Dit zijn een aantal aandachtspunten:

• Er moet over gewaakt worden dat ontwikkelaars zoveel mogelijk gebruik kunnen blijven maken van hun bestaande competenties, zowel op vlak van programmeertalen en frameworks, maar ook op vlak van de benodigde tools.
• Om tot een zo hoog mogelijke graad van automatisatie te komen moeten een aantal services geïntegreerd worden in de PaaS-oplossing en als plug-and-play componenten kunnen aangeboden worden aan ontwikkelaars. Denk daarbij aan gebruikersbeheer en toepassingsmonitoring.
• Het eenvoudiger maken van het leven van de ontwikkelaars zou geen extra belasting mogen teweegbrengen voor operations. Een PaaS-oplossing zou een win-win moeten zijn voor alle betrokkenen in het ontwikkelproces.
• In hoeverre kan het deployment-proces geautomatiseerd worden in al zijn aspecten? Zijn de nodige deployment parameters beschikbaar voor bijvoorbeeld database-connecties of message queues? Moeten er configuratie-aanpassingen gebeuren op niveau van de infrastructuur?

Het valt dus te bezien in hoeverre PaaS-platformen effectief tegemoet komen aan de vraag naar een hogere productiviteit in toepassingsontwikkeling. In ieder geval is de trend naar dergelijke platformen ingezet waarbij de focus ligt op automatisatie en standaardisatie die toelaat om als het ware een assembleerlijn te maken om toepassingen efficiënter te ontwikkelen en ze sneller te kunnen opleveren.

Hoewel de markt van PaaS-oplossingen nog in zijn kinderschoenen staat, zijn er vandaag al veel verschillende oplossingen beschikbaar, met elk hun eigen invalshoek. Dat is echter voer voor een volgende blogpost.

Over aPaaS zijn een Research Note en Presentatie beschikbaar.

Le code mort est le code devenu inutile car plus jamais utilisé dans une application.

Pourquoi du code mort ? Lors des opérations de maintenance correctives ou évolutives les développeurs (disciplinés) créent assez spontanément une nouvelle version de leur code … mais n’élimine que trop (très) peu souvent le code devenu inutile. Au mieux est-il commenté, ce qui finira de toutes façons par constituer une gêne. Autre phénomène tout aussi fréquent : la désynchronisation des commentaires d’avec le code (ou comment apparaissent des commentaires eux-mêmes morts).

Le code mort rend le code utile plus confus et plus complexe, avec comme conséquence immédiate une augmentation des coûts de maintenance.

Selon certaines études le pourcentage de code mort se situerait entre 10 et 15% pour les applications de 5 ans d’âge, et entre 30 et 40% pour les applications au delà de 20 ans d’âge.

D’autres études situent le coût d’une ligne de code autour de 3 à 4 euros, tests compris. L’éradication du code mort peut donc constituer une belle économie sur le budget de maintenance.

L’intérêt pour l’éradication du code mort est encore plus vrai et immédiat dans le cas d’une migration. Confronté par exemple à l’abandon de son mainframe (voulu ou obligé) toute organisation aurait intérêt à se poser la question de l’opportunité d’une telle opération avant de se lancer dans la migration de son code. Que ce soit par la voie d’une traduction automatisée ou par réécriture.

Dans le premier cas la facturation se faisant généralement à la ligne de code l’explication est simple. Et à supposer que la balance entre la réduction du coût de la traduction et le coût de l’éradication du code mort ne soit pas positive , ou pas assez, la justification peut être facilement trouvée dans la volonté de profiter du moment de la migration pour réduire la dette technique (dont l’éradication du code mort est une composante importante).

Dans le second cas, la qualité des documentations étant habituellement ce que nous savons tous, éliminer le code mort ne pourra être que profitable lorsqu’il s’agit de “plonger” dans le code pour en rédécouvrir la finalité. Pas de temps perdu à la redécouverte de code inutile, et pas de parasitage sur la compréhension du code utile par le code inutile.

Une opération d’éradication du code mort se doit d’être automatisée. Des outils existent pour ce faire, tel que l’outil Kris de la firme Telebig, spécialisée dans la migration de systèmes legacy. Il est possible de télécharger une version gratuite qui vous permet de situer votre code mort mais pas de l’éliminer. Il semble que la solution devrait à terme être rendue disponible en mode SaaS.

L’éradication du code mort ? Un outil de réduction des coûts, de gestion de la qualité et une source d’économie sans doute importante dans une opération de migration.

Tijd dan voor een denkoefening: we gaan de klassieke manier van ontwerpen toepassen op de werking van een McDonalds restaurant…

Synchrone verwerking

Bij McDonalds is de verwerking van de bestellingen ontkoppeld van het vervaardigen van de hamburgers.  Beeld u in dat een verkoper verantwoordelijk zou zijn voor de hele (verticale) keten.   Hij zou de bestelling opnemen, de hamburger klaarmaken,de afrekening geven en slechts dan de volgende klant bedienen.  Als deze handeling 5 minuten duurt, kun je met één verkoper 12 klanten kunnen bedienen per uur.

Hij zou niet weten dat de volgende bestelling identiek zou zijn.. Hij zou voortdurend van context moeten veranderen (handen wassen), geld in ontvangst nemen.   Ook zou er erg moeilijk samengewerkt kunnen worden tussen de verschillende verkopers. Niet echt efficiënt dus.

Geen concurrency control (volledige parallellisatie)

Wat als je 24 klanten per uur wil bedienen? Per veelvoud van 12 moet er een extra verkoper aangeworven worden.  En wat als op een bepaald moment  deze 12 klanten tegelijk zouden aankomen?  De 12de zou een uur moeten wachten…

Maar wacht — deze verkoper kan misschien wel verschillende bestellingen tegelijk aannemen? (cf. multithreading) In het extreme geval wordt elke nieuwe bestelling meteen door een verkoper behandeld.  Hij is dan tegelijk bezig met het afhandelen van een betaling, het maken van een paar hamburgers, het opnemen van enkele bestellingen.  Iedereen ziet wel in dat de efficiëntie van deze verkoper drastisch zal dalen door deze “parallellisatie” –– hij beschikt immers slechts over beperkte resources (kan bv. maar N woorden per minuut schrijven – I/O)

Het is duidelijk dat er een optimale trade-off moet gevonden worden tussen de hoeveelheid parallellisatie (# tegelijk behandelde requests door een machine) en de grootte van de wachtrijen.  Stel dan nog dat je “oneindig” veel verkopers kunt aannemen… Op een bepaald moment is er een plaatsgebrek, niet?  Het evenwicht bevindt zich typisch niet aan een van de extremen en hangt af van de bezoekpatronen van de McDanolds —  misschien komen er nooit 12 mensen tegelijk aan?

Centraal register met recepten (centrale database)

Omwille de kwaliteit te garanderen, stelt de chef-kok een centraal register op waarin beschreven staat hoe elke hamburger bereid moet worden.  Omdat de chef zeker wil zijn dat de juiste recepten gevolgd worden, is het een verplichting  om het register steeds te raadplegen voor het klaarmaken van een hamburger.  5 verkopers kunnen wel samen lezen, maar als de chef een wijziging aanbrengt, is het register niet meer zichtbaar.

Wat als er 50 verkopers een recept willen lezen? Of wat als er heel vaak wijzigingen gebeuren?  Hoeveel verkopers er ook aangeworven worden, de bottleneck bevindt zich op het centraal register.  En wat als iemand het register per ongeluk onleesbaar maakt?

Caching aan het eind van de keten

Een ingrediënt voor een bepaald type hamburger is niet meer in stock.  Het is dus onmogelijk om deze hamburger te bereiden.   Omdat de verkoper echter geen korte-termijn geheugen heeft (geen cache), moet hij telkens het recept gaan opzoeken in het centraal register.  Hier haalt hij de ingrediënten op en vraagt of ze nog beschikbaar zijn.  Niet dus — de verkoper loopt terug naar de klant en brengt het spijtige nieuws. Hij loopt onnodig heen, en weer.

Bottom line

Het is belangrijk om bepaalde ontwerp-reflexen in vraag te stellen. Vaak zijn het dogma’s die niet universeel geldig zijn en een serieuze performantie, beschikbaarheid en schaalbaarheidsimpact hebben.

“Een mens is niet gemaakt om alleen te leven,
en vanaf twee maakt ge ruzie“.

Of, het gezond omgaan met conflicten maakt een wezenlijk deel uit van elke relatie. Deze les geldt ook voor een professionele relatie: het ontwikkelen van een applicatie gebeurt immers steeds in team.  Het succes van het uiteindelijke resultaat is volgens mij dan ook meer een gevolg van een vlotte samenwerking dan van de individuele competenties.

Hoewel dit al reeds begin jaren ’70 als cruciale succesfactor werd opgetekend, wordt het belang hiervan volgens mij onderkend, en wordt er (bijvoorbeeld tijdens aanwerving) teveel gefocused op technische competenties (die gemakkelijk aangeleerd worden als de nodige basis aanwezig is), In deze context stootte ik op het interessant artikel over “Egoless Programming”.

Voor meer informatie verwijs ik naar het artikel The Ten Commandments of Egoless Programming – ik herneem kort de tien geboden:

— 1 —
Understand and accept that you will make mistakes.

— 2 —
You are not your code.

— 3 —
No matter how much “karate” you know,
someone else will always know more.

— 4 —
Don’t rewrite code without consultation.

— 5 —
Treat people who know less than you
with respect, deference, and patience.

— 6 —
The only constant in the world is change.

— 7 —
The only true authority stems from
knowledge, not from position.

— 8 —
Fight for what you believe,
but gracefully accept defeat.

— 9 —
Don’t be “the guy in the room.”

— 10 —
Critique code instead of people —
be kind to the coder, not to the code.