LeistungenCoding-Agenten
Einführung von Coding-Agenten über die ersten Teams hinaus
Wir wählen mit Ihnen die Pilotteams aus, binden Agenten in CI und Review ein, klären, wer wofür bezahlt, und schulen Engineers an ihren eigenen Tickets, damit das Setup auch für die Teams funktioniert, die danach kommen.
Voraussetzungen, damit Agenten unbeaufsichtigt arbeiten
- Eine schriftliche Beschreibung reicht aus, um die Aufgabe zu übergeben
- Die Tests laufen ohne Eingreifen und liefern jedes Mal dasselbe Ergebnis
- Keine Änderung wird gemergt, bevor ein Mensch sie reviewt hat
Fehlt eine davon, arbeiten Agenten interaktiv, bis sie erfüllt ist.
Entscheidungen, die sich schwer zurücknehmen lassen
Was zu Beginn eines Rollouts entschieden wird, lässt sich später nur schwer ändern. Dazu gehört, welche Repositories und Arten von Arbeit zuerst an der Reihe sind, wie Agenten mit Ihren Tools und Ihrer CI zusammenarbeiten und welche Regeln für ihren Einsatz gelten. Ebenso geht es darum, wer Zugriff hat und welches Budget die Kosten trägt. Jede dieser Fragen klären wir mit den Verantwortlichen Ihrer Engineering-Teams, bevor der erste Agent aktiviert wird.
Außerdem brauchen Agenten in jedem Repository, in dem sie arbeiten, ein eigenes Setup. Wir bauen es im Rahmen von Harness Engineering.
Ein Pilot mit Aufgaben aus dem Arbeitsalltag
Der Pilot läuft in einem einzelnen Team oder einer kleinen Gruppe von Teams, mit Aufgaben, die ihrer normalen Arbeit ähneln. Das Review durch Menschen und Ihre automatisierten Checks bleiben genau wie bisher. Mehr Autonomie bekommen Agenten nur dort, wo die Ergebnisse des Piloten dafür sprechen.
Wenn im Piloten Tools oder Modelle verglichen werden müssen, nutzen wir dafür eine Evaluierung an Arbeit, die Ihre Teams bereits gemergt haben.
Wann ein Repository für Agenten bereit ist
Bevor Agenten in einem Repository arbeiten, prüfen wir es anhand der folgenden Punkte. Fehlen einige davon, arbeiten Engineers interaktiv mit Agenten. Unbeaufsichtigte Arbeit beginnt erst, wenn alle Punkte erfüllt sind.
- Ein einziger Befehl baut und testet einen frischen Checkout
- Tests brauchen keine manuelle Vorbereitung und schlagen nur fehl, wenn wirklich etwas kaputt ist
- Die Konventionen, auf denen Reviewer bestehen, sind dokumentiert
- Für die Agent-Konfiguration des Repositorys ist jemand verantwortlich
- Weder das Repository noch die Umgebung des Agenten enthält Secrets
- Reviewer können mehr Pull Requests übernehmen
Wie wir schulen und übergeben
Die Schulung findet in den Repositories statt, in denen Ihre Engineers täglich arbeiten, mit den Tools, die Sie ausgewählt haben. Die meiste Zeit verwenden wir darauf, eine Aufgabe zuzuschneiden, zu entscheiden, welchen Kontext der Agent braucht, und zu reviewen, was er zurückliefert.
Von da an führt Ihr Plattformteam den Rollout ohne uns weiter. Auf Wunsch treffen wir uns einmal im Monat und gehen die jüngsten Änderungen an Tools und Modellen durch.
Aufgaben an Devin übergeben
Der Cloud-Agent von Devin übernimmt eine Aufgabe in einer eigenen Remote-Umgebung und liefert das Ergebnis als Pull Request. Als Erstes ist zu klären, welche Arbeit sich schriftlich beschreiben und nach Abschluss prüfen lässt. Typische Kandidaten sind Testabdeckung, Migrationen, Wartungsupdates und klar beschriebene Backlog-Einträge. Für jede dieser Aufgaben braucht ein Reviewer Abschlusskriterien, die sich verifizieren lassen, ohne die Session nachzuvollziehen.
Vor einem Piloten stellen wir sicher, dass das Repository in der Umgebung von Devin jedes Mal gleich startet. Dazu gehören seine Abhängigkeiten, Testdaten und Services sowie die Befehle, mit denen es gebaut und getestet wird. Playbooks speichern wiederverwendbare Aufgaben-Prompts und führen eine Historie ihrer Versionen. Projektkonventionen gehören in Skills und die Repository-Anweisungen, nicht in die Playbooks. Devin Desktop, früher Windsurf, ist ein Editor, der lokal als eigener Ausführungskontext läuft. Wenn Handoff zu Ihrem Plan gehört, können Sie eine lokale Session an die Cloud weitergeben, und wir testen, was dabei mitkommt, bevor sich ein Team darauf verlässt.
Aufgaben erreichen Devin über Ihren üblichen Issue-Eingang, und seine Pull Requests folgen Ihrem bestehenden Prozess. Für sie gilt dieselbe Branch Protection wie für alle anderen, und jeder einzelne wird von einem Menschen reviewt. Mit Sicherheitsprofilen können Sie den Zugriff auf Git, MCP und das Netzwerk einschränken. Ihr Plan legt fest, welche dieser Kontrollen Sie haben, daher prüfen wir das, bevor wir uns auf eine davon stützen. Im Piloten läuft jeder Aufgabentyp mehr als einmal. Über diese Läufe hinweg zählen wir, wie viele reviewte Pull Requests akzeptiert wurden, und erfassen Betriebskosten, Review-Zeit und Nacharbeit. Der Bericht enthält nur, was Ihr eigener Pilot gemessen hat. Produktivitätszahlen des Anbieters fließen nicht ein.
- Aufgabentypen und ihre Abschlusskriterien, festgelegt, bevor etwas delegiert wird
- Eine benannte verantwortliche Person für jedes Playbook und für die Repository-Anweisungen
- Reviewer und Merge-Verantwortliche, namentlich festgelegt, dazu ein Weg zur Eskalation, wenn ein Lauf blockiert ist
Harness-Setup für delegierte Umgebungen · Eine Änderung an Ihrem Workflow evaluieren · Devin-Dokumentation zum Handoff von lokal in die Cloud
Tools, in denen Engineers das Modell selbst wählen
Manche Tools, darunter Kilo, überlassen die Wahl von Anbieter und Modell den einzelnen Engineers. Entscheidungen, die andere Tools für Sie treffen, werden damit Teil Ihres Rollouts. Jemand muss die Liste der freigegebenen Anbieter und Modelle verantworten, ebenso die Keys oder die Gateway-Konten. Auch für die Entscheidung, was geschieht, wenn ein noch von niemandem getestetes Modell in der Auswahl auftaucht, braucht es eine verantwortliche Person. Diese Verantwortlichen und einen Weg für Ausnahmen legen wir während des Piloten fest. Teams werden mit der gemeinsamen Konfiguration eingerichtet, nicht mit persönlichen Setups. Die Konfiguration selbst gehört zum Harness Engineering.
Wenn Sie das Tool wechseln müssen
Coding-Tools entwickeln sich schnell, und hin und wieder zwingt eine Änderung zur Migration. Google hat Gemini CLI auf Antigravity CLI umgestellt. Seit dem 18. Juni 2026 enthalten die Consumer-Abos von Google kein Gemini CLI mehr, Lizenzen für Gemini Code Assist Standard und Enterprise haben ihren Zugang aber behalten. Am 30. April 2027 stellt AWS den Support für die IDE-Plugins von Amazon Q Developer ein und verweist seine Nutzer an Kiro. Aus Windsurf ist Devin Desktop geworden.
Für uns ist eine Migration ein kleiner Rollout. Wo beide Tools AGENTS.md lesen, ziehen die gemeinsamen Anweisungen dorthin um. Modellzugang und Berechtigungen übertragen wir auf das neue Tool und lassen die Abnahmeaufgaben des Piloten erneut laufen. Außerdem prüfen wir, wie sich der Wechsel auf Ihre Rechnung auswirkt, und erst dann wird das alte Tool abgeschaltet.
Ein neues Tool vor dem Wechsel testen · Ankündigung von Google zu Gemini CLI und Antigravity CLI · Hinweis von AWS zum Supportende der IDE-Plugins von Amazon Q Developer
Was Ihnen nach dem Rollout bleibt
- Ein Rollout-Plan, der jedes Team und jedes Repository abdeckt
- Schriftliche Richtlinien für den Einsatz von Agenten und für Zugriffe
- Ergebnisse aus dem Piloten, gewonnen an echten Aufgaben Ihrer Teams
- Runbooks, um neue Teams aufzunehmen, Zugriffe zu verwalten und Konfigurationsänderungen auszurollen
- Schulungsmaterial mit Beispielen aus Ihrem eigenen Code
Was wir über den gesamten Rollout hinweg messen
- Welche Teams Agenten echte Arbeit übertragen, und welche Art von Arbeit das ist
- Review-Aufwand und Nacharbeit bei Pull Requests von Agenten, verglichen mit dem Stand vor dem Rollout
- Die Kosten des Rollouts pro akzeptierter Änderung
Fragen
Wie wählen wir das passende Coding-Tool?
Claude Code, Cursor, GitHub Copilot, OpenAI Codex und OpenCode laufen an verschiedenen Orten, gehen auf eigene Weise mit Anweisungen und Berechtigungen um, können andere Modelle aufrufen und werden jeweils anders abgerechnet. Wir testen eine Auswahl von Tools an echten Aufgaben aus Ihren Repositories und nutzen dabei nur die Modell-Endpunkte und Zugriffe, die Sie freigegeben haben. Danach prüfen wir, wie jedes Tool zu Ihren Tests, Ihrem Review-Prozess und Ihrem Budget passt. Ein einzelnes Tool ist einfacher zu betreiben. Mehrere funktionieren ebenfalls, sofern sie Anweisungen und Richtlinien teilen, wo immer die Tools das zulassen.
Sollte jedes Team Coding-Agenten nutzen?
Nein. Ein gut geplanter Rollout klärt, welche Teams und welche Repositories heute von Agenten profitieren und welche besser erst später an die Reihe kommen.
Können wir anfangen, solange unsere Tests noch unzuverlässig sind?
Ja. Agenten arbeiten dann interaktiv, und ein Engineer verfolgt jeden Schritt. Unbeaufsichtigte Läufe beginnen erst, wenn die Tests verlässlich sind.
Bekommen auch unsere Engineers eine Schulung?
Ja. Jedes Team wird in seinen eigenen Repositories geschult. Die Schulungen finden remote oder vor Ort in Deutschland und Polen statt, und Sie wählen zwischen Deutsch, Englisch und Polnisch.
Verwandte Leistungen
Harness Engineering
Das Setup, das einem Agenten sagt, wie er Ihren Code baut, testet und ändert, abgelegt in der Versionskontrolle.
Evaluierungen auf Ihren Repositories
Tools, Modelle oder Einstellungen im direkten Vergleich, getestet an Änderungen, die Sie bereits gemergt haben, bevor Sie sich festlegen.
LLM-Kostenoptimierung
Agentenkosten, aufgeschlüsselt nach Team und Aufgabe und gesenkt durch Voreinstellungen, Budgets und Routing, die Ihr Plattformteam selbst betreiben kann.
Aus dem Blog
Agentic Engineering
Was Agentic Engineering für ein Engineering-Team bedeutet: wie es sich von Vibe Coding unterscheidet, wohin sich die Arbeit verlagert, was die Forschung über Ergebnisse sagt und welche Grundlagen über den Nutzen entscheiden.
Design eines Coding-Agent-Piloten
Wie Sie Coding-Agenten an derselben Arbeit vergleichen: zufällige Zuteilung der Aufgaben, ein Replay gemergter Änderungen und eine vorab vereinbarte Entscheidungsregel.
Repositories bereit für Coding-Agenten
Was ein Repository braucht, damit Coding-Agenten darin zuverlässig arbeiten, und wie die Setup-Anweisungen zu einem Check werden, der in der CI läuft.
Branch-Schutz für Agenten-Pull-Requests
Welche Einstellungen für Branch-Schutz und Rulesets auf GitHub gelten sollten, wenn Coding-Agenten Pull Requests öffnen, und wie Sie prüfen, ob sie wirklich greifen.
Mit einem Engineer sprechen
Bringen Sie eine Aufgabe mit, die Sie verbessern möchten. Das Gespräch dauert 30 Minuten und braucht keinen Zugriff auf Ihre Systeme oder Ihre Daten.
Die Buchung läuft über Google Kalender.
Lieber zuerst schreiben? Hinterlassen Sie Ihre E-Mail-Adresse und ein paar Zeilen, dann antworten wir mit Terminvorschlägen.
Sehen Sie in Ihrem E-Mail-Programm nach dem Entwurf
Senden Sie ihn von dort ab, und ein Engineer antwortet Ihnen persönlich mit Terminvorschlägen für ein 30-minütiges Gespräch. Hat sich kein Entwurf geöffnet, schreiben Sie uns an miki@cloudsail.com.