Als Cognition Devin im Frühjahr 2024 erstmals vorstellte, war das Echo groß. Ein Agent, der eigenständig Entwicklungsumgebungen aufsetzt, Fehlermeldungen liest, Dokumentation im Browser nachschlägt und sich iterativ zum Ziel arbeitet, war damals ein neues Bild. Seitdem hat sich der Markt stark bewegt: Mehrere große Plattformanbieter haben eigene Cloud-Agenten vorgestellt, und auch klassische Editor-Assistenten haben agentische Modi bekommen. Devin ist dadurch nicht mehr allein, bleibt aber einer der konsequentesten Vertreter des Gedankens, Entwicklungsarbeit an einen Agenten zu delegieren, statt sie mit KI-Hilfe selbst zu erledigen.
Drei Eigenschaften prägen Devin:
Um Devin einzuordnen, hilft eine einfache Stufung. Auf der ersten Stufe stehen Vervollständigungs-Assistenten, die beim Tippen Vorschläge machen. Auf der zweiten Stufe stehen Chat- und Inline-Funktionen, mit denen man im Editor Änderungen beschreibt und als Diff übernimmt. Die dritte Stufe sind Agenten im Editor oder Terminal, die unter Aufsicht mehrere Dateien bearbeiten und Befehle ausführen. Devin gehört zur vierten Stufe: Agenten, die außerhalb des Arbeitsplatzes eigenständig an einer Aufgabe arbeiten und erst am Ende – oder bei Rückfragen – wieder mit einem Menschen interagieren.
Der Unterschied ist nicht nur technisch, sondern organisatorisch. Ein Editor-Assistent beschleunigt eine Entwicklerin bei ihrer eigenen Arbeit. Ein delegierbarer Agent verändert dagegen, wie Arbeit verteilt wird: Tickets können direkt an Devin gehen, Entwicklerinnen und Entwickler werden stärker zu Auftraggebern und Prüfern. Das kann Kapazität freisetzen, verschiebt aber auch die Last – weg vom Schreiben, hin zum präzisen Beschreiben und sorgfältigen Prüfen.
Den größten Nutzen sehen wir bei Teams mit einem stetigen Strom kleinerer, klar abgegrenzter Aufgaben und einer belastbaren Testabdeckung. Typische Beispiele sind Plattform- und Produktteams, die viele Services pflegen, Organisationen mit technischer Schuld in Form veralteter Bibliotheken oder Frameworks und Teams, deren Backlog von „kleinen Dingen“ verstopft wird, die niemand gern übernimmt. Wo automatisierte Tests fehlen, fehlt Devin die wichtigste Rückmeldung – und der Prüfaufwand für Menschen steigt entsprechend.
Weniger geeignet ist Devin für Teams ohne gefestigte Git- und Review-Prozesse, für Projekte mit hochsensiblen Daten, die keine US-Cloud verlassen dürfen, und für sehr kleine Codebasen, bei denen der Aufwand der Aufgabenbeschreibung den Nutzen der Delegation übersteigt. Auch wer KI vor allem als Lernhilfe oder Pair-Programming-Partner nutzen möchte, ist mit einem editor-nahen Werkzeug besser bedient.
Schließlich lohnt ein ehrlicher Blick auf die Erwartungen im Management. Der Begriff „KI-Software-Engineer“ weckt die Vorstellung, man könne Personalengpässe direkt durch Agenten-Lizenzen ausgleichen. Aus unserer Projektpraxis ist das nicht realistisch. Devin kann ein Team spürbar entlasten, aber er braucht Menschen, die Aufgaben schneiden, Kontext liefern, Ergebnisse prüfen und Verantwortung übernehmen. Wer das von Anfang an mitplant, wird von Devin eher positiv überrascht als enttäuscht.
Cognition positioniert Devin bewusst nicht als besseren Autovervollständiger, sondern als zusätzliches Teammitglied, an das man Arbeit abgeben kann. In der Kommunikation des Anbieters stehen deshalb Begriffe wie Autonomie, Parallelität und Durchsatz im Vordergrund: Ein Team soll mehrere Devin-Sitzungen gleichzeitig auf unterschiedliche Tickets ansetzen können, während die Menschen sich auf anspruchsvollere Aufgaben konzentrieren. Die Zielgruppe hat sich dabei erkennbar von experimentierfreudigen Einzelentwicklern hin zu Engineering-Organisationen in größeren Unternehmen verschoben, die große Codebestände modernisieren müssen.
Für die Bewertung im Mittelstand ist diese Positionierung wichtig, weil sie die Erwartung prägt. Devin wird am Ergebnis gemessen – am fertigen, mergefähigen Pull Request –, nicht an der Qualität einzelner Vorschläge. Das macht den Nutzen leichter messbar, aber auch Fehlschläge sichtbarer: Ein Agent, der an einer Aufgabe scheitert, hat Rechenzeit verbraucht und muss neu instruiert werden. Die richtige Auswahl der Aufgaben ist deshalb der wichtigste Erfolgsfaktor.
Im Sommer 2025 wurde berichtet, dass Cognition die KI-IDE Windsurf übernommen hat, nachdem zuvor Übernahmegespräche mit einem anderen großen KI-Anbieter gescheitert waren und Teile der Windsurf-Führung zu einem anderen Technologiekonzern gewechselt sein sollen. Nach übereinstimmenden Berichten gingen Produkt, Marke und wesentliche Teile des Teams an Cognition. Strategisch ergibt das Sinn: Cognition kann so den asynchronen Cloud-Agenten mit einem synchronen Editor-Erlebnis verbinden und beide Arbeitsweisen aus einer Hand anbieten.
Für Unternehmen bedeutet das zweierlei. Einerseits kann eine engere Verzahnung von Editor und Agent den Alltag erleichtern, etwa wenn Aufgaben im Editor begonnen und an den Cloud-Agenten übergeben werden. Andererseits verändern Übernahmen häufig Produktpläne, Tarife, Vertragsbedingungen und Subprozessoren. Prüfen Sie vor einer Entscheidung den aktuellen Stand direkt beim Anbieter: Welche Produkte werden weitergeführt, wie sind sie verzahnt, und welche Vertragspartei ist für welche Datenverarbeitung verantwortlich? Unsere Einordnung von Windsurf finden Sie im eigenen Wissensartikel.
Der wichtigste funktionale Unterschied zu editor-basierten Werkzeugen ist die eigene Arbeitsumgebung. Devin muss nicht darauf warten, dass ein Mensch Befehle bestätigt oder Dateien öffnet, sondern kann in seiner Maschine selbstständig ausprobieren: ein Projekt bauen, einen fehlschlagenden Test reproduzieren, eine Bibliothek aktualisieren, die Auswirkungen beobachten und nachsteuern. Diese Schleife aus Handeln, Beobachten und Korrigieren ist es, die Agenten gegenüber reinen Textgeneratoren auszeichnet.
Damit das funktioniert, muss die Umgebung vorbereitet werden. Devin braucht Zugriff auf die relevanten Repositories, muss Abhängigkeiten installieren können und benötigt unter Umständen Zugänge zu Paketquellen, Test-Datenbanken oder internen Diensten. In der Praxis wird dafür eine Art Grundkonfiguration der Maschine angelegt, die als Ausgangspunkt für alle Sitzungen dient. Je sauberer diese Konfiguration, desto zuverlässiger arbeitet der Agent – und desto wichtiger ist es, sie wie produktive Infrastruktur zu behandeln: dokumentiert, mit minimalen Rechten und ohne dauerhaft hinterlegte Produktivgeheimnisse.
Ein Agent ist nur so gut wie der Kontext, den er bekommt. Devin bringt deshalb Mechanismen mit, um Projektwissen dauerhaft verfügbar zu machen. Dazu gehören hinterlegte Hinweise zu Konventionen und Abläufen, wiederverwendbare Vorlagen für typische Aufgaben und Funktionen, die Repositories automatisch analysieren und in eine durchsuchbare, wiki-ähnliche Dokumentation überführen. Solche Werkzeuge sind nicht nur für den Agenten nützlich: Auch neue Teammitglieder profitieren davon, sich mit einer generierten Übersicht schneller in fremde Codebasen einzuarbeiten.
Wichtig ist, diese Wissensbasis bewusst zu pflegen. Veraltete Hinweise führen den Agenten genauso in die Irre wie veraltete Dokumentation einen Menschen. Zudem gilt: Alles, was in Devins Wissensspeicher landet, liegt beim Anbieter. Interne Hostnamen, Zugangsdaten oder personenbezogene Informationen gehören dort nicht hinein.
Devin ist kein Ersatz für eine vollständige Entwicklungsumgebung im eigenen Netz. Systeme, die nur aus dem Unternehmensnetz erreichbar sind, Hardware-Abhängigkeiten, lizenzpflichtige Spezialwerkzeuge oder Tests, die echte Produktionsdaten benötigen, lassen sich in einer Cloud-Sandbox nur mit Zusatzaufwand oder gar nicht abbilden. Auch grafisch anspruchsvolle Oberflächen oder komplexe, mehrstufige Integrations-Setups stoßen schnell an Grenzen. Für solche Fälle ist ein lokal arbeitender Agent oder die klassische Arbeit mit einem Editor-Assistenten oft die realistischere Wahl.
Eine typische Devin-Sitzung folgt einem wiederkehrenden Muster. Am Anfang steht eine Aufgabenbeschreibung, etwa ein Ticket oder eine Slack-Nachricht. Devin analysiert das Repository, sucht relevante Stellen und schlägt einen Plan vor. Nach Freigabe oder Anpassung des Plans setzt er die Änderungen um, führt Builds und Tests aus, wertet Fehlermeldungen aus und korrigiert sich, bis die Aufgabe aus seiner Sicht erledigt ist. Am Ende stehen ein Pull Request und eine Zusammenfassung der Arbeit. Bei Unklarheiten fragt der Agent nach – über denselben Kanal, über den die Aufgabe kam.
Weil jede Sitzung in einer eigenen Maschine läuft, können mehrere Aufgaben gleichzeitig bearbeitet werden. Darin liegt ein wesentlicher Reiz des Konzepts: Eine Entwicklerin kann morgens mehrere klar umrissene Tickets an Devin übergeben, sich selbst einer anspruchsvollen Aufgabe widmen und später die Ergebnisse prüfen. Bei großen, gleichförmigen Vorhaben – etwa demselben Bibliotheks-Update in vielen Repositories – lassen sich Aufgaben auch in viele Teilaufgaben zerlegen, die parallel abgearbeitet werden.
Die Kehrseite: Parallelität verschiebt den Engpass zum Review. Wer zehn Pull Requests gleichzeitig erzeugen lässt, muss zehn Pull Requests prüfen. Ohne entsprechend geplante Review-Kapazität entsteht schnell ein Stau, oder – schlimmer – die Prüfung wird oberflächlich. Wir empfehlen, die Zahl paralleler Sitzungen bewusst an der realen Review-Kapazität des Teams auszurichten.
Agenten wie Devin arbeiten am besten, wenn Ziel und Erfolgskriterium klar sind und der Agent selbst prüfen kann, ob er sie erreicht hat. Je unschärfer die Aufgabe, desto größer das Risiko, dass der Agent in eine falsche Richtung läuft, plausibel wirkende, aber unpassende Lösungen baut oder sich in Schleifen verfängt. Typische Problemfelder sind vage formulierte Anforderungen, implizites Fachwissen, das nirgends dokumentiert ist, weitreichende Architekturentscheidungen und Änderungen, deren Korrektheit sich nur mit Domänenwissen beurteilen lässt.
Ein oft unterschätzter Vorteil ist die Transparenz der Sitzungen. In der Weboberfläche lässt sich nachvollziehen, welche Befehle Devin ausgeführt, welche Dateien er geöffnet und welche Seiten er im Browser aufgerufen hat. Das ist nicht nur für die Fehlersuche hilfreich, sondern auch ein Governance-Instrument: Wer verstehen will, wie ein Ergebnis zustande kam, kann den Weg dorthin prüfen. Zugleich sollte man den Arbeitsverlauf nicht als Ersatz für das Review des Ergebnisses missverstehen – er ergänzt es, ersetzt es aber nicht.
Die Slack-Integration ist für viele Teams der erste Berührungspunkt. Eine Aufgabe wird in einem Kanal oder Thread an Devin adressiert, der Agent bestätigt, stellt Rückfragen und meldet sich mit dem Ergebnis. Das senkt die Einstiegshürde erheblich, weil niemand ein neues Werkzeug öffnen muss. Ähnlich funktioniert die Anbindung an Ticketsysteme wie Jira oder Linear: Tickets können Devin zugewiesen werden, der Fortschritt wird im Ticket dokumentiert. Gerade für wiederkehrende Kleinaufgaben aus dem Backlog ist dieser Weg sehr effizient.
Aus Sicherheits- und Datenschutzsicht ist genau diese Bequemlichkeit der kritische Punkt. Eine Chat-Integration bedeutet, dass Nachrichteninhalte an den Anbieter fließen können. Ticketsysteme enthalten häufig mehr als Technik: Kundennamen, Fehlerberichte mit personenbezogenen Daten, Screenshots aus Produktivsystemen. Bevor Integrationen aktiviert werden, sollte geklärt sein, welche Kanäle und Projekte Devin sehen darf und welche Inhalte dort grundsätzlich nicht hingehören.
Die Anbindung an die Git-Plattform ist das Rückgrat jeder Devin-Nutzung. Der Agent benötigt Lese- und Schreibzugriff auf die Repositories, an denen er arbeiten soll, und legt Branches und Pull Requests an. Hier entscheidet sich, wie viel Schaden ein fehlerhafter oder kompromittierter Agent anrichten könnte. Wir empfehlen, Devin nur für ausgewählte Repositories freizuschalten, ihm kein Recht zum Zusammenführen in geschützte Zweige zu geben und für jeden Pull Request dieselben automatischen Prüfungen und Review-Regeln anzuwenden wie für menschliche Beiträge.
Die CI-Pipeline wird damit zur wichtigsten Qualitätsschranke. Tests, statische Analyse, Sicherheits- und Lizenzscans laufen auf Devins Änderungen genauso wie auf allen anderen. Teams mit einer starken Pipeline profitieren daher überproportional, denn jede automatische Prüfung entlastet das menschliche Review. Umgekehrt gilt: Wo die Pipeline schwach ist, wächst das Risiko, dass fehlerhafte Agenten-Änderungen durchrutschen.
Über eine Programmierschnittstelle lassen sich Devin-Sitzungen auch aus eigenen Werkzeugen heraus starten – etwa wenn ein Sicherheitsscanner eine verwundbare Abhängigkeit meldet und automatisch ein Update-Versuch angestoßen werden soll. Solche Automatisierungen sind mächtig, brauchen aber klare Grenzen: Mengenbegrenzungen gegen Kostenexplosionen, eindeutige Zuständigkeiten für die erzeugten Pull Requests und eine sorgfältige Verwaltung der API-Zugangsdaten.
Devin spielt seine Stärken aus, wenn ein Team Aufgaben über die eigenen Werkzeuge delegieren möchte, ohne sich auf das Ökosystem einer bestimmten Git-Plattform oder eines Modellanbieters festzulegen. Die Kombination aus vollwertiger Sandbox inklusive Browser, gut ausgebauter Slack- und Ticket-Integration, Wissensverwaltung und paralleler Sitzungen ist auf genau diesen Anwendungsfall zugeschnitten. Auch Organisationen, die bereits mit unterschiedlichen Git-Plattformen arbeiten, profitieren von einem Agenten, der nicht an eine Plattform gebunden ist.
Wer ohnehin tief im GitHub-Ökosystem arbeitet, findet im integrierten Coding-Agenten der Plattform oft eine naheliegende, administrativ einfachere Lösung, die über bestehende Verträge abgedeckt werden kann. Cloud-Agenten der großen Modellanbieter wie OpenAI Codex oder Google Jules sind attraktiv, wenn bereits ein Vertragsverhältnis mit diesem Anbieter besteht. Terminalbasierte Agenten wie Claude Code oder Open-Source-Werkzeuge wie Cline und Aider eignen sich, wenn Code möglichst nicht in eine fremde Ausführungsumgebung wandern soll oder wenn Entwicklerinnen und Entwickler den Agenten eng führen möchten.
In der Praxis ist die Frage selten „entweder–oder“. Viele Teams kombinieren einen editor-nahen Assistenten für die tägliche Arbeit mit einem Cloud-Agenten für delegierbare Aufgaben. Entscheidend sind die vorhandene Toolchain, die Datenschutzanforderungen, die Vertragslage mit bestehenden Anbietern und die Frage, wie viel Autonomie man der KI in welchem Schritt zugestehen möchte. Da sich der Markt sehr schnell bewegt, sollte jede Auswahl regelmäßig überprüft werden.
Im Standardfall laufen Devins Sandboxen in der Cloud-Infrastruktur von Cognition. Code wird dort geklont, verarbeitet und ausgeführt; die Ergebnisse gehen über die Git-Plattform zurück. Für Enterprise-Kunden hat der Anbieter Betriebsvarianten kommuniziert, bei denen die Ausführungsumgebungen in einer vom Kunden kontrollierten Cloud-Umgebung laufen, etwa in einem eigenen virtuellen Netz bei einem großen Hyperscaler. Solche Varianten können Datenflüsse deutlich reduzieren, weil Quellcode und Laufzeitumgebung im eigenen Verantwortungsbereich bleiben.
Wichtig ist der genaue Blick auf die Details, denn „im eigenen Netz“ heißt nicht automatisch „ohne Datenabfluss“. Auch bei isolierten Varianten werden in der Regel Steuerungsinformationen und Modellanfragen mit Code-Ausschnitten an Dienste des Anbieters oder der eingesetzten Modellanbieter übertragen. Klären Sie vor einer Entscheidung schriftlich, welche Komponenten wo laufen, welche Daten welche Grenze überschreiten, in welchen Regionen verarbeitet wird und ob eine Verarbeitung in der EU vertraglich zugesichert werden kann. Ein vollständiges Self-Hosting im Sinne eines eigenständig betreibbaren On-Premises-Produkts ist nach unserem Kenntnisstand nicht das Kerndesign von Devin – Verfügbarkeit und Ausgestaltung bitte aktuell beim Anbieter prüfen.
Bevor Devin produktiv arbeiten kann, muss seine Umgebung eingerichtet werden. Dazu gehört die Auswahl der Repositories, das Hinterlegen der Build- und Testbefehle, das Installieren benötigter Werkzeuge und das Anlegen erster Wissenseinträge. Zugangsdaten zu externen Diensten sollten nur dann bereitgestellt werden, wenn sie für die Aufgaben zwingend nötig sind – und dann mit minimalen Rechten, auf Testumgebungen beschränkt und regelmäßig rotiert. Produktivdatenbanken, Kundendaten und Deploy-Schlüssel gehören grundsätzlich nicht in eine Agenten-Sandbox.
Im laufenden Betrieb braucht Devin eine verantwortliche Rolle – ähnlich wie jedes andere System mit Schreibzugriff auf Quellcode. Diese Rolle überwacht Verbrauch und Kosten, prüft regelmäßig die vergebenen Berechtigungen, pflegt die Wissensbasis und verfolgt Änderungen an Produkt, Tarifen und Vertragsbedingungen des Anbieters. Gerade nach Übernahmen und Produktumbauten ist dieser kontinuierliche Blick wichtig, damit eine anfangs saubere Einführung nicht schleichend zu einem unübersichtlichen Risiko wird.
In unseren Projekten sehen wir drei Szenarien, in denen Devin im Mittelstand besonders sinnvoll sein kann. Das erste ist die Modernisierung von Bestandssoftware: Framework-Upgrades, das Ablösen veralteter Bibliotheken oder das schrittweise Umstellen auf neuere Sprachversionen sind oft gleichförmig, aufwändig und unbeliebt – ideale Kandidaten für einen Agenten, der viele kleine, gut prüfbare Schritte abarbeitet. Das zweite ist die Pflege des Backlogs: kleine Fehler, fehlende Tests, Dokumentationslücken und technische Aufräumarbeiten, die im Tagesgeschäft liegen bleiben. Das dritte ist die Einarbeitung in Altsysteme, bei der automatisch erzeugte Projektdokumentation und die Möglichkeit, dem Agenten Fragen zum Code zu stellen, neuen Teammitgliedern den Einstieg erleichtern.
Weniger geeignet sind dagegen Projekte mit hochsensiblen Daten, stark regulierte Umgebungen ohne Möglichkeit einer isolierten Betriebsvariante, Systeme mit vielen Abhängigkeiten zu internen Diensten und Vorhaben, bei denen die Anforderungen selbst noch unklar sind. In solchen Fällen ist der Aufwand, den Agenten sinnvoll einzusetzen, häufig höher als der Nutzen.
Für ein Entwicklungsteam von fünf bis fünfzehn Personen kann ein Agent wie Devin spürbar Kapazität freisetzen, weil Routinearbeit einen großen Anteil des Alltags ausmacht. Die Voraussetzung ist allerdings, dass jemand Zeit in die Einrichtung, die Pflege der Wissensbasis und das Review investiert. Unsere Erfahrung zeigt: Die erfolgreichsten Teams benennen eine Person, die den Agenten „betreut“, Erfahrungen sammelt und die Qualität der Aufgabenbeschreibungen im Team verbessert. Ohne diese Rolle bleibt Devin häufig ein Experiment, das nach einigen Wochen versandet.
Ob sich Devin rechnet, lässt sich nicht pauschal sagen. Den Lizenz- und Verbrauchskosten stehen eingesparte Entwicklerzeit, schneller abgearbeitete Backlogs und geringere technische Schuld gegenüber – aber auch zusätzlicher Aufwand für Aufgabenbeschreibung, Review, Nacharbeit und Governance. Wir empfehlen, den Nutzen im Pilot anhand konkreter Messgrößen zu bewerten: Wie viele übergebene Aufgaben führten zu einem mergefähigen Ergebnis, wie viel Nacharbeit war nötig, und wie hat sich die Durchlaufzeit im Vergleich zur bisherigen Bearbeitung entwickelt? Erst auf dieser Grundlage ist eine belastbare Entscheidung über einen breiteren Einsatz möglich.
Devin wird typischerweise über eine Kombination aus Abonnement und nutzungsabhängiger Abrechnung bepreist. Der Anbieter verwendet dafür eigene Recheneinheiten, die je nach Dauer und Aufwand einer Sitzung verbraucht werden. Einstiegs-, Team- und Enterprise-Angebote unterscheiden sich in enthaltenem Kontingent, Verwaltungsfunktionen und Sicherheitsoptionen. Konkrete Preise und Einheiten haben sich in der Vergangenheit mehrfach geändert und sollten immer aktuell beim Anbieter geprüft werden.
Für die Budgetplanung ist das nutzungsbasierte Modell eine Herausforderung. Eine schlecht beschriebene Aufgabe, an der der Agent lange erfolglos arbeitet, kostet mehr als eine gut beschriebene, die schnell gelingt. Parallele Sitzungen und automatisch ausgelöste Läufe können Verbrauch schnell in die Höhe treiben. Wir empfehlen feste Budgetgrenzen, ein regelmäßiges Verbrauchs-Reporting und klare Regeln, wer Sitzungen starten darf.
Aus Sicherheitssicht ist Devin ein automatisiertes System mit Schreibzugriff auf Quellcode und – je nach Konfiguration – Zugängen zu weiteren Diensten. Daraus ergeben sich spezifische Risiken. Ein Agent, der im Browser Webseiten aufruft und Dokumentation liest, kann manipulierten Inhalten begegnen, die ihn zu unerwünschten Aktionen verleiten sollen. Abhängigkeiten, die der Agent installiert, können kompromittiert sein. Zugangsdaten in der Sandbox können abfließen, wenn sie nicht sorgfältig begrenzt sind. Die Antwort darauf sind bewährte Prinzipien: minimale Rechte, keine Produktivgeheimnisse in der Sandbox, kein Merge-Recht, vollständige CI-Prüfungen auf jeden Pull Request und eine Protokollierung, die nachvollziehbar macht, was der Agent getan hat. Fragen Sie den Anbieter zudem nach aktuellen Sicherheitszertifizierungen und Prüfberichten.
Wie bei allen KI-Coding-Werkzeugen stellt sich die Frage, wem der erzeugte Code gehört und ob er unbeabsichtigt fremden, lizenzpflichtigen Code enthalten kann. Die Nutzungsbedingungen der Anbieter regeln die Rechte am erzeugten Output in der Regel zugunsten des Kunden, die Details sollten aber vertraglich geprüft werden. Zusätzlich empfehlen wir Lizenz- und Herkunftsscans in der CI-Pipeline, gerade wenn ein Agent eigenständig Abhängigkeiten hinzufügt. Und schließlich gilt: Wer ganze Repositories einem externen Dienst anvertraut, muss vertraglich sicherstellen, dass Vertraulichkeit, Löschfristen und Nutzungsbeschränkungen klar geregelt sind.
Quellcode ist nicht automatisch personenbezogen – aber er enthält es häufiger, als man denkt: in Testdaten, Konfigurationsdateien, Kommentaren, Commit-Historien mit Namen und E-Mail-Adressen oder in Ticketinhalten, die über Integrationen mitgelesen werden. Damit ist die DSGVO in der Regel anwendbar. Erforderlich sind ein Auftragsverarbeitungsvertrag, Transparenz über alle Subprozessoren einschließlich der Modellanbieter, eine Bewertung des Drittlandtransfers in die USA, ein Eintrag im Verzeichnis von Verarbeitungstätigkeiten und gegebenenfalls eine Datenschutz-Folgenabschätzung. Der wirksamste Hebel ist Datenminimierung: nur ausgewählte Repositories, bereinigte Testdaten, begrenzte Integrationen.
Wer maximale Datenhoheit benötigt, sollte isolierte Betriebsvarianten mit Ausführung in einer eigenen, EU-gehosteten Cloud-Umgebung prüfen oder für sensible Codebasen auf lokal betreibbare Agenten und selbst gehostete Modelle ausweichen. Eine Mischstrategie ist oft sinnvoll: Devin für unkritische Repositories, lokale Werkzeuge für den sensiblen Kern.
