Von Assistenten zu Agenten: So bauen wir heute Software

Vor einem Jahr haben wir beschrieben, wie unsere Entwickler KI im Alltag nutzen: Assistenten im Editor, ein KI-Bot, der jeden Pull Request zusammenfasst, und rundherum ein Prozess mit klaren Aufgaben, Tests und Review durch Menschen. Seitdem hat sich die Art, wie wir Software bauen, stärker verändert als in mehreren Jahren davor.

Der Unterschied ist schnell erklärt. Ein Assistent schlägt die nächsten paar Zeilen vor. Ein Agent übernimmt eine ganze Aufgabe: Er liest das Ticket, erkundet die Codebasis, nimmt die Änderung vor, führt die Prüfungen aus und eröffnet einen Pull Request. Die Rolle der Entwickler verschiebt sich vom Schreiben jeder Zeile hin zum Definieren der Arbeit, zum Steuern und zum Review des Ergebnisses.

Das unterstützen wir mit eigenem Budget. Seit Januar 2026 bezahlt das Unternehmen Claude-Abonnements; bis Juni deckten sie Entwickler, den Softwarearchitekten, den Tech Lead und das Projektmanagement ab, mit höheren Tarifen für alle, die am meisten mit Agenten arbeiten. Der KI-orientierte Editor, den unsere Entwickler seit Ende 2024 mit Firmenlizenzen nutzen, gehört weiterhin zum Werkzeugkasten.

Vom Vorschlag zur Aufgabe

Seit März 2026 gehören in einem unserer Kundenprojekte Pull Requests, die mit einem KI-Coding-Agenten vorbereitet wurden, zum täglichen Ablauf. Eine typische Änderung sieht heute so aus:

1. Die Arbeit ist als Ticket mit einem Ziel beschrieben, und der Pull Request trägt die Ticketnummer.
2. Ein Entwickler startet den Agenten dafür im Repository, mit den Projektregeln aus einer Instruktionsdatei.
3. Der Agent nimmt die Änderung in einem eigenen Branch vor und eröffnet einen Pull Request mit einer Zusammenfassung, was er geändert hat und warum.
4. Innerhalb weniger Minuten ergänzt der KI-Review-Bot, den wir seit Ende 2024 einsetzen, seine eigene Erläuterung der Änderung.
5. Der Entwickler liest beides, fordert Korrekturen an oder nimmt sie selbst vor und entscheidet, ob die Änderung gemergt wird. Das Deployment bleibt eine menschliche Entscheidung.

Agenten arbeiten auch gut parallel. Ende Mai haben wir ungenutzten Code in einer mobilen App geprüft – mit Werkzeugen für statische Analyse und vier Agenten, die den Code gleichzeitig durchsuchten. Ergebnis war ein schriftlicher Bericht, keine Löschaktion: Nichts wurde automatisch entfernt. Die Prüfung brachte außerdem einen echten Fehler ans Licht, der wie jeder andere Befund ins Backlog kam.

Die Instruktionsdatei ist das neue Onboarding

Ein Agent beginnt jede Sitzung ohne Wissen über das Projekt. Deshalb schreiben wir in eine Datei, die der Agent zuerst liest, was ein neues Teammitglied am ersten Tag bräuchte: worum es im Projekt geht, das Glossar, wer die Nutzer sind, die Konventionen, welche Dokumente immer geladen werden müssen und was der Agent darf und was nicht. Seit Januar 2026 führen wir solche Dateien nicht nur in Code-Repositories, sondern auch in Analyse-Arbeitsbereichen, in denen Agenten helfen, Workshop-Mitschriften in eine Dokumentation der Ist- und Soll-Prozesse zu überführen. Im selben Projekt richtet eine eigene Instruktionsdatei einen Agenten für UX-Arbeit ein: Er baut klickbare Prototypen aus den echten Komponenten der Anwendung mit Testdaten, und jede Änderung an den Originaldateien muss er kennzeichnen und dokumentieren.

Dieselbe Disziplin gilt für jede Aufgabe. Ein gutes Briefing nennt Ziel und Umfang, was „fertig“ bedeutet, die relevanten Teile des Codes, was nicht angefasst werden darf und wie das Ergebnis geprüft wird. Solche Briefings zu schreiben, gehört heute zu den wichtigsten Fähigkeiten im Team. Und einen Grundsatz aus unserer früheren Arbeit behalten wir bei: kein Ticket, kein Code. Jede Änderung lässt sich auf einen beschriebenen Bedarf zurückführen.

Tests sind Voraussetzung, kein Extra

Eine Änderung, die ein Agent ohne Tests erstellt hat, ist eine Vermutung. Erst Tests und ein funktionierender Build machen daraus etwas, dem ein Reviewer vertrauen kann. Wo eine Codebasis kaum Tests hat, ist eine sinnvolle erste Aufgabe für einen Agenten, Tests für das bestehende Verhalten zu schreiben, bevor irgendetwas geändert wird.

Bei Änderungen, die Nutzer sehen, reichen bestandene Tests allein nicht aus. Jemand muss sich das Ergebnis in einer Entwicklungsumgebung mit echten Inhalten ansehen, bevor es weitergeht.

Sicherheit: Geheimnisse, Berechtigungen und was der Agent liest

Ein Agent, der Befehle ausführen kann, verdient dieselbe Sorgfalt wie ein neues Teammitglied mit Zugang zu Ihren Systemen – in mancher Hinsicht sogar mehr. Unsere Regeln:

• Minimale Rechte. Ein Agent erhält nur den Zugang, den seine Aufgabe erfordert. Kein direkter Zugriff auf die Produktion.
• Geheimnisse bleiben aus Code und Prompts heraus. Zugangsdaten stellt die Umgebung bereit; sie werden nie committet und nie in eine Aufgabenbeschreibung kopiert.
• Die Arbeit endet in einem Branch. Agenten pushen ihre Arbeit und eröffnen Pull Requests; Mergen und Deployment bleiben bei Menschen.
• Inhalte sind Daten, keine Anweisungen. Webseiten, Dokumente und externe Tickets, die ein Agent liest, können Text enthalten, der ihn manipulieren soll. Agenten sollten solche Inhalte als Information behandeln, und die Berechtigungen begrenzen ohnehin, was ein manipulierter Agent tun könnte.
• Kundencode nur mit Zustimmung des Kunden. Es gelten dieselben vertraglichen Regeln wie für jedes andere Werkzeug.

Das passende Modell für die Aufgabe

Nicht jede Aufgabe braucht das leistungsfähigste Modell. Eine kleine, gut beschriebene Änderung kann an ein schnelleres und günstigeres gehen. Arbeit, die viele Dateien umfasst oder sorgfältiges Abwägen erfordert, verdient ein stärkeres. Architekturentscheidungen und unklare Probleme bleiben bei einem Entwickler, unterstützt vom besten verfügbaren Modell. Und wenn ein Agent nicht weiterkommt, ist der richtige Schritt die Übergabe an ein stärkeres Modell oder an einen Menschen – und nicht, dasselbe noch einmal zu versuchen.

Was das für Entwickler und Kunden bedeutet

Für unsere Entwickler hat sich die Arbeit in Richtung Problemverständnis, Lösungsdesign, präzise Briefings und kritisches Review verschoben. Gutes Review ist schwieriger, als es klingt: Man muss eine Änderung, die man nicht selbst geschrieben hat, so sorgfältig lesen, als stünde der eigene Name darauf – denn so ist es.

Für Kunden geht gut definierte Arbeit schneller voran, und die Qualitätsschranken bleiben dieselben: ein Ticket, Tests, Review und eine menschliche Entscheidung, bevor etwas in Produktion geht.

Es gibt auch einen größeren Zusammenhang. Wenn Agenten unsere eigene Arbeit in einem Jahr so stark verändert haben, werden sie auch die Abläufe unserer Kunden verändern: wie Anfragen bearbeitet, Angebote erstellt und Dokumente gelesen werden. Darüber schreiben wir als Nächstes.

Agenten haben die technische Disziplin nicht überflüssig gemacht – sie ist zum entscheidenden Faktor geworden. Wenn Sie darüber sprechen möchten, wie diese Arbeitsweise Ihr Produkt beschleunigen oder wie KI Ihre eigenen Prozesse unterstützen könnte, schreiben Sie uns.