Devin AI: Aufgaben, erster Workflow, Kosten und Kontrolle

Was ist Devin AI, und was ist Cognition?

Cognition ist der Hersteller; Devin ist das Produkt für agentische Softwareentwicklung. Nach der offiziellen Produktdokumentation arbeitet Devin mit einer Entwicklungsumgebung einschließlich Editor, Shell und Browser. Das unterscheidet einen delegierten Entwicklungsauftrag von einer reinen Antwort im Chat: Der Agent kann vorhandenen Code untersuchen, Dateien bearbeiten und die Umgebung zur Überprüfung nutzen.

Die Produktfamilie umfasst Cloud-Arbeit sowie Zugänge über Desktop und Kommandozeile. Entscheidend ist für Ihren Einstieg weniger die Oberfläche als die konkrete Arbeitsweise: Welches Repository sieht der Agent? Welche Befehle darf er ausführen? Wo erscheinen die Änderungen? Wie kontrolliert das Team das Ergebnis? Ein Pull Request ist dabei ein zur Prüfung vorgelegter Änderungsvorschlag; seine Erstellung bedeutet noch keine Freigabe.

„Autonom“ bedeutet, dass mehrere Arbeitsschritte innerhalb eines Auftrags ohne einzelne manuelle Anweisung stattfinden können. Es bedeutet keine garantierte fachliche Richtigkeit. Der Mensch muss weiterhin erwünschtes Verhalten, Grenzen und Abnahme festlegen. Ein Agent kann einen falsch verstandenen Auftrag konsequent ausführen und ihn mit ebenso falsch verstandenen Tests bestätigen.

Betrachten Sie Devin daher als zusätzlichen Akteur in einem bestehenden Engineering-Prozess. Gute Aufgaben und eine funktionierende Testumgebung sind Voraussetzungen für eine sinnvolle Beurteilung. Wer zugleich ein unbekanntes Repository, eine defekte lokale Umgebung und eine unklare Fachanforderung übergibt, kann einen Fehlschlag kaum einer einzelnen Ursache zuordnen.

Welche Aufgaben eignen sich für einen ersten Versuch?

Die Herstellerhinweise zur Aufgabenwahl betonen klare Verifikationskriterien, ausreichenden Kontext und abgegrenzte Arbeitspakete. Daraus lässt sich eine praktische Auswahlregel ableiten: Wählen Sie eine Aufgabe, deren richtige Lösung Ihr Team schon vor der Umsetzung erkennen kann.

Geeignet für einen ersten kontrollierten Versuch sind beispielsweise eine reproduzierbare Fehlerbehebung mit bestehenden Tests, die Ergänzung fehlender Testfälle für bekanntes Verhalten, eine kleine dokumentierte Refaktorierung oder die Aktualisierung einer klar abgegrenzten Dokumentation. Auch wiederkehrende Änderungen können interessant sein, wenn Sie zunächst einen einzelnen Fall prüfen und die Verallgemeinerung anschließend separat bestätigen.

Ein gutes erstes Ticket nennt die betroffene Funktion, Beispiele, erlaubte Änderungen und den vorhandenen Testbefehl. Es lässt Raum für eine begründete Implementierung, aber wenig Raum für erfundenes Sollverhalten. Idealerweise kann ein Reviewer den vollständigen Diff verstehen, ohne erst ein großes neues Subsystem zu untersuchen.

Als redaktionelle Empfehlung für den Erstversuch sollten Sie umfassende Neuentwicklungen ohne bestätigte Anforderungen, großflächige Architekturwechsel und produktive Änderungen an Zahlungen oder Berechtigungen zurückstellen. Solche Aufgaben brauchen mehr Kontext und strengere Abnahme. Das ist keine Aussage, dass das Produkt sie grundsätzlich nicht bearbeiten kann; es begrenzt die Unsicherheit Ihres ersten Versuchs.

Ebenso wichtig ist die Arbeitsumgebung. Kann das Team die vorhandenen Tests selbst ausführen? Sind Abhängigkeiten und notwendige Entwicklungsdienste verfügbar? Lässt sich ein Fehler reproduzieren? Wenn diese Bedingungen fehlen, beginnt Ihr Einstieg mit der Einrichtung und Klärung statt mit delegierter Implementierung.

Der erste Workflow: vom Ticket zum überprüften Pull Request

Die aktuelle First-run-Anleitung unterscheidet Ask für Erkundung und Planung von Agent für Änderungen und Ausführung. Eine unklare Aufgabe können Sie zunächst im Planungsmodus besprechen. Den Umsetzungsauftrag geben Sie erst frei, wenn Kontext, Sollverhalten und Grenzen stimmen. Der folgende Ablauf ist ein Vorschlag für einen kleinen Erstversuch.

1. Repository, Arbeitsraum und Testbasis vorbereiten

Verbinden Sie ausschließlich die benötigten Repositories und prüfen Sie die tatsächlich vergebenen Rechte. Wählen Sie einen Ausgangsbranch, stellen Sie Entwicklungsabhängigkeiten bereit und bestätigen Sie den Testbefehl. Nutzen Sie Testdaten. Produktive Zugangsdaten sind für eine lokale Fehlerbehebung meist kein notwendiger Kontext.

Führen Sie den unveränderten Teststand selbst aus oder halten Sie einen nachvollziehbaren Ausgangslauf fest. So erkennen Sie später, welche Fehler bereits vor dem Auftrag bestanden. Definieren Sie außerdem, wo Devin schreiben darf und wer den Pull Request abnimmt. Ein automatischer Merge gehört nicht in dieses vorgeschlagene Einstiegsmodell.

2. Einen präzisen Auftrag und unabhängige Erwartungen formulieren

Die unabhängige Erwartung beschreibt das Verhalten und keine bestimmte Zeichenfolge der erzeugten URL. Verschiedene zulässige Kodierungen können denselben Wert ergeben. Der Reviewer prüft deshalb den wieder ausgelesenen Parameter. So verhindern Sie, dass ein zufällig vom Agenten gewähltes Format zur erfundenen Fachanforderung wird.

3. Den Plan lesen und die Umsetzung begrenzen

Lassen Sie Devin zunächst Fundstelle, Fehlerursache und Änderungsvorschlag erläutern. Prüfen Sie, ob die genannten Dateien und Tests zum Auftrag passen. Fehlt eine Fachentscheidung oder ein Dienst, klären Sie das gezielt. Ein umfangreicher Umbau der Suchanwendung wäre bei diesem Auftrag kein geeigneter Ersatz für die kleine Fehlerbehebung.

Starten Sie dann die Agentenarbeit mit dem bestätigten Plan. Beobachten Sie zunächst, ob der Agent an der Aufgabe bleibt und ob Rechte oder Umgebung Probleme verursachen. Erweitern Sie Zugriffe nicht allein deshalb, weil ein Befehl scheitert: Prüfen Sie, ob der Zugriff für das gewünschte Ergebnis tatsächlich erforderlich ist.

4. Änderung und Tests unabhängig abnehmen

Lesen Sie den Diff. Prüfen Sie die vier bestätigten Fälle, die bestehenden Regressionstests und den Erhalt anderer Parameter. Achten Sie auf doppelte Kodierung sowie Änderungen außerhalb der vereinbarten Funktion. Ein vom Agenten gemeldeter erfolgreicher Lauf ist hilfreich; die Abnahme bleibt ein eigener Arbeitsschritt.

Dokumentieren Sie Annahme, Nacharbeit oder Abbruch mit dem jeweiligen Grund. Hat Devin die kleine Änderung richtig umgesetzt, aber das Team lange mit der Einrichtung beschäftigt, gehört beides zum Ergebnis. Ein gelungener Codevorschlag und ein wirtschaftlicher Arbeitsablauf sind verwandte, aber unterschiedliche Beobachtungen.

Was kostet Devin, und wie begrenzen Sie den Aufwand?

Stand: 2. Oktober 2026. Die aktuelle Preisübersicht und die Self-serve-Billingdokumentation unterscheiden Individual-, Teams- und Enterprise-Modelle. Die Beträge sind in US-Dollar angegeben. Prüfen Sie vor einer Beschaffung den aktuellen Checkout, das enthaltene Kontingent und die Bedingungen Ihres Angebots.

Die detaillierte Teams-Billinglogik erläutert den Mindestbetrag: Bei weniger als zwei Full Seats wird der verbleibende Betrag zu Shared Credits. Zwei Full Seats ergeben monatlich 80 US-Dollar, drei 120 US-Dollar, jeweils vor zusätzlichem Verbrauch. Die Marketingpreiszeile ist hierzu verkürzt; für eine Kalkulation ist die genaue Billinglogik entscheidend.

Ein Abonnement ist nur ein Teil des Aufwands. Laut Billing-Dokumentation nutzen Self-serve-Pläne enthaltene Kontingente und zusätzliche On-demand Credits; Enterprise arbeitet mit Agent Compute Units, kurz ACUs, zum vertraglichen Preis. Eine universelle Dollar-pro-ACU-Umrechnung lässt sich daraus nicht ableiten.

Die Usage-Dokumentation beschreibt Verbrauch durch tatsächliche Arbeit und die Arbeitsumgebung. Eine schlafende Session verursacht demnach keine Kosten; das bloße Warten auf Tests ist jedoch nicht mit jeder Form von kostenfreiem Stillstand gleichzusetzen. Komplexität, Kontext und wiederholte Schleifen beeinflussen den Aufwand. Es gibt daher keinen verlässlichen pauschalen Preis für „eine Fehlerbehebung“.

Für den Erstversuch setzen Sie ein Zeit- und Verbrauchslimit. Prüfen Sie die verfügbaren Usage-Limits und eine gegebenenfalls aktive automatische Nachladung. Dokumentieren Sie neben dem Produktverbrauch auch aktive Zeit für Auftrag, Einrichtung, Review und Nacharbeit. Eine verworfene Session bleibt Teil dieser Rechnung. Vergleichen Sie anschließend den gesamten Aufwand je akzeptierter Änderung mit Ihrer bisherigen Arbeitsweise.

Welche Daten- und Zugriffskontrollen sollten Sie prüfen?

Trennen Sie drei Fragen: Wer verarbeitet Ihre Inhalte, wofür dürfen sie verwendet werden und welche Aktionen darf der Agent ausführen? Eine eingeschränkte Repository-Freigabe beantwortet keine Trainingsfrage; ein Trainings-Opt-out begrenzt keine Terminalbefehle.

Die am 2. Oktober geprüfte Security-Dokumentation nennt folgende Datennutzungsregeln: Standardmäßig können Daten für Modelltraining verwendet werden. Bezahlte Pläne können in Data Controls widersprechen; bei Teams übernimmt das ein Administrator. Nach dem Opt-out werden die Daten nicht zum Training verwendet und Zero Data Retention bei den Modellanbietern aktiviert. Für Enterprise verlangt Cognition vor Trainingsnutzung die ausdrückliche vorherige schriftliche Zustimmung.

Zero Data Retention bei Modellanbietern bedeutet dabei keine pauschale sofortige Löschung bei Cognition. Die Dokumentation beschreibt dort grundsätzlich Aufbewahrung während der Kundenbeziehung, sofern Kunden nichts anderes festlegen; Feedback- und Interaktionsdaten behandelt sie gesondert. Prüfen Sie diese Angaben zusammen mit den für Ihr Konto geltenden Vertragsbedingungen.

Für die hier betrachteten, von Devin verwalteten Cloud-Sessions können Security Profiles Netzwerk-, MCP- und Git-Zugriffe bündeln und begrenzen. MCP verbindet zusätzliche Werkzeuge oder Systeme mit dem Agenten. Ein empfohlenes Profil kann überschrieben werden; ein verpflichtendes Profil bildet eine Mindestgrenze. Änderungen gelten nicht automatisch für bereits laufende Sessions, sondern werden bei Start beziehungsweise erneutem Aufwachen aufgelöst. Kontrollieren Sie deshalb die tatsächlich wirksame Session-Konfiguration.

Für das kleine URL-Ticket ergibt sich daraus eine konkrete Prüfaufgabe: Zugriff auf das benötigte Repository, Zugriff auf die Entwicklungsabhängigkeiten und keine unnötigen verbundenen Systeme. Prüfen Sie gesondert, ob Integrationen zusätzliche Inhalte lesen oder Schreibaktionen ermöglichen. Die Aussage „Wir haben einen sicheren Plan“ ist weniger aussagekräftig als eine nachvollziehbare Liste der Rechte dieser Aufgabe.

Cognition empfiehlt außerdem Code-Review, Branchschutz und die vorgesehene Secrets-Verwaltung. Das Team bestätigt, dass bestehende Checks vor einer Freigabe greifen und Zugangsdaten nicht unkontrolliert in Tickets landen. Sicherheitsfunktionen sind damit Teil Ihres Betriebsmodells. Sie nehmen Ihnen weder die konkrete Freigabeentscheidung noch die Prüfung Ihrer eigenen Anforderungen ab.

Woran erkennen Sie einen gelungenen Einstieg?

Ein sinnvoller Erstversuch liefert mehr als einen erzeugten Pull Request. Das Team kann erklären, was geändert wurde, welche unabhängigen Fälle bestanden wurden und wie viel Betreuung erforderlich war. Halten Sie offen gebliebene Fragen ebenso fest wie verworfene Ansätze. Bewerten Sie das Ergebnis erst nach der Abnahme und einer angemessenen Beobachtung des geänderten Verhaltens.

Legen Sie Stopppunkte vorab fest: ein unerlaubter Zugriff, Änderungen außerhalb des Auftrags, entfernte Akzeptanztests, wiederholt falsches Verhalten oder ein ausgeschöpftes Versuchslimit. Wenn eine Aufgabe häufig neue Fachentscheidungen braucht, kann eng geführte Assistenz zunächst besser passen als längere Delegation. Das ist eine Entscheidung über die Aufgabenform, keine allgemeine Rangliste von Codingwerkzeugen.

Wiederholen Sie einen gelungenen Versuch mit einem zweiten vergleichbaren Ticket, bevor Sie umfangreiche Automationen zulassen. Ändern Sie beim nächsten Lauf möglichst nicht gleichzeitig Aufgabe, Berechtigungen und Werkzeugkonfiguration. So bleibt nachvollziehbar, welche Anpassung die Arbeit verbessert oder erschwert.

Wenn Sie einen solchen Einstieg mit Teamrollen, Toolchain und Governance verbinden möchten, erläutert die bestehende eBiz-Seite, wie Sie Devin in Ihre Entwicklungsprozesse einbetten können. Die Grundlage dafür sind präzise Aufgaben, begrenzte Zugriffe und eine Abnahme, die Ihr Team selbst versteht.