Apps pflegen, die mit KI gebaut wurden: was dir niemand über Woche zwei erzählt

Am ersten Wochenende mit Proyecta lieferst du etwas Echtes aus. Es funktioniert. Deine Nutzer:innen (oder dein Team oder dein zukünftiges Ich) fangen an, es zu nutzen. Und dann ist Montag, und ein:e Kund:in schreibt: “Kannst du ein Dropdown hinzufügen, um nach Region zu filtern?”

Willkommen bei der Wartung. Das ist der Teil beim Bauen einer KI-App, über den niemand spricht, und der Teil, an dem die meisten Projekte entweder zu einem langlebigen Asset werden oder still von der Klippe fallen. Die gute Nachricht: Eine KI-gebaute App zu pflegen ist eine andere Erfahrung als das Pflegen von klassischem Code. Die ehrliche Nachricht: “anders” heißt nicht “kostenlos”.

Was Wartung wirklich bedeutet

Wenn professionelle Entwickler:innen “Wartung” sagen, meinen sie mehr oder weniger vier Dinge:

Kleine Features hinzufügen, nach denen die Leute nach dem Launch fragen.
Dinge reparieren, die kaputtgegangen oder von Anfang an falsch waren.
Schritt halten mit Änderungen außerhalb deiner App — ein Zahlungsanbieter aktualisiert seine API, ein neuer Browser erscheint, deine Datenform ändert sich.
Aufräumen, damit die Codebasis nicht langsam zum Sumpf wird.

Bei einer KI-gebauten App passieren alle vier weiterhin. Was sich ändert, ist, wer sie macht und wie sich die Arbeit anfühlt.

Die gute Nachricht: du kannst mit ihr reden

Hier ist der Teil, den dir niemand erzählt hat, als du Code aus alten Tutorials kopiert hast. Mit einem KI-App-Builder pflegst du die App genauso, wie du sie gebaut hast: indem du beschreibst, was du willst.

Ein echtes Beispiel. Eine Gründerin, die wir kennen, hat ein kleines CRM für ihre Coaching-Praxis gebaut — Klient:innen, Sitzungen, Zahlungsverfolgung, das ganze Paket. Drei Wochen nach dem Launch erwähnte eine Klientin, sie würde gern sehen, wie viele Sitzungen sie dieses Jahr hatte. Die Gründerin öffnete die App und sagte: “Füg jeder Klientenkarte einen Zähler ‘Sitzungen dieses Jahr’ hinzu, der aus der Sitzungstabelle zieht, wo das Datum in 2026 liegt.” Zwölf Minuten später war es live. Sie war zurück beim Coachen.

Diese Geschichte klingt normal, bis man sich an die Alternative erinnert: eine:n Freelancer:in anpingen, zwei Tage warten, 300 $ zahlen, einen PR durchsehen, den sie nicht ganz verstand, und beten, dass nichts anderes kaputtgeht. Die Wartungsschleife ist nicht schneller, weil die KI schlauer ist als der/die Freelancer:in. Sie ist schneller, weil die Schleife weniger Menschen enthält.

Die schwierigere Nachricht: kleine Dinge summieren sich

Hier ist der Teil, der die Leute kalt erwischt. KI-gebaute Apps wirken leicht zu ändern, weil das Hinzufügen leicht ist. Was nicht leicht ist, ist, das Ganze stimmig zu halten, während es wächst.

Ein paar Muster, die wir schiefgehen sehen:

Das versehentliche Geflecht. Du bittest um “füg dem Checkout ein Rabattfeld hinzu”. Sechs Überarbeitungen später lebt die Rabattlogik an drei Stellen, und nur eine davon ist richtig. Noch ist nichts kaputt, aber die nächste Änderung wird verwirrend.
Die vergessene Anforderung. Im März hast du “Gratisversand ab 50 $” hinzugefügt. Im Mai bittest du die KI, “den Checkout neu zu machen, um Geschenkgutscheine zu unterstützen”. Sie tut es. Die Gratisversand-Regel ist weg. Zwei Wochen lang hat es niemand gemerkt.
Der Drift. Deine App startete als “ein Tool für mich”. Jetzt nutzt sie dein Team. Das mentale Modell, von dem die KI ausgeht, ist immer noch “für mich”, weil du das ursprünglich gesagt hast. Neue Features fühlen sich seltsam daneben an, und du kannst nicht genau benennen, warum.

Nichts davon ist ein Versagen der KI-App-Builder. Es sind Versagen von Gedächtnis und geteiltem Kontext — dieselben Probleme, die ein Team menschlicher Entwickler:innen hat, nur in anderer Form.

Wie du dich aufstellst

Die Teams, die mit Wartung gut zurechtkommen, teilen ein paar Gewohnheiten. Es sind meist keine technischen Gewohnheiten. Es sind Gewohnheiten darüber, wie du beschreibst, was deine App ist und was sich geändert hat.

Führe ein “Was diese App ist”-Dokument. Eine Seite. Die Zielgruppe, die Ziele, die Regeln (“Gratisversand ab 50 $”, “Wir mailen Nutzer:innen nie sonntags”, “Telefonnummer ist der Primärschlüssel, nicht die E-Mail”). Wenn du die KI bittest, etwas zu ändern, füg die passende Regel in den Prompt ein. Du umgehst nicht die Intelligenz der KI; du fütterst sie mit dem Kontext, den sie unmöglich behalten kann.

Beschreibe Änderungen in Begriffen von Verhalten, nicht von Code. “Ich will, dass Nutzer:innen sehen, dass ihr Region-Filter zwischen Sitzungen gemerkt wird” ist ein viel besserer Wunsch als “füg dem Filter localStorage hinzu”. Der erste beschreibt, was du willst; der zweite schreibt einen von fünfzehn Wegen vor, das zu tun, und wahrscheinlich nicht den besten.

Mach Änderungen einzeln, eine nach der anderen. Zwei Änderungen in einem Prompt bedeuten, dass eine still scheitern kann und du nicht weißt, welche. Der schnellste Weg, eine KI-App zu pflegen, ist, deine Iterationen klein genug zu halten, dass du auf einen Blick erkennen kannst, ob das Ergebnis stimmt.

Schau dir an, was sich geändert hat. Die meisten KI-App-Builder zeigen dir eine Vorschau. Nutze sie. Die dreißig Sekunden, die du damit verbringst, herumzuklicken und zu bestätigen, dass das neue Feature funktioniert und die alten Features noch tun, sind die billigste Versicherung, die du dieses Jahr kaufst.

Was du nicht kannst (und wahrscheinlich nicht solltest)

Es gibt die Versuchung, sobald man eine App mit KI gebaut hat, zu denken, sie könne die App auch für einen betreiben. Kann sie nicht, und die Lücke ist real:

Sie sagt dir nicht, wenn etwas still kaputtgegangen ist. Logs, Monitoring, Bereitschaftsdienste — das ist immer noch ein eigenes Thema. Die meisten KI-App-Builder überwachen deine Produktiv-App nicht so, wie es ein:e Backend-Engineer:in täte.
Sie weiß nichts über die Welt außerhalb deiner App. Wenn ein Zahlungsanbieter eine API abkündigt, weiß die KI das nicht, bis du es ihr sagst. Abonniere die Changelogs deiner Anbieter. Lies deine E-Mails.
Sie kann keine Produktentscheidungen für dich treffen. Ob du ein Feature hinzufügst, welchen Kompromiss du eingehst, was deine Nutzer:innen wirklich wollen — das bist immer noch du. Die KI ist eine sehr schnelle Hand; das Gehirn bist du.

Das realistische Bild

Nach sechs Monaten mit einer KI-gebauten App landen die meisten, mit denen wir sprechen, ungefähr hier: Sie verbringen vielleicht zwei bis vier Stunden im Monat mit Änderungen, fast alles davon im Gespräch. Die großen Umbauten, vor denen sie früher Angst hatten — “Ich will einen ganz neuen Bereich hinzufügen” —, fühlen sich an wie ein guter Nachmittag. Der langweilige Kram — “Das Datumsformat im Export ist falsch” — fühlt sich an wie ein guter Prompt.

Was sie nicht haben, ist das ständige Hintergrundrauschen einer klassischen Codebasis: Dependency-Updates, Framework-Migrationen, Sicherheitspatches, Build-Konfigurationen. Dieses Rauschen ist in die Plattform aufgesogen worden. Du zahlst dafür, dass die Plattform das übernimmt, was ein viel besserer Deal ist, als eine:n Entwickler:in dafür zu bezahlen.

Wenn du gerade dabei bist, deine erste App zu bauen, lohnt sich vor dem Start der Beitrag dazu, was deine erste KI-gebaute App sein sollte. Und wenn du schon ein paar Wochen drin bist und einige der obigen Muster spürst, ist das normal. Schreib dieses Wochenende dein “Was diese App ist”-Dokument. Dein Ich von in drei Monaten, das nach einem neuen Dashboard fragt, wird sehr froh sein, dass du es getan hast.