Nach 6 Monaten Arbeit an einem CodeGen-Entwicklungstool (GPT-Pilot) habe ich Folgendes gelernt

In den letzten 6 Monaten habe ich an GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ) gearbeitet, um zu verstehen, wie weit wir die Codierung mit KI wirklich automatisieren können, deshalb wollte ich unsere Erkenntnisse teilen bisher und wie weit es gehen kann.

Als ich mit der Entwicklung von GPT Pilot begann, schrieb ich diesen Blog-Beitrag darüber, wie es sich vorstellt. Jetzt möchte ich meine überarbeitete Denkweise teilen und darauf eingehen, was funktioniert hat und was nicht.

Abschließend sehen Sie Beispiele für Apps, die mit GPT Pilot erstellt wurden, und wie Sie mit einem echten KI-Paarprogrammierer eine App erstellen können.

Was ist die Idee hinter GPT Pilot?

GPT Pilot ist als echter KI-Entwickler gedacht – nicht als Autovervollständiger oder Chatbot . Vielmehr ist es ein Entwickler, der einen Plan erstellt, wie Ihre App oder Funktion erstellt werden soll, und mit dem Codieren beginnt. Es möchte den größten Teil der Codierung selbst erledigen, aber wenn es nicht weiterkommt, die gegebenen Anforderungen geklärt werden müssen oder eine Codeüberprüfung erforderlich ist, werden Sie um Hilfe gebeten.

Ist KI wie ein Junior-Entwickler? Oder…

Ich sehe oft CodeGen GPT-4-basierte Tools, die sagen, dass sie einen KI-Junior-Entwickler aufbauen.

Irgendwie hatte ich schon immer ein Problem damit, denn wenn ich ChatGPT zum Codieren verwende, bekomme ich Antworten und Ideen, die nur eine hochrangige Person geben könnte – etwas, das absolut kein Junior-Entwickler überhaupt begreifen könnte. Dennoch kann kein LLM eine App auch nur annähernd so gut erstellen wie ein erfahrener Entwickler, aber das Wissen, das GPT-4 über das Codieren hat, übersteigt bei weitem die Kenntnisse eines Junior-Entwicklers.

Ich würde sagen, dass GPT-4 so viel Wissen über jeden Teil der Softwareentwicklung hat, als wäre es der älteste Entwickler der Welt, aber mit dem Gedächtnis eines Goldfisches. Ich stelle es mir als einen übermenschlichen Roboter vor, der einfach in der Mitte eines Raumes steht und jeweils nur eine einzige kleine Aktion ausführen kann, aber nicht viele Aktionen kombinieren und wiederholt arbeiten kann. Sie müssen ihm genau sagen, was er als nächstes tun soll.

Das ist es, was wir mit GPT Pilot erreichen wollen – wir wollen einen Denkrahmen für das LLM schaffen, der diesen übermenschlichen Roboter dazu bringt, kontinuierlich zu arbeiten, indem er seine vorherigen Aktionen überprüft, eine Feedback-Schleife hat und festlegt, was er als nächstes tun soll um das Endziel zu erreichen, das darin besteht, eine produktionsreife Anwendung zu erstellen.

In dem Blog-Beitrag, den ich oben erwähnt habe , habe ich die Hauptpfeiler skizziert, auf denen GPT Pilot aufgebaut ist. Diese haben sich jedoch aufgrund der Erkenntnisse unseres Teams ein wenig geändert, daher sind hier die überarbeiteten Säulen:

1. Ein Mensch wird benötigt, um die KI zu überwachen, nicht nur, weil die KI nicht gut genug ist, sondern auch, weil Sie möglicherweise die Funktionsweise oder die Implementierung einer Sache ändern möchten. Es ist üblich, dass ein Entwickler oder Produktmanager, sobald er sieht, wie eine Implementierung aussieht, beschließt, sie zu ändern.

   
   

2. Oder Sie stellen fest, dass es mehr Grenzfälle gibt, als Sie ursprünglich erwartet hatten, und denken, dass es einfacher ist, Ihre aktuelle Implementierung umzugestalten, als jedes Problem zu beheben. Das Problem besteht darin, dass Sie die gesamte App fertigstellen und dann versuchen, sie umzugestalten. Dann wird es viel schwieriger, da sich jede Änderung auf alle anderen Funktionen auswirkt.

   
   

   Wenn Sie hingegen die Umgestaltung durchführen, bevor Sie Ihre Änderungen festschreiben, können Sie zusätzlich zu gut geschriebenem Code mit den nächsten Funktionen fortfahren. Aus diesem Grund ist es für einen KI-Entwickler von entscheidender Bedeutung, dass bei jeder Implementierung einer Aufgabe ein Mensch auf dem Laufenden ist .

   
   

   Auf diese Weise kann der Mensch die Implementierung jeder Aufgabe überprüfen (genau wie eine Codeüberprüfung vor dem Zusammenführen einer PR), bevor GPT Pilot mit der nächsten Aufgabe fortfährt. Wenn ein Mensch GPT Pilot mitteilt, was falsch ist, ist es viel einfacher, die Probleme innerhalb der Aufgabe selbst zu beheben. Gleichzeitig verfügt das LLM über den Kontext dessen, was in der Aufgabe getan werden muss und was bisher getan wurde.

   
   

3. KI kann ihre eigenen Fehler wiederholen. Ich habe das Gefühl, dass viele Leute die Fähigkeit von ChatGPT, Code zu schreiben, danach beurteilen, wie gut es liefert, wenn man es zum ersten Mal auffordert, etwas zu programmieren. Wenn es keinen funktionierenden Code produziert, werden viele denken, dass es nicht beeindruckend ist. In Wirklichkeit schreiben Menschen fast nie beim ersten Versuch funktionierenden Code . Stattdessen schreiben Sie Code, führen ihn aus, sehen sich die Fehler an und iterieren. Genau das ermöglicht GPT Pilot GPT-4 – nachdem es Code geschrieben hat, kann GPT Pilot den Code ausführen, die Ausgabe übernehmen und den LLM fragen, ob die Ausgabe korrekt ist, ob etwas behoben werden sollte und wenn ja, wie .

   
   

4. Softwareentwicklung kann orchestriert werden . Es gibt viele sich wiederholende Routinen, die alle Entwickler beim Erstellen einer App durchlaufen. Eine der Routinen kann sein – Code schreiben, ausführen, Fehler lesen, Code ändern, erneut ausführen usw. Eine andere Routine auf höherer Ebene kann sein – eine Aufgabe übernehmen, sie implementieren, die Implementierung testen (wiederholen, bis alle Tests bestanden sind). , senden Sie es zur Überprüfung, beheben Sie die Probleme (wiederholen Sie den Vorgang, bis der Prüfer zustimmt) und stellen Sie ihn bereit. Viele dieser Routinen können orchestriert werden, wenn wir einen intelligenten Entscheidungsträger auf dem Laufenden haben (wie ein LLM).

   
   

5. Der Codierungsprozess verläuft nicht geradlinig . Als wir die erste Version von GPT Pilot erstellten, dachten wir, dass Aufgaben iteriert, Code implementiert, behoben und weitergemacht werden müsste. In Wirklichkeit kommt man beim Codieren einer App nicht kontinuierlich voran – man schreibt seinen Code ständig neu.

   
   

   Manchmal überarbeiten Sie die Codebasis, weil Sie nach der ersten Implementierung erkennen, dass es eine bessere Möglichkeit gibt, etwas zu implementieren. In anderen Fällen geschieht dies aufgrund geänderter Anforderungen. Wie ich in Nr. 1 erwähnt habe, müssen Sie, nachdem Sie festgestellt haben, dass eine Lösung nicht funktioniert, manchmal eine Reihe von Änderungen rückgängig machen, über eine alternative Lösung für das Problem nachdenken und versuchen, es auf diese Weise zu lösen.

   
   

   Damit GPT Pilot oder jeder andere KI-Entwickler in großem Maßstab funktionieren kann, muss er über einen Mechanismus verfügen, der es ihm ermöglicht, zurückzugehen, einen alternativen Weg zu wählen und eine Aufgabe erneut zu implementieren.

Was haben wir gelernt?

Generell handelt es sich bei LLMs um eine neue Technologie, die jeder zu verstehen versucht – wie sie funktioniert, was besser gemacht werden kann, wie man ein ordnungsgemäßes Prompt-Engineering durchführt usw. Unser Ansatz besteht darin, uns auf den Aufbau der Anwendungsschicht zu konzentrieren, anstatt daran zu arbeiten, sie zu bekommen LLMs, um bessere Ergebnisse zu erzielen .

Der Grund dafür ist, dass LLMs besser werden und wenn wir Wochen damit verbringen, eine Eingabeaufforderung zu optimieren, könnte dies mit der neuen Version von GPT vollständig gelöst werden.

Stattdessen konzentrieren wir uns darauf, wie das Benutzererlebnis aussehen sollte und welche Mechanismen erforderlich sind, um das LLM so zu steuern, dass es kontinuierlich funktioniert und der endgültigen Lösung immer näher kommt. Hier sind unsere bisherigen Erkenntnisse:

1. Die anfängliche Beschreibung der App ist viel wichtiger als wir dachten . Unser ursprünglicher Gedanke war, dass GPT Pilot mit dem Input des Menschen in der Lage sein würde, in die richtige Richtung zu navigieren und der funktionierenden Lösung immer näher zu kommen, selbst wenn die ursprüngliche Beschreibung vage war.

   
   

   Allerdings verzweigt sich die Denkweise von GPT Pilot in alle Eingabeaufforderungen, beginnend mit der ersten Beschreibung. Und wenn bei der ersten Eingabeaufforderung etwas irreführend ist, führen alle anderen Informationen, die GPT Pilot hat, in die falsche Richtung. Wenn Sie es also auf der ganzen Linie korrigieren, wird es so tief in diesem falschen Weg versinken, dass es fast unmöglich sein wird, es auf den richtigen Weg zu bringen.

   
   

   Jetzt, wo ich das schreibe, scheint es so offensichtlich, aber das ist etwas, was wir lernen mussten – um uns viel mehr auf die ursprüngliche Beschreibung zu konzentrieren. Deshalb haben wir einen neuen Agenten namens „Spec Writer“ entwickelt, der mit Ihnen zusammenarbeitet, um die Projektanforderungen aufzuschlüsseln, bevor mit der Codierung begonnen wird.

   
   

2. Codierung ist keine gerade Linie . Wie ich oben im Abschnitt „Säulen“ erwähnt habe, kommt es ständig zu Refactorings, und GPT Pilot muss dies auch tun. Wir haben hierfür noch keine Lösung implementiert, aber es wird wahrscheinlich funktionieren, indem wir GPT Pilot die Möglichkeit hinzufügen, Markierungen rund um seinen Entscheidungsbaum zu erstellen, sodass er immer dann, wenn etwas nicht funktioniert, Markierungen überprüfen und darüber nachdenken kann, wo es sein könnte eine falsche Drehung gemacht.

   
   

3. Agenten können sich selbst bewerten . Meiner Meinung nach wäre es überflüssig, wenn ein Agent überprüft, was der andere Agent getan hat, da es sich um denselben LLM handelt, der dieselben Informationen erneut verarbeitet. Aber es stellt sich heraus, dass es erstaunlich gut funktioniert, wenn ein Agent die Arbeit eines anderen Agenten überprüft. Wir haben zwei verschiedene „Reviewer“-Agenten, die überprüfen, wie der Code implementiert wurde.

   
   

   Einer führt dies auf einer hohen Ebene aus, beispielsweise wie die gesamte Aufgabe implementiert wurde, und ein anderer überprüft jede Änderung, bevor sie an einer Datei vorgenommen wird (z. B. wenn Sie git add -p ausführen).

   
   

4. LLMs funktionieren am besten, wenn sie sich auf ein Problem konzentrieren können und nicht auf mehrere Probleme in einer einzigen Eingabeaufforderung. Wenn Sie GPT Pilot beispielsweise anweisen, zwei verschiedene Änderungen in einer einzigen Beschreibung vorzunehmen, wird es Schwierigkeiten haben, sich auf beide zu konzentrieren. Daher teilen wir jede menschliche Eingabe in mehrere Teile auf, falls die Eingabe mehrere unterschiedliche Anforderungen enthält.

   
   

5. Ausführliche Protokolle helfen . Das ist jetzt sehr offensichtlich, aber anfangs haben wir GPT-4 nicht angewiesen, Protokolle rund um den Code hinzuzufügen. Jetzt wird Code mit ausführlicher Protokollierung erstellt, sodass GPT-4 das Debuggen erheblich erleichtert, wenn Sie die App ausführen und auf einen Fehler stoßen, da es erkennt, welche Protokolle geschrieben wurden und wo sich diese Protokolle im Code befinden.

   
   

6. Das Aufteilen der Codebasis in kleinere Dateien hilft sehr . Das ist auch eine naheliegende Schlussfolgerung, aber wir mussten sie lernen. Für GPT-4 ist es viel einfacher, Funktionen zu implementieren und Fehler zu beheben, wenn der Code in viele Dateien statt in ein paar große Dateien aufgeteilt wird. Genau wie wir Menschen denken: Es ist viel einfacher, kleinere Codeblöcke zu verarbeiten als große. Dies erreichen wir durch die Schaffung von Abstraktionsebenen – Funktionen, Klassen usw.

   
   

   Eine der einfachsten Möglichkeiten, das LLM dazu zu bringen, eine besser verwaltbare Abstraktion zu erstellen, besteht darin, es einfach anzuweisen, modulareren Code zu erstellen und ihn in mehr Dateien aufzuteilen. Es funktioniert erstaunlich gut und das Endergebnis ist auch für uns Entwickler besser.

   
   

7. Damit ein Mensch den Code reparieren kann, muss ihm klar gezeigt werden, was in der Aufgabe geschrieben wurde und welche Idee dahinter steckt . Das Ziel von GPT Pilot besteht darin, 90 % aller Codierungsaufgaben zu erledigen und die anderen 10 % einem Menschen zu überlassen. Bei diesen 10 % handelt es sich in der Regel um Korrekturen oder kleine Änderungen, die der LLM nur schwer bemerkt, aber für den Menschen kann es sich um eine einfache Änderung handeln.

   
   

   Das Problem besteht jedoch darin, dass es nicht einfach ist, dem Menschen zu sagen, was nicht funktioniert und welchen Code er sich ansehen sollte. Wenn GPT Pilot 3.000 Zeilen Code schreibt, muss der menschliche Entwickler, wenn er GPT Pilot helfen möchte, die gesamte Codebasis verstehen, bevor er sich mit dem eigentlichen Code befasst.

   
   

   In zukünftigen Versionen von GPT Pilot erhält der menschliche Entwickler eine detaillierte Erklärung darüber, welcher Code zur aktuellen Aufgabe hinzugefügt wurde und welche Gründe dafür vorliegen. Auf diese Weise können Sie GPT Pilot unterstützen.

   
   

8. Menschen sind faul . LLMs sind besser dran, Menschen Fragen zu stellen, als sie über alle möglichen Fehler nachdenken zu lassen. Auch hier ist es im Rückblick sehr offensichtlich, aber eines der Dinge, die uns auffielen, war, dass die Leute viel eher bereit waren, Fragen zu beantworten, die GPT Pilot ihnen stellte, anstatt ein offenes Eingabefeld zu haben, in das sie uneingeschränktes Feedback schreiben konnten.

   
   

9. Es ist schwierig, einen LLM dazu zu bringen, über den Tellerrand hinaus zu denken . Das war für mich eine der größten Erkenntnisse. Ich dachte, Sie könnten GPT-4 dazu anregen, indem Sie ihm ein paar Lösungen geben, die es bereits zur Behebung eines Problems verwendet hat, und es auffordern, über eine andere Lösung nachzudenken. Allerdings ist das nicht so einfach, wie es sich anhört.

   
   

   Am Ende haben wir das LLM gebeten, alle möglichen Lösungen aufzulisten, die ihm einfielen, und sie im Speicher zu speichern. Wenn wir etwas anderes ausprobieren mussten, zogen wir die Alternativlösungen heraus und forderten es auf, eine andere, aber spezifische Lösung auszuprobieren.

Mit GPT Pilot erstellte Apps

Derzeit können Sie mit GPT Pilot einfache, aber nicht triviale Apps erstellen. Wir haben auch gesehen, dass Leute mit GPT Pilot sehr beeindruckende Apps erstellt haben, beispielsweise eine App, die ein ResNet-Modell so optimieren kann, dass es Palmen zählt und dann, wenn Sie ein Bild hochladen, die darin enthaltenen Bäume zählt. Hier sind ein paar Apps, die wir erstellt haben, zusammen mit dem Code, Statistiken und Demos:

Prompt Lab ( DEMO )

Stellen Sie sich das als OpenAI Playground auf Steroiden vor – es ermöglicht Ihnen, eine Konversation aus einem JSON-Array zu laden oder manuell einzugeben, die Konversation X-mal mit dem LLM auszuführen, die Konversation in der Datenbank zu speichern und sie wieder zu laden. Wir Verwenden Sie diese App tatsächlich, wenn wir eine Eingabeaufforderung entwickeln und sehen möchten, wie sie sich verhält.

Der Playground ist nicht gut genug, da es zeitaufwändig ist, eine einzelne Eingabeaufforderung wiederholt auszuführen. Mit Prompt Lab können Sie auswählen, wie oft es ausgeführt werden soll, und die App die Eingabeaufforderung wiederholt ausführen lassen.

Sobald es fertig ist, können Sie die Ergebnisse analysieren. Dies kann für Personen nützlich sein, die eine KI-App erstellen und ihre Eingabeaufforderungen optimieren müssen.

• ⏳ Zeitaufwand: ~2 Tage
• 💾 Github-Repo

SQLite-Datenbankanalysator-Tool ( DEMO )

Dies ist auch eine App, die wir intern zur Analyse einer lokalen SQLite-Datenbank verwenden. Es ruft die Daten aus der Datenbank in einem Format ab, das sehr spezifisch für die Datenbankstruktur von GPT Pilot ist, kann aber leicht an andere Strukturen angepasst werden.

Es liest und lädt Ihre SQLite-Datenbank hoch, teilt die Zeilen nach einem bestimmten Feld auf, entpackt die Zeilen in Werte, lädt die LLM-Konversationsdaten in ein Formular und ermöglicht Ihnen, einfach eine der Nachrichten zu ändern und die LLM-Anfrage an GPT-4 zu senden um zu sehen, wie die Ergebnisse aussehen werden.

Auf diese Weise können Sie die Gespräche, die die Agenten von GPT Pilot mit dem LLM führen, analysieren und leicht herausfinden, was passieren würde, wenn die Eingabeaufforderungen anders wären.

• ⏳ Zeitaufwand: ~2 Tage
• 💾 Github-Repo

Code Whisperer ( DEMO )

Code Whisper ist ein unterhaltsames Projekt, das wir als Beispiel zur Präsentation erstellt haben. Die Idee ist, dass Sie damit dem LLM Fragen zu Ihrer Codebasis stellen können. Sie fügen den Link zu einem öffentlichen Github-Repo ein.

Anschließend klont es das Repository, sendet die relevanten Dateien zur Analyse an das LLM, das für jede Datei eine Beschreibung der Funktionsweise des Codes erstellt und diese Beschreibungen in der Datenbank speichert.

Danach können Sie der App Fragen zur Codebasis stellen und die Codebasis zeigt Ihnen die Antwort. In dieser Demo verwenden wir GPT-3.5.

• ⏳ Zeitaufwand: 7 Stunden
• 💾 Github-Repo

Sterngeschichte ( DEMO )

Ich veröffentliche schon seit Jahren Open-Source-Projekte und wollte schon immer sehen, wie schnell mein Github-Repo im Vergleich zu anderen erfolgreichen Repositories auf https://star-history.com/ wächst. Das Problem ist, dass ich bei Star History nicht in die Grafik hineinzoomen kann, sodass ein neues Repo mit 1.000 Sternen nicht mit einem großen Repo mit 50.000 Sternen verglichen werden kann, weil man nicht sehen kann, wie sich das größere Repo am Anfang schlägt .

Deshalb habe ich GPT Pilot gebeten, diese Funktionalität zu entwickeln. Es durchsucht Github-Repos nach Sternguckern, speichert sie in der Datenbank, stellt sie in einem Diagramm dar und ermöglicht das Vergrößern und Verkleinern des Diagramms.

• ⏳ Zeitaufwand: 6 Stunden
• 💾 Github-Repo

Abschluss

Ich hoffe, Sie haben einen Einblick in den aktuellen Stand, die Probleme und Erkenntnisse gewonnen, mit denen wir uns bei GPT Pilot befassen.

Um es noch einmal zusammenzufassen:

Wir sind der Meinung, dass ein echtes KI-Entwicklertool auf den folgenden Säulen basieren sollte:

• Zur Überwachung der KI wird ein Mensch benötigt.

  
  

• Wir sollten es der KI ermöglichen, ihre eigenen Fehler zu wiederholen.

  
  

• Softwareentwicklung kann orchestriert werden , die auf einer Ebene über LLMs implementiert werden sollte.

  
  

• Der KI-Entwickler sollte in der Lage sein, die Codebasis umzugestalten , da der Codierungsprozess in Wirklichkeit nicht geradlinig verläuft.

Bisher haben wir Folgendes gelernt:

1. Die anfängliche App-Beschreibung ist viel wichtiger als wir dachten

2. Die Codierung verläuft nicht geradlinig, Agenten können sich selbst überprüfen

3. LLMs funktionieren am besten, wenn sie sich auf ein Problem konzentrieren und nicht auf mehrere Probleme in einer einzigen Eingabeaufforderung

4. Ausführliche Protokolle bewirken Wunder

5. Das Aufteilen der Codebasis in kleinere Dateien hilft sehr

6. Damit ein Mensch den Code reparieren kann

7. Es muss klar dargestellt werden, was geschrieben wurde und welche Idee dahinter steckt

8. Menschen sind faul

9. Es ist schwierig, den LLM dazu zu bringen, über den Tellerrand hinaus zu denken

   
   

Was denken Sie? Ist Ihnen eines dieser Verhaltensweisen im Umgang mit LLMs aufgefallen oder haben Sie eine andere Meinung dazu?

Ich würde mich sehr freuen, von Ihnen zu hören. Hinterlassen Sie also unten einen Kommentar oder schreiben Sie mir eine E-Mail an [email protected] .

Sie können hier versuchen, mit GPT Pilot eine App mit KI zu erstellen:

• GPT Pilot Open-Source-Repo
• GPT Pilot VS Code-Erweiterung

Wenn Ihnen dieser Beitrag gefallen hat, würde es uns viel bedeuten, wenn Sie das GPT Pilot Github-Repo markieren würden, und wenn Sie es ausprobieren, teilen Sie uns Ihre Meinung mit. Ihr Feedback ist für das gesamte GPT-Pilotteam sehr wichtig.

Auch hier veröffentlicht