Keine Zeile Code per Hand
Wie die Entwicklung bei Peuka heute aussieht, seit KI-Agenten den Großteil des Codes schreiben.
Mein Tag beginnt mit einem Blick in Slack. Bevor ich irgendetwas anderes mache, schaue ich nach, was über Nacht passiert ist: Welche Pull Requests sind durchgelaufen und wo gibt es Feedback? Zusammensuchen muss ich mir das nicht. Unsere Agenten schicken mir morgens eine Zusammenfassung, was sie nachts beschäftigt hat, wie viele Pull Requests fertig geworden sind und was gereviewt wurde.
In Plötzlich angestellt habe ich erzählt, dass ich bei Peuka keine Zeile Code mehr per Hand schreibe. Zum Team gehören neben mir vier bis fünf Entwickler und mindestens genauso viele Agenten. Hier also, wie das im Alltag aussieht.
Bob, Marvin und der Rest
Wir probieren ständig neue Tools aus, die Basis ist allerdings seit dem ersten Tag dieselbe: Unser Hauptagent heißt Bob, läuft auf OpenClaw und nutzt GPT von OpenAI als Modell. Einfach, weil wir ihn damals als Erstes so aufgesetzt haben, und seitdem läuft er erstaunlich zuverlässig. Bob kennt die gesamte Plattform in- und auswendig, und dank Slack eigentlich auch das ganze Unternehmen: Er ist dort eingebunden wie ein normales Teammitglied und liest vieles mit. Bob orchestriert die anderen Agenten. Die laufen teils ebenfalls auf OpenClaw, teils als Shell-Skripte und teils als gehostete Lösungen. Zudem nutzen wir Amp, damit auch die Entwickler selbst Aufgaben anstoßen können, die dann eigenständig weiterlaufen.
Das Gruppenfoto ganz oben zeigt übrigens unser Core-Agent-Team, von links: Bao, Bob, Jean und Eve. Fotografiert hat es natürlich niemand, das Bild habe ich mit ChatGPT erstellt. Bao, Jean und Eve kümmern sich vor allem um technische Reviews, können aber auch andere Aufgaben übernehmen. Jeder von ihnen nutzt ein anderes Modell: Bao basiert auf DeepSeek, Jean auf Claude und Eve auf Grok. Jean entwickelt zudem auch selbst, genau wie Bob. Bao und Eve könnten das ebenfalls, sollen sich aber auf die Reviews konzentrieren. Bob kann umgekehrt auch reviewen: Schreibt zum Beispiel Marvin den Code, springt Bob als Reviewer ein. So stellen wir sicher, dass immer mindestens drei Agenten reviewen können.
Und dann gibt es noch Marvin. Wer meine ClockLab-Story kennt, dem kommt der Name bekannt vor: Marvin habe ich von damals mitgebracht. Zum Core-Team gehört er deswegen nicht, er arbeitet eher wie ein externer Freelancer. Gleichzeitig ist er unser fortschrittlichster Agent und läuft als einziger auf Mission Control, einem riesigen Kanban-Board, auf dem man sieht, woran er gerade arbeitet. Er macht aus einem Issue selbstständig die To-dos, den Plan und die Qualitätssicherung, entwickelt die Funktion und reagiert auf das Feedback der anderen Agenten, bis der Pull Request abgeschlossen ist. Wenn man so will, ist das wieder Prozessautomatisierung, quasi ClockLab 2.0: ohne Zeiterfassung und Rechnungsstellung, dafür ist GitHub wie damals integriert.
Vom Issue zum Pull Request
Ein typischer Ablauf bei Peuka sieht so aus: Eine Funktion wird entwickelt und landet als Pull Request auf GitHub. Dort reviewt zuerst Codex automatisch. Danach übernehmen weitere Agenten mit unterschiedlichen Spezialgebieten, und zwar bewusst mit verschiedenen Modellen, damit die Reviews nicht alle gleich ausfallen. Je nach Umfang und Code-Ownership schaut anschließend noch ein Mensch drüber. Kleinere, unkritische Änderungen gehen inzwischen vollautomatisiert live.
Was ich noch selbst mache
Meine Hauptaufgabe ist zu entscheiden, welche Funktionen überhaupt wie in die Entwicklung gehen. Ich gebe die Produktdetails und die Richtung vor, reviewe die Konzepte und prüfe am Ende das Ergebnis. Kommt ein Agent nicht weiter, bin ich der Human in the Loop: Ich löse den Blocker, und dann geht es weiter.
Lehrgeld
Natürlich lief nicht alles glatt. Ein Klassiker: Kommt ein Update für eines der Modelle, verhalten sich die Agenten auf einmal anders. Was gestern noch zuverlässig funktionierte, macht heute plötzlich etwas völlig anderes.
Das größere Problem war allerdings hausgemacht. Bob sollte vom ganzen Unternehmen genutzt werden, das war schließlich das Ziel. Die meisten Kollegen hatten allerdings wenig Erfahrung mit KI: Sessions wurden nie beendet, und so ziemlich alles wurde hochgeladen und weitergegeben. Irgendwann reichten die Serverkapazitäten nicht mehr aus, und auch die Tokens waren schneller weg als gedacht.
Deswegen haben wir immer mehr Leitplanken in Shell-Skripte ausgelagert, die unsere Regeln abbilden. Reviews laufen zum Beispiel in einer festen Reihenfolge, statt alle gleichzeitig zu starten. Fehlen Anforderungen von Menschen, gibt es einen Blocker. Und längst nicht mehr alles wird parallelisiert.
Und der Datenschutz?
Bei Bob läuft jede Anfrage zuerst durch ein lokales Modell auf unseren eigenen Rechnern im Büro. Das klassifiziert die Daten, und erst danach entscheidet sich, was überhaupt an externe Modelle weitergereicht wird. Datenschutzrelevante Themen bleiben auf den lokalen Modellen.
Eine Aufgabe ist nie fertig
Bleibt die Frage nach dem Slop. Den geschriebenen Code prüfen bei uns viele spezialisierte Agenten. Das passiert im Pull Request, aber auch danach noch: Nachts gehen weitere Agenten über den bestehenden Code, validieren ihn erneut und räumen auf.
Genau genommen ist daraus inzwischen ein Agent Graph geworden: ein Netz aus Agenten, die sich gegenseitig Aufgaben übergeben. Eine Aufgabe ist dabei nie wirklich abgeschlossen, denn sie kann jederzeit erneut gereviewt und überarbeitet werden, und dabei werden auch Bugs gefunden, die sonst erst viel später aufgefallen wären. Man kann es sich ein bisschen so vorstellen, als hätten wir mehrere Teams, die rund um die Uhr arbeiten.
Das Ergebnis spricht für sich
Dass das System mit der Zeit stabiler wird, hatte ich erwartet. Die anderen Entwickler waren anfangs allerdings skeptisch. Die bestehende Plattform komplett neu zu schreiben, ist leider keine Option, dafür ist sie an manchen Stellen zu komplex. Den Kern bildet also nach wie vor die alte Software. Drumherum haben wir jedoch Zahlungsprozesse und Schnittstellen überarbeitet, vor allem aber die Sicherheit, und zahlreiche neue Microservices integriert. Nach einigen intensiven Wochen lief das System so stabil, dass es weiterbestehen kann, bis es irgendwann abgelöst wird.
Parallel entsteht eine neue Plattform, die auf die alte zugreift. Über sie laufen bereits die Anbindungen neuer Partner, und nach und nach soll sie immer mehr Aufgaben der alten Plattform übernehmen. Daneben haben wir unter anderem Apple Pay eingeführt und neue Apps gelauncht. Gastbuchungen gibt es dafür nicht mehr: Wer über Peuka bucht, braucht jetzt ein Nutzerkonto.
Anfangs deployten wir noch von Hand. Heute läuft alles automatisiert über GitHub CI/CD, mit einer Testabdeckung, auf die ich ziemlich stolz bin.
Der Kulturschock
Für das Team war das ein Kulturschock. Bis dahin schrieben alle jede Zeile Code per Hand und fragten KI höchstens mal um Hilfe, um das Ergebnis dann teilweise rüberzukopieren. Der erste Schritt war, überhaupt Claude Code und Codex in der IDE zu verwenden. Der nächste Schock folgte kurz darauf: Mit Amp braucht man gar keine IDE mehr.
Vom klassischen Entwickler, der jede Zeile selbst schreibt und verstehen will, hin zu jemandem, bei dem es auf die Orchestrierung ankommt: Das alles innerhalb eines halben Jahres ist eine krasse Umstellung. Weil die Ergebnisse für sich sprachen, war der Schock am Ende allerdings nicht so groß wie gedacht, und sogar der Wechsel zu Amp war möglich: Alle haben verstanden, welches Potenzial darin steckt. Das Team hat die Umstellung richtig gut gemeistert.