Entwicklung autonomer Code-Agenten vorgestellt

Nach einer längeren Abwesenheit begrüßt der Streamer die Zuschauer und erläutert seine aktuelle multitasking-behaftete Situation. Er gibt Einblicke in seine derzeitigen Projekte, darunter die Bootstrap Academy Version 2, The DMZ, eine Gesundheits-App namens Claude Mythos und interne Projekte wie Morphi. Ein zentrales Thema werden die plötzlich gestiegenen API-Kosten für Claude sein, die ein Problem für seine Arbeit darstellen.

Der Streamer beschreibt die Fortentwicklung seines Autonom-Tools von einem einfachen Skript zu einem komplexeren System, das als Shell-Projekt gewachsen ist. Dieses Tool automatisiert das Erstellen von GitHub-Issues aus Dokumenten und den anschließenden Entwicklungsprozess. Er zeigt ein erstes Flow-Diagramm auf, das den Prozess von der Recherche über die Implementierung bis zu zwei Reviewern und einem Finalisierer abbildet, um Code-Probleme autonom zu lösen.

Es wird deutlich, dass die ersten Versionen des Tools nicht ausreichten. Ein Hauptproblem war die Anhäufung von tausenden, teils nicht validen, GitHub-Issues, was die manuelle Überforderung zur Folge hatte. Ein weiteres Problem war die generierte Software, die oft als Legacy-Bullshit bezeichnet wird und unbrauchbar ist. Dies führt zu der Erkenntnis, dass die Pipeline sich nicht nur auf Funktionalität, sondern auch auf Code-Qualität wie Konsistenz, Duplikate und Single Responsibility konzentrieren muss, um wartbaren Code zu produzieren.

Um die erkannten Probleme zu lösen, präsentiert der Streamer eine überarbeitete Pipeline mit sieben spezialisierten, parallel laufenden Agenten: Research, Implement, Linter, Tester und fünf Reviewer. Jeder Agent hat eine klare Aufgabe, wie z.B. Correctness, Issue Coverage oder Security. Ein neuer Controller-Agent koordiniert den Prozess, entscheidet bei Fehlern über Neustarts und sorgt für eine skalierbare Qualitätssicherung durch mehrstufige Reviews. Das Ziel ist, menschliche Überprüfung nur noch für die finalen Production-Code-Einsätze zu benötigen.

Ein zentraler Bestandteil der neuen Pipeline ist die Integration von Test-Driven-Development (TDD). Der Test-Dev-Agent wird nach der Implementierung aktiv und schreibt Tests basierend auf dem ursprünglichen Issue und nicht auf dem implementierten Code. Diese Verhaltens-Spezifikation (x erwartet y) soll Regressionen effektiver abdecken und den Implementierer entlasten. Die Tests sind reaktiv aufgeteilt in Fix-Tests für Bugfixes und Regressionstests für Refactoring, um eine klare Verhaltensänderung zu verifizieren.

Die Wahl der verwendeten KI-Modelle stellt einen kritischen Faktor dar. Der Streamer vergleicht teure Modelle wie Claude Opus mit kostengünstigeren Alternativen wie Minimax M2.7 und GLM 5.1. Für seine autonome Pipeline hat er sich für Minimax entschieden, da es durch sein Reset-System (alle 5 Stunden) extrem günstig im Dauereinsatz ist und eine Leistung erbringt, die der von Sonet 4.6 ähnelt. Das Ziel ist, die Prozesskosten zu minimieren, während die Qualität für die meisten Aufgaben ausreichend ist und nur für finale Production-Checks auf teurere Modelle wie Claude ausgewichen wird.

Ein weiteres wichtiges Feature der Pipeline ist der dedicated Documentation-Domain. Dieser ist dafür ausgelegt, automatisch verschiedene Arten von Dokumentation zu erstellen, darunter Code-Dokumentationen (Docstrings), Architektur-Dokumente (ADRs, C4-Diagramme) und Onboarding-Dokumente. Die Idee ist, die Wartbarkeit und Verständlichkeit der Projekte durch kontinuierliche, automatische Generierung von Dokumentation zu erhöhen, sobald ein Feature oder eine Änderung implementiert wurde.

Der Streamer diskutiert die Effizienz verschiedener KI-Modelle wie Claude Opus 4.6 und Minimax, wobei Minimax für Code-Reviews bevorzugt wird. Er erwägt ein GLM 5.1 Abo und plant, dieses mit Minimax und Claude in einem Agenten zu kombinieren, der basierend auf der Komplexität eines Issues das passende Modell auswählt. Um die Schwierigkeit einzuschätzen, fragt er, wie lange ein menschlicher Entwickler für eine Aufgabe bräuchte, und nutzt diese Metrik als Richtwert für die Auswahl des Modells.

Es wird der Autodev-Workflow vorgestellt, ein historisch gewachsenes Shell-Skript, das zu einem eigenen Projekt entwickelt wurde. Dieses Skript nutzt verschiedene Agenten für den Research, die Implementierung und den Clean-Code-Review im DMZ-Projekt. Die Automatisierung soll die manuelle Arbeit reduzieren, indem Agenten Issues von GitHub-Boards abarbeiten, den Code implementieren und prüfen, wobei der Fokus auf Prozessverständnis liegt, nicht auf dem Verstehen jedes einzelnen Codezeile.

Ein zentrales Thema ist die rasante Entwicklung von KI-Modellen, insbesondere die zunehmende Effizienz kleinerer Modelle wie Gemma 4, die auf Consumer-Grafikkarten laufen und die Leistung früherer Servermodelle erreichen. Der Streamer prophezeit, dass Modelle wie Gemma 5 lokale Ausführung der Top-Modelle ermöglichen und damit die KI-Nutzung massiv beschleunigen werden. Gleichzeitig wird das Potenzial von selbstgehosteten KI-Lösungen für Unternehmen thematisiert, um Abhängigkeiten von Drittanbietern und hohe Kosten zu umgehen.

Der Streamer live-demonstriert den Autodev-Workflow am DMZ-Projekt. Ein Research-Agent analysiert ein Issue, gefolgt von einem Dev-Agent, der den Code implementiert. Ein Clean-Code-Agent prüft den Code. Ein Quality-Gate-System wird eingeführt, das nur neue Fehler als Regressionen abtut, während bestehende Fehlertoleranz erlaubt. Der Push zu GitHub scheitert jedoch mehrmals an Husky-Hooks, was als gezielte Optimierung des Prozesses thematisiert wird und die Herausforderungen bei der vollständigen Automatisierung aufzeigt.

Der Streamer reflektiert über die sich verändernde Rolle des Softwareentwicklers. KI-Agenten ermöglichen die Bearbeitung von Projekten, die sonst das Äquivalent von Dutzenden Entwicklern erfordern würden. Er argumentiert, dass der Fokus vom Verstehen aller Code-Details auf das Verstehen und Optimieren der übergeordneten Prozesse verlagert werden muss. Die menschliche Aufgabe sei nicht mehr, die Lösungen selbst zu finden, sondern kritisch zu prüfen, wo die Automatisierung versagt und die Workflows zu verbessern.

Als Alternative zu proprietären Systemen wie Claude Code wird Open Code vorgestellt, eine Open-Source-Plattform, die es ermöglicht, eigene KI-Abos (z.B. Minimax, Kimi, DeepSeek) mit verschiedenen Agenten zu verbinden. Das System bietet Flexibilität, indem Nutzer je nach Aufgabe und verfügbarem Budget das passende Modell einsetzen können. Der Streamer betont den Wert dieses offenen Ansatzes im Vergleich zu geschlossenen Ökosystemen und seine positive Einstellung zur Open-Source-Community.

Es wird die Frage diskutiert, ob verschiedene Nutzergruppen unterschiedliche Versionen von KI-Modellen erhalten. Es wird vermutet, dass große Tech-Unternehmen wie Nvidia, Linux oder Google exklusiven Zugang zu leistungsfähigeren oder rohen Versionen neuer Modelle wie Mythos haben. Gleichzeitig wird erörtert, ob es möglich ist, bestehende Abos wie GitHub Copilot mit Plattformen wie Open Code zu verbinden, um deren Funktionalität zu erweitern und die Flexibilität zu erhöhen.

Nach der finalen Code-Analyse wurde der Dokumentationsagent als essentieller Bestandteil der Pipeline identifiziert. Sein Hauptziel ist es, sauberen Code, Implementierung und Reviews abzudecken und die finale Qualität zu sichern. Die Dokumentation wird in denselben Commit wie die Code-Änderungen integriert, um Konsistenz zu gewährleisten. Für zukünftige Anwendungen wurde entschieden, dass der Agent nur dann läuft, wenn auch tatsächliche Code-Änderungen vorgenommen werden. Standardmäßig soll er aktiviert sein, kann aber über eine Konfigurationsdatei deaktiviert werden. Der Standard-Timeout wurde auf 30 Minuten festgelegt, da Dokumentationsaufgaben weniger rechenintensiv sind als die eigentliche Implementierung. Der Agent soll im Fix-Modus jedoch nur in der ersten Implementierungsphase und nicht nach nachfolgenden Reparaturverfügungen laufen.

Der Streamer erwähnt die offizielle Partnerschaft mit 'Open Code', die er als 'geil' bezeichnet. Im Detail werden die Kompatibilität von Open Code mit anderen Modellen wie 'Grog with Q' und 'Open Router' diskutiert. Der Hauptvorteil von Open Code, insbesondere im API-Betrieb, ist die volle Transparenz über den Ressourcenverbrauch, wie die genaue Anzeige von Kosten, Token-Nutzung und dem Context-Window-Füllgrad pro Session. Die Nutzung von Spracheingaben ('Slash Voice') wird angesprochen, der Streamer entscheidet sich jedoch bewusst dafür, zu schreiben, da er seine Skripte ständig überarbeitet. Dies sei eine reine Geschmackssache und hängt auch vom Denkstil des jeweiligen Modells ab. Eine separate Datenschutzdebatte über WhatsApp findet statt, wobei der Streamer den Kontakt zu wichtigen Personen über die Privatsphäre stellt.

Auf eine Frage zur Entwicklung eines KI-DJ wird erläutert, dass dies sehr komplex ist, wenn man das zugrundeliegende Modell selbst entwickeln möchte. Eine mögliche, einfachere Methode wäre die Nutzung von Embedding-Modellen. Diese Modelle berechnen, wie ähnlich Inhalte sind – im Falle eines DJ-Tools könnte man so die musikalische Ähnlichkeit von Tracks ermitteln, um fließende Übergänge zu ermöglichen. Eine weitere Frage zielt darauf ab, wie man große Sprachmodelle (LLMs) auf unternehmenseigene Daten beschränken kann. Zwei Lösungsansätze werden vorgestellt: Retrieval Augmented Generation (RAG), bei dem externe Daten indiziert und durch eine Suchanfrage abgerufen werden, und das Feintuning des Modells auf einen spezifischen Wissensbestand, was zwar leistungsfähiger, aber auch deutlich rechen- und kostenintensiver ist.

Bei der automatisierten Entwicklung tauchen wiederholt Probleme auf, insbesondere im Bereich der 'Finalization Stage'. Ein Dokumentationsagent wird Denied, da ihm die notwendigen Rechte fehlen, was den gesamten Prozess unterbricht. Parallel dazu werden Tests durchgeführt, die jedoch auf komplexe Probleme bei der BPM-Berechnung und Tonartenerkennung stoßen, auf die der Streamer aufgrund mangelndes musiktheoretischen Wissens keinen Zugriff hat. Eine 'Welle von Reviewern' wird eingesetzt, um Fehler im Code zu finden. Es werden verschiedene Modelle und ihre Leistungen auf Benchmarks wie SWE-Bench und MMLU verglichen. Ein entscheidender technischer Fehler tritt auf: Ein Agent versucht, auf ein externes Verzeichnis zuzugreifen, was von der OpenCode-Berechtigungssystem korrekt blockiert wird. Das Problem wird als fehlende explizite Anleitung für die Scope-Definition von CLI-Tools identifiziert.

Um die Qualitätssicherung flexibler zu gestalten, wird der Entwurf eines skalierbaren Reviewer-Systems skizziert. Anstelle fester fünf Reviewer sollen individuelle, spezifische Agenten wie z.B. für Barrierefreiheit (Accessibility) oder Mehrsprachigkeit (Multilingual Support) dynamisch aktiviert oder deaktiviert werden können. Die Konfiguration soll über eine zentrale Registry erfolgen, die CLI-Befehle zur Steuerung bereitstellt. Ein parallel laufender Versuch zeigt jedoch einen extrem hohen Ressourcenbedarf auf, bei dem die Arbeitsspeicherauslastung bis zu 96% erreicht. Der Wunsch nach einer Containerisierung des Systems wird diskutiert, stößt jedoch auf das gleiche Problem des hohen Ressourcenbedarfs. Dies führt zum Schluss, dass eine vollständige Parallelisierung und Skalierung der Pipeline momentan mit den verfügbaren Ressourcen nicht machbar ist.

Ein zentrales technisches Problem bei der Parallelisierung des Entwicklungsprozesses ist das Management von 'Git Worktrees' und die anschließende Zusammenführung der Änderungen. Wenn mehrere Agenten an derselben großen Datei arbeiten, führt dies unweigerlich zu Merge-Konflikten. Die Frage, ob das Zusammenführen von hunderten paralleler 'Trees' überhaupt möglich ist, wird mit einem 'Ja' beantwortet, jedoch unter der Bedingung, dass die zugrundeliegenden Issues unabhängig voneinander sind und keine Abhängigkeiten bestehen. Eine mögliche Lösung wäre das Durchführen eines 'Rebase' vor dem finalen Merge, um Konflikte zu minimieren. Es wird die Notwendigkeit eines Dependency-Managementsystems deutlich gemacht, da der aktuelle Ansatz ohne zentrale Koordination bei steigender Komplexität untauglich wird.

Aufgrund der identifizierten Komplexität und der Notwendigkeit einer zentralen Steuerung wird die Entwicklung einer dedizierten 'Software-as-a-Service' (SaaS)-Lösung für Autodev ins Auge gefasst. Dies würde eine stabile, skalierbare Backend-Infrastruktur bieten und den lokalen Ressourcenengpass umgehen. Eine weitere geplante Erweiterung ist ein 'Autodev-Estimator'. Dieser Agent würde am Anfang eines Issues bewerten, wie aufwendig die Aufgabe ist und automatisch die passendsten KI-Modelle sowie eine optimale Konfiguration derReviewer vorschlagen. Das Ziel ist ein maximal adaptiver und autonomer Entwicklungsprozess, der sich an die spezifischen Anforderungen jedes Projekts anpasst.

Der Streamer spricht über praktische Rahmenbedingungen, wie die Notwendigkeit einer Klimaanlage für die kommenden Sommermonate, um die Temperatur im Stream-Raum in einem erträglichen Bereich zu halten, da sonst die Elektronik und die Arbeitsbedingungen gefährdet sind. Er gibt seine zukünftigen Sendezeiten bekannt, die typischerweise donnerstags von 14:30 bis 18:30 Uhr stattfinden. Der Versuch, das Skalierbarkeitssystem der dynamischen Reviewer umzusetzen, scheitert an technischen Problemen, bei denen Tools versuchen, außerhalb des definierten Projektverzeichnisses zu operieren. Der Stream endet mit einem Cliffhanger und der Ankündigung, das Thema in einem späteren Video weiterzuverfolgen. Der Streamer wünscht den Zuschauern einen schönen Abend und verabschiedet sich.