Agentisches Entwickeln im Praxistest: In kürzester Zeit vom Experiment zur produktiven App

Im ersten Teil zu diesem Thema habe ich beschrieben, was agentisches Entwickeln bedeutet und warum es die Machbarkeit Grenze verschiebt. Hier im zweiten Teil wird es konkret: Ich zeige am Beispiel einer App, die ich täglich produktiv nutze, wie der Arbeitsalltag mit KI-Agenten aussieht.

Agentisch entwickeln: Das Projekt

Zeitbuchung ist in einer Agentur wie comspace Pflicht. Der bisherige Prozess war für mich ein Reibungspunkt: jeden Tag Tickets raussuchen, Zeiten eintragen, Buchungstexte formulieren. Ich wollte herausfinden, ob sich das grundlegend verbessern lässt — und gleichzeitig verproben, wie weit agentisches Entwickeln in der Praxis trägt.

Das Ergebnis ist der Time Tracker: eine App, die die Zeitbuchung weitgehend automatisiert. Sie synchronisiert sich mit unserem internen System, zeigt Tagesverläufe an, erkennt bearbeitete Tickets, optimiert Buchungstexte per KI und funktioniert offline.

Was in zehn Personentagen entstanden ist

Die App begann als Experiment — und ist längst darüber hinaus. Die Idee dahinter: Die Buchung soll dort möglich sein, wo man gerade arbeitet — als Desktop-Programm, im Browser, per Sprachbefehl oder aus dem Terminal. Heute umfasst das Projekt eine Desktop-App für macOS und Windows, Browser-Extensions für Chrome und Firefox, Sprachschnittstellen für natürlichsprachige Buchungen, eine eigene Produktwebseite — und rund 17.000 Zeilen Produktionscode mit über 750 automatisierten Tests.

Der Code ist vollständig agentisch entstanden — mit Anthropics Claude als KI-Modell.

Wie die Zusammenarbeit aussieht

Ein typischer Arbeitstag beginnt damit, dass ich ein Feature beschreibe: was es tun soll, welche Randbedingungen gelten, wie es sich in die bestehende Architektur einfügt. Der Agent liest den bestehenden Code, schlägt einen Umsetzungsplan vor, und nach einer kurzen Abstimmung implementiert er das Feature inklusive Tests.

Dabei arbeite ich nicht mit einem blanken KI-Modell, sondern mit strukturierten Workflows. Open-Source-Frameworks wie Superpowers oder Get Shit Done geben dem Agenten einen definierten Prozess vor: Anforderung verstehen, Plan erstellen, in kleinen Schritten umsetzen, nach jedem Schritt testen. Das klingt nach Aufwand — aber genau dieser Rahmen ist es, der den Unterschied zwischen „KI hat Code generiert“ und „KI hat ein Feature geliefert“ ausmacht.

Mein Anteil ist die Steuerung: Architekturentscheidungen, Code-Reviews, Qualitätssicherung. Ich prüfe, ob die Lösung zum Gesamtbild passt, ob die Tests die richtigen Fälle abdecken, ob die Benutzerführung stimmt. Das Modell hält dabei eine Disziplin durch — konsistente Namensgebung, vollständige Testabdeckung, saubere Fehlerbehandlung —, die unter Zeitdruck als Erstes leidet, wenn man alles selbst schreibt.

Wo es hakt

Agentisches Entwickeln ist kein Selbstläufer. Drei Beispiele:

Kontext ist alles. Der Agent kennt nur das, was man ihm zeigt. Ohne klare Konventionen und Architekturregeln im Projekt trifft er Entscheidungen, die lokal sinnvoll sind, aber nicht zum großen Ganzen passen. Investition in gute Projektdokumentation zahlt sich doppelt aus.

Bestehendes muss man kennen. Wenn der Agent Code schreibt, der eine bereits vorhandene Funktion dupliziert, muss ich das erkennen. Domänenwissen und Kenntnis der eigenen Codebasis sind nicht optional — sie sind die Voraussetzung.

Überraschungen gehören dazu. Gelegentlich schlägt der Agent Lösungen vor, die technisch funktionieren, aber am eigentlichen Problem vorbeigehen. Die Fähigkeit, einen Schritt zurückzutreten und die richtige Frage zu stellen, bleibt menschliche Kernkompetenz.

Was bleibt

Das Projekt hat mir gezeigt, dass agentisches Entwickeln nicht nur für Prototypen oder Wegwerf-Code taugt. Die App läuft seit Wochen stabil im Produktiveinsatz, wird regelmäßig aktualisiert und von mehreren Kolleg:innen genutzt.

Die interessanteste Erkenntnis ist dabei nicht technischer Natur: Es geht nicht darum, schneller dasselbe zu tun. Es geht darum, Dinge in Angriff zu nehmen, die vorher nicht realistisch waren. Und das ist nicht nur eine Frage für Entwickler — sondern für jedes Unternehmen, das Software baut oder bauen lässt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Dieses Formular speichert Deinen Namen, Deine E-Mail-Adresse sowie den Inhalt, damit wir die Kommentare auf unserer Seite auswerten und anzeigen können. Weitere Informationen findest Du in unserer Datenschutzerklärung.