Principaux piliers de GPT Pilot
Pour que l'IA puisse créer une application pleinement fonctionnelle, un développeur doit être impliqué dans le processus de création de l'application. Il doit être en mesure de modifier le code à tout moment et GPT Pilot doit continuer à travailler avec ces changements (par exemple, ajouter une clé API ou résoudre un problème si l'IA est bloquée).
L'application doit être écrite étape par étape comme le ferait un développeur. Supposons que vous souhaitiez créer une application simple et que vous sachiez tout ce qu'il faut coder et que vous ayez toute l'architecture en tête. Même dans ce cas, vous ne la coderez pas entièrement, puis vous l'exécuterez pour la première fois et vous déboguerez tous les problèmes en même temps. Vous allez plutôt mettre en œuvre quelque chose de simple, comme ajouter des itinéraires, l'exécuter, voir comment cela fonctionne, puis passer à la tâche suivante. De cette manière, vous pouvez résoudre les problèmes au fur et à mesure qu'ils se présentent. Il devrait en être de même lorsque l'IA code. Elle commettra certainement des erreurs, mais pour qu'elle ait plus de facilité à résoudre les problèmes et pour que le développeur comprenne ce qui se passe, l'IA ne doit pas cracher toute la base de code d'un seul coup. Au contraire, l'application doit être développée étape par étape, comme le ferait un développeur : par exemple, établir des itinéraires, ajouter une connexion à la base de données, etc.
L'approche doit être évolutive afin que l'IA puisse créer une application prête pour la production.
- Remontée du contexte : Pour résoudre chaque tâche de développement, la taille du contexte du premier message envoyé au LLM doit être relativement la même. Par exemple, la taille du contexte du premier message du LLM lors de la mise en œuvre de la tâche de développement n° 5 doit être plus ou moins la même que celle du premier message lors de la mise en œuvre de la tâche n° 50. Pour cette raison, la conversation doit être ramenée au premier message à chaque tâche.
- Les conversations récursives sont des conversations LLM qui sont configurées de manière à pouvoir être utilisées "récursivement". Par exemple, si GPT Pilot détecte une erreur, il doit la déboguer, mais disons que, pendant le processus de débogage, une autre erreur se produit. Dans ce cas, GPT Pilot doit arrêter le débogage du premier problème, corriger le second, puis revenir à la correction du premier problème. Il s'agit d'un concept très important qui doit fonctionner pour permettre à l'IA de construire elle-même des applications importantes et évolutives. Cela fonctionne en rembobinant le contexte et en expliquant chaque erreur dans la récursion séparément. Une fois que l'erreur la plus profonde est corrigée, on remonte dans la récursion et continuons à corriger cette erreur. Nous procédons ainsi jusqu'à ce que toute la récursion soit terminée.
- TDD (Test Driven Development) : Pour que GPT Pilot soit capable de faire évoluer la base de code, il devra être capable de créer du nouveau code sans casser le code précédemment écrit. Il n'y a pas de meilleure façon de le faire que de travailler avec la méthodologie TDD. Pour chaque code que GPT Pilot écrit, il doit écrire des tests qui vérifient si le code fonctionne comme prévu, de sorte que chaque fois que de nouvelles modifications sont apportées, tous les tests précédents peuvent être exécutés.
L'idée est que l'IA ne pourra pas (du moins dans un avenir proche) créer des applications à partir de zéro sans que le développeur ne soit impliqué. C'est pourquoi ils ont créé un outil interactif qui génère du code, mais qui exige également que le développeur vérifie chaque étape afin qu'il comprenne ce qui se passe et que l'IA ait une meilleure vue d'ensemble de toute la base de code.
Comment fonctionne GPT Pilot ?
Voici les étapes suivies par GPT Pilot pour créer une application
- Vous entrez le nom de l'application et sa description
- Le Product Owner agent pose quelques questions pour mieux comprendre les besoins.
- Le Product Owner agent rédige des histoires d'utilisateurs et vous demande si elles sont toutes correctes (ce qui l'aide à créer le code plus tard).
- L'Architect agent rédige les technologies qui seront utilisées pour l'application.
- Le DevOps agent vérifie si toutes les technologies sont installées sur la machine et les installe si ce n'est pas le cas.
- Le Tech Lead agent rédige les tâches de développement que le développeur devra mettre en œuvre. Il s'agit d'une partie importante car, pour chaque étape, l'agent Tech Lead doit spécifier comment l'utilisateur (le développeur du monde réel) peut vérifier si la tâche est accomplie.
- Le Developer agent prend chaque tâche et rédige ce qui doit être fait pour la mettre en œuvre. La description est sous une forme lisible par l'homme.
- Enfin, le Code Monkey agent prend la description du développeur et le fichier en cours d'implémentation et y applique les modifications.
Il est évident qu'il n'est pas encore possible de créer une application prête pour la production, mais le concept général de la façon dont cela pourrait fonctionner est là.
Source : GitHub
Et vous ?
Quel est votre avis sur GPT Pilot ? Cette approche est elle crédible ?
Selon vous, cet outil va-t-il faciliter la vie des développeurs ?
Pensez-vous que ce genre d'avancées technologie met en péril l'avenir des emplois pour les développeurs ?
Voir aussi :
Qu'est-ce que Auto-GPT, le nouvel outil d'IA "à tout faire", et comment fonctionne-t-il ? Voici ce qu'il faut savoir sur ce chatbot d'IA basé sur le modèle GPT-4 d'OpenAI
Le coût de développement d'un logiciel serait-il beaucoup plus abordable si le code était écrit par GPT-4 ?
Cas d'utilisations GPT-4 : créer un jeu vidéo complexe sans formation en programmation, un chatbot qui analyse des données financières volumineuses, coder sur son Apple Watch rien qu'avec sa voix