Ein Projekt wiederbeleben, das man mit Coding-Assistenten sonst nie fertiggestellt hätte

 (blog.matthewbrunelle.com)
1 Punkte von GN⁺ 3 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein lange liegen gebliebenes persönliches Projekt war eher darauf ausgerichtet, die Implementierung abzuschließen, als etwas neu zu lernen, und eignete sich deshalb gut, um Coding-Assistenten auszuprobieren
  • Der Autor implementierte einen Shim neu, der YouTube Music über die OpenSubsonic API bereitstellt, sodass sich verschiedene Subsonic-Clients auf die gleiche Weise anbinden lassen
  • Nachdem zunächst eine minimale Struktur und Implementierungskonventionen festgelegt worden waren, wurde in kurzen Iterationen gearbeitet und dabei sowohl auf OpenAPI-Spezifikationen basierende Stubs generiert als auch Tests mit echten Clients durchgeführt
  • Die erste Implementierung, die nur zur Spezifikation passte, brach bei echten Verbindungen sofort zusammen; durch wiederholtes Prüfen der Request-Logs und das Hinzufügen von Unit-Tests wurde sie schrittweise bis zu einem Stand gebracht, auf dem Suche und Wiedergabe funktionierten
  • Wenn es nicht um ein Stretch-Projekt zum Lernen geht, sondern um ein Projekt, das einfach existieren soll, können Coding-Assistenten sehr dabei helfen, aufgeschobene Arbeiten in einen tatsächlich nutzbaren Dienst zu verwandeln

Projekthintergrund und Vorgehensweise

  • Ein persönliches Projekt, das vor langer Zeit begonnen, aber nie abgeschlossen wurde, eignete sich gut, um AI-Coding-Assistenten zu testen
    • Wiederbelebt wurde ein Shim zwischen YouTube Music und der OpenSubsonic API
    • OpenSubsonic diente als API-Vertrag, um Musik-Streaming-Clients und -Server zu entkoppeln
    • Als Server wurde Navidrome genutzt, als Desktop-Client Feishin und auf Android Symfonium
  • Der Shim stellt YouTube Music so über die OpenSubsonic API bereit, dass sich jeder Client damit verbinden kann
    • Für das Abrufen von Metadaten wurde ytmusicapi verwendet, für Streaming wurde yt-dlp programmatisch aufgerufen
    • Das grundlegende Streaming ließ sich relativ leicht anbinden, doch bei der vollständigen Implementierung aller Endpunkte gemäß Spezifikation blieb viel Nacharbeit übrig
  • In diesem Projekt stand weniger ein neuartiges oder originelles Problem im Vordergrund als vielmehr die Umsetzung einer klaren Spezifikation, was gut zu Coding-Assistenten passte
    • Der Versuch wurde mit Claude Code und Opus 4.6 durchgeführt, indem alles von Grund auf neu implementiert wurde

Initiales Setup

  • Ausgangspunkt war ein minimales Projekt mit vorab eingeschränkter Struktur
    • Es wurde ein uv-Projekt erstellt und fastapi, pydantic, ytmusicapi und yt-dlp als Abhängigkeiten hinzugefügt
    • main.py wurde durch eine FastAPI-Beispiel-Hauptdatei ersetzt, und die OpenSubsonic-OpenAPI-Spezifikation wurde in einen Ordner gelegt
    • Im README wurden kurz die Rolle des Servers, die verwendeten Bibliotheken, Dokumentations-URLs und der Speicherort von openapi.json notiert
    • Eine leere TODO-Datei wurde ergänzt und mit /init eine CLAUDE.md erzeugt
  • In CLAUDE.md wurden Implementierungskonventionen separat festgehalten, um wiederholte Anweisungen zu reduzieren
    • Für Methodenargumente und Rückgabewerte wurden Typannotationen und Docstrings verlangt
    • Das Datenmodell wurde an die Konventionen von Pydantic V2 angepasst
    • Für Docstrings wurden Google-Style-Abschnitte für args und returns verlangt
    • Tests wurden auf modernen pytest-Stil mit Funktionen auf höherer Ebene sowie assert und Fixtures ausgerichtet
  • Dieser Startpunkt wurde als git repository festgehalten

Ablauf der MVP-Implementierung

  • Die Arbeitsweise basierte auf Planungsmodus und kurzen Iterationen
    • Die nächste Aufgabe wurde als Prompt übergeben, und es wurde geprüft, was im ursprünglichen Plan fehlte oder problematisch war
    • Bei Abweichungen wurden zusätzliche Links zu relevanten Ressourcen gegeben, oder bei mehreren Optionen wurde das Suchwerkzeug eingesetzt, um nach einem gebräuchlicheren Ansatz zu suchen
    • Nach jeder Aufgabe wurde mit "Accept and clear context" der Kontext geleert und die Schleife wiederholt
  • Die erste Implementierung konzentrierte sich darauf, aus der OpenAPI-Spezifikation nur neue JSON-Endpunkte als Stubs zu erzeugen
    • Zwar existierten alte XML-Endpunkte und neue JSON-Endpunkte nebeneinander, doch der Umfang wurde auf die neue Variante begrenzt
    • Nach der Implementierung wurde ein Validierungsschritt eingefügt, um erneut zu prüfen, ob alle Methoden korrekt waren
    • Trotz vorhandener Spezifikation traten im ersten Versuch Fehler auf, die beim zweiten Prüfdurchlauf größtenteils gefunden wurden
  • Nach größeren Änderungen wurde /init erneut ausgeführt, um CLAUDE.md an den neuen Stand anzupassen
  • Als Nächstes wurde minimale Funktionalität für Suche und Streaming definiert und umgesetzt
    • Ziel war eine minimale Funktion, mit der sich ein Subsonic-Client verbinden sowie Songs suchen und abspielen lassen
    • Für die Suche wurde ytmusicapi, für das Streaming yt-dlp verwendet

Probleme in der echten Anbindung und Korrekturen

  • Oberflächlich entstand schnell eine plausible Implementierung, doch beim tatsächlichen Anschluss an Feishin brach sie sofort zusammen
    • Der Client wurde direkt getestet, und die Server-Request-Logs wurden an Claude Code übergeben, um sie iterativ zu korrigieren
    • Es gab Details, die allein aus der Spezifikation nicht ersichtlich waren; so musste etwa das Suffix .view von Endpunkten entfernt werden
  • Bei jedem Fehler wurden neue Unit-Tests erstellt, um Regressionen zu verhindern
  • Schon nach wenigen Iterationen begann in Feishin tatsächlich die Audiowiedergabe zu funktionieren
    • Das Kernproblem war, dass Stub-Endpunkte gar nichts zurückgaben
    • Die meisten Endpunkte mussten so geändert werden, dass sie selbst dann strukturell korrekte Antworten zurückgeben, wenn sie inhaltlich leer sind
  • Dieses Niveau des MVP unterschied sich allerdings nicht stark von dem früheren POC, und die tatsächliche Nutzbarkeit hing von der langen Liste nachgelagerter Arbeiten ab

Lange Nacharbeiten und Ausbau auf volle Funktionalität

  • Laut der OpenSubsonic-Dokumentation umfasste die API rund 80 Endpunkte in 15 Kategorien
  • Der für das MVP nötige Umfang war vergleichsweise klein
    • getLicense, getUser, getGenres und getMusicDirectories geben leere, aber gültige Sammlungen zurück
    • getSong wurde als Pass-through umgesetzt, das die ID aus dem Query-Parameter unverändert zurückgibt und Standardwerte ergänzt
    • search3 wurde mit einem einfachen ytmusicapi-Aufruf implementiert
    • stream extrahiert per yt-dlp-Aufruf, gekapselt mit asyncio.to_thread, eine URL im Format "bestaudio"
    • getCoverArt extrahiert mit yt-dlp die URL des Coverbilds
  • Für die Unterstützung der vollständigen Funktionalität eines Subsonic-Clients war zusätzliche Arbeit nötig
    • Um Nutzungslimits zu vermeiden, wurde um ytmusicapi-Aufrufe ein einfacher In-Memory-Cache gelegt
    • Zum Speichern von Musikmetadaten wurde sqlite verwendet, und alle Endpunkte der Browsing-Kategorie wurden implementiert
    • Auch getTopSongs wurde durch Abfragen einer Top-Songs-Liste umgesetzt
  • Während des Streamings wurden Songs auf der Festplatte gespeichert, um erneute Downloads zu vermeiden
    • Wenn der Client die Verbindung zum Stream-Endpunkt vor Abschluss des Downloads abbrach, war zusätzliche Logik nötig, um unvollständige Dateien zu bereinigen
  • Solche Arbeiten hätten ursprünglich auch manuell erledigt werden können, waren aber nie fertig geworden; da kein Deployment geplant war, wurden schwierige Bereiche wie Authentifizierung weiterhin ausgelassen
  • Am Ende entstand in kurzen Abendstunden ein funktionierender Dienst, mit dem sich Subsonic-Clients verbinden konnten; der Projektname lautet Sub-standard

Wofür sich das eignet

  • Statt Coding-Assistenten bedingungslos zu forcieren, blieb auch die Sorge vor Kompetenzabbau durch Abhängigkeit bestehen
  • Persönliche Projekte ließen sich grob in zwei Gruppen einteilen
    • Stretch-Projekte zum Lernen und Wachsen
    • Projekte, von denen man einfach möchte, dass sie existieren
  • Dieses Projekt gehörte zur zweiten Gruppe, und Coding-Assistenten eigneten sich gut dazu, einen lange unerfüllten Wunsch konkret werden zu lassen
    • Ein Projekt, das sonst nie angegangen worden wäre, wurde tatsächlich realisiert, und das fühlte sich eher so an, als würde man einen Stapel ungelesener Bücher um eines verkleinern
  • Der entscheidende Maßstab war weniger, ob man Projekte der zweiten Gruppe macht, sondern ob daneben auch weiterhin Lernprojekte aus der ersten Gruppe verfolgt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 일 전
Hacker-News-Kommentare

  • Die am häufigsten aufgegebenen Projekte waren bei mir Videospiele.
    Ich habe Dutzende Ordner mit abgebrochenen Projekten, und inzwischen betrachte ich sie wieder als Experimente.
    Letzte Woche habe ich eines davon noch einmal mit Claude aufgegriffen, und das hat wirklich gut gepasst und sofort die Richtung korrigiert.
    Weil ich von Anfang an gesagt hatte, dass es ein aufgegebenes Projekt war, hat es mich dazu gedrängt, erst die V0-Gameplay-Loop fertigzustellen und von dort aus den Spaß zu finden und dann zu erweitern, sodass ich nicht wieder aufgegeben habe.
    Wenn ich ihm Game-Design-Ideen gegeben habe, kam lauffähiger Code zurück; wenn ich Papers zu prozeduralen Algorithmen gegeben habe, kam sogar eine Implementierung heraus; es hat beim Brainstorming für Items geholfen, Grafik-Assets erstellt und sogar beim Aufbau der Lore unterstützt.
    Die Kombination aus Claude Code + Godot macht wirklich Spaß, und es war lange her, dass sich die Nutzung eines Computers so erfreulich angefühlt hat.

    • Das ist das erste Mal, dass ich sehe, dass jemand ein LLM nicht it, sondern he nennt.
      Ich will das nicht kritisieren, aber es wirkte ziemlich interessant und zugleich leicht unangenehm.
    • Bei mir ist es genau umgekehrt.
      Ich hatte Dutzende Ordner mit Experimenten, und viele davon werden jetzt zu echten Projekten.
    • Was im Moment Spaß macht, ist, Projekte wieder hervorzuholen, die vor ein paar Monaten oder vor einem Jahr mit agent driven development begonnen haben und dann stecken geblieben sind, und sie mit aktuellem Claude oder codex weiterzutreiben.
      Manche laufen inzwischen sogar, andere sind immer noch zu komplex, als dass ein Agent damit klarkäme.
      Trotzdem wird es immer einfacher, persönliche Apps zu bauen.
      Bald sind wir wahrscheinlich an dem Punkt, an dem man sagen kann: „Alexa, mach mir eine iPhone-App, die Fotos vom Essen im Kühlschrank macht, Nährwertinformationen sammelt, sie mit einer Fitness-App synchronisiert, mit den Zielen der Gesundheits-App abgleicht und mir per E-Mail bessere Zutaten empfiehlt, passend zu Budget, Region und Ernährungseinschränkungen“ – und innerhalb von 15 Minuten ist die App da.
    • Godot scheint kein für LLMs gut entworfenes Tool zu sein.
      Zum Beispiel kamen ein paarmal fehlerhafte .tres-Dateien heraus, und dem LLM die Generierung von IDs zu überlassen, wirkte auch ziemlich instabil.
    • Im prozeduralen Bereich experimentiere ich auch damit, LLMs als Teil einer prozeduralen Schleife einzusetzen.
      Im Grunde legt man eine Art Live-Narrativ darüber.
      Lokale Modelle sind noch langsam und schwach, aber es war trotzdem ziemlich interessant zu sehen, was dabei herauskommt.

  • Wirklich großartig.
    Es gibt jetzt unglaublich viel persönliche Software.
    Gestern habe ich einen nativen Texteditor gebaut, der vollständig in MediaWiki integriert ist, mit automatischer Link-Vervollständigung und Hilfe bei der Syntaxeingabe.
    Für andere hätte diese Software fast keinen Wert, also hätte niemand außer mir einen Grund, sie zu bauen, und früher hätte ich sie auch nicht gebaut, weil es zu lange gedauert hätte.
    Wenn ich das Coding aber einem Agenten überlasse, ist der Engpass nicht mehr die Implementierung, sondern meine Aufmerksamkeit, und es funktioniert gut, solche persönlichen Aufgaben in freie Slots im Kopf zu schieben.
    Fühlt sich wirklich nach einer guten Zeit an.

    • Vor ein paar Wochen habe ich endlich meinen Quake-2-Mod fertiggestellt, den ich 1998 begonnen hatte.
      Dank AI bin ich über Burnout seit COVID und einen Haufen halbfertiger Projekte hinweggekommen.
      Heute habe ich auch ein terminalbezogenes RDP-Tool repariert und kümmere mich wieder um ein Issue, das ich vor 10 Jahren bei OpenRA eingereicht hatte.
      Die Engine ist 10-mal schneller geworden, und das Pathfinding funktioniert jetzt größtenteils richtig.
    • Es ist wirklich enorm.
      Ich habe ungefähr 120 persönliche Tools, und es stimmt genau, dass sich der Engpass von der Implementierung zum Kontextwechsel verlagert hat.
      Deshalb habe ich jetzt in jedem Projekt-Root eine Markdown-Datei, in die ich beim Anhalten den Status und die nächsten Schritte schreibe.
      So spare ich mir beim Zurückkommen die 20 Minuten Kosten für „Wo war ich noch mal?“.
      Da es ohnehin niemand außer mir benutzt, gibt es auch keinen Druck, Edge Cases abzudecken oder zu dokumentieren; ich löse einfach exakt mein Problem und gehe direkt zum Nächsten weiter.
    • Ich frage mich, wie lange du schon ohne AI ausgekommen bist.
      Wenn ich mir die Produktivitätsexplosion jetzt anschaue, scheint es, als hätte es auch einiges an Zeit gebraucht, so viele kleine Bedürfnisse anzusammeln.
    • Ich habe auch eine App zur Planung einer Oster-Scavenger Hunt gebaut.
      Es ist fast schon komisch, wie nischig das ist.

  • Ich konnte schon immer Code schreiben, hatte aber nie genug Zeit, und AI war ein kompletter Gamechanger, der es mir ermöglicht hat, Open-Source-Projekte in die Welt zu bringen.
    Linux-Apps mit lokalem GUI, für die mir früher die Motivation gefehlt hätte, baue ich jetzt mit Begeisterung.

    • Sambervise: https://github.com/edward-murrell/sambervise
      Eine Linux-GUI-App zur Fernverwaltung eines Samba 4 Active Directory Domain Controller.
    • Krbtray: https://github.com/edward-murrell/krbtray
      Eine GTK3-System-Tray-App zur Verwaltung von Kerberos-Tickets für Linux Mint / Cinnamon und GTK-Umgebungen mit GtkStatusIcon.
    • Das bringt mich wirklich dazu, mich für AI Coding zu begeistern.
      Denn genau nach solchen Apps hatte ich gesucht und ich brauche beide tatsächlich.
    • Eine weitere wichtige Veränderung ist, dass die Kosten großer Refactorings stark gesunken sind.
      Dank Coding-Assistenten kann ich tiefgreifende strukturelle Änderungen einschließlich Modulentwurf mit viel weniger Zeitaufwand als früher ausprobieren.
      Natürlich ist das nicht kostenlos, und manche Modelle produzieren oft Code, der den Maßstäben für Wartbarkeit nicht genügt.
      Nur weil man Zeit beim Schreiben spart, verschwinden die Zeit für wiederholte Korrekturen, Aufräumen und das Nachschärfen von System Prompt oder Instruction-Dateien nicht.

  • Ich stimme Aussagen, man könne durch zu viel Tool-Nutzung deskilling erfahren, nicht besonders zu.
    Ich bin Millennial und baue Möbel mit Handwerkzeugen und alten Holzverbindungen.
    Ich habe das von niemandem gelernt, sondern mir alles über Online-Materialien beigebracht, und am Ende konnte ich trotzdem alles lernen, was ich wollte.
    Ich habe auch keine Angst, diese Fähigkeiten später zu verlieren, denn wenn ich sie brauche, kann ich sie wieder auffrischen.
    Bücher, Videos, Werkzeuge und Holz verschwinden ja nicht.
    Nur weil man AI nutzt und deshalb weniger oft Code von Hand tippt, entsteht im Gehirn kein schwarzes Loch.
    Es ist nicht wie Alzheimer, bei dem Informationen für immer verloren gehen; man braucht nur kurz Zeit zum Wiederaufwärmen, dann ist es schnell wieder da.
    Auch Leute, die vom Coding ins Management gewechselt sind und Jahre später zurückkommen, sind höchstens etwas eingerostet und steigen dann wieder ein.
    Gerade bei persönlichen Projekten muss man dafür auch nicht unnötig Opus-Tokens verbrennen.
    Ein günstiges Abo und etwas wie MiniMax, in einem Container im yolo mode ausgeführt, plus Kontext, Prompts, Websuche und ein Ticket-System wie beads reichen aus.
    Da es nicht eilt, kann man die Reihenfolge brainstorm → plan → implementation → testing einhalten, und wenn man nicht nur Mocks oder Unit-Tests, sondern echte Testmöglichkeiten einbaut, kann man Zeit und Geld sparen und am Ende trotzdem fertig werden.

  • Vor 12 Jahren wollte ich eine einfache App bauen, die als Balkenlängen zeigt, wie viel von meinem Tag / meiner Woche / meinem Monat noch übrig ist, und die auch Wetterdaten wie Höchst- und Tiefsttemperatur oder Bewölkung als Balken darstellt.
    Mit Text und ASCII kam ich ein Stück weit, aber ich habe es nicht geschafft, eine Oberfläche zu bauen, die ich täglich hätte benutzen wollen, und ein grafisches UI habe ich am Ende nie hinbekommen.
    Also habe ich Claude Code die gewünschte grafische Oberfläche beschrieben und es laufen lassen, und heraus kam genau die App, die ich wollte, inklusive eines Date-Parser-Bugs, den ich selbst nicht bemerkt hatte.
    Jetzt habe ich diese App immer in einer Bildschirmecke offen.
    Als Nächstes will ich eine iPhone-App bauen, die an schulfreien Tagen meiner Kinder morgens automatisch den Wecker ausschaltet.
    Von iPhone-Apps verstehe ich gar nichts, und Zeit, es zu lernen, hatte ich auch nie, deshalb wäre ich früher gar nicht auf die Idee gekommen.
    Für persönliche Apps ist Claude Code wirklich hervorragend, und weil Codequalität nicht extrem wichtig ist, kann ich das Ergebnis problemlos direkt verwenden.

    • Claude Code passt wirklich sehr gut zu persönlichen Apps.
      Mein Clipboard-Manager für den Mac, den ich seit Jahren nutze, wurde nach einem OS-Update merkwürdig, und die Alternativen im App Store hatten nicht die Funktionen, die ich wollte.
      Also habe ich nach Simon Willisons SwiftUI-vibe-coding-Artikel mit Claude Code selbst einen gebaut.
      Es brauchte ein paar Iterationen, aber jetzt erledigt er in der Mac-Menüleiste alles, was ich wollte, und noch mehr.
      Besonders beeindruckend fand ich, dass ich CC nach Ideen für Zusatzfunktionen gefragt habe und eine lange Liste mit Optionen bekam, auf die ich selbst nicht gekommen wäre, und die ausgewählten davon anschließend direkt umsetzen ließ.
      Vor zwei Tagen wollte ich außerdem einen dedizierten Markdown-Editor, ähnlich der neuen Markdown-Editing-Komponente von LibreOffice, aber kleiner und leichter.
      Also habe ich mit GPT 5.5 ein Konzept erstellt und es mit CC implementiert, und nach nur zwei vibe-coding-Sessions war eine leichte native Mac-App fast fertig, die Dateien öffnen und erstellen, textverarbeitungsähnlich editieren und in canonical markdown speichern kann.
      Nur Markdown-Tabellen fehlen noch, und darum will ich mich heute weiter kümmern.
      https://simonwillison.net/2026/Mar/27/vibe-coding-swiftui/
      https://news.ycombinator.com/item?id=47298885
    • Genau so ist es.
      Ich mag es, Dinge zu bauen, aber manchmal will ich einfach nur schnell das fertige Ergebnis haben.
      Wenn ich ein persönliches Tool für einen bestimmten Zweck haben möchte, ohne dafür ein ganzes Wochenende zu opfern, ist die Hilfe eines LLMs wirklich großartig, und die Codequalität ist dabei nicht besonders wichtig.
    • Vielleicht musst du die App nicht einmal selbst bauen.
      Auf dem iPhone könnte das schon mit der standardmäßigen Shortcuts-App lösbar sein.
      Man kann einen Shortcut erstellen, der alle Wecker ausschaltet, dann Signale wie den Kalender auslesen und zu bestimmten Daten oder Zeiten Wecker an- und ausschalten lassen und das Ganze über einen regelmäßigen Zeitplan laufen lassen.

  • Ich finde, Side Projects sind meist nicht viel wert, wenn man sie nicht wirklich machen will.
    Wenn der Prozess und die Erfahrung im Vordergrund stehen, ist es Freizeit; wenn das Ergebnis im Vordergrund steht, ist es Arbeit.
    Wenn man viele Side Projects nur wegen des Ergebnisses macht, arbeitet man letztlich in seiner freien Zeit, und dann ist die Frage, wie frei diese Zeit wirklich ist.
    Die moderne Gesellschaft verlangt ohnehin schon zu viele Ergebnisse von uns, deshalb würde ich Side Projects gern wenigstens für die geistige Gesundheit als etwas Eigenes behalten.
    Wenn es allerdings einen Zweck gibt, an den man für ein größeres Gut glaubt, kann das eine Ausnahme sein, denn so ein Ziel kann den Prozess selbst bereichern.

    • Ich habe viele Hobbys, und Programmieren ist nur eines davon.
      Manchmal brauche ich Software, die mir andere Hobbys angenehmer macht, aber das heißt nicht, dass ich dafür Zeit von Hobby X abzweigen und diese Software selbst bauen möchte.
      Außerdem ist so etwas oft gar nicht die Art von Coding, die mir Spaß macht.
      Genau hier lag für mich der sweet spot von LLM-unterstütztem Coding, und ich habe tatsächlich mehrere Helper-Apps gebaut, um andere Hobbys mehr genießen zu können.
      Es bleibt zwar Hobbyzeit, aber das Hobby muss nicht Coding sein.
    • Wenn man nur um des Codings willen codet, mag das stimmen.
      Aber wenn man ein bestimmtes itch kratzen oder eine Ambition verwirklichen will und es bisher nur an Zeit oder Motivation gefehlt hat, verstehe ich nicht, warum das dann Arbeit in der Freizeit sein soll.
      Projekte, die früher ganze Wochenenden oder sogar Urlaube aufgefressen hätten, haben heute in 15 Minuten ein Grundgerüst, und das liegt eher am entgegengesetzten Ende von Arbeit.
    • Ich kann diese Sicht nachvollziehen, und ich halte sie für ziemlich gesund.
      Ich programmiere seit über 30 Jahren, war aber immer schon mit Kommandozeilen-Apps zufrieden und habe erst vor Kurzem Qt gelernt, um richtige Desktop-App-UIs hinzuzufügen.
      Die Lernkurve war extrem steil, aber inzwischen habe ich sie einigermaßen überwunden.
      Dann habe ich auf LinkedIn Screenshots der App gepostet und erwähnt, dass sie kostenlos und Open Source ist, und prompt kamen Hunderte Kommentare von LinkedIn-artigen Leuten, die mich nicht einmal einstellen würden.
      Reaktionen wie „Das würde ich gern in unseren Workflow integrieren“ oder „Du bist nicht die erste Person, die das versucht“ waren überhaupt nicht motivierend; eher fühlte es sich an, als würde ich nur für andere arbeiten oder nutzlose Kritik einstecken.
      Von diesem Schock habe ich ungefähr einen Monat lang die Finger davon gelassen und dann für mich sortiert, dass ich eigentlich den Prozess selbst mochte: Qt zu lernen und zu sehen, wie meine alten Programme zum Leben erwachen.
      Deshalb behandle ich das jetzt wie mein project car.
      Ich zerlege und überarbeite es ständig, tausche das Datenmodell komplett aus, um die Vor- und Nachteile anderer Entwürfe zu sehen, baue sogar die Grafikansicht selbst und ergänze Sprachübersetzungen.
      Funktional ist es längst fertig, aber es gibt ungefähr fünf Versionen mit völlig unterschiedlicher interner Struktur, und genau das macht den Spaß aus.
      Im Arbeitsalltag nutze ich es den ganzen Tag, und auf LinkedIn werde ich es nie wieder erwähnen.

  • In meinem persönlichen Repo gab es gleich drei Versuche für eine Notiz-App, und alle waren in der Lücke zwischen Idee und freier Zeit stecken geblieben.
    Dank Claude Code habe ich aber in zwei Monaten endlich genau die eine fertigbekommen, die ich wirklich wollte.
    Der Bauprozess selbst war das beste Hobby, das ich bisher gefunden habe, deutlich besser als Gaming oder Scrollen.
    Wenn eine Idee, die man seit Jahren mit sich herumträgt, endlich veröffentlicht wird, steckt viel tiefer ein Teil von einem selbst in dieser App, und ich glaube, dass es künftig viel mehr Solo-Builder geben wird, die so etwas machen.

    • Aber wer das kaufen soll, ist eine ganz andere Frage.
      Ich will niemanden herunterziehen, der alte Projekte wieder aufgreift, aber der Markt wird wahrscheinlich mit extrem spezialisierten Projekten überschwemmt.
      Früher stand auf App-Schachteln eine Spezifikation; vielleicht braucht es jetzt so etwas wie eine neue Modellierungssprache, die Zweck und Umfang der Nutzung erklärt.

  • Meine Erfahrung war fast genau dieselbe.
    Ein Side Project für Vergleichsaggregation hing über ein Jahr lang bei 20 % fertig fest, und einmal im Monat öffnete ich es, schaute auf die To-do-Liste, wurde müde und schloss den Tab wieder.
    Dann habe ich ein paar Wochenenden gemeinsam mit Claude daran gesessen und bin durch diese Wand aus halbfertigem Zustand hindurchgekommen.
    Das Erstaunliche war nicht die reine Geschwindigkeit, sondern dass die Wiedereinstiegskosten verschwanden – also die Stunde, in der ich mir meinen alten Code jedes Mal erst wieder in den Kopf laden musste, bevor ich überhaupt etwas tun konnte.
    Übertriebener Hype nervt mich zwar, aber die meisten Leute, die über solche Tools spotten, haben wahrscheinlich nie selbst ausprobiert, wie nützlich sie gerade für solche langweiligen Aufgaben sein können.

  • Ich hatte schon immer mehr Ideen als ich umsetzen konnte, und einige davon waren ziemlich gut.
    Mit AI-Tools kann ich jetzt deutlich mehr davon in etwas verwandeln, das zumindest einigermaßen funktioniert.
    Ironischerweise sinkt der Wert solcher Implementierungen sehr schnell.
    Vor ein paar Wochen habe ich eine kleine Suchbibliothek gebaut, die im Browser läuft und keinen Server braucht, den Großteil von Elasticsearch-artigen Term-/Matching-Queries und Aggregationen unterstützt und sogar ANN vector search über WebGPU eingebaut hat.
    Es war fast so, als müsste ich nur sagen „Füge Feature X hinzu“ und es passierte direkt, und ich habe sie auch schon auf echten Websites eingesetzt.
    Sie skaliert nicht groß, ist aber für Blogs oder Dokumentationsseiten sehr gut, und die Doku dazu steht unter https://querylight.tryformation.com/.
    Es funktioniert exakt so, wie ich es mir vorgestellt habe, und ich könnte wahrscheinlich mit wenig Aufwand auch viele der Long-Tail-Funktionen von Elasticsearch ergänzen.
    Die Resonanz auf GitHub war dagegen ziemlich verhalten.
    Offenbar sind jetzt alle damit beschäftigt, mit AI ihre eigenen Dinge zu bauen, und freuen sich deshalb nicht mehr besonders über die Arbeit anderer – was ich ehrlich gesagt auch nachvollziehen kann.
    Wenn man eine Suchbibliothek braucht, kann man sich selbst eine generieren lassen oder die AI eine passende auswählen lassen.
    Es war ja auch von vornherein keine enorme Menge an Arbeit, das zu bauen.
    Der wirtschaftliche Wert solcher Projekte sinkt schnell.
    Trotzdem mache ich weiter, weil ich das Bauen liebe, und ich halte es auch für wichtig, die Lernkurve dieser Tools zu meistern.
    Es wird auch in Zukunft genug Arbeit geben, aber die Leute werden für weniger Geld ordentliche Ergebnisse erwarten, und um das zu liefern, muss man diese Tools beherrschen.
    Am Ende erweitert ein größerer Möglichkeitsraum nur auch den Maßstab für Ambition, und wer denkt, man müsse selbst keine Erwartungen mehr erfüllen, weil AI die Arbeit übernimmt, täuscht sich.
    Ich habe in den letzten Monaten ebenfalls sehr lange gearbeitet.

  • Jahrelang hatte ich jede Woche mehrere Produktideen, aber sie landeten alle nur in Apple Notes.
    Im letzten Monat habe ich daraus aber drei echte, nutzbare Betas gemacht, und alle drei nutze ich jetzt täglich.