Driftwatch V3 veröffentlicht: KI-gestütztes Tool zur Überwachung von Codebasen

Driftwatch V3 Build abgeschlossen

Driftwatch V3 wurde fertiggestellt und in ein öffentliches Repository auf bubbuilds.com hochgeladen. Der Build dauerte 5-6 Tage statt der erwarteten 1-2 Tage, umfasste etwa 9.000 Codezeilen und kostete rund 160 US-Dollar an API-Guthaben plus ein Claude Pro-Konto.

Was ist neu in V3

• Verfolgt, welche Markdown-Dateien zu groß sind und Gefahr laufen, stillschweigend gekürzt zu werden
• Markiert widersprüchliche Anweisungen über Dateien hinweg
• Kostenverfolgung mit Empfehlungen, welche Dateien Aufmerksamkeit benötigen
• Integrierter Markdown-Editor zum direkten Beheben von Problemen im Browser
• Snapshot-Export/Import zur Verfolgung von Änderungen zwischen Scans
• Einige Funktionen entfernt, die sich nicht bewährt haben
• Immer noch komplett im Browser, nichts wird auf einem Server gespeichert

Wichtige Erkenntnisse aus dem Build

Kosten & Delegation: Dass Opus konsequent dachte, Aufgaben selbst zu erledigen sei schneller und billiger als zu delegieren, war der größte Kostentreiber. Alle QA-Schritte bis nach dem vollständigen Build zu sammeln und Korrekturen auf einmal zu geben, erwies sich als kostengünstiger als nach jedem Sprint anzuhalten.

Spezifikationen & Prompts: Ein strukturiertes Spezifikationsblatt vor jedem Sprint war der größte Kostensenker. Der Entwickler baute ein "Prompt Clarifier" Claude-Projekt, das unübersichtliche Prompts in detaillierte Markdown-Spezifikationen für Bub umwandelt. Dass Bub die vollständige Spezifikation liest und vor dem Bau Fragen stellt, sparte verschwendete Tokens im Vergleich zum bloßen Senden von Anweisungen.

Kontextverdichtung: Verdichtung und Kontextüberlastung sind die größten Hindernisse, um Bub mehr Autonomie zu geben. Sprint-Zusammenfassungen im Spezifikationsvorlage halfen, den Kontext wiederherzustellen, und wichtige Anweisungen werden jetzt in lokalen Markdown-Dateien platziert, auf die Bub verweisen kann, anstatt sie in den Chat einzufügen.

QA & Testing: QA-Schritte bis nach allen Sprints zu sammeln und dann alles auf einmal zurückzugeben, war effizienter für Zeit und Kosten als Überprüfung/Korrekturen nach jedem Meilenstein.

Webseitendesign: Mobile-First-Design muss von Anfang an in den Spezifikationen enthalten sein – Nachrüstung verursachte viel Hin und Her, wo kleine Änderungen neue Probleme schufen.

Workflow: Der Entwickler benötigt eine bessere Organisation für Claude-Chats und plant, testgetriebene Entwicklung zu studieren. Telegram-Chatverlauf zu exportieren und durch Opus laufen zu lassen, hilft zu identifizieren, wo Gespräche mit Bub scheitern, und Claudes Recherchemodus funktioniert gut zum Faktencheck technischer Spezifikationen.

Was kommt als Nächstes

Der Entwickler plant, Driftwatch auf Bub anzuwenden, um seine Architektur zu überprüfen und ihm ein komplettes Redesign zu geben, um Delegations- und andere Probleme aus diesem Build zu beheben. Nächste Schritte umfassen den Aufbau eines zweiten Gehirns für den Entwickler, Bub und Claude zum Teilen, das unauffindbare Claude Pro-Chats organisiert, und das Testen von Architektur-Upgrades während des Baus von Driftwatch Pro-Funktionen.