Seit vier Monaten betreibe ich zwei eigene Nextcloud-Apps: eine für das Verwalten von Verträgen (Verträge) und eine für die systematische Arbeitszeiterfassung (Worktime). Beide laufen im produktiven Einsatz, beide haben einen eingespielten Workflow. Features und Bugfixes entstehen effizient. Bis zu diesem Wochenende liefen auch die Releases ohne Drama durch.
Am Freitag kam mein Kollege auf mich zu. Er pflegt das AI-First-Development-Framework von cpcMomentum. Es ist unser plugin-basierter Ansatz mit strukturierten Skills für Planung, Entwicklung, Review und Release. Bisher lag der Fokus auf Projekten mit Next.js und FastAPI. Die neue Version sollte sich darüber hinaus automatisch an unterschiedliche Entwicklungsumgebungen anpassen und die jeweiligen Rahmenbedingungen erkennen. Ich erprobte das an meiner Nextcloud-Umgebung. Der automatisierte Befehl zur Anpassung kam zu einem klaren Ergebnis: Claude empfahl mir, die Plugins zunächst nicht einzusetzen. Stattdessen entschieden wir uns, die Grundprinzipien und Neuerungen in meine bestehenden Skills und Commands zu integrieren. So wollten wir den Prozess optimieren. Das haben wir dann getan und den bisherigen Workflow an mehreren Stellen grundlegend überarbeitet. Das war Freitagabend.
Zu dem Zeitpunkt war ich noch guten Mutes, dass die Entwicklung der Apps noch effizienter und stabiler wird. Letztendlich hat es aber dazu geführt, dass ich über das Wochenende sechs neue Versionen von Worktime released habe - fünf davon nur, um die Fehler der jeweils vorherigen zu beheben.
Das ist die Art Wochenende, nach dem man sich fragt, ob man das besser nicht angefasst hätte. Und es ist eine Erfahrung, die ich gerne teilen möchte.
Der Anlass
Auslöser war eine Integritätswarnung von Nextcloud nach einem App-Update: Zwei Dateien waren im Release-Paket, die da nicht hingehörten. Kein kritischer Fehler, keine gebrochene Funktion, aber störend - und ein Hinweis, dass der Release-Prozess nicht sauber war. Genau an dieser Stelle wollten Claude Code und ich am Samstag ansetzen.
Claude hat eine Whitelist-Prüfung eingebaut, einen automatischen Cleanup-Mechanismus für bestehende Installationen, und mir versichert: "Jetzt ist sichergestellt, dass dieses Problem nicht wieder auftaucht."
Das war der Moment, an dem ich hätte nachhaken müssen. Habe ich nicht.
Was dann kam
war eine Kaskade von sechs, kurz aufeinander folgenden Softwareversionen. In den Versionen waren auch einige kleine Features enthalten. Diese habe ich nicht aufgeführt.
v0.4.1 entfernte die störenden Dateien aus künftigen Releases. Bei bestehenden Installationen blieben sie aber liegen, weil Nextcloud beim Update nichts entfernt, nur ersetzt.
v0.4.2 brachte einen automatischen Cleanup-Mechanismus. Zusätzlich landete versehentlich Code aus einem Feature-Branch im Release, der zufällig in meinem Arbeitsverzeichnis lag. Die Datenbank-Migration für ein noch nicht fertiges Feature wurde mit ausgeliefert. Jeder User bekam eine zusätzliche Datenbank-Spalte, die er eigentlich nie hätte bekommen sollen.
v0.4.3 sollte einen weiteren Folgefehler fixen - eine Bibliothek, die ich versehentlich ausgeschlossen hatte. Der PDF-Export funktionierte seit zwei Releases nicht mehr.
v0.4.4 korrigierte, dass eine .htaccess-Datei in der TCPDF-Bibliothek lag, die Nextcloud beim Installieren automatisch entfernt. Das Release-Paket war also mit einer Datei signiert, die im fertigen Install garantiert nicht mehr existiert.
v0.5.0 war der große Moment: Plötzlich gingen bei mehreren Usern die Apps gar nicht mehr auf. Interner Serverfehler. Grund war die Datenbank-Spalte aus v0.4.2, die für das halbfertige Feature vorgesehen war. Der dazugehörige PHP-Code fehlte, weil er eigentlich erst später kommen sollte. Die Spalte war da, der Code konnte sie nicht verarbeiten.
v0.5.1 behob UI-Fehler in dem Feature, das jetzt wohl oder übel ausgeliefert werden musste: Eine Überschrift wurde von der Sidebar überlagert, die Monatsnavigation funktionierte nicht. Beides Dinge, die in anderen Views derselben App längst korrekt gelöst waren.
Was ich daraus gelernt habe
Tests müssen den echten Weg simulieren, nicht einen ähnlichen. Mein Check für den Release-Prozess hat nur geprüft, ob das Paket extrahiert werden kann. Nicht, ob es auch nach einem Update von einer älteren Version funktioniert. Genau dort lagen die kritischen Fehler. Ein Fresh-Install ist keine zuverlässige Simulation dessen, was auf den Servern von Bestands-Usern passiert.
Release-Pakete dürfen nicht aus dem Arbeitsverzeichnis gebaut werden. Genau das hat unser Release-Skill aber bis dahin getan. Aufgefallen war es nie, weil meine Releases vorher immer aus einem aufgeräumten Verzeichnis liefen. An diesem Wochenende war das anders: Parallel lagen die Dateien eines Feature-Branches im Arbeitsverzeichnis, und der Skill nahm sie beim Packen einfach mit. Der Fix ist simpel - git archive HEAD statt Dateisystem-Export - und hätte beim Bau des Skills von Anfang an mitgedacht werden müssen.
Bestehende Muster im Projekt prüfen, bevor neue gebaut werden. Die UI-Fehler in v0.5.1 entstanden, weil Claude eine neue View gebaut hat, ohne sich die bestehenden Views im gleichen Projekt anzuschauen. Jeder andere Screen in der App hat die korrekte Überschriften-Behandlung und die richtige Monatsnavigation. Neu erfunden heißt in diesem Fall: falsch erfunden.
Ein KI-Assistent, der "stabil" sagt, ist nicht automatisch verlässlich. Claude hat mehrfach behauptet, der Prozess sei jetzt sicher. Im Nachhinein ist offensichtlich, dass die Aussage zu schnell kam. Wichtige Nextcloud-Besonderheiten waren in den neuen Tests nicht abgebildet, obwohl ich sie im Vorfeld klar benannt hatte. Ein Beispiel ist der FilenameValidator, der beim Install bestimmte Dateien automatisch entfernt. Das war kein fehlendes Wissen, das war fehlende Sorgfalt. Eine Behauptung wie "jetzt ist es sicher" wiegt schwer. Sie sollte nur fallen, wenn sie auch belegt ist.
Die tiefere Lektion
Es ist verlockend, einen Schuldigen zu suchen - entweder Claude, weil er nicht sorgfältig genug war, oder mich, weil ich seine Aussagen nicht hartnäckig genug hinterfragt habe. Tatsächlich war es beides. Aber die Schuldfrage hilft hier nicht weiter. Was die Geschichte wirklich erklärt, liegt eine Ebene tiefer: in der Art, wie wir beide Fehlerquellen definiert haben.
Hinzu kam ein Eindruck, den auch Kollegen im Austausch bestätigten: Claude reagierte an diesem Wochenende spürbar weniger präzise als sonst. Mein Kollege hatte die neue Version des Frameworks parallel in seiner eigenen Umgebung getestet. Bei ihm lief der Übergang sauber durch. Die Schwierigkeiten lagen also nicht im Werkzeug, sondern in der Kombination aus Nextcloud-Eigenheiten und einem Tag, an dem nicht alles lief. Das entbindet mich nicht von der Verantwortung, aber es ist Teil der ehrlichen Erzählung.
Ein Check, der prüft, ob verbotene Dateien drin sind, fängt nur Bekanntes. Jeder Fehler, den wir im Laufe des Wochenendes gefunden haben, war unbekannt - bis er aufgetreten ist. Whitelist-Tests fangen mehr als Blacklist-Tests, aber noch besser sind Tests, die den echten Weg simulieren: Vorversion installieren, Update einspielen, prüfen ob die App läuft.
Das ist die eigentliche Stärke unseres cpcMomentum-Frameworks: Nicht, dass die KI Fehler verhindert. Sondern dass man nach einem Wochenende wie diesem die Lücken im Prozess dokumentiert, die Skills anpasst, die Regeln schärft. Damit wird das nächste Release besser. Die KI beschleunigt Entwicklung. Die Qualität kommt aus dem Framework, das menschliche Erfahrung in nachvollziehbare Regeln übersetzt.
Wer Software mit KI-Unterstützung entwickelt, sollte Prozesse bauen, die gegen Annahmen schützen, nicht nur gegen Fehler, die man schon kennt. Ein KI-Assistent, der schnell und plausibel antwortet, kann einen schlecht definierten Prozess nicht retten. Aber er kann einen gut definierten Prozess schnell ausführen.
Was jetzt anders ist
Ich habe den Release-Prozess an drei Stellen zusammen mit Claude angepasst. Die Änderungen sind jetzt Teil meiner Skills und damit bei allen kommenden Apps automatisch aktiv.
Das Release-Paket wird aus dem sauberen Git-Stand gebaut, nicht mehr aus dem Arbeitsverzeichnis. Code, der nicht committed ist, kann nicht mehr in ein Release rutschen. Der Test installiert die Vorversion, spielt das neue Release darüber und prüft dann die Integrität - also genau das, was bei jedem Endnutzer passiert. Und vor jeder neuen View, jedem neuen Controller, jeder neuen Komponente wird verpflichtend in bestehendem Code nach ähnlichen Mustern gesucht. Nichts wird mehr neu erfunden, was in derselben App bereits existiert.
Parallel entwickeln wir unser AI-First-Development-Framework selbst weiter. Eine neue Version 4.0 ist bereits in Arbeit. Sie soll genau die Lücke schließen, die das Wochenende sichtbar gemacht hat: Die automatische Anpassung an die technischen Rahmenbedingungen eines konkreten Projekts muss zuverlässiger werden. Eigenheiten wie die einer Nextcloud-Umgebung sollen besser erkannt und respektiert werden. So lässt sich der Ansatz auch unabhängig vom Tech-Stack tragfähig nutzen.
Der erste echte Test des neuen Prozesses steht auch schon an. Die Produktbeschreibung für einen neuen Nextcloud-Dienst ist gerade fertig geworden und bereit zur Umsetzung. Mal sehen, ob es diesmal beim ersten Versuch bleibt.
Ich werde berichten.