KI in der App-Entwicklung: Was sie wirklich spart

Die Frage kommt inzwischen in fast jedem Erstgespräch: „Macht KI das nicht bald alles allein?” Meistens steckt dahinter eine zweite, unausgesprochene: „Muss ich dafür noch so viel bezahlen?”

Beide Fragen verdienen eine ehrliche Antwort, und die ist unbequemer als ein einfaches Ja oder Nein. KI hat unsere Arbeit tatsächlich verändert — aber nicht dort, wo die meisten es vermuten.

Die kurze Antwort: KI beschleunigt das Schreiben von Code und verschiebt den Aufwand ins Prüfen. Der teure Teil eines App-Projekts war aber nie das Tippen, sondern die Entscheidung, was überhaupt gebaut wird — und die bleibt.

Was sich messbar geändert hat

Wir setzen KI im Alltag ein, nicht als Experiment. Wo sie zuverlässig trägt:

Code, der aus Mustern besteht. Datenmodelle aus einer API-Beschreibung ableiten, Serialisierung schreiben, Formulare mit Validierung aufbauen, Testfälle für offensichtliche Grenzwerte. Diese Arbeit war nie schwierig, nur zeitraubend. Sie ist heute deutlich schneller.

Fremden Code verstehen. Wenn wir eine App übernehmen, die jemand anders gebaut hat, ist die erste Woche Lesen. Ein Modell, das eine Codebasis zusammenfasst und Fragen dazu beantwortet, verkürzt das spürbar. Es ersetzt das Verstehen nicht, aber es findet die Stellen, an denen man anfangen muss.

Übersetzungen und Textarbeit. Acht Sprachen aus einer Codebasis heißen achtmal Texte. Die Vorlage kommt heute maschinell, die Prüfung bleibt bei Menschen — bei medizinischen oder rechtlich heiklen Formulierungen ohne Ausnahme.

Die lästigen Anfänge. Ein Migrationsskript, eine Konfiguration, ein Gerüst für einen neuen Screen. Der erste Entwurf steht in Minuten statt in einer Stunde.

Das ist zusammengenommen ein echter Effekt. Er ist nur kleiner, als die Schlagzeilen suggerieren — weil das Schreiben von Code nie der teure Teil war.

Was KI nicht abnimmt

Die Entscheidung, was gebaut werden soll. Der aufwendigste Teil eines Projekts ist selten die Umsetzung, sondern das Aussortieren: Welche der vierzig gewünschten Funktionen tragen das Produkt, welche kosten nur Pflege? Diese Frage braucht Kontext über das Geschäft des Kunden, den kein Modell hat.

Die Verantwortung für das Ergebnis. Ein Modell kann eine Berechnung plausibel aussehen lassen, die falsch ist. Bei einer Zyklusprognose oder einer Betriebsstundenzählung ist „sieht richtig aus” wertlos. Jemand muss verstehen, warum die Zahl stimmt — und dieser Jemand haftet dafür.

Alles, was mit echter Hardware zu tun hat. Eine Bluetooth-Verbindung, die im Testgerät funktioniert und im dritten Gerät der Kundencharge nicht, ist kein Codeproblem. Sie ist ein Problem, das man nur findet, indem man das Gerät in die Hand nimmt.

Die Integration in ein gewachsenes System. Generierter Code ist an sich meist korrekt. Ob er zu den Konventionen der bestehenden Codebasis passt, ob er die richtige Fehlerbehandlung nutzt, ob er die Architektur respektiert — das entscheidet sich beim Review.

Die Verschiebung, über die zu wenig gesprochen wird

Hier liegt der eigentliche Punkt: KI verschiebt Aufwand vom Schreiben zum Prüfen.

Früher war das Verhältnis ungefähr: viel Zeit fürs Schreiben, wenig fürs Review. Heute steht Code schneller da, aber jede Zeile muss trotzdem verstanden werden, bevor sie in ein Produkt geht. Und Prüfen ist die anstrengendere Tätigkeit — sie erfordert dasselbe Wissen wie das Schreiben, nur ohne den Denkprozess, der beim Selbstschreiben nebenbei entsteht.

Daraus folgen zwei Dinge, die für Auftraggeber relevant sind:

Erstens: Die Ersparnis ist real, aber nicht dramatisch. Wer erwartet, dass eine App jetzt ein Drittel kostet, wird enttäuscht. Wer erwartet, dass ein Projekt schneller in einen vorzeigbaren Zustand kommt, hat recht.

Zweitens: Erfahrung wird wichtiger, nicht unwichtiger. Ein Modell erzeugt plausiblen Code, der eine Sicherheitslücke enthält, ohne dass sich das an der Oberfläche zeigt. Wer das erkennen soll, muss wissen, wonach zu suchen ist. Die Behauptung, KI mache Senior-Entwickler überflüssig, ist ungefähr das Gegenteil dessen, was wir im Alltag erleben.

Was das im Alltag konkret heißt

Ein Beispiel aus unserer Arbeit: Wir übernehmen eine App, die jemand anders gebaut hat. Früher hätten wir eine Woche gelesen, bevor wir die erste Zeile ändern. Heute fassen wir die Codebasis maschinell zusammen, lassen uns die Datenflüsse erklären und finden die kritischen Stellen in ein bis zwei Tagen.

Das ist eine echte Ersparnis. Sie hat nur einen Haken: Was das Modell zusammenfasst, ist eine Beschreibung des Codes, keine Bewertung. Ob eine Architektur trägt, ob eine Abkürzung an einer Stelle später an anderer teuer wird, ob ein Muster im Projekt konsequent durchgehalten wurde — das steht in keiner Zusammenfassung. Dafür muss jemand mit Erfahrung hineinsehen.

Anders gesagt: KI bringt uns schneller an die Stelle, an der die eigentliche Arbeit beginnt.

Wo KI im Produkt selbst hilft — und wo nicht

Bisher ging es um KI als Werkzeug. Die zweite Frage ist, ob KI in die App gehört. Unsere Antwort: seltener, als gerade gebaut wird.

Sinnvoll ist sie dort, wo Sprache oder Muster im Spiel sind: unstrukturierte Eingaben verstehen, Freitext einordnen, aus vielen Datenpunkten eine Zusammenfassung machen, Bewertungen nach Themen sortieren. Das sind Aufgaben, die klassisch schwer zu programmieren und mit einem Modell plötzlich machbar sind.

Nicht sinnvoll ist sie dort, wo eine Regel reicht. Wir haben Anfragen gesehen, bei denen ein Sprachmodell entscheiden sollte, was eine if-Abfrage zuverlässiger, billiger und nachvollziehbarer erledigt. Ein Modell an dieser Stelle bringt Latenz, Kosten pro Aufruf, Abhängigkeit von einem Anbieter und die Eigenschaft, gelegentlich etwas anderes zu antworten als beim letzten Mal.

Die Prüffrage, die wir dabei stellen: Was passiert, wenn die Antwort falsch ist? Bei einer Textvorschlagsfunktion: ärgerlich. Bei einer Dosierungsempfehlung: inakzeptabel. Je schwerer die Folge, desto weniger gehört die Entscheidung an ein Modell — oder desto mehr Prüfung muss dahinter.

Drei weitere Fragen, die wir vor jedem KI-Feature stellen:

Was kostet ein Aufruf, und wie oft passiert er? Ein Modell im Hintergrund einer App, die zehntausend Menschen täglich nutzen, ist ein laufender Kostenposten. Der gehört in die Kalkulation, bevor das Feature gebaut wird.

Was passiert, wenn der Anbieter ausfällt oder die Preise ändert? Eine Kernfunktion, die von einem externen Dienst abhängt, ist ein Klumpenrisiko. Für eine Zusatzfunktion ist das vertretbar, für den Hauptzweck der App nicht.

Wohin gehen die Daten? Bei Gesundheits-, Betriebs- oder Personendaten ist das keine technische, sondern eine rechtliche Frage — und sie muss beantwortet sein, bevor der erste Aufruf rausgeht.

Was das für dein Projekt bedeutet

Wenn du eine App bauen oder modernisieren lässt, ist die praktische Konsequenz überschaubar:

• Erwarte etwas mehr Tempo in der Umsetzung, besonders in frühen Phasen, wenn viel Gerüst entsteht.
• Erwarte keine andere Größenordnung beim Preis. Der Aufwand liegt in Abstimmung, Architektur, Prüfung und Betrieb — und der ist geblieben.
• Sieh dir an, wie der Dienstleister selbst arbeitet. Lass dir das Vorgehen konkret zeigen — inklusive der Stellen, an denen bewusst nicht automatisiert wird.
• Frag nach, wie geprüft wird. Nicht ob KI eingesetzt wird, sondern wer den erzeugten Code liest und verantwortet. Diese Antwort sagt mehr über einen Dienstleister aus als jede Technologieliste.
• Sei skeptisch bei KI-Funktionen im Produkt, für die niemand erklären kann, was bei einer falschen Antwort passiert.

Wir setzen KI ein, wo sie Arbeit abnimmt, und lassen sie weg, wo sie nur gut klingt. Das ist keine besonders aufregende Haltung — aber sie hält auch dann noch, wenn der nächste Hype vorbei ist.

---

Passend dazu: Wenn du wissen willst, wie wir Projekte grundsätzlich angehen: App-Entwicklung.