Jan-Stefan und CTX: Interview zu AI Coding

Gerade an zwei Dingen. Erstens am Einstieg: Dokumentation, ein Erklärvideo und ein Setup, das auch ohne Agenten funktioniert. Bisher war ctx vor allem mein eigenes Werkzeug, inzwischen kommen Pull Requests und Feedback von außen, und daran merkt man schnell, wo die Doku nur in meinem Kopf existiert. Zweitens am Hintergrundprozess, den ich Dream nenne. Er verknüpft Wissensblöcke und markiert Veraltetes. Aktuell lernt er, ältere Urteile neu zu bewerten, sobald ein neuer Block ihnen widerspricht, statt bis zum nächsten regulären Dream-Durchlauf zu warten.

AI Coding ist dabei nicht Hilfsmittel, sondern die Arbeitsweise. ctx wird mit ctx gebaut: Die Agenten, die den Code schreiben, lesen vor jeder Sitzung die Architekturentscheidungen, Fehler und Korrekturen der vorherigen aus dem Speicher und schreiben ihre eigenen zurück. Ohne dieses Gedächtnis fängt jede Sitzung bei null an. Genau das Problem wollte ich maschinenübergreifend lösen, und das Projekt ist sein eigener härtester Testfall.

Der Harness ist Claude Code in tmux und Hermes-Desktop. Das stärkste Modell orchestriert, plant und prüft, eine Stufe darunter bauen Agenten klar umrissene Arbeitspakete, jeder in einem eigenen Git-Worktree. Sub-Agenten sind bei mir der Normalfall: In einer gemessenen Dreitagesstrecke liefen 200 davon, und rund 90 Prozent aller Tool-Aufrufe fanden in ihnen statt. Wiederkehrende Abläufe stecken in Skills, etwa Planung mit eingebauten Gegenprüfungen, Entscheidungsvorlagen als klickbare Seite mit technischen Details und Diagrammen, Code-Prüfung mit Beweisstufe je Befund und ein Abschlussritual am Ende einer Sitzung.

ctx selbst ist ein einzelnes Go-Programm mit PostgreSQL 18, pgvector für die Vektorsuche und TimescaleDB für Zeitreihen. Angesprochen wird es über MCP, eine Kommandozeile oder HTTP; der MCP-Server ist Teil von ctx, und über ihn teilen sich mehrere Claude-Instanzen und andere Harnesse denselben Wissensstand. Im Betrieb arbeitet in meinem Setup kein Cloud-Modell: Bewertung, Verknüpfung und Antwortsynthese laufen auf einem lokalen Qwen mit 27 Milliarden Parametern auf einer DGX Spark, die Embeddings ebenfalls lokal. Der Speicher selbst kommt damit ohne Cloud-Dienst aus und bietet auf der Hardware genug Luft für parallele Nutzung.

Andere Nutzer verwenden stattdessen Claude Sonnet mit niedriger Thinking-Stufe oder DeepSeek. Das Backend-Management ist absichtlich anpassbar gehalten.

Eine Zahl nur für ctx gibt es nicht, weil Claude Code seine Protokolle nur 30 Tage aufbewahrt. Seit Juni 2026 sammle ich den Verbrauch aber mit tokscale, über alle Werkzeuge und Projekte hinweg. Stand heute stehen dort gut 117 Milliarden Tokens aus knapp 11.000 Sitzungen an 220 aktiven Tagen. Davon wurden 112 Milliarden aus dem Cache gelesen und nur 590 Millionen erzeugt. Dieses Verhältnis zeigt, wie agentisches Arbeiten tatsächlich aussieht: Geschrieben wird wenig, gelesen wird ständig. Auf ctx entfiel in den letzten 30 Tagen knapp die Hälfte davon; die Monate vor Mai 2026 sind nur lückenhaft erfasst.

Zu den Listenpreisen der APIs entspräche das rund 100.000 US-Dollar. Meine explizit dafür verwendeten Claude Ultra Subscriptions haben in der Zeit ungefähr 3.000 Euro gekostet.

Was sich über die ganze Strecke belegen lässt, steht im Repository: seit Ende März 2026 gut 2.100 Commits an 117 aktiven Tagen, 234 Releases, knapp 600.000 Zeilen Go, davon fast zwei Drittel Tests. Angefangen hat es Ende 2025 als Key-Value-Ablage über den MCP-Knoten von n8n. Der gab jede Eingabe komplett wieder aus und redete zu viel, also wurden daraus erst Webhooks und dann ein eigenes Programm. Die Neufassung in Go war eine Sache von einer Stunde.

Stunden zähle ich anders als früher. In jener Dreitagesstrecke entstanden 44 fertige Arbeitspakete, und ich habe dafür 52 Nachrichten getippt. Knapp die Hälfte davon war automatische Routine, um eine volle Sitzung an eine frische zu übergeben; nur acht waren Entscheidungen. Meine Zeit steckt in Planung und Entscheidungen, nicht im Schreiben. Laut meiner Partnerin bin ich aber sehr beschäftigt im Vergleich zu früher. Es macht halt einfach Spaß, kreative Freiheiten auszureizen und zu erkunden.

Ich programmiere seit über 20 Jahren, autodidaktisch, und seit mehr als zwölf Jahren beruflich im Enterprise- und Consulting-Umfeld, die meiste Zeit zwischen Softwareentwicklung und Infrastruktur. Eigene Server betreibe ich seit 2006.

2017 befasste ich mich aktiv mit PyTorch zur Bildgenerierung und zum Stiltransfer.

2021 beteiligte ich mich als Entwickler an einem ML-Projekt zur Erkennung problematischer Crypto-Token, um Anleger vor Betrug zu schützen.

Mit dem Release der kleinen DeepSeek-R1-Modelle im Januar 2025 ist mein Fokus komplett auf die lokale Inferenz und ihre Möglichkeiten gewechselt. Mein erstes eigenes Harness habe ich nur wenige Monate später gebaut und schnell festgestellt, dass es einiges an Brute Force kostet, saubere Prompts für einzelne Arbeitsschritte in einem Harness zu definieren.

Vollständig agentisch arbeite ich seit Ende 2025, und ctx ist aus genau dieser Umstellung entstanden, da wir damals noch nicht eine Million Tokens Kontext pro Sitzung hatten: Nach wenigen Wochen war klar, dass nicht das Schreiben von Code der Engpass ist, sondern dass jede neue Sitzung die Entscheidungen der letzten vergessen hat. Seitdem ist ctx das Gedächtnis hinter jeder Sitzung, über mehrere Rechner und Claude-Konten hinweg. Heute liegen dort in meinem persönlichen Tenant gut 10.000 Blöcke.

Schaltpläne, Layouts und Firmware entwerfen Agenten heute schon. Eigenständig entwickeln heißt für mich aber, dass jemand prüft, ob es funktioniert, und da liegt die Grenze. Software gibt einem Agenten in Sekunden Rückmeldung: Der Test läuft durch oder nicht. Hardware antwortet in Wochen und kostet bei jedem Versuch Geld. Solange Simulation diese Rückmeldung nicht ersetzt, bleibt ein Mensch mit Messgerät in der Schleife. Da diverse kompetente Hersteller Board-Reviews durchführen und Rückfragen stellen, bevor es teuer wird, sinkt die Schwelle, und das Ganze wird realistischer.

Die größten Grenzen sehe ich ohnehin nicht bei der Intelligenz der Modelle, sondern drumherum. Erstens Gedächtnis: Agenten sind zustandslos, und was beim Zusammenfassen von einer Sitzung zur nächsten wandert, wird nicht nur weniger, sondern verschiebt sich. Aus einer Beobachtung wird eine Empfehlung, aus der Empfehlung eine Regel. Zweitens Selbstauskunft: Ein Modell klingt bei einer falschen Antwort genauso sicher wie bei einer richtigen. Es zu ermahnen ändert nichts. Was hilft, sind Prüfungen von außen, also Tests, Messungen und ein zweiter Agent, der gegen die Quelle liest. Drittens Vollzugsmeldungen: „Fertig“ wird schneller gesagt als geprüft. Ein großer Teil meiner erfolgreichen Arbeit an und mit ctx besteht darin, für diese drei Punkte Strukturen zu bauen, die nicht auf gutem Willen beruhen.