Dominik und Openspider: Interview zu AI Coding

Gerade am Release 1.0, geplant für den 17. November. OpenSpider deckt den Funktionsumfang von Screaming Frog ab, ist aber Open Source (Apache-2.0) und von Anfang an auch für Agenten gebaut: CLI, MCP-Server und Desktop-App greifen auf denselben Rust-Kern zu.

Entwickelt wird als Clean-Room. Die Agenten bekommen nur unsere eigene Spezifikation mit prüfbaren Akzeptanzkriterien. Das Referenzprodukt sehen sie nie, und jeder Test trägt die Spec-ID, die er abdeckt.

Bei der Performance ist AI Coding stark, wenn man die Agenten erst messen lässt. Zwei Beispiele aus den letzten Tagen:

Schreibpfad: Ein Agent hat den Writer auf einen Kanal mit größeren SQLite-Transaktionen umgebaut. Große Crawls brauchen dadurch rund 30 % weniger Zeit. Link-Score: Die Analyse läuft jetzt im Speicher statt per SQL. Für eine Million URLs sank sie von 113 auf 23 Sekunden.

Ohne harte Budgets wird es aber schnell beliebig. Das Detailfenster im Live-Crawl hat ein Budget von 150 ms und liegt jetzt im Median bei 34 ms, gemessen auf echter Hardware im Release-Build.

Modelle mit getrennten Rollen:

Claude Opus 5.5: Orchestrierung und Bau OpenAI Codex mit GPT-6.1 Sol: Bau-Pakete in Schleifen auf einem Hetzner-Server Claude Sonnet 5.5: unabhängige Abnahmetests, nur aus der Spec, ohne den Verlauf des Bauers Fable 5.1: Review vor jedem Merge

Die Trennung zahlt sich aus. Der unabhängige Testagent fand eine Beschädigung von Crawl-Dateien, die seit dem ersten Meilenstein im Code steckte: Ein File::open/close im Besitzerprozess hob die POSIX-Sperren von SQLite auf.

Harness:

Claude Code als Zentrale mit vielen parallelen Sub-Agents, jeder in einem eigenen Git-Worktree gebaut und getestet wird auf dem Server, die CI-Matrix für macOS, Windows und Linux läuft in GitHub Actions, inklusive Signatur und Notarisierung 17 Rust-Crates, rund 2.500 Commits in vier Wochen

Techstack:

Rust mit Tokio SQLite im WAL-Modus, eine Datei pro Crawl Chromium per CDP fürs Rendering Tauri v2 mit React und TypeScript Playwright in Chromium und WebKit

MCP ist bei uns Produktfunktion: OpenSpider bringt einen eigenen MCP-Server mit, den man per Klick an Claude Desktop, Claude Code, Codex oder Cursor anbindet.

Rund 14,5 Milliarden Tokens in knapp vier Wochen, gezählt aus den Sitzungsprotokollen, Stand 9. November. Davon gehen gut 11 Milliarden auf Claude (Opus 5.5, Sonnet 5.5, Fable 5.1) und gut 3 Milliarden auf Codex mit GPT-6.1 Sol. Die Zahl klingt riesig, aber rund 94 % davon sind Cache-Lesezugriffe. Die Agenten lesen immer wieder denselben Kontext: Spec, Code, Berichte. Wirklich erzeugt haben die Modelle „nur“ rund 50 Millionen Output-Tokens. Daraus sind gut 2.500 Commits und rund 380.000 Zeilen Rust entstanden.

Mein eigener Aufwand liegt bei 50% meiner freien Zeit. Ich schreibe kaum Code selbst. Ich entscheide, was gebaut wird, kläre Fragen aus der Spec, teste auf echter Hardware und gebe Releases frei und schau auch ab und zu über den Code rüber. Die Agenten laufen dafür fast rund um die Uhr, auch nachts und am Wochenende.

Bei den Kosten arbeite ich mit Abos (Claude und Codex 200,- Euro Pakete) statt mit der API. Dazu kommen ein Build-Server bei Hetzner für rund 300 € im Monat, der Apple-Entwickler-Account und die Code-Signatur für Windows über Azure. Abgerechnet über die API wäre das ein Vielfaches gewesen. Das ist für mich der eigentliche Hebel: Mit Abo und Cache lohnt sich ein Agenten-Setup dieser Größe auch für ein Open-Source-Projekt.

Software entwickle ich seit über 25 Jahren, die meiste Zeit fürs Web. Ins AI Coding bin ich relativ früh eingestiegen, mit Cursor vor mindestens anderthalb Jahren. Ich war unter den ersten 10.000 Nutzern. Danach habe ich GitHub Copilot ausprobiert und war auch bei Claude Code früh dabei, damals noch nur als CLI.

Zum Web kam dann meine erste Apple-App, und mit OpenSpider baue ich jetzt zum ersten Mal eine komplette Desktop-Anwendung. Das ist bewusst so gewählt: Ich will sehen, wie weit KI in ganz unterschiedlichen Tech-Stacks trägt, vom Web über Mobile bis zum Desktop. Und OpenSpider ist mit Rust-Kern, signierten Installern für macOS und Windows und einem eigenen MCP-Server bisher der härteste Test dafür.

„Hardware entwickeln“ kann vieles heißen. Ich habe selbst schon kleine Roboter gebaut und mit KI angepasst, zum Beispiel eine Media-Box für meine Tochter. Da verschwimmen Hardware, Software und KI ohnehin. Eigene Chips von Agenten sehe ich dagegen noch nicht, das liegt aber auch außerhalb meiner Kompetenz. Grundsätzlich sehe ich keinen großen Unterschied zu Software: Auch dort entwickeln sich Modelle bereits selbst weiter. Bei Hardware wird es eben physisch, und es braucht spezielle Maschinen.

Bei OpenSpider sehe ich die Grenzen heute weniger beim Code als an vier Stellen rundherum:

Was Agenten nicht sehen, können sie nicht prüfen. Eine signierte Desktop-App auf echtem macOS und Windows lässt sich nur begrenzt automatisieren. Den Update-Klick in der Release-App unter Windows kann bis heute kein Agent fernsteuern. Dafür setze ich mich selbst an zwei Rechner. „Grün“ heißt oft nur „grün auf Linux“. Unsere Agenten bauen auf einem Linux-Server. Ein Test, der unter Linux läuft, kann unter Windows an einem Dateinamen mit Doppelpunkt scheitern. Das sieht man erst in der Plattform-Matrix der CI. Agenten machen Tests leise weicher. Bittet man einen Agenten, wackelige Zeit-Tests robust zu machen, hebt er gern Grenzen an oder senkt die Last, bis nichts mehr geprüft wird. Deshalb prüfen bei uns andere Modelle gegen, und wir bauen absichtlich Fehler ein, um zu sehen, ob ein Test noch anschlägt. Der Engpass ist die Orchestrierung, nicht das Schreiben. Mit vielen Agenten parallel wurden Plattenplatz, Laufzeiten der CI und widersprüchliche Aufträge zum Problem. Code schreiben sie schneller, als man ihn sauber integrieren kann.

Entscheiden, priorisieren und auf echter Hardware abnehmen bleibt für mich Menschenarbeit.