Direkt vorweg
Bevor ich anfing, Pulsefield zu bauen, hatte ich Xcode genau einmal geöffnet. Den Simulator vielleicht eine Stunde lang benutzt. Das war der gesamte Umfang meiner iOS-Erfahrung. Ein paar Jahre professionelle Softwareentwicklung im Rücken, keines davon auf Apples Plattform.
Die Entstehungsgeschichte steht im vorherigen Beitrag. Dieser hier handelt davon, wie das Bauen wirklich aussah.
Das falsche Werkzeug zuerst
Der naheliegendste erste Schritt war ChatGPT. Ich nutzte es seit Ende 2022 und es war das, was ich kannte. Der Arbeitsablauf war vorhersehbar: beschreiben was ich will, die Ausgabe kopieren, in Xcode einfügen, schauen was kaputt geht, den Fehler zurückeinfügen, wiederholen.
Es hat funktioniert, technisch gesehen. Aber es war langsam. Der Kontext verdampfte zwischen den Gesprächsrunden. Die Codequalität war inkonsistent, besonders als das Projekt komplexer wurde. Ich stiess immer wieder an Grenzen — nicht weil die Ideen falsch waren, sondern weil das Werkzeug nicht genug vom Problem auf einmal halten konnte, um mir zu helfen, es zu durchbrechen.
Zur gleichen Zeit fing das Unternehmen, bei dem ich arbeite, an, Claude verstärkt in der täglichen Entwicklung einzusetzen. Ich probierte es an ein paar Pulsefield-Problemen aus, bei denen ich nicht weiterkam. Der Unterschied war sofort offensichtlich — nicht marginal, nicht subtil, wirklich offensichtlich. Ich kaufte ein privates Claude-Pro-Abonnement ohne viel Überlegung.
Zwanzig Dollar. Es stellte sich heraus, dass dies die günstigste nützliche Ausgabe des gesamten Projekts war.
In Xcode einbinden
Ich integrierte Claude direkt in Xcode — nicht als Chatfenster, aus dem ich kopierte, sondern als Agent mit vollem Zugriff auf die Codebasis. Er konnte Dateien lesen, Dateien schreiben, Builds starten, Compiler-Ausgaben lesen und darauf basierend iterieren.
Im besten Fall war das etwas ganz anderes. Der Agent hielt den Kontext über mehrere Dateien gleichzeitig. Wenn sich ein Datenmodell änderte, verfolgte er die Auswirkungen. Er schrieb Tests neben den Implementierungen. Er entdeckte Probleme, die ich stundenlang nicht gefunden hätte. Die Core-Haptics-Engine, das Game-Center-Leaderboard, der StoreKit-2-Kaufablauf, vollständige VoiceOver-Unterstützung — alles kam schneller zusammen, als es im Alleingang möglich gewesen wäre.
Es gibt eine Art Schwung, der entsteht, wenn man seine Zeit damit verbringt, zu überprüfen und zu entscheiden, anstatt Dokumentation für eine API nachzuschlagen, die man noch nie angefasst hat. Der Agent übernimmt die unbekannte Oberfläche. Man selbst übernimmt die Urteilsaufgaben. Das ist eine wirklich gute Aufteilung.
Ein Teil davon liegt daran, was Anthropic rund um das gesamte Erlebnis aufgebaut hat. Das Modell, die Oberfläche, die Qualität der Ausgabe — es hat eine Qualität, die Vertrauen schafft. Und Vertrauen lässt einen tiefer einsteigen. Ich fand mich mehr als einmal tief in der Nacht beim Arbeiten wieder, nicht aus Pflicht, sondern weil das nächste Ding nah fühlte. Es gab immer ein nächstes Ding.
Die Nutzungsrechnung erzählt die Geschichte ehrlich. 5 Dollar runter, als eine Session lang lief. Nochmal 5 Dollar eine Stunde später. 10 Dollar bei einem besonders ehrgeizigen Refactoring. Fünfzig Dollar in einer Woche, bevor ich es richtig eingerechnet hatte. Irgendwann fügte Anthropic 20 Dollar Guthaben zu meinem Konto hinzu — ein Geschenk, das genau in dem Moment ankam, als ich mehr verbraucht hatte als ich eingeplant hatte. Ich dachte darüber nach, was es bedeutet, dass ein Unternehmen so viel Vertrauen in sein Produkt hat. Man probiert es. Man macht weiter.
Der Drei-Simulator-Vorfall
Es entwickelt sich ein Ritual. Man schreibt einen Prompt von dem man weiss, dass er lange dauern wird — ein komplexes Refactoring, eine Multi-Datei-Integration, etwas, das der Agent wirklich Zeit braucht, um es durchzuarbeiten. Man drückt auf Eingabe. Und dann, fast sofort, wechselt man zu claude.ai im Browser.
Von dort aus kann man die Nutzungsprozentsätze in nahezu Echtzeit verfolgen. Ich drückte alle paar Sekunden auf Aktualisieren. Die Zahl steigt zunächst langsam. 35%. Dann schneller. 60%. Die MacBook-Lüfter starten irgendwo hier.
87%. 92%.
Ich griff nach meiner Kreditkarte. Lud 10 Dollar auf. Aktualisierte. Stieg immer noch. 95%. Die Maschine wurde richtig heiss, das Lüftergeräusch war zu einem echten Brüllen geworden, und ich sass dort und war mir wirklich nicht sicher, ob das Kontextfenster bei 99% abbrechen und die Aufgabe halb abgeschlossen lassen würde — oder ob der Laptop zuerst durch Hitzedrosselung nutzlos werden würde.
Keines von beidem passierte. Ich liess es zu Ende laufen.
Dann schaute ich nach, was tatsächlich passiert war.
Ich hatte mein Build-Ziel auf mein iPhone gesetzt. Mein iPhone war nicht eingesteckt. Also fiel der Agent auf den Simulator zurück. Er führte den Build aus, fand Probleme, korrigierte den Code und öffnete den Simulator erneut zur Überprüfung. Fand mehr Probleme. Behob sie. Öffnete den Simulator wieder. Dreimal.
Ich hatte drei vollständige iOS-Betriebssysteme gleichzeitig auf meinem Laptop laufen. Deshalb war es so heiss. Deshalb spikte die Nutzung so stark.
Das Feature hat funktioniert, das sei der Vollständigkeit halber erwähnt.
Wo die Grenzen sichtbar werden
Als die Codebasis wuchs, wurden die Konturen der Einschränkungen deutlicher.
Aufgabenumfang ist entscheidend. Ein vager „mach das besser"-Prompt auf einer grossen, vernetzten Codebasis verbrennt schnell Kontext. Der Agent liest Dateien, startet Builds, interpretiert Ausgaben — das summiert sich. Ich lernte, Aufgaben bewusst einzugrenzen: ein klares Ziel pro Session, explizite Grenzen.
Er meldet nicht, was er nicht weiss, dass er es nicht weiss. Ein paar Mal implementierte der Agent etwas mit einer API auf eine Weise, die kompilierte, lief und gut aussah — aber für den Anwendungsfall nicht ganz richtig war. Ich bemerkte das, weil ich den Code kritisch lesen konnte. Jemand ohne Softwareentwicklungshintergrund hätte das vielleicht nicht. Der Agent ist ein Multiplikator bestehender Fähigkeiten, kein Ersatz für sie.
Man ist weiterhin Eigentümer der Codebasis. Wenn etwas auf eine Weise kaputt ging, die der Agent nicht diagnostizieren konnte, musste ich es selbst debuggen. Es gab ein paar solcher Momente. Der Agent hat mich schneller dort hingebracht, aber „dort" erforderte immer noch, dass ich verstand, was passierte.
Meine ehrliche Einschätzung
Claude als Coding-Agent ist kein Zauberkürzel. Es macht einen nicht zum Entwickler, wenn man keiner ist. Was es tut, ist den Lernkurven-Komprimierung für unbekanntes Terrain — in meinem Fall eine gesamte Plattform und ein Ökosystem, in dem ich zuvor nie gearbeitet hatte.
Die Kombination aus echten Programmierkenntnissen und einem fähigen agentischen Werkzeug ist bedeutend leistungsfähig. Keines funktioniert ohne das andere so gut.
Pulsefield ist meine App. Ich traf die Entscheidungen, ich verstand den Code, ich debuggte die Fehler. Aber ich habe sie nicht alleine gebaut, und das werde ich nicht so tun als ob. Das 20-Dollar-Pro-Abonnement war die beste Investition des gesamten Projekts — mit grossem Abstand.