De softwareontwikkelingsindustrie is een domein dat vaak zowel overleg als intuïtie vereist, gekenmerkt door ingewikkelde beslissingsstrategieën. Bovendien vereisen de ontwikkeling, het onderhoud en de exploitatie van software een gedisciplineerde en methodische aanpak. Het is gebruikelijk dat softwareontwikkelaars beslissingen baseren op intuïtie in plaats van overleg, afhankelijk van de complexiteit van het probleem. In een poging om de efficiëntie van software-engineering te verbeteren, inclusief de effectiviteit van software en de verlaging van de ontwikkelingskosten, onderzoeken wetenschappers het gebruik van deep-learning-gebaseerde kaders om verschillende taken binnen het softwareontwikkelingsproces aan te pakken. Met recente ontwikkelingen en vooruitgang in de deep learning- en AI-sectoren, zoeken ontwikkelaars naar manieren om softwareontwikkelingsprocessen en -praktijken te transformeren. Ze doen dit door geavanceerde ontwerpen te implementeren op verschillende stadia van het softwareontwikkelingsproces.

Vandaag gaan we het hebben over ChatDev, een innovatieve benadering op basis van een Large Language Model (LLM) die ertoe strekt het veld van softwareontwikkeling te revolutioneren. Deze paradigma zoekt ernaar om de noodzaak voor gespecialiseerde modellen tijdens elk stadium van het ontwikkelingsproces te elimineren. Het ChatDev-kader maakt gebruik van de mogelijkheden van LLM-kaders, waarbij natuurlijke taalcommunicatie wordt gebruikt om belangrijke softwareontwikkelingsprocessen te verenigen en te stroomlijnen.

In dit artikel zullen we ChatDev onderzoeken, een virtueel bedrijf dat gespecialiseerd is in softwareontwikkeling. ChatDev past het watervalmodel toe en deelt het softwareontwikkelingsproces zorgvuldig op in vier primaire stadia.

1. Ontwerp.
2. Codering.
3. Testen.
4. Documentatie.

Elk van deze stadia maakt gebruik van een team van virtuele agenten, zoals codeprogrammeurs of testers, die samenwerken met elkaar door middel van dialogen die resulteren in een naadloze workflow. De chatketen werkt als een faciliterend middel en breekt elk stadium van het ontwikkelingsproces op in atomaire subtaken, waardoor dubbele rollen mogelijk worden, waardoor voorstellen en validatie van oplossingen mogelijk worden met context-gevoelige communicatie die ontwikkelaars in staat stelt om de gespecificeerde subtaken effectief op te lossen.

De instrumentele analyse van ChatDev toont aan dat niet alleen het ChatDev-kader extreem effectief is in het voltooien van het softwareontwikkelingsproces, maar ook extreem kostenefficiënt, aangezien het het hele softwareontwikkelingsproces voltooit voor minder dan een dollar. Bovendien identificeert het kader niet alleen potentiële kwetsbaarheden, maar verlicht het ook potentiële hallucinaties, terwijl het een hoge efficiëntie en kostenefficiëntie behoudt.

ChatDev : Een Introductie tot LLM-gebaseerde Softwareontwikkeling

Traditioneel is de softwareontwikkelingsindustrie een domein dat is gebouwd op de fundamenten van een gedisciplineerde en methodische aanpak, niet alleen voor het ontwikkelen van toepassingen, maar ook voor het onderhoud en de exploitatie ervan. Traditioneel gesproken is een typisch softwareontwikkelingsproces een zeer ingewikkeld, complex en tijdrovend proces met lange ontwikkelingscycli, aangezien er meerdere rollen betrokken zijn bij het ontwikkelingsproces, waaronder coördinatie binnen de organisatie, taaktoewijzing, code schrijven, testen en ten slotte documentatie.

In de afgelopen jaren, met de hulp van LLM of Large Language Models, heeft de AI-gemeenschap significante mijlpalen bereikt in de gebieden van computerzicht en natuurlijke taalverwerking, en na training op “next word prediction”-paradigma’s, hebben Large Language Models hun vermogen aangetoond om efficiënte prestaties te leveren op een breed scala aan downstream-taken, zoals machinetaal, vraagbeantwoording en codegeneratie.

Hoewel Large Language Models code kunnen schrijven voor de hele software, hebben ze een groot nadeel : codehallucinaties, die vergelijkbaar zijn met de hallucinaties die optreden bij natuurlijke taalverwerking. Codehallucinaties kunnen problemen omvatten zoals onontdekte bugs, ontbrekende afhankelijkheden en onvolledige functie-implementaties. Er zijn twee belangrijke oorzaken van codehallucinaties.

• Gebrek aan Taak Specificatie: Wanneer de softwarecode in één enkele stap wordt gegenereerd, kan het niet definiëren van de specifieke taak de LLM’s in de war brengen, aangezien taken in het softwareontwikkelingsproces, zoals het analyseren van gebruikersvereisten of het selecteren van de voorkeurstaal, vaak een gerichte denkwijze bieden, iets dat ontbreekt in de high-level taken die door deze LLM’s worden afgehandeld.
• Gebrek aan Cross Examination : Significante risico’s ontstaan wanneer een cross-examinatie niet wordt uitgevoerd, vooral tijdens de besluitvormingsprocessen.

ChatDev beoogt deze problemen op te lossen en LLM’s in staat te stellen om state-of-the-art en effectieve softwaretoepassingen te creëren door een virtueel bedrijf voor softwareontwikkeling te creëren dat het watervalmodel toepast en het softwareontwikkelingsproces zorgvuldig opdeelt in vier primaire stadia,

1. Ontwerp.
2. Codering.
3. Testen.
4. Documentatie.

Elk van deze stadia maakt gebruik van een team van virtuele agenten, zoals codeprogrammeurs of testers, die samenwerken met elkaar door middel van dialogen die resulteren in een naadloze workflow. Bovendien maakt ChatDev gebruik van een chatketen die werkt als een faciliterend middel en elk stadium van het ontwikkelingsproces opdeelt in atomaire subtaken, waardoor dubbele rollen mogelijk worden, waardoor voorstellen en validatie van oplossingen mogelijk worden met context-gevoelige communicatie die ontwikkelaars in staat stelt om de gespecificeerde subtaken effectief op te lossen. De chatketen bestaat uit meerdere knooppunten waar elk individueel knooppunt een specifieke subtaak vertegenwoordigt, en deze twee rollen engageren in multi-turn context-gevoelige discussies om niet alleen voorstellen te doen, maar ook oplossingen te valideren.

In deze benadering analyseert het ChatDev-kader eerst de vereisten van een klant, genereert creatieve ideeën, ontwerpt en implementeert prototypesystemen, identificeert en adresseert potentiële problemen, creëert aantrekkelijke graphics, legt de debug-informatie uit en genereert de gebruikershandleidingen. Ten slotte levert het ChatDev-kader de software aan de gebruiker, samen met de broncode, gebruikershandleidingen en afhankelijkheidsomgevingspecificaties.

ChatDev : Architectuur en Werking

Nu we een korte inleiding tot ChatDev hebben gehad, laten we eens kijken naar de architectuur en werking van het ChatDev-kader, beginnend met de Chat Chain.

Chat Chain

Zoals we in de vorige sectie hebben vermeld, maakt het ChatDev-kader gebruik van een watervalmethode voor softwareontwikkeling die het softwareontwikkelingsproces opdeelt in vier fasen, waaronder ontwerp, codering, testen en documentatie. Elk van deze fasen heeft een unieke rol in het ontwikkelingsproces, en er is een behoefte aan effectieve communicatie tussen hen, en er zijn potentiële uitdagingen die optreden bij het identificeren van individuen om mee te engageren en het bepalen van de volgorde van interacties.

Om deze uitdaging aan te pakken, maakt het ChatDev-kader gebruik van Chat Chain, een gegeneraliseerde architectuur die elk stadium van het ontwikkelingsproces opdeelt in subatomaire chats, waarbij elk van deze fasen zich richt op taakgerichte rolvervulling die dual-rollen omvat, waardoor voorstellen en validatie van oplossingen mogelijk worden met context-gevoelige communicatie die ontwikkelaars in staat stelt om de gespecificeerde subtaken effectief op te lossen. De chatketen-paradigma voor intermediate taakoplossing wordt geïllustreerd in de afbeelding hieronder.

Voor elke individuele chat, initieert de instructeur eerst de instructies en leidt vervolgens het gesprek naar de voltooiing van de taak, en ondertussen volgen de assistenten de instructies die door de instructeur zijn gegeven, bieden ideale oplossingen en engageren in discussies over de haalbaarheid van de oplossing. De instructeur en de agent engageren in multi-turn gesprekken totdat ze tot een overeenstemming komen en ze de taak als succesvol voltooid beschouwen. De chatketen biedt gebruikers een transparante kijk op het ontwikkelingsproces, werpt licht op het pad voor besluitvorming en biedt kansen voor het opsporen van fouten wanneer deze optreden, waardoor eindgebruikers de fouten kunnen analyseren en diagnosticeren, tussentijdse uitvoer kunnen inspecteren en ingrijpen in het proces als dat nodig is. Door de chatketen op te nemen, kan het ChatDev-kader zich richten op elke specifieke subtaak op een granulair niveau, waardoor niet alleen effectieve samenwerking tussen de agenten mogelijk wordt, maar ook resulteert in de snelle verwerving van de vereiste uitvoer.

Ontwerp

In de ontwerpfase vereist het ChatDev-kader een initiële idee als invoer van de menselijke klant, en er zijn drie vooraf gedefinieerde rollen in dit stadium.

1. CEO of Chief Executive Officer.
2. CPO of Chief Product Officer.
3. CTO of Chief Technical Officer.

De chatketen komt vervolgens in actie en deelt de ontwerpfase op in opeenvolgende subatomaire chat-taken, waaronder de programmeertaal (CTO en CEO) en de modaliteit van de doelsoftware (CPO en CEO). De ontwerpfase omvat drie sleutelmechanismen : Roltoewijzing of Rol Specialisatie, Geheugenstroom en Zelfreflectie.

Roltoewijzing

Elke agent in het Chat Dev-kader wordt een rol toegewezen met behulp van speciale berichten of speciale prompts tijdens het rolspelproces. In tegenstelling tot andere conversational language modellen, beperkt het ChatDev-kader zich tot het initiëren van rolspelscenario’s tussen de agenten. Deze prompts worden gebruikt om rollen toe te wijzen aan de agenten voordat de gesprekken beginnen.

Aanvankelijk neemt de instructeur de verantwoordelijkheden van de CEO op zich en engageert in interactief plannen, terwijl de verantwoordelijkheden van de CPO worden afgehandeld door de agent die taken uitvoert en de vereiste antwoorden biedt. Het kader maakt gebruik van “inception prompting” voor rol specialisatie, waardoor de agenten hun rollen effectief kunnen vervullen. De assistent- en instructieprompts bestaan uit vitale details met betrekking tot de toegewezen rollen en taken, beëindigingscriteria, communicatieprotocollen en verschillende beperkingen die zijn bedoeld om ongewenst gedrag te voorkomen, zoals oneindige lussen, oninformatieve antwoorden en instructieherhaling.

Geheugenstroom

De geheugenstroom is een mechanisme dat door het ChatDev-kader wordt gebruikt om een uitgebreid conversatieverslag van de vorige gesprekken van een agent te behouden en om te helpen bij het besluitvormingsproces dat volgt op een manier die bewust is van de uiting. Het ChatDev-kader maakt gebruik van prompts om de vereiste communicatieprotocollen vast te stellen. Bijvoorbeeld, wanneer de partijen een overeenstemming bereiken, wordt een eindbericht gegenereerd dat voldoet aan een specifiek formaatvereiste, zoals (<MODALITY>: Desktop Application”). Om te garanderen dat het formaat correct is, houdt het kader de huidige dialoog voortdurend in de gaten en stopt deze uiteindelijk wanneer deze voldoet aan de vereiste.

Zelfreflectie

De ontwikkelaars van het ChatDev-kader hebben situaties waargenomen waarin beide partijen een gezamenlijke overeenstemming hadden bereikt, maar de vooraf gedefinieerde communicatieprotocollen niet werden geactiveerd. Om deze problemen aan te pakken, introduceert het ChatDev-kader een zelfreflectiemechanisme dat helpt bij het ophalen en extraheren van herinneringen. Om het zelfreflectiemechanisme te implementeren, initieert het ChatDev-kader een nieuw en fris gesprek door “pseudo self” op te nemen als een nieuwe vraagsteller. De “pseudo self” analyseert de vorige gesprekken en historische records en informeert de huidige assistent, waarna het een samenvatting van conclusieve en actiewaardige informatie vraagt, zoals wordt gedemonstreerd in de figuur hieronder.

Met behulp van het zelfreflectiemechanisme wordt de ChatDev-assistent aangemoedigd om de beslissingen die het heeft voorgesteld te reflecteren en te analyseren.

Codering

Er zijn drie vooraf gedefinieerde rollen in de coderingsfase, namelijk de CTO, de programmeur en de ontwerper. Zoals gebruikelijk, deelt de chatketenmechanisme de coderingsfase op in individuele subatomaire taken, zoals het genereren van code (programmeur en CTO) of het ontwerpen van een GUI of grafische gebruikersinterface (programmeur en ontwerper). De CTO instrueert de programmeur om de instructies voor de configuratie van de omgevingsafhankelijkheden te gebruiken en een document te maken zoals “dependency requirements.txt”. Tegelijkertijd worden de vereisten en systeemontwerp door de CEO aan de CPO meegedeeld om de gebruikershandleiding voor het product te genereren.

Codebeheer

Het ChatDev-kader maakt gebruik van objectgeoriënteerde programmeertalen zoals Python, Java en C++ om complexe software-systemen te behandelen, omdat de modulariteit van deze programmeertalen het gebruik van zelfstandige objecten mogelijk maakt die niet alleen helpen bij het opsporen van fouten, maar ook bij de samenwerking en ontwikkeling, en ook helpen bij het verwijderen van redundantie door objecten te hergebruiken door middel van het concept van overerving.

Gedachteninstructies

Traditionele methoden van vraagbeantwoording leiden vaak tot irrelevante informatie of onnauwkeurigheden, vooral bij het genereren van code, aangezien het geven van naive instructies kan leiden tot LLM-hallucinaties en een uitdagend probleem kan worden. Om dit probleem aan te pakken, introduceert het ChatDev-kader het “gedachteninstructie”-mechanisme dat inspiratie put uit chain-of-thought-prompts. Het “gedachteninstructie”-mechanisme adresseert expliciet de individuele probleemoplossende gedachten die zijn opgenomen in de instructies, vergelijkbaar met het oplossen van taken in een sequentiële en georganiseerde manier.

Testen

Het schrijven van foutloze code in de eerste poging is een uitdaging, niet alleen voor LLM’s, maar ook voor menselijke programmeurs, en in plaats van de onjuiste code volledig te verwijderen, analyseren programmeurs hun code om fouten te identificeren en te corrigeren. De testfase in het ChatDev-kader wordt opgedeeld in drie rollen : programmeur, tester en reviewer. Het testproces wordt verder opgedeeld in twee opeenvolgende subatomaire taken : Peer Review of Static Debugging (reviewer en programmeur) en System Testing of Dynamic Debugging (programmeur en tester). Static debugging of Peer review analyseert de broncode om fouten te identificeren, terwijl dynamic debugging of system testing de uitvoering van de software verifieert door middel van verschillende tests die worden uitgevoerd met behulp van een interpreter door de programmeur. Dynamic debugging richt zich voornamelijk op black-box testing om de toepassingen te evalueren.

Documentatie

Nadat het ChatDev-kader klaar is met het ontwerpen, coderen en testen, maakt het gebruik van vier agenten, namelijk de CEO, CTO, CPO en programmeur, om de documentatie voor het softwareproject te genereren. Het ChatDev-kader maakt gebruik van LLM’s om few-shot-prompts te gebruiken met in-context voorbeelden om de documenten te genereren. De CTO instrueert de programmeur om de instructies voor de configuratie van de omgevingsafhankelijkheden te gebruiken en een document te maken zoals “dependency requirements.txt”. Tegelijkertijd worden de vereisten en systeemontwerp door de CEO aan de CPO meegedeeld om de gebruikershandleiding voor het product te genereren.

Resultaten

Software Statistieken

Om de prestaties van het ChatDev-kader te analyseren, voerde het team van ontwikkelaars een statistische analyse uit op de softwaretoepassingen die door het kader waren gegenereerd op basis van een aantal sleutelmetrics, waaronder verbruikte tokens, totale dialoogomwentelingen, beeldassets, softwarebestanden, versie-updates en een aantal andere, en de resultaten worden weergegeven in de tabel hieronder.

Duur Analyse

Om ChatDev’s productietijd voor software te onderzoeken voor verschillende aanvraagprompts, voerden de ontwikkelaars ook een duuranalyse uit, en het verschil in de ontwikkelingstijd voor verschillende prompts weerspiegelt de variërende duidelijkheid en complexiteit van de taken die zijn toegewezen, en de resultaten worden weergegeven in de figuur hieronder.

Case Study

De volgende figuur toont ChatDev die een Five in a Row of een Gomoku-spel ontwikkelt.

De linkermost figuur toont de basissoftware die door het kader is gegenereerd zonder het gebruik van een GUI. Zoals duidelijk te zien is, biedt de toepassing zonder GUI beperkte interactie, en kunnen gebruikers dit spel alleen spelen via de opdrachtterminal. De volgende figuur toont een meer visueel aantrekkelijk spel dat is gemaakt met het gebruik van een GUI, dat een betere gebruikerservaring en een verhoogde interactie biedt voor een aantrekkelijke gameplay-omgeving die door gebruikers kan worden genoten. De ontwerper-agent maakt vervolgens extra graphics om de bruikbaarheid en esthetiek van de gameplay verder te verbeteren zonder de functionaliteit van de software te beïnvloeden. Echter, als de menselijke gebruikers niet tevreden zijn met het gegenereerde beeld, kunnen ze het beeld vervangen nadat het ChatDev-kader de software heeft voltooid. De flexibiliteit die het ChatDev-kader biedt om beelden handmatig te vervangen, stelt gebruikers in staat om toepassingen aan te passen aan hun voorkeuren voor een verhoogde interactie en gebruikerservaring zonder de functionaliteit van de software te beïnvloeden.

Slotbeschouwing

In dit artikel hebben we het gehad over ChatDev, een LLM-gebaseerd innovatief paradigma dat ertoe strekt het veld van softwareontwikkeling te revolutioneren door de noodzaak voor gespecialiseerde modellen tijdens elk stadium van het ontwikkelingsproces te elimineren. Het ChatDev-kader beoogt de mogelijkheden van de LLM-kaders te benutten door natuurlijke taalcommunicatie te gebruiken om belangrijke softwareontwikkelingsprocessen te verenigen en te stroomlijnen. Het ChatDev-kader maakt gebruik van de chatketenmechanisme om het softwareontwikkelingsproces op te delen in opeenvolgende subatomaire taken, waardoor een granulair focus mogelijk wordt, en waardoor gewenste uitvoer voor elke subatomaire taak wordt gepromoot.