Mit Claude Code eine Mac-App entwickeln

• Mit Claude Code wurde fast der gesamte Code einer macOS-App mit mehr als 20.000 Zeilen generiert und veröffentlicht; selbst geschrieben wurden weniger als 1.000 Zeilen
• Mit dem Aufkommen von AI-Coding-Agenten entsteht eine promptzentrierte Entwicklungserfahrung statt der Arbeit in einer klassischen IDE
• Die Generierung von Swift- und SwiftUI-Code hat zwar gewisse Grenzen, doch mit Priming, Context Engineering und gut gestalteten Feedback-Loops lässt sich die Qualität verbessern
• Automatisierung, Deployment, Dokumentation und Tests wurden größtenteils von Claude übernommen, wodurch sich wiederkehrende manuelle Arbeit und Zeitaufwand drastisch reduzieren ließen
• Die IDE der Zukunft wird sich statt um Code-Editoren um Agentennutzung und Kontextverwaltung als neue UX drehen

---

Erfahrung beim Veröffentlichen einer macOS-App nur mit Claude Code

Projektüberblick

• Kürzlich wurde eine native macOS-App namens Context veröffentlicht. Sie ist ein Entwicklertool zum Debuggen von MCP-Servern
• Diese App wurde nahezu zu 100 % mit Claude Code erstellt. Von rund 20.000 Zeilen stammen nicht einmal 1.000 direkt vom Autor
• Um mit Claude Software zu bauen, braucht es weiterhin das Können des Entwicklers, iterative Arbeit und die Fähigkeit, gute Prompts zu formulieren
• Dieser Beitrag erklärt den gesamten Prozess der App-Entwicklung mit Claude Code im Detail, einschließlich Werkzeugwahl, Vor- und Nachteilen sowie Methoden zur Erzeugung hochwertigen Codes

1. Von Copilot zu Claude Code und der Wandel der Entwicklungsumgebung

• Das erste verwendete AI-Coding-Tool war GitHub Copilot, und schon einfache Autovervollständigung steigerte die Entwicklungseffizienz deutlich
• Danach erschienen mit Cursors Agent Mode, Windsurf und anderen zahlreiche agentische Tools, die Kontext aus der Codebasis sammeln und Build- sowie Testzyklen automatisieren
• Im Gegensatz zu herkömmlichen Editoren wie VS Code verfolgt Claude Code eine reine Agenten-Umgebung für das Terminal mit promptbasierter Eingabe
• Es bietet eine einfache UX, die fast alle klassischen IDE-Funktionen weglässt und im Wesentlichen nur ein Prompt-Feld und Ergebnisse zeigt
• Der Coding-Agent ergänzt die bestehende IDE nicht nur, sondern versucht, sie vollständig zu ersetzen
• Wegen der andersartigen Benutzeroberfläche und Nutzungserfahrung bestand zunächst Skepsis gegenüber der UX, doch der neue Ansatz wirkte attraktiv genug, um ihn auszuprobieren

2. Ein Side-Project wieder aufnehmen

• Wie bei vielen Entwicklern neben dem Berufsalltag sammeln sich unvollendete Side-Projects immer weiter an
• Prototypen entstehen schnell, doch in den letzten 20 % bis zur Fertigstellung fehlen oft Zeit und Energie, sodass es nicht bis zum echten Release kommt
• Bei Tests von MCP-Servern entstand der Eindruck, dass eine native App nötig sei, also fiel die Entscheidung, selbst eine zu entwickeln
• In diesem Prozess begann der intensive Einsatz von Claude Code, und es wurde deutlich, wie groß die praktische Hilfe durch AI-Agenten tatsächlich ist

3. Die starke Codegenerierung von Claude Code

• Claude Code mit den aktuellen Modellen Sonnet 4 und Opus 4 erzeugt wirklich schnell guten Code
• Es liest den Projektkontext, erkennt den Codestil, liest relevante Dokumentation und Spezifikationen, implementiert Funktionen und schreibt auch Testcode automatisch
• Build- und Testwiederholungen, Konsolenlog- und Screenshot-Analyse sowie Bugfixing sind nahezu automatisiert
• Mit nur einem sehr kleinen Teil der Zeit, in der ein Entwickler selbst Code schreiben würde, entstehen hochwertige Ergebnisse
• Es erreicht ein Niveau, bei dem selbst ein neu eingestellter Mitarbeiter ohne Kontext innerhalb weniger Minuten Features fertigstellen könnte

4. Die tatsächliche Qualität der Swift- und SwiftUI-Unterstützung

• Verwendet wurden Swift 6.1, macOS 15.5 und aktuelles SwiftUI
• Claude beherrscht Swift bis Version 5.5 größtenteils gut, ist bei neueren Änderungen wie Concurrency aber anfällig
• Mitunter verwechselt es moderne und Legacy-APIs oder mischt Objective-C und SwiftUI fehlerhaft
• Bei SwiftUI-Code sind erste Entwürfe etwas unfertig und grob, lassen sich durch wiederholte Anweisungen aber gut verfeinern
• Wenn UI-Code komplex wird, treten Compilerfehler auf, etwa fehlgeschlagene Typinferenz; Claude kann solchen Code automatisch in kleinere Funktionen refaktorieren
• Wenn Anweisungen in einer CLAUDE.md-Datei festgehalten werden, lässt sich die Codequalität von Claude noch einmal deutlich steigern
  • Zum Beispiel: SwiftUI bevorzugen, die Apple Human Interface Guidelines einhalten, moderne macOS- und Swift6-Features aktiv nutzen
• Zusätzlich lässt sich mit den Richtlinien aus dem Repository agent-rules noch hochwertigerer Code erzeugen

5. Man kann einfach sagen: „Mach es schöner“

• Claude kann mit einfachen Prompts wie „Mach es schöner / eleganter / benutzerfreundlicher“ das UI-Design verbessern
• Bei UI-Bugs oder Verbesserungen lassen sich Screenshots in Claude einfügen und iterativ Feedback geben, das sofort übernommen wird
• Noch systematischer geht es, indem man zuerst fragt: „Schlag vor, wie das UI schöner werden kann“, und anschließend nur die gewünschten Änderungen auswählt und anwenden lässt

6. Die Bedeutung von Context Engineering

• Aktuelle AI-Modelle verstehen auch unvollständige Prompts und grammatikalische Fehler erstaunlich gut
• Wirklich wichtig ist, innerhalb des begrenzten Kontextfensters (200k Tokens) nur die tatsächlich nötigen Informationen unterzubringen
• Wenn der Gesprächskontext voll ist, führt Claude automatisch eine Zusammenfassung (compaction) durch und setzt den Kontext zurück; dabei besteht das Risiko, dass Details verloren gehen oder die Qualität sinkt
• Daher ist Context Engineering, also das Erzielen möglichst hoher Qualität innerhalb des begrenzten Kontexts, die zentrale Aufgabe beim Einsatz von AI-Agenten

7. Agenten-Priming

• Da in diesem compaction-Prozess wichtiger Kontext verloren gehen kann, ist es wirksam, bei Bedarf manuell zusammenfassen zu lassen oder zusätzliche Informationen vorab als Priming bereitzustellen
• Neben CLAUDE.md verbessert sich die Ausgabequalität, wenn man Claude gezielt bestimmte Quelltexte, Spezifikationen oder andere Dokumente vorab lesen und zusammenfassen lässt
• Inhalte wie neue Bibliotheken oder aktuelle APIs, die nach dem Knowledge Cutoff von Claude erschienen sind, lassen sich mit bestimmten Tools wie Context7 oder llm.codes in eine für Claude leichter verständliche Form überführen
• Priming bedeutet, Claude zunächst den Kontext vollständig verstehen zu lassen, etwa mit einer Anweisung wie: „Lies all diese Quelltextdateien, Dokumente und Spezifikationen und fasse sie zusammen“

8. Agenten brauchen eine klare Spezifikation

• Wenn Claude ein Feature implementieren soll, muss unbedingt eine konkrete und detaillierte Spezifikation eingegeben werden, um das gewünschte Ergebnis zu erhalten
• Das oft in Demos gezeigte „Eine App mit einem einzigen Satz als Prompt bauen“ reicht in der Praxis nur für Prototypen
• Auch wenn die Spezifikation nicht perfekt ausgearbeitet ist, genügt es, sie auf eine bequeme Weise zu erklären, etwa per Spracheingabe oder durch Tippen

9. „Ultrathink and Make a Plan“

• Wenn Claude sofort ungeplant mit der Implementierung beginnt, sinkt die Ausgabequalität; deshalb ist es wirksam, zunächst mit erweiterten Denkmodi wie „think“ oder „ultrathink“ einen Plan erstellen zu lassen
• Wenn vor der Umsetzung schrittweise erst der Plan geprüft und Feedback gegeben wird, steigt die Qualität
• Das Dokument Claude Code: Best practices for agentic coding von Anthropic wird als Pflichtlektüre empfohlen

10. Aufbau eines Feedback-Loops

• Die wahre Stärke von Claude Code entfaltet sich dann, wenn es einen Feedback-Loop eigenständig betreiben kann
• Entscheidend ist also ein automatisierter Zyklus, in dem Claude selbst Code ändert, Builds ausführt, Testergebnisse analysiert, den Fehlerkontext sammelt und dann erneut iteriert
• Je besser dieser Loop gestaltet ist, desto autonomer kann Claude hochwertigen Code fertigstellen
• 1. Build
  • Claude muss den Prozess des App-Builds (Kompilierens) selbst ausführen können
  • Bei Swift-Paketen ist ein Build mit dem Befehl swift build einfach möglich, und Claude verarbeitet das problemlos
  • Bei macOS-App-Targets wie Xcode-Projekten ist Claude jedoch oft unsicher, welchen xcodebuild-Befehl es verwenden soll
  • Um dieses Problem zu lösen, wurde ein Tool namens XcodeBuildMCP verwendet, das Claude mit einer vereinfachten Schnittstelle beim Bauen und Ausführen der App unterstützt
• 2. Test
  • Nachdem der Code gebaut wurde, sollte Claude automatisch Tests ausführen und deren Ergebnisse analysieren können
  • Swift-Pakete lassen sich natürlich mit swift test testen, und Claude kommt damit gut zurecht
  • Das direkte Ausführen vollständiger App-Tests oder UI-Tests durch Claude wurde noch nicht ausprobiert; dafür wären voraussichtlich ebenfalls Tools wie XcodeBuildMCP nötig
  • Auf Basis der Testergebnisse, also Erfolgs- oder Fehlerlogs, setzt sich der Loop zur Codekorrektur fort
• 3. Fix Bugs
  • Claude kann Probleme nachverfolgen, indem es zum Debugging Logs hinzufügt
  • Allerdings kann Claude die App nicht selbst bedienen, um solche Logs auszulösen
  • Daher ist ein Schritt nötig, bei dem der Benutzer die App manuell bedient und anschließend Logs aus der Konsole kopiert und in Claude einfügt
  • Auch diese Methode funktioniert in der Praxis gut, aber ohne ausreichend vorbereitete Unit-Tests oder UI-Tests ist vollautomatisches Bugfixing schwierig
  • Für Web-Apps gibt es Browser-Automatisierungslösungen wie playwright-mcp, für native Apps fehlt bisher jedoch noch eine klare Alternative
• 4. Fix UX Issues
  • Für Verbesserungen bei UI/UX-Problemen kann man Screenshots direkt in Claude einfügen und iterativ Feedback geben
  • Mit Tools wie Peekaboo lässt sich das Erstellen von Screenshots zwar automatisieren, doch zunächst muss die App manuell in den gewünschten Zustand gebracht werden, bevor ein Screenshot aufgenommen werden kann
  • Das heißt: Auch bei der UX-bezogenen Automatisierung ist weiterhin Benutzerinteraktion nötig

11. Claude Code macht mehr als nur Code schreiben

• Da Claude Code auf einem allgemeinen Large Language Model (LLM) basiert, lässt es sich auch für viele nicht rein entwicklungsbezogene Aufgaben einsetzen
• So kann man Claude zum Beispiel ganz natürlich um das Überarbeiten von In-App-Texten, die Planung eines Release-Plans oder Vorschläge zur Feature-Verbesserung bitten
• Besonders nützlich war unter anderem die automatische Erstellung von Mock-Daten in frühen Phasen ohne echte Datenbasis
  • Während der Entwicklung der App Context war die MCP-Client-Bibliothek für Swift noch nicht fertig, dennoch sollte bereits am UI-Prototyp gearbeitet werden
  • Realistisch wirkende Mock-Daten manuell zu erstellen wäre in der Praxis sehr mühsam und zeitaufwendig gewesen und wäre wahrscheinlich gar nicht versucht worden
  • Claude erzeugte jedoch innerhalb weniger Sekunden sehr überzeugende Mock-Daten und schuf damit UI-Zustände, die von echten kaum zu unterscheiden waren
  • Tatsächlich wurden beim Teilen des UI mit Freunden auch Screenshots auf Basis dieser Mock-Daten verwendet, die denselben Eindruck wie ein echter Service vermittelten
  • Bei MCP-Servern waren damals oft nur Teile der offiziellen Spezifikation implementiert, sodass echte Daten schwer zu erhalten waren
  • Trotzdem ließ sich mit den von Claude erzeugten Mock-Daten der gesamte UI-Flow und das Verhalten der Funktionen überprüfen

12. Hochwertige Automatisierung ist in dieser Zeit fast kostenlos geworden

• Einer der schmerzhaftesten Teile der letzten 20 % bis zum Software-Release ist die Automatisierung des App-Release-Prozesses
• Gerade bei macOS-Apps verzögerten komplexe Deployment-Abläufe wie Code Signing, Notarization und Packaging (DMG-Erstellung) Veröffentlichungen oft durch Handarbeit oder instabile Skripte
• Bisher wurden dafür meist Automatisierungstools wie fastlane mühsam eingerichtet oder minimale Python-Skripte direkt selbst geschrieben
• In diesem Projekt erzeugte Claude mit nur einigen Stunden iterativer Prompts und Debugging ein vollständiges Automatisierungsskript für Releases
• Zu den Hauptaufgaben dieses Skripts gehören:
  • Prüfung der Umgebungs-Setup: Kontrolle, ob alle benötigten Tools korrekt installiert sind
  • Automatische Erstellung des Changelogs: Änderungen aus Git-Commits extrahieren und mit manuell geschriebenen Punkten zu HTML-Release-Notes zusammenführen
  • App-Build und Packaging: den gesamten Ablauf von App-Build → Code Signing → Notarization → DMG-Paketierung automatisieren
  • Erstellung des Sparkle-Update-Feeds (appcast): automatische Updates für bestehende Nutzer bereitstellen
  • Release-Tags und Veröffentlichung: Tags auf GitHub hinzufügen und Releases veröffentlichen
  • Sentry-Symbol-Upload: Debug-Symbole automatisch hochladen, um Crash-Reports analysieren zu können
• Nachdem das Skript fertig war, reichte der Einzeiler-Prompt „Mach die CLI-Ausgabe schöner“, um auch die CLI-UI noch zu verbessern
• Das Endergebnis waren rund 2.000 Zeilen Python-Code; bei manueller Umsetzung wären vermutlich nur Pflichtfunktionen entstanden, mit Claude wurde es hochwertig abgeschlossen
• Dank dieses Automatisierungsskripts lassen sich bei jedem Release wiederkehrend viele Dutzend Minuten Arbeit sparen
• Wenn man die Spezifikation in natürlicher Sprache beschreibt und Claude nur die während der Ausführung gefundenen Fehler zur Korrektur zurückmeldet, ist der Großteil der Arbeit erledigt

13. Die IDE der Zukunft wird völlig anders aussehen

• Während dieses Projekts wurden von Anfang bis Ende tatsächlich nur zwei Tools genutzt: Claude Code und GitHub Desktop (zum Anzeigen von Diffs)
• Klassische Kernfunktionen traditioneller IDEs wie Dateibaum, Code-Editor, Erweiterungen und Plugins wurden fast gar nicht benötigt
• Gelegentlich wurde Xcode geöffnet und Code direkt bearbeitet, aber auch Xcode-spezifische Funktionen wie SwiftUI Previews oder der View Debugger kamen kaum zum Einsatz
• Gerade jetzt befinden wir uns noch am frühesten und schwächsten Punkt der Fähigkeiten von AI-Coding-Agenten, daher liegt die Vermutung nahe, dass sich IDEs künftig in eine völlig neue Form entwickeln werden

• Copilot, Cursor und Windsurf bauen alle auf VS Code auf und ergänzen Funktionen, aber VS Code selbst unterscheidet sich kaum von JetBrains-IDEs vor 20 Jahren
• Projekte wie Warp modernisieren zwar das Terminal und wollen es in eine Agenten-Entwicklungsumgebung verwandeln, doch auch eine terminalzentrierte UX ist wohl nicht die endgültige Antwort der Zukunft

• Der Kern der IDE der Zukunft wird darin liegen, Entwickler beim effektiven Priming des Agentenkontexts sowie beim Entwerfen und Verwalten von Feedback-Loops zu unterstützen
• Das heißt: Nicht mehr der Code-Editor steht im Zentrum, sondern eine UX rund um Agentennutzung und Kontextmanagement

14. Side-Projects lassen sich wieder veröffentlichen

• Der beeindruckendste Teil dieser Reise war nicht nur, eine großartige App gebaut zu haben, sondern wieder tatsächlich eigene Side-Projects veröffentlichen zu können
• Es fühlte sich an, als gäbe es jeden Tag fünf zusätzliche Stunden, und der Preis dafür lag bei nur 200 US-Dollar im Monat
• Dank AI-Coding-Agenten wie Claude Code kamen der Antrieb und das Selbstvertrauen zurück, lange aufgeschobene Ideen endlich in die Realität umzusetzen

[geek12356]

Mach das oft.

[GN⁺]

Hacker-News-Kommentare

• Noch vor zwei Jahren war ich überzeugt, ein wirklich herausragender Python-Ingenieur zu sein, und jetzt kann ich in wenigen Tagen oder sogar Stunden native Mobile-Apps, Desktop-Apps mit Slack-Anbindung, in Go geschriebene APIs und komplette Web-Apps auf React-Basis bauen.
  Es fühlt sich an, als hätte ich Superkräfte bekommen, und Produktivität, Tempo und Kreativität sprudeln nur so, aber gleichzeitig empfinde ich auch eine merkwürdige Traurigkeit.
  Mein Beruf, meine Leidenschaft und all die Dinge, die ich mir über lange Zeit mit viel Einsatz und Verzicht angeeignet habe, werden nun größtenteils von Maschinen ersetzt.
  Die Firmen, die solche Tools bauen, stehen dabei erst am Anfang.
  Ich frage mich, was das für die nächste Generation von Ingenieuren bedeutet und wie weit dieser Trend noch gehen wird.
  Mich würde interessieren, ob andere ähnlich empfinden.

  • Dass ich inzwischen auf verschiedenen Plattformen effizient mit Native-, Mobile-, Go-, React- und anderen Tools umgehen kann, verdanke ich meiner Erfahrung in der Softwareentwicklung als Python-Ingenieur.
    Was LLMs ersetzen, ist die Notwendigkeit, sich plattformspezifische Kleinigkeiten und Trivia einzuprägen.
    Ich muss in Go die Syntax von for-Schleifen nicht auswendig können und kann trotzdem sofort nützlichen Go-Code schreiben.
    Unverändert bleibt aber, dass man die Grundlagen verstehen muss: Schleifen, Go-Konzepte, strukturierte Programmierung, Compiler sowie Build- und Test-Skripte.
    Menschen ohne Programmierhintergrund fehlt genau dieser Teil in hohem Maß.
    Für mich sind LLMs ein Verstärker und Beschleuniger, der das vage, über viele Berufsjahre angesammelte Wissen direkt auf verschiedene Sprachen und Plattformen übertragbar macht.
    Früher habe ich alle Probleme nur mit Python, JavaScript und SQL gelöst, weil es mir zu mühsam war, die kleinen Unterschiede neuer Sprachen und Plattformen wieder neu zu lernen.
    Jetzt nutze ich auch bereitwillig Go, Bash, AppleScript, jq, ffmpeg und ziehe sogar Swift-Projekte in Betracht.

  • Ich habe Nicht-Techniker dabei beobachtet, wie sie mit LLMs Dinge bauen wollten, und meistens sind sie deutlich langsamer oder scheitern fast vollständig.
    Technische Fähigkeiten sind am Ende vielleicht nicht zwingend notwendig, aber die Fähigkeit, sich klar auszudrücken, ist es auf jeden Fall.
    Schon ein grundlegendes Verständnis von HTML reicht, um Text sauber einzubetten, sodass das LLM ihn klarer versteht.
    Ich denke weiterhin, dass ein technischer Hintergrund ein Vorteil ist.

  • Ich denke, Handwerker vor der Industriellen Revolution hatten vermutlich ähnliche Gefühle.
    Man muss aber bedenken, dass die meisten von ihnen kaum Bildung hatten, dass 1 bis 2 ihrer Kinder vor dem zehnten Lebensjahr an banalen Krankheiten starben und dass sie ohne Strom, fließendes Wasser, Inneninstallationen und Kühlschränke lebten.
    Werkzeuge selbst von Hand zu bauen, hat etwas Romantisches daran (so wie Python-Code von Hand zu schreiben), aber ich denke, je weiter die Zeit voranschreitet, desto mehr nützt es auch unseren Vorfahren, auf abstrakteren Ebenen zu leben.
    Niemand hindert jemanden daran, weiterhin selbst Python-Code zu schreiben, und vermutlich wird es Leute geben, die das wie Graphitkunst als Hobby betreiben.

  • Ich tue mich schwer mit der Vorstellung, dass mein Beruf, meine Leidenschaft und meine Fähigkeiten nun von Maschinen übernommen werden.
    Maschinen folgen lediglich Anweisungen; sie haben weder Erfahrung noch Weitblick, Reflexion, Planungsfähigkeit oder Kreativität.
    Nur Menschen haben Ideen, Kreativität, Ziele und Empathie und können andere mit guten Ideen überzeugen oder den Kontext einer Situation angemessen berücksichtigen.
    Ich denke nicht, dass der Beruf des Programmierers verschwindet, sondern dass er sich auf eine deutlich höhere Abstraktionsebene verlagert.
    Früher konnte man Entwickler sein, ohne Bits, Bytes oder eine Zeile Assembler zu kennen, obwohl es einmal Zeiten gab, in denen Assembler unverzichtbar war.
    Jetzt leben wir in einer Zeit, in der Programme entstehen können, ohne dass man Programmiersprachen selbst beherrschen muss, solange man Englisch und Anforderungen gut versteht.
    Trotzdem verstehen Menschen mit Kenntnissen über Speicherstrukturen, Assembler und Low-Level-Konzepte weiterhin besser, was im Hintergrund passiert, und können es bei Bedarf „besser“ machen.
    Das bedeutet aber nicht, dass höhere Abstraktionsebenen nutzlos werden oder verschwinden.

  • Ich empfinde genau dasselbe.
    Ich entwickle seit über 20 Jahren professionell Software, und diese Arbeit hat mir wirklich Freude gemacht.
    Jetzt nutze ich Claude Code zu 100 % und meine Produktivität ist eindeutig gestiegen, aber während sich der frühere Prozess wie Kunst anfühlte, wirkt es heute eher wie industrialisierte Massenproduktion.
    Ich möchte in dieser neuen Realität wieder etwas finden, das mir erlaubt, tief in Software einzutauchen, und es ist sicher, dass viel von diesem Spaß verloren gegangen ist.

• Der Beitrag ist sehr gut geschrieben und allein das Lesen macht Freude.
  Die IDE der Zukunft wird ganz anders aussehen als heute.
  Ich habe selbst mit Cursor angefangen, dann verstärkte VS-Code-IDEs genutzt und bin am Ende bei Claude Code gelandet.
  Dadurch wurde das Terminal immer wichtiger, sodass mein Workflow zu iTerm mit Ghostty (schnell, leichtgewichtig und modern), Tmux, Tmuxinator und NeoVim übergegangen ist.
  Ich prüfe Dateien mit cat oder bat, bearbeite nur gelegentlich Text, und den Großteil der schweren Arbeit übernimmt Claude Code.
  In NeoVim oder Emacs schreibe ich im Grunde nur Spezifikationen und Prompts, und ich mag diesen Workflow sehr.
  Nicht nur für die Codegenerierung, sondern auch beim Anpassen von Konfigurationsdateien für zsh, neovim, ghostty usw. delegiere ich Aufgaben an Claude Code.
  Selbst Refactorings von Konfigurationsdateien sind in wenigen Minuten erledigt.
  Fragen zur Codebase, Code-Refactoring, Code-Dokumentation, das Erstellen von Commit-Messages – all das überlasse ich ebenfalls dem Tool; einfach großartig.

  • Am Ende wurde erwähnt, dass es auch Fragen zur Codebase, Refactoring, Code-Dokumentation und sinnvolle Commits übernimmt; ich selbst habe mit CC ebenfalls hervorragende Commit-Messages erzeugt und Informationen sowie Beispiele zu Conventional Commits in eine CLAUDE.md-Datei geschrieben.

  • Mich würde interessieren, ob CC persönliche Konfigurationsdateien wie .zshrc automatisch sichert, bevor es Änderungen vornimmt.

• Terminal + Claude Code + Projektordner
  Mir ist erst jetzt klar geworden, dass das wirklich schon ausreicht.
  Ich mochte umfangreiche IDE-Setups ohnehin nie, weil sie umständlich sind, und auch das Cross-Compiling für verschiedene Betriebssysteme mit QT war kompliziert; ich fand die Kombination aus Editor und Terminal immer am logischsten.
  Mit Claude Code als weiterem offenem Terminalfenster, das bei Anfragen hilft, fühlt es sich an, als wäre ich vom Entwickler zum Projektleiter „aufgestiegen“.
  Ohne den Stress, Mitarbeiter zu managen.
  Seit Claude im März erschienen ist, habe ich in nur wenigen Monaten all die Side-Projekte fertiggestellt, die ich schon lange angehen wollte.

• Vor ein oder zwei Jahren dachte ich bereits, dass LLMs für erfahrene Entwickler großartige Assistenten sind, als Ersatz für erfahrene Entwickler aber chaotisch, und für unerfahrene Entwickler sogar gefährliche Assistenten.
  Wenn man eigene Erfahrungen sammelt, bestätigt sich dieser Eindruck meist.
  Inzwischen denke ich zwar, dass LLMs für unerfahrene Entwickler auch gute Mentoren sein könnten, aber in der Praxis sieht man meist eher, dass sie wahllos Dinge ändern, ohne zu verstehen, warum der Code funktioniert, und einfach so lange herumprobieren, bis es irgendwie läuft.
  Deshalb hat sich mein ursprünglicher Eindruck, dass LLMs in solchen Situationen gefährliche Assistenten sind, eher noch verfestigt.
  Dann schlummern oft subtile Bugs oder Probleme unbemerkt im Code, und selbst wenn man sie entdeckt, versteht man häufig ihre Ursache nicht.

• Besonders eindrucksvoll fand ich die Schlussfolgerung, dass LLM-Assistenten die letzten 20 % bis zur Fertigstellung eines Side-Projekts drastisch verkürzt haben.
  Für mich ist auf dieser Reise das Interessanteste weniger die neue App als vielmehr, dass ich meinen Coding-Drang wieder stillen und saubere Side-Projekte endlich mit hoher Qualität veröffentlichen kann.
  Es fühlt sich an, als hätte ich jeden Tag fünf Stunden zusätzlich, und 200 Dollar im Monat reichen dafür aus.

• Ich nutze es hauptsächlich zum Erstellen kleiner Utilities, und dafür funktioniert es wirklich fantastisch.
  Ich habe mit Claude in nur wenigen Stunden ein Utility genau so umgesetzt, wie ich es wollte, das den Status von launchctl/launchd-Tasks (ausgeführt, entladen, fehlgeschlagen usw.) ähnlich wie das OrbStack-Menü-Icon anzeigt.

  • Ich selbst habe zum Spaß eine iOS-App und ein Wordpress-Plugin gebaut und war damit wirklich zufrieden.
    Ich glaube, dass künftig noch mehr Menschen so etwas machen werden, und frage mich, ob dann nicht alle ihren Code auf GitHub teilen sollten.

• Wer seit 2008 Software für den Mac baut, hätte vermutlich schnell gemerkt, wo Claude falsch abgebogen ist, und das sofort korrigieren können.

  • Tools wie Claude Code verstärken vorhandene Fähigkeiten und Erfahrung.
    Sie ersetzen Fachwissen niemals.

  • Am Ende des Beitrags kommt heraus, dass diese Arbeit 200 Dollar pro Monat kostet, und ich finde es schon schwer, selbst die 50 Dollar für Autodesk auszugeben, die ich für mein wichtigstes Hobby brauche.
    Diese AI-Firmen schreiben keine Gewinne, und wenn Investoren anfangen, Rendite zu verlangen, werden steigende Kosten oder sinkende Servicequalität unvermeidlich sein.
    Wenn diese Modelle Prozesse verlieren, weil sie auf unrechtmäßig zum Training verwendeten Code zurückgreifen, wird auch Claudes Fähigkeit, Swift zu generieren, sofort nachlassen.
    Ob man wirklich darauf hoffen sollte, dass Disney in AI-Klagen verliert, ist fraglich.
    Ehrlich gesagt ist mein Kommentar vielleicht nicht besonders bedeutend, aber meine AI-Müdigkeit ist wirklich massiv.
    Ich finde, auf HN und in anderen Tech-Foren sollten solche Posts inzwischen verboten werden.
    Wenn jemand schreiben würde, dass er mit Google oder StackOverflow ganz leicht Code gebaut hat, würden alle das als banal abtun und zynisch kommentieren; ich denke, solche Posts sind im Grunde dasselbe.
    Dieses Gerede darüber, mit AI beim Hobby oder Beruf „mitzufahren“, geht mir auf die Nerven.

• Mit Tools wie Windsurf und CLI-Tools ist es viel einfacher geworden als früher, eigene maßgeschneiderte Tools zu bauen.
  Das ist wirklich eine spannende Zeit.

• Ich habe das Gefühl, dass bald jemand mit einem LLM gleich macOS selbst nachbauen wird.

• Vor ein paar Wochen habe ich mit LLM-Tooling erfolgreich einen 6DOF-Drahtgitter-Renderer in einer System-6-App (klassischer Mac) mit retro68 und c++ zum Laufen gebracht.