Ein mit Claude Code vibe-codiertes Bücherregal-Projekt

 (balajmarius.com)
10 Punkte von GN⁺ 2025-12-30 | 2 Kommentare | Auf WhatsApp teilen
  • Fallbeispiel eines persönlichen Projekts, das Claude Code nutzt, um rund 500 Bücher automatisch zu kategorisieren und zu visualisieren
  • Das Problem, dass bestehende ISBN-Scanner oder Goodreads rumänische Ausgaben nicht erkannten und daher scheiterten, wurde mit der OpenAI Vision API und von Claude erstellten Skripten gelöst
  • Nach der Extraktion von Metadaten mit 90 % Genauigkeit wurde der Rest manuell korrigiert und Cover-Bilder über Open Library und SerpAPI automatisch gesammelt
  • Mit Framer Motion wurden scrollbasierte Animationen und eine Darstellung der Buchdicke auf Basis der Seitenzahl umgesetzt, um eine Interaktion wie bei einem echten Bücherregal zu erzeugen
  • Gezeigt wird eine kollaborative Struktur, in der die AI die Ausführung übernimmt und der Nutzer ästhetische Urteile und Entscheidungen trifft; betont wird, dass „die Kosten der Ausführung sinken, Geschmack aber weiterhin Sache des Menschen ist“

Das fertige Bookshelf - https://balajmarius.com/bookshelf ansehen

Projektüberblick

  • Trotz eines Bestands von rund 500 Büchern ohne gepflegte Liste wurde mithilfe von AI-Tools ein System zur automatischen Kategorisierung und Visualisierung aufgebaut
  • Statt einer einfachen Tabellenkalkulation wurden die Ausführungsschritte mit Claude Code automatisiert, wodurch ein lange aufgeschobenes persönliches Projekt abgeschlossen werden konnte
  • Der Kern des Projekts lag weniger in technischer Perfektion als darin, Engpässe bei der Umsetzung zu beseitigen

Problemerkennung

  • ISBN-Scanner-Apps und Goodreads erkannten rumänische Ausgaben oder seltene Veröffentlichungen nicht, wodurch die Daten unvollständig blieben
  • Unvollständige Daten sorgten eher für zusätzliche Verwirrung, sodass das Projekt wiederholt ins Stocken geriet
  • Benötigt wurde nicht eine perfekte App, sondern eine Systemstruktur, die mit Unvollkommenheit umgehen kann

Datenerfassung und -verarbeitung

  • Die Datenbasis wurde auf Grundlage von 470 Fotos der Buchcover und Buchrücken aufgebaut
  • Ein von Claude geschriebenes Skript sendete jedes Bild an die OpenAI Vision API, extrahierte Autor, Titel und Verlag und speicherte die Ergebnisse in einer JSON-Datei
  • Dabei wurde eine Genauigkeit von etwa 90 % erreicht; die übrigen Fehler entstanden durch Beleuchtung, Beschädigungen oder Auflösungsprobleme
  • Die verbleibenden 10 % wurden manuell korrigiert; beim Hinzufügen neuer Bücher läuft dieselbe Pipeline anschließend automatisch

Ergänzung der Cover-Bilder

  • Über die Open Library API wurden Cover geladen, doch etwa die Hälfte war von niedriger Qualität oder zeigte falsche Bilder
  • Claude ergänzte ein System zur Qualitätsbewertung und Fehlerkennzeichnung; bei Fehlschlägen wurde stattdessen über SerpAPI eine Google-Bildersuche genutzt
  • Von rund 460 Büchern mussten nur 10 manuell nachgebessert werden, wodurch eine hohe Automatisierungseffizienz erreicht wurde

Umsetzung der Bücherregal-UI

  • Statt eines einfachen Cover-Grid wurde eine visuelle Darstellung mit Fokus auf Buchrücken umgesetzt, die einem echten Bücherregal ähnelt
  • Claude übernahm die Farbauswahl-Extraktion (color quantization) und die Berechnung kontrastierender Textfarben
  • Mithilfe der Seitenzahldaten von Open Library wurde die Buchdicke abgebildet und durch leichte Variationen realistischer gemacht
  • Das Ergebnis war eine visuelle Textur, die einem echten Bücherregal nahekommt

Animationen und Interaktion

  • Mit Framer Motion wurden scrollbasierte Animationen ergänzt, bei denen sich die Buchrücken beim Scrollen neigen
  • Anfangs kam es durch React-State-Updates zu Rucklern, doch mit motion values und spring animation wurde das behoben
  • Danach entstand eine flüssige Bewegung; die niedrigen Experimentierkosten ermöglichten wiederholte Versuche

Entfernen unnötiger Funktionen

  • Zwar wurde eine Infinite-Scroll-Funktion hinzugefügt, doch unterschiedliche Containerhöhen und Scrollfehler verschlechterten die Nutzererfahrung
  • Technisch funktionierte sie, war aber nicht nötig und wurde deshalb entfernt
  • Damit wird betont, dass die Entscheidung, „funktionierenden, aber unnötigen Code“ zu entfernen, die Rolle des Menschen ist

Mobile-Unterstützung und Stack-View

  • Weil horizontales Scrollen auf Mobilgeräten unkomfortabel war, wurde eine vertikale Stack-View ergänzt
  • Claude analysierte den bestehenden Code und nutzte Animationstiming, Farbauswahl-Extraktion und Scroll-Transparenzbehandlung erneut
  • Ohne gesonderte Erläuterung wurde eine vollständig neue Komponente erzeugt, was die Fähigkeit der AI zum Codeverständnis und zur Rekonstruktion zeigte

Die Rolle des Menschen und Fazit

  • Claude schrieb den gesamten Code, doch der Nutzer traf folgende Entscheidungen
    • Akzeptanz von 90 % Genauigkeit
    • Manuelle Korrektur von 10 Cover-Bildern
    • Wahl eines buchrückenorientierten Designs
    • Entfernen unnötiger Funktionen
    • Bestätigung der sensorischen/stilistischen Qualität der Animationen
  • Das Endergebnis ist ein webbasiertes Bücherregal, das 460 Bücher automatisch kategorisiert und visualisiert
  • Es zeigt ein Kollaborationsmodell, in dem die AI die Ausführung übernimmt und der Mensch Geschmack und Urteilsvermögen beisteuert
  • Das Fazit lautet: „Die Kosten der Ausführung sinken weiter, aber Geschmack bleibt weiterhin Sache des Menschen.“

Verwandte Beiträge

2 Kommentare

 
ahwjdekf 2025-12-31

Es wird behauptet, dass nur 10 Stück manuell bearbeitet werden mussten, aber das ist bloße Selbstrechtfertigung. Um diese 10 zu finden, war eine vollständige Prüfung nötig. Der Schwanz wedelt mit dem Hund.
 
GN⁺ 2025-12-30
Hacker-News-Kommentare

  • Vibe Coding passt aktuell genau für kleine Projekte.
    Wenn ein Projekt größer wird, wird Kontext-Management schwierig, und ein LLM erzeugt leicht unnötig viel Code oder subtile Bugs.
    Dann ist es besser, wieder in den Brainstorming-Modus zurückzugehen, sich vom LLM nur beim Design helfen zu lassen und den eigentlichen Code selbst zu schreiben oder ein Grundgerüst zu bauen, das das LLM dann ausfüllt.
    LLMs sind immer noch schwach darin, bestehenden Code nur leicht zu ändern oder vorhandene Strukturen zu nutzen. Meist versuchen sie, neue Abstraktionen oben draufzusetzen.

    • Stimme ich auch zu. Mit Claude Code funktioniert es meiner Erfahrung nach aber auch bei großen Projekten gut.
      Ich entwerfe die Modulstruktur selbst und weiß klar, wie das Ergebnis aussehen soll. Wenn man jeden Code gründlich prüft und gute Prompts und sauberes Kontext-Management nutzt, zum Beispiel mit Beispielcode oder einem agent.md-Leitfaden, lässt sich das gut kontrollieren.
    • Dieses Problem ist eigentlich auch bei menschlichen Entwicklern ein klassisches Thema der Softwarearchitektur.
      Wenn eine Codebasis wächst, verschlechtert enge Kopplung (tight coupling) zwischen Modulen die Leistungsfähigkeit.
      Die Lösung ist das Prinzip: „Programmiere gegen Schnittstellen, nicht gegen Implementierungen.“
      Wenn man die Grenzen der einzelnen Module klar definiert, nur die nötigen Teile über Schnittstellen freigibt und diese in separate Dateien auslagert, sodass Claude oder Kollegen nur diese Schnittstellen verwenden, reicht das aus.
      Dadurch reduziert sich der Kontext, und Claude arbeitet besser.
      Wenn das Projekt noch größer wird, kann es irgendwann zu viele Schnittstellen geben; dann muss man in noch größere Einheiten aufteilen oder den Änderungsumfang stärker begrenzen.
    • Inzwischen gibt es ein ganzes Spektrum, von Vibe Coding über Copilot-Stil, Design-Unterstützung bis hin zu vollständig manuellem Coden.
      Mittlerweile ist das Niveau erreicht, auf dem man diese Ansätze auch in ziemlich großen Projekten mischen kann.
    • Im Moment ist es gut für kleine Projekte geeignet, aber am Ende kommt wohl eine Zeit, in der jede Software auf diese Weise geschrieben wird.
    • Das erinnert mich an das „7000rpm“-Zitat von Ken Miles. Ich frage mich, ab welcher Größenordnung diese Grenzen auftauchen.

  • Der Satz „Es brauchte keine bessere App, sondern ein System, das Unvollkommenheit aushält“ ist mir besonders hängen geblieben.
    Der Schreibstil, in dem Claude nicht die Ideen geliefert, sondern die Umsetzung übernommen hat und ich für den Geschmack zuständig war, gefiel mir.

    • Für mich wirkt dieser Stil aber stärker so, als wäre er von einer AI geschrieben, als von einem Menschen.
      In E-Mails sieht man heute oft Sätze wie: „Wir haben das Rad nicht neu erfunden. Wir sind das Rad.“
    • Auf mich wirkte dieser Stil eher wie ein Blogpost eines Anfängers.
      Dass keine großen Worte benutzt werden und die gleichen Satzstrukturen wiederkehren, wirkte eher wie eine menschliche Gewohnheit.
      AI mischt Satzmuster normalerweise eher zufällig durch; hier bleibt das Muster eher konsistent.
      Es fühlt sich nach jemandem an, dessen editorisches Gespür noch nicht ganz ausgereift ist und der absichtlich stilvoll schreiben will.
      Mich würde interessieren, ob andere darin wirklich diesen AI-Geruch wahrgenommen haben.
    • Das sehe ich ähnlich, aber diesmal hatte es für mich seltsamerweise weniger AI-Anmutung.
      Auf LinkedIn gibt es so einen Stil allerdings inzwischen so oft, dass ich gestern irgendwann die Fassung verloren und selbst einen Post dazu geschrieben habe.
      Vermutlich beeinflusst eine subtile Mischung aus Wertigkeitsgefühl und Stimmung die AI-Erkennung.
    • Der Satz „So viel hat gereicht“ ist mir im Kopf geblieben.

  • Ich habe noch kein großes erfolgreiches Projekt gesehen, das mit Vibe Coding entstanden ist.
    Meist sind es kleine Programme, die es in den Trainingsdaten ohnehin schon gab.
    Wenn es wirklich revolutionär ist, würde ich gern sehen, wie damit ein neuer Kompressionsalgorithmus oder eine optimale Lösung für das Traveling-Salesman-Problem entwickelt wird.

    • Aber muss das überhaupt sein? Von einem Hammer erwartet man auch nicht mehr, als Nägel einzuschlagen.
      AI-Coding-Tools sollten sich auf die Bereiche konzentrieren, in denen sie stark sind.
      Ich baue mit solchen Tools oft kleine Automatisierungsprogramme für Unternehmen.
      Dadurch kann ich Dinge tun, die früher unmöglich waren, und meine Produktivität hat sich verzehnfacht.
    • Stimmt, aber die meiste Software existiert bereits.
      Wie im Artikel Perfect Software beschrieben, ist die perfekte App für jemanden genau die, die zu dessen Geschmack und Zweck passt.
      Dank LLMs kann man solche individuell angepasste perfekte Software jetzt leicht bauen.
    • Ich habe mit LLM-Agenten zwei Rust/C++-Wettbewerbe angeführt.
      Wettbewerb 1, Wettbewerb 2
      Mein Ergebnis hat andere Teilnehmer dazu gebracht, ihre Lösungen weiter zu verbessern.
    • Der Großteil des Codings ist repetitiv und steckt ohnehin schon in den Trainingsdaten.
      Wenn AI diese langweiligen Aufgaben entfernt, können sich Menschen auf kreative Arbeit konzentrieren.
    • Diese Kritik ist etwas unerquicklich. Im Moment ist das eine Zeit des Entdeckens und Lernens.
      Solches Vibe Coding, das kleine Probleme löst, ist eine deutlich sinnvollere Nutzung der Zeit.

  • Ich habe vor ein paar Tagen mit derselben Idee auch eine Bücherregal-App mit Claude gebaut.
    nindalf.com/books
    Seitdem lese ich mehr, und Highlights sowie Notizen lassen sich viel bequemer ansehen.
    Claudes UI-Vorschläge waren viel besser als das, was ich selbst gebaut hätte, und auch das Backend war fast gleichwertig.
    Nur manchmal bestand Claude auf seltsamer Validierungslogik; wenn ich sie selbst korrigierte, gab es sofort zu: „Sie haben recht!“ Solche Fälle waren aber selten.

    • Cool. Importierst du die Highlights und Notizen aus Kindle?
      Ich habe auch eine ähnliche Bücherregal-App gebaut, aber für die Verwaltung von Hörbuch-Notizen habe ich noch keine gute Lösung gefunden.
    • Ich baue gerade auch etwas Ähnliches. Claude trifft oft seltsame Entscheidungen, aber mit strikter Steuerung und Worktrees bleibt es trotzdem schnell.
      Deine Version ist ebenfalls interessant.
    • Könntest du den Code vielleicht veröffentlichen? Ich würde auch gern eine App für mein jährliches Leseprotokoll bauen.

  • Ich habe etwas Ähnliches versucht, aber bei mir war es eher ein Claude-Fehlschlag.
    Auf andrewblinn.com wollte ich die Bücherregal-Bilder anklickbar machen.
    Aber Claude hat häufig Goodreads-Links falsch erzeugt und ungültige IDs angehängt.
    Auch die Erkennung der Buchrücken war ungenau, also habe ich es am Ende manuell in Figma gemacht.
    Die von Claude vorgeschlagene Automatisierung war zu langsam und zu teuer.

  • Ich habe jedes Jahr eine statische Bücherregal-Seite als HTML gebaut, auf der die gelesenen Bücher aufgeführt sind.
    Früher habe ich sogar darüber geschrieben, wie ich Delicious Library nachbauen wollte.

    • Ich erinnere mich auch an die App. Das war eine schöne Erinnerung an die frühen Mac-Jahre.
      Man brauchte sie nicht unbedingt, aber allein das Organisieren von Büchern hat Spaß gemacht.
    • Daran hatte ich komplett nicht mehr gedacht, aber die Ästhetik von Delicious Library passt wirklich perfekt zu solchen Apps.

  • Ich stimme der Aussage zu: „460 Bücher sind kein Skalierungsproblem. Zu wissen, wann man funktionierenden Code löschen sollte, kann AI einem nicht abnehmen.“
    Ich habe auch eine App mit Daten zu 900 Bewertungen und 550 Büchern gebaut, und Infinite Scroll oder komplexe Suche will ich erst einbauen, wenn der Browser an seine Grenzen kommt.
    Im Moment reicht „Auf der Seite suchen“ völlig aus.

  • Mir gefiel der Satz: „90 % Genauigkeit reichen aus.“
    Selbst wenn ein LLM neue Fehler erzeugt, gibt es auf der Welt ohnehin viele fehlertolerante Systeme.
    Diese Haltung könnte selbst Menschen mit einer anti-AI-Haltung weiterhelfen.

    • Stimme zu. In Gesprächen mit LLMs kommen manchmal lustige Ergebnisse heraus, aber wenn 90 % nützlich sind, ist das meiner Meinung nach schon besser als eine Google-Suche.

  • Ich habe auf moviesonthe.computer auch eine App zum Protokollieren meiner gesehenen Filme per Vibe Coding gebaut.
    Mit einer klaren Idee wie „mein eigener Letterboxd-Klon“ kommt man schnell voran.
    Diese Fähigkeit, personalisierte Apps zu bauen, ist enorm mächtig.
    Allerdings sind die aktuellen Tools für Nicht-Entwickler noch nicht gut darin, die Denkweise selbst zu vermitteln.

    • Ich wollte auch schon eine App für Filmprotokolle bauen, aber Letterboxd hat mir nie richtig gefallen.
      Wie du sagst, können Menschen mit Programmierhintergrund solche Projekte leichter gut prompten.

  • Ganz ehrlich: Die Usability von dem, was diese Person gebaut hat, ist miserabel.
    Für die Person selbst mag es sich wie ein Erfolg anfühlen, aber in Wirklichkeit ist es eher ein Spielzeug zur Unterhaltung als ein Produktivitätswerkzeug.
    Trotzdem kann man aus solchen Versuchen etwas lernen.

    • Bei „moo point“ musste ich an den Witz denken, dass es so bedeutungslos ist wie die Meinung einer Kuh.
      Aber bei einem persönlichen Tool kann der Spaß selbst das Ziel sein.
      Ich habe als Kind auch aus Spaß in BASIC programmiert. Produktiv war das nicht, aber es hatte trotzdem seinen Wert.