Was wir beim Aufbau von End-to-End-Testfunktionen in Devins virtueller Maschine gelernt haben.
Vor 3 Monaten bin ich zu Cognition gekommen, um am Aufbau der Zukunft der Softwareentwicklung mitzuwirken. Devin hat seit dem Start als erster KI-Softwareentwickler einen langen Weg zurückgelegt, und ich bin immer wieder begeistert, wenn ich sehe, wie das Team dahinter Devin tatsächlich tagtäglich einsetzt.
Eine Sache, die mir besonders auffiel, war, wie Devin seinen Computer nutzt, um Arbeiten autonom in der Cloud zu verifizieren. Von der Validierung unserer Slack-Integration bis zum Test komplexer Windsurf-Funktionen – das Team hat immer eine Armee von Devins im Testmodus. In diesem Beitrag erkläre ich, warum wir so stark auf End-to-End-Cloud-Agent-Verifikation setzen und wie wir daran arbeiten, sie aufzubauen.
Der Wandel hin zur asynchronen Softwareentwicklung
Wir bei Cognition haben kürzlich einen neuen Meilenstein erreicht. Zum ersten Mal werden mehr Devins asynchron ausgelöst – durch Ereignisse, Automatisierungen, Zeitpläne und andere Devins. Wir gehen davon aus, dass sich dieser Trend mit unserer kürzlichen Einführung von Auto-Triage weiter beschleunigen wird.
Bei diesem Übergang in die asynchrone Welt ist es entscheidend, dass Entwickler auf verifizierte Ergebnisse zurückgreifen können, die bereit für die Integration sind. Anfang des Jahres haben wir Devin Review eingeführt, ein Code-Review-Tool, das das menschliche Verständnis komplexer Code-Änderungen skaliert. Es markiert nicht nur Fehler – Devin schließt den Kreislauf, indem es jeden Befund behebt, bis der Änderungssatz sauber ist. Aber ein sauberes Review allein reicht oft nicht aus – Ingenieure wollen die Änderung End-to-End getestet sehen, so wie sie sie selbst testen würden.
Es ist ein großartiges Gefühl, wenn Devin einen Pull-Request (PR) einreicht, der eine Benutzerbeschwerde behebt, bevor man überhaupt die Nachricht im Bug-Kanal gesehen hat. Was es magisch macht, ist, wenn dieser PR mit einem Beweis kommt, dass die Behebung tatsächlich funktioniert. Und diese Magie könnte bald zur Notwendigkeit werden – je mehr PRs durch den Aufstieg proaktiver Agenten entstehen, desto schneller werden ungeprüfte Änderungen unkontrollierbar.
Von Anfang an
Seit dem Start von Devin konnte es seine Arbeit stets auf einer Cloud-VM demonstrieren. Vor etwa 6 Monaten haben wir Devins Computer-Use-Fähigkeiten erweitert. In der Praxis bedeutet das, dass wir Devins Werkzeugsatz um Funktionen wie Screenshots erstellen, Maus bewegen, klicken, ziehen, tippen, Tasten drücken, scrollen, warten, zoomen sowie Aufnahmen starten/stoppen ergänzt haben. Computer Use gibt es zwar schon eine Weile, aber wir haben festgestellt, dass die neueste Modellkohorte der führenden Labore wirklich gut darin geworden ist, diese Werkzeuge zu nutzen.
Computer Use hat für Devin einige unterhaltsame neue Fähigkeiten freigeschaltet, wie das Erstellen und Spielen eines Desktop-Spiels oder die Nutzung des Browsers, um Produkte auf Amazon zu bestellen. Aber die eigentliche Entdeckung, die wir machten, war Devins Fähigkeit, seine eigene Arbeit zu testen. Devin startet die App, klickt sich durch sie hindurch und bestätigt, dass seine Änderungen tatsächlich funktionieren – genau so, wie ein Entwickler es tun würde. Alles läuft in der Cloud und kann parallel skaliert werden. Das wurde mir richtig klar, als ich sah, wie Entwickler 10 bis 20 Devins parallel laufen ließen, jeder mit seinem eigenen Dev-Server, die an Änderungen arbeiteten – das ist etwas, das man auf einem einzelnen Laptop einfach nicht machen kann. Automatisierte Cloud-Tests haben uns enorm viel Zeit gespart, da wir den Code nicht mehr lokal ausführen und verifizieren müssen.
Um ehrlich zu sein, der Weg hierher war nicht einfach. Wir sind auf dem Weg auf zahlreiche Fehlermodi gestoßen, die uns jeweils etwas darüber gelehrt haben, was nötig ist, um dieses System zuverlässiger zu machen.
Steigerung der Zuverlässigkeit
In frühen Versionen kam es sehr häufig vor, dass Devin während des Testens vom Kurs abkam. Das geschah auf verschiedene Arten: Übermäßiges Testen nicht zusammenhängender Teile des Produkts, Verlieren in der Einrichtung, bevor die eigentliche Funktion erreicht wurde, oder einfach das Übersehen des Kernverhaltens, das der PR eigentlich ändern sollte.
Um dem entgegenzuwirken, lassen wir Devin im Testmodus zunächst einen Testplan erstellen, der ein klares Ziel vorgibt. Dieser Plan muss auf dem Quellcode und nicht auf Annahmen basieren. Ohne Verankerung im Code neigen die Modelle dazu, anzunehmen, sie könnten Wege in der App gehen, die es gar nicht gibt. Darüber hinaus erhöht der Testplan die Komplexität der Änderungen, die Devin erfolgreich testen kann, erheblich. Zu unseren ambitioniertesten Anfragen gehörten Funktionen, die den Betrieb mehrerer Dienste, spezifische Admin-Einstellungen und die richtigen Flags erforderten, bevor das Verhalten überhaupt erreichbar war. Wenn Devin den Code im Voraus liest, richtet es die Umgebung mit größerer Wahrscheinlichkeit korrekt ein, anstatt mitten im Test festzustellen, dass etwas fehlt. Der Testplan fungiert als eine Form der Vorabstimmung und verringert die Wahrscheinlichkeit, dass Devin während des aktiven Testens abdrifft.
Während Devin den Plan abarbeitet, fügt es eigene Annotationen in den Zeitstrahl ein. Dazu gehören Dinge wie Einrichtungsnotizen, der Start jedes benannten Tests und Behauptungen, die als bestanden, fehlgeschlagen oder nicht getestet markiert sind. Wir haben festgestellt, dass Devin weniger über seine Ergebnisse lügt, wenn es sein erwartetes Verhalten direkt vor der Durchführung einer Aktion annotiert – ähnlich wie bei der testgetriebenen Entwicklung: Wenn man sich im Vorfeld auf die Erwartung festlegt, wird es viel schwieriger, ein unerwartetes Ergebnis als Bestehen zu rechtfertigen.
Einige Teile des Testablaufs wiederholen sich bei fast jedem Durchlauf. Das klassische Beispiel ist das Einloggen: Das Steuern eines Anmeldeformulars per Computer Use bedeutet oft, eine E-Mail einzugeben, SSO abzuschließen, durch Weiterleitungen zu klicken und bei jedem Seitenaufbau Screenshot für Screenshot zu warten. Das kann sowohl zeit- als auch tokenintensiv sein. Um die Zuverlässigkeit und Kosten für diese Aktionen zu verbessern, hat Devin die Arbeit in ein deterministisches Skript extrahiert, das als Testfertigkeit in unserem Repository lebt. Auf diese Weise kann Devin das Skript ausführen, in Sekunden eine authentifizierte Browser-Sitzung erhalten und direkt zum Kern des Tests springen. Der deterministische Charakter dieser Skripte half, die Fehleranfälligkeit drastisch zu reduzieren. Wir haben Devin so aktualisiert, dass es diesen Kreislauf auch selbst schließen kann. Wenn Devin auf die harte Tour einen Einrichtungsschritt herausfindet, kann es vorschlagen, dieses Wissen als Testfertigkeit im Repository zu speichern und die Korrektur dem Benutzer als PR mit nur einem Klick vorzuschlagen.
Wir experimentieren auch damit, die Testphase an verschiedene Modelle weiterzuleiten. Da das Testen auf anderen Stärken beruht als das Schreiben von Code – wie dem Lesen von Screenshots, dem Verfolgen des UI-Zustands und der Entscheidung über die nächste Browser-Aktion – sind einige Modelle einfach besser darin als das typische Modell, das man für die Codebearbeitung wählen würde.
Autonomes Testen mit Devin heute nutzen
Devin betritt den Testmodus derzeit auf zwei Wegen: durch eine explizite Aufforderung, eine Änderung zu testen, oder nachdem Devin einen PR erstellt hat, bietet es an, die Änderung gegebenenfalls zu testen. Von dort aus erstellt es den Testplan und beginnt mit der Arbeit.
Oft benötigt Devin anfangs bei der Nutzung seiner Testfähigkeiten Ihre Unterstützung. Ein gutes Beispiel ist, wenn es beim lokalen Ausführen Ihrer App Geheimnisse benötigt. Um diesen Prozess reibungsloser zu gestalten, kann Devin Sie in der Sitzung nach fehlenden Anmeldeinformationen oder anderen Informationen fragen. Für schwierigere Fälle können Sie Devins Computer übernehmen und Dinge wie OTP-Codes eingeben. Die gute Nachricht ist: Sobald Devin mit der Einrichtung Ihres Repositorys fertig ist, kann es eine deklarative Konfiguration in Form einer YAML-Blueprint speichern, die für jede zukünftige Sitzung einen Snapshot erzeugt, von dem aus gestartet werden kann.
Was Sie zurückbekommen
Wenn Devin mit dem Testen fertig ist, sagt es Ihnen nicht nur, ob die App funktioniert hat. Eine reine Bildschirmaufzeichnung ist nützlich, aber wir fanden, dass sie allein nicht ausreicht – Sie müssen verstehen, was Sie sehen, warum Devin jede Aktion durchgeführt hat und welche Teile des Tests bestanden oder fehlgeschlagen sind.
Für eine schnelle Überprüfung liefert Devin einen Testbericht mit beschrifteten Screenshots von Schlüsselmomenten des Durchlaufs, damit Sie schnell sehen können, was Devin getestet hat und wie die App dabei aussah.
Wenn Sie eine tiefergehende Überprüfung wünschen, erstellt Devin auch ein Testvideo mit einer umfangreichen Player-Oberfläche, die Kapitel enthält, um zwischen Testabschnitten zu springen, den gesamten Durchlauf zu durchsuchen und die bestandenen oder fehlgeschlagenen Behauptungen in einer chronologischen Listenansicht zu inspizieren. In der Nachbearbeitung wird die tote Zeit zwischen Aktionen komprimiert, während die Momente um die Aktionen herum in normaler Geschwindigkeit abgespielt werden. So wird ein langer Durchlauf zu einer Aufnahme verdichtet, die Sie sich tatsächlich ansehen können. Diese Artefakte sind in unserer Weboberfläche verfügbar und werden auch an Slack verteilt, wenn Devin von dort gestartet wurde.
Schwierige Kanten
Computer Use hat immer noch seine Schwierigkeiten. Ein Beispiel ist das Timing – wenn Devin eine Toast-Benachrichtigung testet, kann ein zu früh oder zu spät aufgenommener Screenshot den Toast vollständig verpassen, und die Modelle können verwirrt sein, ob das erwartete Verhalten tatsächlich eingetreten ist.
Ein weiterer Fehlermodus ist das Schummeln. Sich selbst überlassen, neigen die Modelle manchmal dazu, sich zu stark auf die Ausführung von JavaScript im Browser zu verlassen, um Zustände programmatisch auszulösen, anstatt durch die UI zu klicken. Dies kann hilfreich sein, um Funktionalität zu testen, aber Benutzer möchten oft sehen, dass Devin die App so bedient, wie ein echter Benutzer es tun würde.
Wir arbeiten aktiv an diesen Problemen durch verbesserte Evaluierungen, strengere Schutzmechanismen im Werkzeugsatz und jede neue Modellgeneration, die besser im Computer Use wird.
Die Zukunft der asynchronen Entwicklung ist verifiziert
In den letzten Monaten hat sich die Anzahl der genehmigten Testläufe pro Tag auf Devin mehr als verdoppelt. Dieses Wachstum spiegelt etwas Einfaches wider: Asynchrone Agenten sind nur dann nützlich, wenn Entwickler dem vertrauen können, womit sie zurückkommen. Oft kann dieses Vertrauen nicht allein aus dem Code kommen: Bei vielen Änderungen möchte man wissen, dass die App tatsächlich ausgeführt wurde, die wichtigen Abläufe durchgespielt wurden und das Ergebnis so festgehalten wurde, dass es leicht überprüfbar ist.
Dafür ist das autonome Testen in Devin konzipiert. Devin plant den Test, bedient die App, zeichnet auf und annotiert, was passiert ist, und liefert schließlich Artefakte, die das Ergebnis überprüfbar machen. Es gibt noch viel zu verbessern, aber wir glauben, dass dies die richtige Form der Zukunft ist: Agenten, die nicht nur asynchron arbeiten, sondern mit einem Beweis zurückkommen.
Wir sind ständig überrascht, wie viel Zeit Devin uns spart, indem es seine eigene Arbeit testet, und haben das Gefühl, dass viele Kunden die automatisierte Testfunktion von Devin noch nicht voll ausschöpfen. Um Experimente zu unterstützen, berechnen wir derzeit nur 1/5 der normalen Nutzungskosten im Testmodus.
Probieren Sie unsere Arbeit auf devin.ai oder windsurf.com aus. Und wenn die Arbeit an solchen Problemen interessant klingt, kontaktieren Sie uns unter ido [at] cognition.ai
