8 Jahre Sehnsucht, 3 Monate bis zur Fertigstellung – wie KI die Formel für Side Projects verändert hat

• Ein hochwertiges Entwicklungswerkzeug für SQLite, das lange gefehlt hatte, wurde mit Hilfe von KI in kurzer Zeit fertiggestellt
• Der fehlende offizielle Grammatik-Standard und die komplexe C-Codebasis machten den Bau des Parsers zur größten Hürde
• Mit KI-Coding-Agenten wie Claude Code wurde die erste Implementierung zwar schnell vorangetrieben, wegen Spaghetti-Code erfolgte jedoch eine Neuschreibung auf Rust-Basis
• KI zeigte große Effizienz bei Codegenerierung, Refactoring, Lernunterstützung und UX-Verbesserung, brachte aber auch Nebenwirkungen wie verzögerte Designentscheidungen, Entfremdung von der Codebasis und Abhängigkeitsverhalten mit sich
• Letztlich ist KI nur ein Werkzeug zur Beschleunigung der Implementierung; für Design und die Richtung der Software müssen Menschen die Verantwortung tragen

---

Drei Monate Aufbau eines SQLite-Entwicklungswerkzeugs mit KI

• Schon lange bestand der Wunsch nach einem hochwertigen Entwicklungswerkzeug für SQLite, doch bestehende Open-Source-Tools waren in Bezug auf Zuverlässigkeit, Geschwindigkeit und Flexibilität unzureichend
  • Während der Wartung von PerfettoSQL gab es Bedarf an Funktionen wie Formatter, Linter und Editor-Erweiterungen, aber kein passendes Tool
  • Ein neues Tool als persönliches Projekt zu bauen, wurde über Jahre aufgeschoben, weil Schwierigkeit und der Aufwand wiederkehrender Arbeit zu hoch waren

Die Schwierigkeiten des Projekts

• SQLite hat keine offizielle Grammatik-Spezifikation und keine stabile Parser-API
  • Intern wird kein Parse-Tree erzeugt, daher musste die Parser-Logik direkt aus dem Quellcode extrahiert werden
  • Mehr als 400 Grammatikregeln mussten einzeln abgebildet werden; das Schreiben von Tests und das Debugging waren äußerst repetitive und ermüdende Arbeiten
• Die C-Codebasis von SQLite ist komplex und dicht, was das Verständnis erschwert
  • Schon das Erfassen von API und Implementierung der virtuellen Tabellen kostete mehrere Tage, so verschachtelt war die Struktur

Der Entwicklungsprozess mit KI

• Seit Ende 2025 wurden KI-Coding-Agenten wie Claude Code ernsthaft eingesetzt
  • Anfangs wurden Entwurf und Implementierung größtenteils an die KI delegiert und im Stil von „vibe-coding“ gearbeitet
  • Das Ergebnis funktionierte zwar, aber die Codebasis wurde zu einem Spaghetti-Geflecht und war auf Dauer nicht wartbar
• Danach wurde alles in Rust neu geschrieben und die Struktur neu aufgebaut
  • Statt C wurde Rust verwendet, um höherliegende Komponenten wie Validator und Language Server leichter entwickeln zu können
  • Die KI wurde auf die Rolle eines „verstärkten Autocomplete-Werkzeugs“ begrenzt, während Entwurf, Review und Tests direkt gesteuert wurden
  • Es wurde ein Scaffolding zur Validierung von KI-Ergebnissen aufgebaut, darunter Linting, Verifikation und Testautomatisierung

Was KI möglich gemacht hat

• Trägheit überwinden

  • KI zerlegte die Arbeit in konkrete Problemblöcke und machte so den Einstieg leichter
  • Statt „Ich muss SQLite-Parsing verstehen“ lautete der Ansatz „Ich prüfe den von der KI vorgeschlagenen Weg“, was die Umsetzung beschleunigte

• Geschwindigkeit bei Codegenerierung und Refactoring

  • Bei klaren Anforderungen schrieb die KI schnell standardisierten und konsistenten Code
  • Bei nicht standardisierten Entwürfen, etwa der Parser-Struktur, war sie eher hinderlich, sodass direkt selbst geschrieben werden musste
  • Nach groß angelegter Codegenerierung war kontinuierliches Refactoring unverzichtbar, um die Qualität zu halten

• Rolle als Lernhilfe

  • KI erklärte neue Konzepte wie den Wadler-Lindig-Formatting-Algorithmus in Echtzeit
  • Auch in weniger vertrauten Bereichen wie Rust oder VS Code-Erweiterungen war ein schneller Einstieg möglich
  • Wenn der Projektkontext verloren ging, ließ er sich mit Fragen wie „Erklär mir diese Komponente“ sofort wiederherstellen

• Höherer Reifegrad

  • Bei Zusatzfunktionen wie Editor-Erweiterung, Python-Bindings, WASM-Playground und Dokumentationsseite sanken die Entwicklungskosten
  • Durch den geringeren Implementierungsaufwand konnte stärker auf UX-Verbesserungen fokussiert werden, etwa bei Fehlermeldungen und CLI-Design

Nebenwirkungen des KI-Einsatzes

• Suchtpotenzial

  • Eine slotmaschinenartige Belohnungsstruktur, bei der man immer wieder „noch einen Prompt“ versucht
  • Je müder man ist, desto schlechter werden die Prompts, was die Ergebnisse verschlechtert und einen Teufelskreis auslöst

• Entfremdung von der Codebasis

  • Je mehr Code die KI erzeugt, desto stärker geht das Gefühl für die Detailstruktur verloren
  • Geht der Kontext verloren, werden auch Gespräche mit der KI länger und ineffizienter
  • Als Gegenmaßnahme wurde die Gewohnheit eingeführt, den generierten Code sofort selbst zu lesen und zu prüfen, wo man ihn anders geschrieben hätte

• Verzögerte Designentscheidungen und Erosion

  • Weil Refactoring leicht fällt, entsteht die Tendenz, zentrale Designentscheidungen aufzuschieben
  • Selbst mit vielen Tests lassen sich grundlegende Designfehler nur schwer verdecken; am Ende wird doch eine komplette Neuschreibung nötig

• Fehlendes Zeitgefühl

  • KI versteht den zeitlichen Kontext und die Entwicklungsgeschichte von Code nicht
  • Dadurch werden frühere Fehler wiederholt oder bereits gelöste Probleme unnötig erneut untersucht
  • Dokumentation kann helfen, aber die Designabsicht vollständig festzuhalten ist schwierig

Die Relativität des KI-Einsatzes

• In Bereichen, die man tief versteht, ist KI hervorragend und ermöglicht schnelles Review und Iteration
  • Beispiel: Das Generieren von Parser-Regeln ist effizient, weil es eine klare richtige Antwort gibt
• In teilweise bekannten Bereichen ist sie als Lernwerkzeug nützlich, verlangt aber kontinuierliche Aufmerksamkeit
  • Beispiel: das Erlernen von Formatter-Algorithmen
• In der Phase, in der noch unklar ist, was überhaupt gebaut werden soll, ist sie eher schädlich
  • Beispiel: In der Architekturphase entstehen unproduktive Schleifen
• Bei verifizierbaren Problemen wie erfolgreichem Kompilieren und bestandenen Tests ist KI stark,
  bei Fragen ohne eindeutige Antwort wie Design oder API-Qualität jedoch schwach

Fazit

• Dass ein acht Jahre lang geplantes SQLite-Tool in nur drei Monaten realisiert werden konnte, war der KI zu verdanken
  • Der Prozess war jedoch keine simple Erfolgsgeschichte, sondern brachte Grenzen und Kosten der KI-Abhängigkeit mit sich
• KI ist ein Beschleuniger für die Implementierung, aber kein Ersatz für Design
  • Technische Fragen beantwortet sie präzise, aber Geschichte, Geschmack und Nutzergefühl fehlen ihr
• Die eigentliche Lehre ist: Auch wenn man mit KI schneller gegen Wände läuft,
  müssen Menschen die Richtung des Designs und die „Seele der Software“ verantworten
• Was künftig gebraucht wird, sind geteilte Projektbeispiele auf einem Niveau, das echten Nutzern und langfristiger Wartung standhält
  • Nicht bloß Experimente, sondern die Ansammlung realistischer und nachhaltiger Erfahrungen mit KI-gestützter Zusammenarbeit in der Entwicklung

[GN⁺]

Hacker-News-Kommentare

• Es ist erfrischend, eine ausgewogene Sichtweise auf AI-Coding zu sehen
  Das ist wahrscheinlich eine Erfahrung, mit der sich die meisten ernsthaften Entwickler identifizieren können — anfangs ist man beeindruckt, wie gut AI Code schreibt, aber später stellt man fest, dass die Codebase zu einem Spaghetti-Code-Chaos geworden ist
  Manche machen nicht einmal Code-Reviews und verkünden lautstark: „Manuelles Coden ist jetzt vorbei“, während andere pauschal behaupten: „AI-Coding ist nutzlos“
  Aber die Realität liegt irgendwo dazwischen. AI kann ein großer Produktivitätsbeschleuniger sein, muss aber richtig in den Workflow integriert werden, und der Mensch muss weiter eingebunden bleiben

  • Ich selbst nutze seit den letzten 3 Monaten Claude als mein primäres Coding-Interface
    Es begann als Prototyp, entwickelte sich aber schnell zu einem echten Service. Danach hatte ich beim Refactoring zu kämpfen, um unnötigen Code wieder zu entfernen
    Trotzdem gäbe es das heutige Produkt ohne dieses schnelle Prototyping nicht. Claude war beim Aufräumen des Codes nützlich, fast wie eine Kettensäge
    Kürzlich habe ich per pre-commit-Hook einen Type-Checker hinzugefügt und 90 Fehler in nur 2 Stunden behoben.
    AI-Coding ist erstaunlich, aber bei Produktionscode sind menschliches Review und Urteilsvermögen weiterhin unverzichtbar
  • Mir gefiel dieser Beitrag besonders wegen seiner ausgewogenen Perspektive
    Allerdings ist dieses Beispiel ein persönliches Greenfield-Projekt, daher lässt es sich nicht ohne Weiteres auf normale Team-Entwicklung übertragen
    Trotzdem finde ich Spaghetti-Code in Ordnung, wenn man einen Prototyp mit der Annahme baut, dass er später verworfen wird.
    Das Problem war, dass der Autor irrtümlich glaubte, daraus ein echtes Produkt weiterentwickeln zu können.
    Aber gerade durch dieses Scheitern hat er vermutlich ein besseres Design gelernt
  • Eigentlich sind diese extremen Reaktionen wohl eine Phase, die jeder beim ersten Kontakt mit AI-Coding durchläuft
    Zuerst ist man begeistert, dann enttäuscht, und am Ende findet man ein Gleichgewicht.
    Es wirkt fast wie eine AI-Version des Kübler-Ross-Modells
  • Umgekehrt halte ich die Fixierung auf Codequalität im AI-Zeitalter für einen blinden Fleck
    Qualität ist natürlich wichtig, aber Codequalität an sich wird inzwischen weniger wichtig
    Es gibt immer mehr Code wie private Apps, die keine Wartung brauchen, und auch die Design-Fähigkeiten von AI verbessern sich schnell
    Letztlich verändert sich die „Wahrheit über AI-Coding“ ständig weiter, und dieser Trend wird nicht aufhören
  • Ich denke, es gibt zwei Gründe, warum solche realistischen Beiträge selten sind
    Erstens genießen die meisten Entwickler stillschweigend 2–50 % Produktivitätssteigerung und sehen keinen Grund, darüber viel Aufhebens zu machen
    Zweitens ist echtes AI-Coding langweilig und visuell wenig spektakulär.
    Am Ende ist ein LLM nur ein Werkzeug, mit dem man sich Boilerplate nicht auswendig merken muss; das Wesen des Codens bleibt gleich

• Ich hatte bei der AI-gestützten Testgenerierung dasselbe Problem
  Mehr Tests geben einem zwar ein Gefühl der Sicherheit, aber in Wirklichkeit decken sie Edge Cases nicht ab
  Besonders beim Refactoring von Legacy-Code ohne Tests prüfen von AI erzeugte Tests nur, ob etwas funktioniert, garantieren aber keine Konsistenz des Verhaltens
  In React-Apps war dieses Problem besonders stark. Deshalb denke ich gerade darüber nach, BDD + spezifikationsbasierte Entwicklung mit AI zu kombinieren

  • Gute Tests zu schreiben fühlt sich 10-mal schwieriger an als das eigentliche Coden
    Bei Unit-Tests ist kreatives Mock-Design entscheidend, bei Integrationstests die Datenmanipulation und bei e2e-Tests die Stabilität der Selektoren
    Diese Art kreativer Entscheidungen kann AI bislang nur schwer nachvollziehen
  • Man sollte sich nicht von Coverage-Zahlen täuschen lassen
    Selbst bei 97 % Coverage gab es im logischen Eingaberaum noch viele Lücken.
    Kürzlich habe ich klassische Methoden wie equivalence partitioning mit AI-Agenten automatisiert und auf 60 Modelle angewendet
  • Ich empfehle einen Ansatz, bei dem man mit TLA+ das Systemverhalten spezifiziert und Code und Spezifikation miteinander verbindet
    Entscheidend ist, möglichst viele pure Funktionen zu isolieren und das Input-Output-Mapping vollständig zu testen

• Langfristig liegt der wahre Wert von AI meiner Meinung nach in ihrer Rolle als Werkzeug zur Verstärkung des Verständnisses
  Zum Beispiel könnte sie Regeln in komplexem C-Code analysieren und die Struktur dokumentieren
  Wenn eine solche Wissensextraktion möglich wird, lassen sich API-Dokumentation, Regel-Mapping, Bug-Analyse und sogar Architektur-Optimierung automatisieren
  Letztlich wird die Fähigkeit, Kontext zu strukturieren, wichtiger werden als das Erzeugen von Code

  • Die Art, wie Menschen AI nutzen, geht stark auseinander
    ① Der allwissende-Orakel-Typ, der nur Anforderungen hinschmeißt und eine ganze App generieren lässt
    ② Der Assistenzwerkzeug-Typ, der in der IDE Zeile für Zeile mitprüft
    Wenn man einen nachhaltigen Service bauen will, ist ② deutlich realistischer

• Die Aussage „Architektur entsteht, wenn lokale Teile miteinander interagieren“ ist mir besonders hängen geblieben
  AI ist stark bei lokaler Ausführung, aber schwach in mehrdeutigen Designphasen
  Eigentlich gilt das auch für menschliche Entwickler. Design ist schließlich eine fortlaufende Reihe von Trade-offs ohne eindeutige richtige Antwort

  • Ich bin auch schon durch lange Gespräche mit AI zu Design-Entscheidungen gekommen
    Besonders bei ClickHouse-SQL-Design hat sie mir sehr geholfen
    Dank des von der AI vorgeschlagenen template-basierten SQL-Include-Ansatzes konnte ich Redundanz verringern und auch die Performance verbessern
    Vielleicht gab es diesen Ansatz schon vorher, aber ohne AI hätte ich ihn wohl kaum gefunden

• Dieser Beitrag wirkt glaubwürdig, weil darin 250 Stunden echte Arbeit stecken
  Für mich ist ein Projekt dieser Größenordnung ein realistisches Modell für AI-unterstützte Systemprogrammierung

• Die Formulierung „AI-Coding ist wie ein Spielautomaten“ trifft es perfekt
  Ich habe in der Firma ebenfalls unbegrenzten Zugang zu AI-Agenten, und wenn man einmal anfängt mit „nur noch ein Prompt“,
  sind plötzlich 12 Stunden vergangen. Die Sogwirkung ist enorm

• Im Moment ist vermutlich die schwierigste Phase des AI-Codings
  Dinge, die vor 6 Monaten noch unvorstellbar waren, sind heute möglich
  Ich arbeite an Projekten in mehreren Sprachen, und AI erzeugt Code inzwischen so schnell,
  dass jetzt die Review-Geschwindigkeit zum Bottleneck wird
  Sobald eine gewisse Menge an Tests durchläuft, fragt man sich: „Ist das gut genug?“
  Ich schreibe in Prompts Qualitätsmerkmale wie SOLID-Prinzipien, Kopplung und Kohäsion explizit hinein
  Ich frage die AI nach Refactoring-Ideen, und wenn etwas gut aussieht, sage ich einfach: „Okay, ausführen“
  Letztlich ist die Kunst des Prompt-Designs entscheidend
  Aber ich denke, schon bald wird AI solche Qualitäts-Geländer standardmäßig selbst übernehmen

  • Es gab auch die Frage, warum man Projekte in mehreren Sprachen macht
    Die Sprache selbst ist zwar nicht der Performance-Bottleneck, aber das Experimentieren mit neuen Sprachen hilft beim Lernen

• Das erinnert an Fred Brooks’ Philosophie „baue eins, um es wegzuwerfen“
  AI ist optimal dafür, diese erste Version, also den Throwaway, schnell zu bauen
  Sofort Produktionsqualität zu erwarten ist ein törichter Ansatz
  Der richtige Weg ist: schnell bauen, lernen und danach refactoren
  Ich kann auch nachvollziehen, dass Prompts bei Müdigkeit unklarer werden und dadurch die Ergebnisse schlechter ausfallen

  • Interessant ist allerdings auch, dass Brooks seine Position später eher in Richtung iterative refinement geändert hat

• Es hat mich überrascht, dass der SQL-Parser von SQLite nicht mit lemon generiert wurde
  Als ich pikchr nach Go portiert habe, habe ich zuerst lemon übertragen, aber SQLite erzeugt nicht einmal einen Parse-Tree
  Wenn man die lemon-Dokumentation liest, wirkt das wie ein Fall von unzureichender Problemdefinition in der Designphase

• Ich stimme dem Fazit dieses Beitrags ebenfalls voll zu
  Es ist ein gutes Beispiel, das die Realität von AI-Coding ehrlich und ohne Übertreibung zeigt