Back to Software Development

Ziert alle meine "ai-developed" Software-Projekte. Aber ist nur Spass. Oder?

Ich entwickle seit 25 Jahren Software, seit einem Jahr mit KI. Zeit für ein Experiment und einen Zwischenbericht.

Angefangen hat es nebenher, neben der Agenturarbeit, in einer Reihe eigener Projekte: ein Podcast-Fediverse-Mashup (Fediverse: dezentrales soziales Netzwerk), eine Map-SPA (Single Page App) zum Thema Parkraum-Nutzung mit Datascraping (automatisiertes Auslesen von Webdaten), Krypto-Trend-Prediction, Objekterkennung mit eigenem Model-Training, ein liegengebliebenes Unity-Virtual-Reality-Projekt, eine sprachgesteuerte Second-Brain-Obsidian-Manager-App mit lokalem und selbst trainiertem LLM (Sprachmodell), ein Familien-Dashboard auf Tablet und Mac Mini. Und jetzt eine Tippspiel-App. („Wow, spannend." Ja ja. Aber bleibt trotzdem kurz bei mir.)

Der Weg über diese Projekte war eine Lernkurve, und sie verlief nicht wie im Feed versprochen.

Am Anfang: ein Prompt, eine App. Geht irgendwie, geht irgendwie auch gar nicht.

Dann habe ich diktiert. Wirklich diktiert, mit meiner Stimme. Ich bin Entwickler, ich weiß, was zu tun wäre. Stack, Architektur, Datenmodell, Services, Controller, Logik, alles selbst vorgegeben und scharf reviewt. Funktioniert, fühlt sich aber an wie Mikromanagement.

Dann habe ich Vertrauen gewonnen und losgelassen: den Stack definiert, Dependencies und Pattern vorgegeben, Rest machen lassen. Mehr Tempo, weniger Kontrolle, living on the edge.

Dann Richtung spec-driven: Aufgaben und Fehler zu einem Projekt in Task- und Bug-MD-Files (Text-Datei-Format) erfassen, wasserdicht spezifizieren und gegen Abnahmekriterien abarbeiten lassen. Doch da musste mehr möglich sein.

Das Experiment: Agentur agentisch

Die Idee war größer als „eine App bauen lassen". Ich wollte unseren kompletten Agentur-Prozess agentisch durchspielen, end to end: vom Kennenlern-Gespräch über Grobkonzept, inhaltliches Konzept mit Anforderungen, Design, Implementierungsplanung und Umsetzung bis zu Test, Server-Deploy, Store-Release. Nicht eine isolierte Coding-Aufgabe, sondern die ganze Kette mit allen Rollen dahinter: Entwickler, Software-Architekt, Designer, DevOps (Bauen, Ausliefern und Betreiben), Kundenbetreuer, Manager. Im Agenturalltag sind das verschiedene Menschen. Hier waren es die Agenten und ich.

Als Projekt dafür habe ich kein Heldenprojekt gewählt, sondern den Agentur-Durchschnittsfall. Klarer Scope, mittelgroß, nicht trivial, aber kein Forschungsprojekt mit offenem Ausgang. Flutter-App für iOS, Android und Web, Symfony (PHP-Enterprise-Framework) im Backend (REST-API, Administration, Services), mit Push, User-Auth über Google, Apple und E-Mail. Unser Standard, eben.

Und sogar der Zeitdruck war echt, nur kam er diesmal nicht vom Kunden, sondern vom Anpfiff: Start am 9. Mai, WM-Beginn am 11. Juni. Knapp vier Wochen, nebenher.

Konzept. Im Dialog mit Claude, eher wie ein Kundengespräch, in dem ich der Kunde bin. Nur dass Claude die Interviewer-Rolle übernahm: nachfragen, Anforderungen herausarbeiten, Lücken und Sonderfälle aufdecken. Erst aus Spielersicht beschrieben: wie sich die App anfühlt, was man tippen und in der Bande machen kann, dazu die Verwaltungsseite mit dem Turnier dahinter. Dann die App selbst: welche Views, welche Funktionen, was wo sitzt, wie der Flow läuft. Erst danach Technik, Stack und Plugins. Patterns ja, Architektur aber kaum noch. Konzept und Plan habe ich schreiben und gegenlesen lassen.

Design. Die Spec dafür habe ich mir aus der Konzeptphase schreiben lassen, worum es geht, Funktionen, Views, und mit meinen Layoutideen angereichert. Das dann in Claude Design eingekippt (damals gerade ein paar Tage verfügbar) und iterativ ein Design bauen lassen, am Ende ein Export für Claude Code. Den hat Claude Code später in die schon laufende Flutter-App eingearbeitet, dank konsequenter MVVM-Trennung (Model-View-ViewModel, Layout sauber getrennt von Logik) erstaunlich sauber. MVVM ftw! Das Logo ist ein uninspirierter One-Shot von ChatGPT, auch Sam Altman braucht was zum Leben.

Implementierung. Den Plan habe ich in lauter Tasks zerlegt, zerlegen lassen, natürlich, jede so geschnitten, dass sie als One-Shot ohne weitere Rückfragen durchläuft. Umgesetzt wurde dann jede einzelne über ein Command mit festem Ablauf, jeweils mit frischem, eigenem Context:

• Plan formulieren, von einem Sub-Agenten (eigene Claude-Instanz mit klarem Auftrag) reviewen lassen
• implementieren, Tests gleich mitschreiben
• Tests laufen lassen, bis grün, kein Merge ohne grün
• Code-Review und Architektur-QA gegen die Projektregeln
• Final-Review durch einen zweiten Sub-Agenten
• Branch, Squash, Merge nach main (eigener Arbeitszweig, zusammengefasst, zurück in die Hauptlinie), alles automatisch

Das ist Software-Architekt, Entwickler und QA (Qualitätssicherung) in einem Ablauf, abgesichert über harte Gates (GO/NO-GO-Prüfpunkte). Und DevOps lief gleich mit: Das Command legt den Branch an, arbeitet, squasht und merged nach main, dazu Docker-Builds und Server. Die langweilige, fehleranfällige Handarbeit, die keiner gern macht, und ohnehin das Erste, das ich automatisieren wollte.

In Zahlen: 143 Task-Files, 47 Bug-Files, 277 Commits, 80.000 Zeilen Code.

Sich Freunde bauen

Ich habe alle Tasks automatisiert über Tage durchlaufen lassen und erst am Ende der Phase das erste Mal die App gebaut und in den Admin-Bereich geschaut. Tagelang ohne laufendes Programm. Das geht nur, weil das Vertrauen nicht im „sieht im Browser gut aus" sitzt, sondern in den Gates davor. Tests waren permanenter Teil der Arbeit, im Server wie in der App.

Dann die Testphase, und das war der schönste Teil. Ich habe Personas definiert, Nutzer mit unterschiedlichem Tippverhalten (inspiriert von echten Freunden), und die App über mehrere Simulatoren gleichzeitig bedienen lassen, per MCP (Model Context Protocol, offener Standard zur Anbindung von KI an externe Tools) und Marionette (steuert und überwacht die Flutter-Apps fern), von Claude. Signup, Login, tippen, Tipps verpassen, aufs Board posten, interagieren. Die App dabei wie von Geisterhand auf mehreren Simulatoren gleichzeitig laufen zu sehen, hat etwas.

Claude Code orchestriert die App auf mehreren Simulatoren.

Danach echte Tester (und Freunde, Danke an Harry, Frank, Stephan, Erik). Davor die Deploy-Wege etabliert, über Commands und fastlane (Automatisierung für App-Builds und Store-Upload), Server-Deploy inklusive. Dafür habe ich dem Agenten SSH-Zugang gegeben. Was kann schon schiefgehen. (Ging gut. War ja nur ein Testserver.) Den Rücklauf der Tester habe ich eins zu eins in Bug-Files gekippt und abarbeiten lassen.

Auch der komplette App-Store-Deploy lief automatisiert, über Claude und Tools wie fastlane, und das war früher jedes Mal echte Arbeit. Die Texte kamen von Claude, deutsch und englisch. Die Screenshots über Marionette: Beispieldaten anlegen, die App durchsteuern, die richtigen Screens auswählen und abgreifen. Vom Erzeugen über den Upload bis zum Release, alles automatisiert. Kleine Landing-Page mit wenig Liebe? Geschenkt.

Was ich mitnehme

Sechs Dinge und eine App.

Es funktioniert. End to end, vom Konzept bis in den Store.

Kann jetzt jeder Software bauen? Ja. Kann jetzt jeder Software bauen? Nein.

Es ist trotzdem viel Arbeit. Nur eine andere: planen, spezifizieren, reviewen statt tippen. Man tippt weniger und ist stärker gebunden.

Man ist schneller, aber nicht so viel, wie behauptet wird, und nicht so schnell wie im reinen Vibecoding-Modus. Agentisches Arbeiten braucht Zeit, Struktur, Verständnis, Wissen, Erfahrung, Organisation und Prozesse. Das alles gilt es aufzubauen und zu etablieren. Und Claude ist aktuell nicht eben flink.

Die perfekte App? Rundum polierte UX (User Experience), ein unverwechselbares Layout, das letzte Prozent? Sicher nicht. Aber lösbar, das kostet nur echte Zeit, gute Specs und Iterationen. Und vielleicht auch wieder ein bisschen menschliche Kreativität.

Und das Wichtigste: Vibecoding hat sich immer falsch angefühlt. Kontrollverlust, Casino-Vibes, ein Auf und Ab von kurzen Peaks bis zum AI-Vampir. Man bekam immer etwas, aber nie ganz das, was man wollte. Dieser Weg nicht. Er fühlt sich wieder nach Softwareentwicklung an. Nach einer neuen Art davon: Plan, Tests, Reviews, Audit-Trail (lückenlose Nachvollziehbarkeit). Nur dass Planer, Implementierer und Reviewer jetzt Agenten sind. Und ich der, der die Spec hält.

Was bleibt: Software-Entwickler entwickeln Software. Wir wollen verstehen, wie Software funktioniert, wir wollen erschaffen und wir tragen die Verantwortung. Und sein wir ehrlich, wer will den Job denn sonst schon machen?

Alte Disziplin, neue Werkzeuge.

„Yes, we're developers. Developers is what we are."

Was unbeantwortet bleibt

Sind die gefundenen Prozesse in drei Monaten schon wieder obsolet?

Ist agentic Development nur die nächste Abstraktionsebene, wie der Weg von Assembler über funktional zu OOP, oder eine ganz neue Disziplin?

Entsteht der Wert beim Kunden durch das Produkt oder durch die Arbeitszeit beim Dienstleister?

Wie bewegen wir uns im Spannungsfeld zwischen gelernten Patterns in Softwareentwicklung, Design und UX und echter Innovation und Kreativität? Und was davon ist überhaupt gewollt und wie zu bewerten?

Und ganz allgemein: Möchte ich so arbeiten und habe ich überhaupt eine Wahl?

PS. Die App gibt es wirklich, sie heißt Tippspielbande und läuft zur WM. Wer Lust auf eine Tippspielrunde hat: Der Zugang ist Invite-only (Family & Friends), meld dich kurz, dann gibt's einen Code. Eigene Bande aufmachen oder einer beitreten geht in der App in zwei Klicks.

• App Store (iOS)
• Google Play (Android): (in Prüfung)
• Web
• Invite-Code? Schreib mich an.