Das sagt dir keiner: Die eigentliche Arbeit beginnt, nachdem die KI „Fertig" sagt

Q: Was hat Claude Code tatsächlich an einem Abend gebaut?

So sieht meine Git-Historie aus: | Phase | Was passiert ist | Commits | |-------|--------------|---------| | Design-Dokument + Implementierungsplan | Architekturentscheidungen, 12 Aufgaben | 2 | | Claude baut „die gesamte App" | Gerüst → Auth → Bibliothek → Detail → Studio → StoreKit → Barrierefreiheit | 6 | | Der Mensch öffnet den Simulator | Korrigieren, testen, neu gestalten, korrigieren, testen, neu gestalten | 12+ (und wächst noch) | Die erste Phase – Claude Code baut das gesamte App-Gerüst – war wirklich beeindruckend. An einem Abend bin ich von einem leeren Xcode-Projekt zu einer kompilierenden App gelangt mit: Apple Sign-In, Google OAuth, E-Mail-/Passwort-Auth und MFA Einem 5-Schritt-Podcast-Erstellungsassistenten Einer Podcast-Bibliothek mit Suche und Pull-to-Refresh Audio-Wiedergabe mit StoreKit 2 In-App-Käufe mit serverseitiger Verifizierung Studio (Verwaltung wiederkehrender Shows) Lokalisierung in 7 Sprachen Blog-Webview und Barrierefreiheits-Labels 69 Swift-Dateien. 7.568 Codezeilen. Davon habe ich ungefähr null geschrieben. Hier endet jeder KI-Blog-Beitrag. Der triumphale Screenshot. Der „Schaut, was ich gebaut habe"-Moment. Die Commit-Anzahl und die Zeilenzahl und der Zeitplan, der eigentlich nicht möglich sein sollte. Aber ich hatte keine App. Ich hatte eine Codebasis, die kompilierte. ---

Ich habe Xcode noch nie geöffnet.

Ich kenne kein Swift. Ich kenne kein SwiftUI. Ich weiß nicht, was ein @Observable-Makro macht oder warum AVAudioSession eine Kategorie braucht. Vor zwei Tagen, wenn du mich gefragt hättest, was StoreKit ist, hätte ich geraten, dass es eine Möbel-App ist.

Und trotzdem baue ich eine native iOS-App – und entdecke dabei, dass KI-generierter Code dich etwa 60 % des Weges bringt. Die letzten 40 %, der Teil, wo eine Codebasis zu einem Produkt wird, ist vollständig menschliche Arbeit. Das ist das, was keiner der „Ich habe X mit KI gebaut"-Beiträge je erwähnt.

Die App ist für DIALØGUE – meinen KI-Podcast-Generator. Kein Web-Wrapper. Kein React Native. Eine echte SwiftUI-App mit Apple Sign-In, In-App-Käufen, einem Audio-Player mit Sperrbildschirm-Steuerung und Lokalisierung in 7 Sprachen.

Warum jetzt?

Am 3. Februar kündigte Apple an, dass Xcode 26.3 agentisches Coding unterstützen würde – mit dem integrierten Anthropic Claude Agent SDK. Nicht nur Autovervollständigung. Nicht nur schrittweise Vorschläge. Vollständige autonome Agents, die deine Projektstruktur erkunden, Apples Dokumentation durchsuchen, Xcode-Previews aufnehmen, um zu sehen, was sie bauen, und eigenständig durch Builds und Korrekturen iterieren können.

Claude Code kann jetzt über MCP mit Xcode kommunizieren. Es kann den Simulator sehen. Es kann Build-Warnungen und Fehlermeldungen lesen. Es kann sich ansehen, wie die Benutzeroberfläche tatsächlich aussieht, und entscheiden, ob sie geändert werden muss.

Das hat meine Kalkulation verändert. Ich hatte seit Monaten über eine native iOS-App nachgedacht, aber immer wieder aufgeschoben, weil ich kein Swift kenne. Mit Claude Agent in Xcode verlagerte sich die Frage von „Kann ich Swift schnell genug lernen?" zu „Kann ich klar genug beschreiben, was ich möchte?"

Sie ist noch nicht fertig. Ich bin noch in der abschließenden Polierphase, finde noch Dinge, die nicht richtig funktionieren, lerne noch Swift, indem ich den Code lese, den Claude für mich geschrieben hat. Aber die Geschichte bis jetzt – ähnlich wie bei meinem 14-tägigen DIALØGUE-Umbau – hat dieselbe unbequeme Lektion bestätigt.

Was hat Claude Code tatsächlich an einem Abend gebaut?

So sieht meine Git-Historie aus:

Phase	Was passiert ist	Commits
Design-Dokument + Implementierungsplan	Architekturentscheidungen, 12 Aufgaben	2
Claude baut „die gesamte App"	Gerüst → Auth → Bibliothek → Detail → Studio → StoreKit → Barrierefreiheit	6
Der Mensch öffnet den Simulator	Korrigieren, testen, neu gestalten, korrigieren, testen, neu gestalten	12+ (und wächst noch)

Die erste Phase – Claude Code baut das gesamte App-Gerüst – war wirklich beeindruckend. An einem Abend bin ich von einem leeren Xcode-Projekt zu einer kompilierenden App gelangt mit:

Apple Sign-In, Google OAuth, E-Mail-/Passwort-Auth und MFA
Einem 5-Schritt-Podcast-Erstellungsassistenten
Einer Podcast-Bibliothek mit Suche und Pull-to-Refresh
Audio-Wiedergabe mit AVPlayer
StoreKit 2 In-App-Käufe mit serverseitiger Verifizierung
Studio (Verwaltung wiederkehrender Shows)
Lokalisierung in 7 Sprachen
Blog-Webview und Barrierefreiheits-Labels

69 Swift-Dateien. 7.568 Codezeilen. Davon habe ich ungefähr null geschrieben.

Hier endet jeder KI-Blog-Beitrag. Der triumphale Screenshot. Der „Schaut, was ich gebaut habe"-Moment. Die Commit-Anzahl und die Zeilenzahl und der Zeitplan, der eigentlich nicht möglich sein sollte.

Aber ich hatte keine App. Ich hatte eine Codebasis, die kompilierte.

Was ist kaputt gegangen, als ich die App tatsächlich benutzt habe?

Ich habe herumgetippt. Dinge wurden geladen. Manche Bildschirme sahen okay aus. Ich dachte: „Vielleicht wird das tatsächlich funktionieren."

Dann habe ich versucht, einen Podcast zu erstellen.

Der „Fertig"-Button hat deine Arbeit weggeworfen

Der Script-Editor erlaubt es dir, einzelne Dialogzeilen zu bearbeiten, bevor du Audio generierst. Es gibt einen „Fertig"-Button. Ich habe eine Zeile bearbeitet, auf Fertig getippt, und... meine Bearbeitungen verschwanden.

Der Button hat den Bearbeitungsmodus beendet, bevor er gespeichert hat. Im Code sah es korrekt aus – editMode = false – aber die Reihenfolge war falsch. Erst speichern, dann beenden.

Das ist der Typ von Bug, der Nutzer dazu bringt, ihr Telefon zu werfen. Und die KI hat ihn geschrieben, weil die Logik technisch korrekt ist – nur rückwärts.

Echte Daten haben die App zum Absturz gebracht

Ich bin zu einem Podcast navigiert, der vom Produktions-Backend generiert wurde. Absturz. Das Feld research_facts kam als Array von Objekten zurück ({fact, source, reference, confidence}), aber das Swift-Modell erwartete ein Array von Strings. Dasselbe Muster überall – Status-Enums waren case-sensitiv (completed vs. COMPLETE), sodass jedes Status-Badge „Unbekannt" anzeigte.

Claude hat gebaut, was das Design-Dokument sagte. Die Produktionsdatenbank war anderer Meinung. Das ist die Art von Dingen, die du nur mit echten Daten entdeckst, nicht mit Testdaten.

Realtime WebSocket hat sich einfach... nicht verbunden

Im Web funktioniert Supabase Realtime hervorragend. Auf iOS ist die WebSocket-Verbindung stillschweigend fehlgeschlagen. Kein Fehler, kein Absturz. Einfach... keine Updates.

Die Lösung war ein Hosenträger-und-Gürtel-Ansatz: Die Realtime-Subscription beibehalten, aber einen 5-Sekunden-Polling-Fallback hinzufügen, der unabhängig davon läuft. Nicht elegant, aber zuverlässig. Mobile Netzwerke sind unberechenbar, und deine Nutzer werden sich nicht darum kümmern, wie die Status-Updates kommen – nur dass sie es tun.

Die gesamte App verwendete Systemfarben

Jeder Bildschirm war in Standard-iOS-Blau und -Grau. Helles Farbschema. Die Web-App hat ein sorgfältig gestaltetes Dark-Mode-Design – Bernstein und Gold auf Anthrazit, was ich „Studio Warmth" nenne. Claude hatte pflichtbewusst jeden Bildschirm gebaut, aber in Systemfarben.

Ich musste alle 24 View-Dateien anfassen. Jedes Color.accentColor durch Theme.brandPrimary ersetzen. .preferredColorScheme(.dark) an der Wurzel erzwingen.

Das ist kein Bug. Die KI hat genau das getan, was vernünftig war. Aber „vernünftig" und „gut" sind verschiedene Dinge.

DIALØGUE iOS app podcast detail page with Studio Warmth dark theme showing amber radial glow header and integrated audio controls — Die Podcast-Detailseite nach dem Studio-Warmth-Durchlauf – Bernstein-Leuchten, Dark-Theme, integrierte Wiedergabe. Nichts davon existierte in Claudes ursprünglichem Gerüst.

Outline-Überprüfung war ein Button, der „Genehmigen" sagte

Der Podcast-Generierungsablauf hat eine interaktive Phase: Die KI erstellt ein Outline, und du überprüfst es, bevor du fortfährst. Im Web ist das eine erweiterbare Kartenoberfläche, die die Beschreibung, Gesprächspunkte und Forschungsquellen jedes Segments anzeigt.

Auf iOS hat Claude einen Button gebaut, der „Genehmigen" sagte. Das war alles. Kein Outline-Inhalt. Keine Möglichkeit zu sehen, was du genehmigst. Dasselbe für die Script-Überprüfung – ein Button, kein Editor.

Audio wurde nicht abgespielt

Der Audio-Player sah korrekt aus. Play-Button, Fortschrittsleiste, Sperrbildschirm-Steuerung. Aber auf Play tippen tat nichts. Die URL-Auflösungskette war unterbrochen – signierte Download-URLs schlugen in der Entwicklungsumgebung fehl, und die Fallback-URLs verwendeten interne Docker-Hostnamen, die der Simulator nicht auflösen konnte.

Nachdem ich den Audio-Player repariert und die Podcast-Detailseite mit integrierten Wiedergabe-Steuerelementen neu gestaltet hatte, war die persistente Mini-Player-Leiste am unteren Rand jedes Tabs überflüssig. Ich habe sie gelöscht. Code löschen, der funktioniert, aber nicht existieren sollte – das ist ein rein menschliches Urteilsvermögen.

Wie sieht KI-generierter Code vs. ein echtes Produkt aus?

KI-generierter Code ist architektonisch solide, aber erfahrungsmäßig hohl. Ich beschwere mich nicht – was Claude Code geleistet hat, ist bemerkenswert. Von „Ich kenne kein Swift" zu einer kompilierenden App mit Auth, IAP, Audio-Wiedergabe und 7-sprachiger Lokalisierung an einem Abend? Das hätte mich Monate gekostet.

Aber es gibt eine Erzählung da draußen – in Blog-Beiträgen, Tweets, Demo-Videos – dass die KI die App schreibt und du sie nur überprüfst. Sie veröffentlichst. Fertig.

So lief es nicht. Hier ist, was tatsächlich passiert ist:

Claude hat ein Gerüst gebaut, das architektonisch solide war. Die Entscheidung, Supabase direkt zu nutzen (keine eigene API-Schicht), bedeutete, dass die iOS-App mit demselben Backend wie die Web-App kommuniziert. Auth, Datenbank, Realtime, Storage – alles wiederverwendet. Ich brauchte nur eine neue serverseitige Komponente (eine verify-ios-purchase Edge-Funktion). Diese Architekturentscheidung war brillant und hat enorm viel Zeit gespart.
Claude hat die schwierigen Teile richtig hinbekommen. Apple Sign-In mit einem kryptografischen Nonce über CryptoKit. StoreKit 2-Kaufablauf mit serverseitiger Verifizierung. AVAudioSession-Konfiguration für Hintergrundwiedergabe. Das hätte ich allein durch Dokumentation Tage lang herausfinden müssen.
Claude hat die Produktteile falsch gemacht. Nicht falsch im Sinne von fehlerhaft – falsch im Sinne von „so sieht eine Codebasis aus, nicht wie eine App sich anfühlt."

Was Claude gebaut hat	Was tatsächlich gebraucht wurde
Ein Button, der „Genehmigen" sagt	Ein erweiterbarer Outline-Reviewer mit Forschungsquellen
Systemfarben auf jedem Bildschirm	24 Dateien mit Brand-Tokens, erzwungener Dark Mode
JSON-Decoder für das dokumentierte Schema	Benutzerdefinierter Decoder für das, was die Datenbank tatsächlich zurückgibt
Realtime-Subscriptions (Web-Muster)	Realtime + Polling-Fallback (Mobile-Muster)
Ein Erstellungsassistent, der funktioniert	Ein Erstellungsassistent, der auf ein Telefondisplay passt

DIALØGUE iOS creation wizard showing voice customization with speed and pitch sliders in dark theme — Der Erstellungsassistent nach menschlichem Eingreifen – Stimmanpassung mit Geschwindigkeits-/Tonhöhe-Reglern, einklappbare Abschnitte, alles passend auf ein Telefondisplay.

Die linke Spalte ist korrekter Code. Die rechte Spalte ist ein Produkt.

Was sollten wir der nächsten Generation über KI sagen?

Ich habe vor einigen Wochen geschrieben darüber, eine teenagerhafte Tochter zu haben und nicht zu wissen, was ich ihr über ihre Zukunft sagen soll. Darüber, wie die Umsetzungsfähigkeiten automatisiert werden und die Schwelle für „Ich kann kritisch denken" immer höher steigt.

Diese iOS-App zu bauen hat es geschärft – aber nicht in die Richtung, die ich erwartet hatte.

Die Implementierungsfähigkeiten – Swift-Syntax, SwiftUI-Layout, StoreKit-API – brauchte ich nicht. Claude hat all das übernommen. Wenn „Programmieren lernen" bedeutet „die Syntax und APIs einer Programmiersprache lernen", dann hat dieser Ratschlag ein Ablaufdatum, das in Monaten gemessen wird, nicht in Jahren.

Aber hier ist, was ich tatsächlich brauchte: Produktgeschmack, Designurteil und die Disziplin, den Simulator zu öffnen und die Sache tatsächlich zu benutzen, anstatt der Code-Überprüfung zu vertrauen.

Das sind nicht nur „Geschmackssachen". Sie erfordern kritisches Denken – echtes kritisches Denken, nicht die Buzzword-Version. Die Art, bei der du etwas anschaust, das kompiliert, das Tests besteht, das eine KI dir zuversichtlich sagt ist fertig, und du sagst: „Nein. Das stimmt nicht. Lass mich dir erklären, warum."

Das ist der Teil, den wir nicht auslagern können. Noch nicht, vielleicht nie. Die KI ist außerordentlich gut darin, Lösungen zu generieren. Sie ist schlecht darin, zu erkennen, wenn eine Lösung auf eine Weise falsch ist, die in den Logs nicht auftaucht. Sie benutzt das Produkt nicht. Sie hält das Telefon nicht. Sie spürt nicht die Frustration eines Fertig-Buttons, der deine Arbeit auffrisst. Jemand muss steuern. Jemand muss in der Schleife bleiben. Jemand muss die Bauchkontrolle liefern, die sagt: „Das funktioniert, aber es ist nicht gut."

Vielleicht ist das, was ich meiner Tochter sagen sollte. Nicht „Programmieren lernen" – dieses Fenster schließt sich. Aber auch nicht „Einfach lerne kritisch zu denken", weil das zu vage ist. Etwas Spezifischeres:

Lerne, die Person zu sein, die den Simulator öffnet.

Sei derjenige, der das echte Ding mit echten Daten testet und bemerkt, was falsch ist, bevor es deine Nutzer tun. Entwickle Geschmack, indem du großartige und schreckliche Produkte benutzt und den Unterschied verstehst. Entwickle das Selbstvertrauen, etwas zurückzuweisen, das technisch korrekt, aber erfahrungsmäßig kaputt ist – auch wenn das, womit du dich auseinandersetzt, eine KI ist, die sehr sicher klingt.

Der Mensch in der Schleife ist keine Formalität. Er ist das gesamte Produkt.

Ich bin immer noch nicht überzeugt, dass es genug ist. Aber es ist das Spezifischste, was ich bisher sagen konnte.

Wie ist der aktuelle Stand der iOS-App?

Die App befindet sich noch in der Entwicklung. Ich bin in der Polierphase – der Phase, die KI-Blog-Beiträge so tun, als gäbe es sie nicht. Echte Produktionsdaten gegen jede View testen. Die Randfälle finden, die nur auftauchen, wenn man die Sache tatsächlich benutzt.

Mein Git-Log der letzten zwei Tage hat mehr fix:-Commits als feat:-Commits. Das fühlt sich richtig an. Die Features waren der einfache Teil. Die Fixes sind das Produkt.

Hier der aktuelle Stand:

Was funktioniert	Was noch aussteht
Auth (Apple, Google, E-Mail, MFA)	PDF-Upload (Dokumenten-Picker + Supabase Storage)
5-Schritt-Erstellungsassistent mit vollständiger Anpassung	Offline-MP3-Download
Podcast-Detail mit Outline-/Script-Überprüfung	Push-Benachrichtigungen (auf v1.1 verschoben)
Audio-Wiedergabe mit Sperrbildschirm-Steuerung	TestFlight Beta-Distribution
StoreKit 2 In-App-Käufe	App-Store-Einreichung
Studio (wiederkehrende Shows)
7-sprachige Lokalisierung
Studio-Warmth-Designsystem

Ich werde einen Follow-up schreiben, wenn die App im App Store landet. Oder wenn sie abgelehnt wird. Angesichts von Apple könnte die Ablehnungsgeschichte interessanter sein.

Wie schnell beschleunigt sich die KI-Entwicklung wirklich?

Lass mich die Tabelle aktualisieren, die mich immer wieder verfolgt:

Projekt	Komplexität	Bauzeit
DIALØGUE v1	MVP Podcast-Generator	~6 Monate
STRAŦUM	10 KI-Agents, 11 Frameworks, Multi-Tenant	75 Tage
Site-Redesign	WordPress-Frontend-Überarbeitung	3 Tage
DIALØGUE v2	Vollständiger Web-App-Umbau	14 Tage
Blog-Migration	WordPress → Next.js, 490 Beiträge, Sydney RAG	4 Tage
DIALØGUE iOS	Native iOS-App, erstes Mal Swift verwenden	Noch in Arbeit – aber das Gerüst hat einen Abend gebraucht

Ich habe eine neue Spalte in meinem Kopf hinzugefügt: „Zeit für Claude" vs. „Zeit für mich." Das Verhältnis verändert sich immer weiter. Claudes Teil wird kürzer. Mein Teil bleibt ungefähr gleich. (Ich habe dasselbe Muster bemerkt, als ich mein Blog-Backend in 4 Tagen neu aufgebaut habe – die Migration war schnell, aber die 8 Tage der sich aufbauenden Verfeinerungen, die folgten, sind der Ort, wo die Site wirklich zusammengekommen ist.)

Und die Werkzeuge werden immer besser. Als Apple und Anthropic am 3. Februar die Xcode + Claude Agent SDK-Integration ankündigten, war das nicht nur eine Pressemitteilung. Es hat fundamental verändert, was möglich ist. Claude kann jetzt den Simulator sehen, Build-Fehler lesen, Previews aufnehmen und visuell iterieren – genau die Schleife, die iOS-Entwicklung für Menschen schwierig macht, wird zur KI native.

Zwei Wochen nach dieser Ankündigung habe ich begonnen, eine iOS-App zu bauen, ohne Swift zu kennen. Das ist kein Zufall.

Die nächste Person, die das tut, wird keinen Blog-Beitrag darüber schreiben müssen. Es wird einfach... normal sein. So sieht Beschleunigung von innen aus – jeder Meilenstein wirkt weniger bemerkenswert als der letzte, auch wenn die tatsächlich zurückgelegte Strecke immer größer wird.

Das ist das, was dir keiner sagt. Die KI wird schneller. Die menschliche Arbeit nicht. Noch nicht jedenfalls.

Häufig gestellte Fragen

Kann man wirklich eine iOS-App mit KI bauen, wenn man kein Swift kennt?

Ja – Claude Code hat 69 Swift-Dateien und 7.568 Codezeilen an einem Abend erstellt, einschließlich Apple Sign-In, StoreKit 2 In-App-Käufen, Audio-Wiedergabe und 7-sprachiger Lokalisierung. Aber „bauen" macht in diesem Satz viel Schwerstarbeit. Die KI produziert eine Codebasis, die kompiliert; sie in ein Produkt umzuwandeln, das du tatsächlich veröffentlichen würdest, erfordert umfangreiche menschliche Tests, Designurteil und Debugging mit echten Daten.

Was ändert Xcode 26.3 mit dem Claude Agent SDK?

Die am 3. Februar 2026 angekündigte Xcode + Claude Agent SDK-Integration ermöglicht es KI-Agents, deine Projektstruktur zu erkunden, Apples Dokumentation zu durchsuchen, Xcode-Previews aufzunehmen, den Simulator zu sehen, Build-Fehler zu lesen und autonom zu iterieren. Das verändert fundamental, was für Entwickler möglich ist, die kein Swift kennen – die Frage verlagert sich von „Kann ich die Sprache lernen?" zu „Kann ich beschreiben, was ich möchte?"

Wie viel Prozent einer KI-gebauten App erfordert tatsächlich menschliche Arbeit?

Nach meiner Erfahrung bringt die KI dich ungefähr 60 % des Weges – die Architektur, den Boilerplate, die schwierigen API-Integrationen. Die restlichen 40 % sind Produktarbeit: Bugs beheben, die nur mit echten Daten auftreten, UIs neu gestalten, die funktionieren, sich aber nicht richtig anfühlen, und Urteile darüber treffen, was beizubehalten und was zu löschen ist. In diesen 40 % lebt das eigentliche Produkt.

Welche Fähigkeiten sind am wichtigsten beim Bauen mit KI-Coding-Agents?

Produktgeschmack, Designurteil und kritisches Denken. Die Implementierungsfähigkeiten (Syntax, APIs, Frameworks) werden zunehmend von der KI übernommen. Was nicht ausgelagert werden kann, ist die Fähigkeit, das echte Ding mit echten Daten zu testen, zu bemerken, was falsch ist, und etwas zurückzuweisen, das technisch korrekt, aber erfahrungsmäßig kaputt ist.

Ist die DIALØGUE iOS-App im App Store verfügbar?

Noch nicht – sie befindet sich noch in der Entwicklung, in der abschließenden Polierphase. Die Features funktionieren, aber ich teste noch gegen Produktionsdaten und finde die Randfälle, die nur auftauchen, wenn man die App tatsächlich benutzt. Ich werde einen Follow-up schreiben, wenn sie im App Store landet (oder abgelehnt wird).

Noch am Bauen. Noch nicht fertig. Noch dabei herauszufinden, was ich meiner Tochter sagen soll.