Überlegungen zur Verwendung von Devin nach einem Monat, in dem mehr als 20 Aufgaben mit Devin ausgeführt wurden

Im März 2024 trat ein neues KI-Unternehmen mit beeindruckender Unterstützung ins Rampenlicht: eine 21 Millionen Dollar schwere Serie A unter der Leitung von Founders Fund und mit Unterstützung von Branchenführern wie den Collison-Brüdern, Elad Gil und anderen Tech-Größen. Das Team hinter dem Unternehmen? Goldmedaillengewinner der Internationalen Informatik-Olympiade - sie sind die Art von Leuten, die Programmierprobleme lösen können, die die meisten von uns nicht einmal ansatzweise verstehen können. Ihr Produkt, Devin, verspricht ein völlig autonomer Software-Ingenieur zu sein, der sich mit Ihnen wie ein menschlicher Kollege unterhalten kann und in der Lage ist, alles zu tun, vom Erlernen neuer Technologien und dem Debuggen ausgereifter Code-Basen bis hin zur Bereitstellung vollständiger Anwendungen und sogar dem Training von KI-Modellen.

Die ersten Demos waren überzeugend. Die Demonstration der Devin Wie man selbstständig eine Kopfgeldaufgabe auf Upwork erledigt, indem man ein PyTorch-Projekt ohne menschliches Zutun installiert und ausführt. Das Unternehmen behauptet, dass Devin in der Lage war, das 13,86% reale GitHub-Problem im SWE-Bench-Benchmark Ende-zu-Ende zu lösen - etwa dreimal besser als das vorherige System. Das System war zunächst nur einer kleinen Gruppe von Nutzern zugänglich, was zu aufregenden Tweets darüber führte, wie es die Softwareentwicklung revolutionieren würde.

handeln als Antwort.AI Da wir zu einem Team gehören, das häufig KI-Entwicklungstools ausprobiert, hatten wir das Gefühl, dass Devin etwas Besonderes ist. Wenn es nur die Hälfte von dem hält, was es verspricht, könnte es die Art und Weise, wie wir arbeiten, verändern. Aber bei aller Begeisterung auf Twitter konnten wir nicht viele detaillierte Berichte von Leuten finden, die es tatsächlich benutzen. Also haben wir beschlossen, das Programm gründlich zu testen, und zwar anhand einer Reihe von Aufgaben aus der Praxis. Hier ist unsere Geschichte - ein gründlicher, realistischer Versuch, mit einem der am meisten gehypten KI-Produkte des Jahres 2024 zu arbeiten.

Was ist Devin?

Was Devin einzigartig macht, ist seine Infrastruktur. Anders als typische KI-Assistenten betreibt und startet Devin seine eigene Rechenumgebung über Slack. Wenn Sie mit Devin sprechen, sprechen Sie mit einer KI, die Zugriff auf eine vollständige Rechenumgebung hat - komplett mit Webbrowser, Code-Editor und Shell - die Abhängigkeiten installieren, Dokumentation lesen und sogar eine Vorschau der von ihr erstellten Webanwendungen anzeigen kann. Hier sehen Sie einen Screenshot einer Möglichkeit, Devin zu starten, um eine Aufgabe auszuführen:

Eine Möglichkeit, Devin über Slack mit einer Aufgabe zu beginnen

Dieses Erlebnis soll Ihnen das Gefühl geben, mit einem Kollegen zu plaudern. Sie beschreiben, was Sie wollen, und dann macht sich Devin an die Arbeit. Über Slack können Sie ihm dabei zusehen, wie er Probleme durchdenkt, bei Bedarf Anmeldeinformationen anfordert und Links zu abgeschlossenen Arbeiten teilt. Hinter den Kulissen läuft Devin in einem Docker-Container, der ihm die nötige Isolierung bietet, um sicher zu experimentieren und gleichzeitig Ihr System zu schützen. Devin bietet auch eine Weboberfläche, über die Sie auf seine Umgebung zugreifen und ihm bei der Arbeit in Echtzeit zuschauen können. Unten sehen Sie einen Screenshot der Weboberfläche:

Früher Erfolg

Unsere erste Aufgabe war einfach, aber wahr: Wir mussten die Daten aus dem Begriff Die Datenbank wurde in Google Sheets extrahiert. Devin löste dieses Problem mit erstaunlicher Kompetenz. Er navigierte zur Notion-API-Dokumentation, verstand, was er brauchte, und führte mich durch den Prozess der Einrichtung der erforderlichen Anmeldeinformationen in der Google Cloud Console. Anstatt einfach nur API-Befehle auszugeben, führte es mich durch jedes Menü und jeden Schaltflächenklick - das sparte mir Zeit, die ich normalerweise für eine mühsame Dokumentationssuche benötigt hätte. Der gesamte Prozess dauerte etwa eine Stunde (aber nur ein paar Minuten menschlicher Interaktion). Am Ende stellte Devin einen Link zu einem perfekt formatierten Google Sheet mit unseren Daten zur Verfügung.

Der erzeugte Code ist etwas langwierig, aber er funktioniert. Das fühlt sich wie ein Blick in die Zukunft an - eine KI, die die "Glue Code"-Aufgaben übernehmen kann, die so viel Zeit eines Entwicklers in Anspruch nehmen. Johno hatte mit Devin einen ähnlichen Erfolg bei der Erstellung eines Planetentrackers, um Behauptungen über die historische Lage von Jupiter und Saturn zu widerlegen. Besonders beeindruckend ist, dass er dies komplett von seinem Mobiltelefon aus gemacht hat, während Devin die ganze Arbeit des Einrichtens der Umgebung und des Schreibens des Codes übernommen hat.

Ausweitung unserer Tests

Aufbauend auf unserem frühen Erfolg nutzten wir Devins asynchrone Fähigkeiten. Wir stellten uns vor, dass Devin während der Besprechungen Dokumentationen schreiben oder Probleme debuggen würde, während wir uns auf die Designarbeit konzentrierten. Doch als wir unsere Tests ausweiteten, zeigten sich Risse. Scheinbar einfache Aufgaben dauerten oft Tage statt Stunden, und Devin stieß auf technische Sackgassen oder produzierte Lösungen, die zu komplex waren, um sie zu verwenden.

Noch besorgniserregender ist Devins Tendenz, auf Aufgaben zu drängen, die praktisch unmöglich sind. Als er gebeten wurde, mehrere Anwendungen in einem einzigen Railway-Deployment einzusetzen (eine Funktion, die von Railway nicht unterstützt wird), verbrachte Devin mehr als einen Tag damit, verschiedene Ansätze auszuprobieren und Funktionen zu erfinden, die nicht existierten.

Am frustrierendsten sind nicht die Fehlschläge selbst - alle Werkzeuge haben ihre Grenzen -, sondern die Zeit, die wir damit verbringen, diese Versuche zu retten.

Einsicht in das, was schief gelaufen ist

Auf unserer Reise waren wir verwirrt. Wir sahen, dass Devin in der Lage war, APIs kompetent zu integrieren und funktionale Anwendungen zu erstellen, aber mit scheinbar einfacheren Aufgaben hatte es Probleme. War das einfach nur Pech? Hatten wir es falsch eingesetzt?

Im Laufe eines Monats haben wir unsere Versuche in den folgenden Kategorien systematisch dokumentiert:

1. Ein neues Projekt von Grund auf erstellen
2. Umsetzung des Forschungsauftrags
3. Analyse und Modifizierung bestehender Projekte

Die Ergebnisse waren entmutigend. Von 20 Aufgaben hatten wir 14 Misserfolge, 3 Erfolge (einschließlich unserer ersten 2) und 3 nicht eindeutige Ergebnisse. Noch bezeichnender ist, dass wir kein Muster erkennen konnten, um vorherzusagen, welche Aufgaben erfolgreich sein würden. Aufgaben, die unseren ersten Erfolgen ähnelten, scheiterten auf unerwartete Weise.Nähere Informationen zu diesen Aufgaben finden Sie im folgenden Anhang. Im Folgenden finden Sie eine Zusammenfassung unserer Erfahrungen in jeder Kategorie während des Prozesses:

1. ein neues Projekt von Grund auf erstellen

Diese Kategorie sollte Devins Stärke sein. Schließlich zeigt das Demo-Video des Unternehmens, wie es selbstständig Kopfgeldaufgaben auf Upwork erledigt, und unsere ersten Erfolge deuten darauf hin, dass es brandneue Entwicklungen bewältigen kann. Doch die Realität erwies sich als komplizierter.

Nehmen wir zum Beispiel unseren Versuch, eine Beobachtungsplattform namens Braintrust mit einem Large Language Model (LLM) zu integrieren. Die Aufgabe war klar: synthetische Daten generieren und hochladen. Anstatt eine zielgerichtete und klare Lösung zu liefern, generierte Devin etwas, das man nur als Codesuppe bezeichnen kann - mehrere Abstraktionsebenen, die einfache Operationen unnötig kompliziert machten. Schließlich gaben wir Devins Versuch auf und verwendeten die Cursor Es erwies sich als effizienter, die Integration Schritt für Schritt aufzubauen. Als er gebeten wurde, eine Integration zwischen unserem KI-Notizbuch und Spiral.computer zu erstellen, produzierte Devin etwas, das ein Teammitglied als "Spaghetticode, der schwerer zu lesen war als Code, den ich von Grund auf neu geschrieben hatte" beschrieb. Obwohl er Zugang zur Dokumentation für beide Systeme hatte, schien Devin jeden Aspekt der Integration zu verkomplizieren.

Am aufschlussreichsten ist vielleicht unser Versuch des Web-Crawlings. Wir baten Devin, die Google Scholar-Links zu verfolgen und die 25 neuesten Veröffentlichungen der Autoren zu crawlen - eine einfache Aufgabe für ein Tool wie Playwright. In Anbetracht von Devins Fähigkeit, im Internet zu surfen und Code zu schreiben, hätte dies eigentlich ein Kinderspiel sein müssen. Stattdessen blieb es in einer Endlosschleife stecken, in der es versuchte, HTML zu parsen, und konnte sich selbst nicht aus dem Weg gehen.

2. der Forschungsauftrag

Wenn Devin bei bestimmten Codierungsaufgaben Schwierigkeiten hat, ist es dann wahrscheinlich, dass es bei einem forschungsorientierten Unterfangen besser abschneidet? Die Ergebnisse sind bestenfalls gemischt. Während es grundlegende Dokumentensuchen bewältigen kann (wie wir bei der frühen Notion/Google Sheets-Integration gesehen haben), erwiesen sich komplexere Rechercheaufgaben als schwierig.

Als wir Devin baten, Transkriptionszusammenfassungen mit genauen Zeitstempeln zu untersuchen (eine spezifische technische Herausforderung, mit der wir konfrontiert waren), wiederholte er lediglich oberflächlich relevante technische Informationen, anstatt sich mit dem Kernproblem auseinanderzusetzen. Anstatt potenzielle Lösungen zu erforschen oder die wichtigsten technischen Herausforderungen zu identifizieren, lieferte es allgemeine Codebeispiele, die nicht auf das zugrunde liegende Problem eingingen. Selbst wenn Devin Fortschritte zu machen scheint, sind die Ergebnisse meist nicht das, was sie zu sein scheinen. Als wir zum Beispiel gebeten wurden, ein minimales DaisyUI-Theme zu erstellen, wurde eine Lösung generiert, die zu funktionieren schien. Bei näherer Betrachtung stellten wir jedoch fest, dass das Theme eigentlich gar nichts tat - die Farben, die wir sahen, stammten vom Standard-Theme, nicht von unseren Anpassungen.

3. die Analyse und Änderung des bestehenden Codes

Die vielleicht besorgniserregendsten Fehler unterlaufen Devin bei der Arbeit mit bestehenden Codebasen. Diese Aufgaben erfordern das Verstehen von Zusammenhängen und die Wahrung der Konsistenz mit etablierten Mustern - Fähigkeiten, die zum Kern der Fähigkeiten eines KI-Softwareingenieurs gehören sollten.

Unsere Versuche, Devin dazu zu bringen, nbdev-Projekte zu bearbeiten, waren besonders aufschlussreich. Als wir ihn baten, ein Python-Projekt auf nbdev zu migrieren, war Devin nicht in der Lage, das grundlegende nbdev-Setup zu verstehen, selbst wenn wir ihm eine umfassende Dokumentation zur Verfügung stellten. Noch verwirrender war die Art und Weise, wie es mit Notizbüchern umging - anstatt sie direkt zu bearbeiten, wurden Python-Skripte erstellt, um sie zu ändern, was eine einfache Aufgabe unnötig kompliziert machte. Während es gelegentlich nützliche Kommentare oder Ideen liefert, ist der eigentliche Code, den es erzeugt, durchweg problematisch.

Bei der Sicherheitsüberprüfung traten ähnliche Probleme auf. Als wir Devin baten, ein GitHub-Repository (weniger als 700 Codezeilen) auf Sicherheitsschwachstellen zu prüfen, ging es zu weit: Es wurden viele falsch-positive Meldungen angezeigt und Probleme ausgeblendet, die gar nicht existierten. Diese Art der Analyse wird wahrscheinlich am besten durch einen gezielten Aufruf des Large Language Model (LLM) gehandhabt und nicht durch den anspruchsvolleren Ansatz von Devin.

Dieses Muster setzte sich auch bei den Debugging-Aufgaben fort. Bei der Untersuchung, warum die SSH-Schlüsselweiterleitung im Setup-Skript nicht funktionierte, konzentrierte sich Devin auf das Skript selbst und zog nicht in Betracht, dass das Problem woanders liegen könnte. Dieser "Peek-a-boo"-Effekt führte dazu, dass wir die eigentliche Ursache nicht entdecken konnten. Als ein Teammitglied gebeten wurde, eine Konfliktprüfung zwischen Benutzereingaben und Datenbankwerten hinzuzufügen, verbrachte es Stunden damit, Devins Versuche zu studieren, bevor es aufgab und die Funktion in etwa 90 Minuten selbst schrieb.

Reflexionen im Team

Nach einem Monat intensiver Tests kam unser Team zusammen, um unsere Erfahrungen zu sortieren. Diese Zitate bringen unsere Gefühle am besten zum Ausdruck:

Die Aufgaben, die es erledigen kann, sind so klein und klar definiert, dass ich sie besser und schneller auf meine Weise erledige. Ich denke, dass es bei größeren, zeitsparenden Aufgaben, die ich sehen könnte, wahrscheinlich versagen wird. Folglich gibt es keine wirklichen Anwendungsfälle, in denen ich es wirklich einsetzen möchte.- Johno Whitaker

Anfangs war ich sehr aufgeregt, weil es so nah dran war und ich das Gefühl hatte, dass ich die Dinge noch optimieren könnte. Dann wurde ich langsam frustriert, weil ich immer mehr ändern musste und schließlich den Punkt erreichte, an dem es besser war, alles schrittweise von Grund auf neu zu machen.- Isaac Flath

Devin hatte Schwierigkeiten mit den internen Werkzeugen von AnswerAI, was unter anderem die Nutzung erschwerte. Trotz der umfangreichen Dokumentation und der Beispiele, die wir Devin zur Verfügung stellen, ist dies immer noch ein Problem. Ich habe festgestellt, dass dies bei Tools wie Cursor kein Problem ist, da es hier mehr Möglichkeiten gibt, die Dinge schrittweise in die richtige Richtung zu lenken.- Hamel Husain

Im Vergleich zu Devin haben wir festgestellt, dass entwicklergesteuerte Prozesse (wie Cursor) die meisten der Probleme, die wir in Devin hatten, vermieden haben.

ein Urteil fällen

Die Zusammenarbeit mit Devin veranschaulicht die Vision der autonomen KI-Entwicklung. Die Benutzererfahrung ist hervorragend - Chatten über Slack, beobachten, wie es asynchron arbeitet, Umgebungen einrichten und mit Abhängigkeiten umgehen. Wenn es funktioniert, ist es beeindruckend.

Aber genau da liegt das Problem - es funktioniert selten. Von den 20 Aufgaben, die wir versuchten, schlugen 14 fehl, 3 hatten ein ungewisses Ergebnis und nur 3 waren erfolgreich. Noch beunruhigender war, dass wir nicht vorhersagen konnten, welche Aufgaben erfolgreich sein würden. Selbst Aufgaben, die unseren frühen Erfolgen ähnelten, scheiterten auf komplexe und zeitraubende Weise. Was wie eine vielversprechende Autonomie aussah, wurde zu einer Belastung - Devin verbrachte Tage damit, unmögliche Lösungen zu finden, anstatt die zugrunde liegenden Hindernisse zu identifizieren.

Dies spiegelt ein Muster wider, das wir wiederholt bei KI-Tools beobachtet haben. Aufregung in den sozialen Medien und Unternehmensbewertungen haben wenig mit dem tatsächlichen Nutzen zu tun. Die verlässlichsten Signale, die wir gefunden haben, stammen aus detaillierten Berichten von Nutzern, die Produkte und Dienstleistungen liefern. Im Moment bleiben wir bei Tools, die uns die Möglichkeit geben, den Entwicklungsprozess zu steuern und gleichzeitig KI-Unterstützung zu leisten.

Anhang: Devins versuchter Einsatz

In der folgenden Tabelle sind die Projekte aufgelistet, die wir Devin übertragen haben, unterteilt nach folgenden Themen: (1) Erstellung neuer Projekte, (2) Forschung, (3) Analyse bestehender Codebasen und (4) Änderung von Codebasen.

1. die Schaffung neuer Projekte

2) Durchführungsstudien

3. die Analyse des bestehenden Codes

4. die Änderung von bestehenden Projekten