0906 | Agenten im Einsatz: Debuggen, Lernen und das Leben daneben

Lena Vogel: Hallo und willkommen zurück! Ich bin Lena Vogel.

Felix Hartmann: Und ich Felix Hartmann. Schön, dass du wieder dabei bist. Wir haben heute wieder einen Haufen neuer Produkte durchgeschaut, die in den letzten 24 Stunden gestartet sind, und wir haben gemerkt: Es zieht sich ein roter Faden durch fast alles. Es geht darum, dass KI-Agenten längst nicht mehr nur Spielzeuge sind, sondern echten Arbeit machen – und jetzt fangen wir an, Werkzeuge zu bauen, die sie kontrollieren, korrigieren und im besten Fall besser machen.

Lena Vogel: Genau. Und das spannt einen ganz weiten Bogen: von der Produktion über sauberen Code bis hin zu Apps, die ehrliche Erinnerungen festhalten. Fangen wir ganz vorn an, bei dem Punkt, wo es am meisten wehtut: wenn es nachts um zwei in der Produktion brennt.

Felix Hartmann: Das Produkt heißt HyperProbe, und das Problem, das es beschreibt, kenne ich – naja, kenne ich aus den Schilderungen – eigentlich jeder, der mal On-Call war. Coding-Agenten schreiben heute einen Großteil des Codes, der in Produktion geht. Wenn dann nachts etwas kaputtgeht, kann das niemand erklären. Die Fehler replizieren nicht lokal, sie kommen durch Tests und Code-Review durch, und der Agent steht dann da und rät aus Logs und Traces, die den entscheidenden Zustand nie aufgezeichnet haben.

Lena Vogel: Und was macht man klassisch? Man fügt eine Console-Log-Zeile hinzu, deployt neu, und wartet. Währenddessen blutet das Problem weiter und verliert Nutzer. HyperProbe will genau diesen Loop killen.

Felix Hartmann: Die Idee: Über ein MCP, also die Schnittstelle, über die Agenten wie Claude Code, Codex oder Cursor mit Tools sprechen, kann der Agent sogenannte Probes in einen laufenden Dienst setzen. Das sind read-only, also lesende, virtuelle Breakpoints an einer konkreten Zeile im Code. Wenn dann echter Traffic an dieser Stelle vorbeikommt, feuert der Breakpoint und fängt die exakten Variablenwerte ein – die Werte, die eben nie in den Logs waren. Danach verschwindet der Probe wieder.

Lena Vogel: Wichtig ist den Machern zufolge: Der Probe blockiert nichts. Der Service pausiert nicht, die Requests laufen mit voller Geschwindigkeit durch, und die Nutzer merken nichts. Angeblich liegt der Overhead bei weniger als einem Prozent bei 3000 Requests pro Sekunde. Und der Agent kann nur lesen – er kann keinen Speicher schreiben und keinen Code ausführen.

Felix Hartmann: Die Versprechen sind beachtlich. Der Hersteller gibt an, dass die Zeit zur Ursachenfindung von drei bis vier Stunden auf unter zehn Minuten sinkt, dass keine Redeploys pro Incident mehr nötig sind und dass auch keine zwei bis drei Senior-Engineers mehr in die Untersuchung reingezogen werden müssen. Ein Nutzer habe laut der Vorstellung ein Payments-Problem in 9,5 Minuten gelöst, das vorher vier Stunden gedauert hatte.

Lena Vogel: Und ich will betonen: Das sind Angaben des Herstellers, keine von uns verifizierten Ergebnisse. Es gibt auf der Seite zwei Zitate von Leuten bei CheQ Digital und Housing.com, die von schneller Reproduktion und einer gelösten Race-Condition berichten – aber das sind Testimonial-Aussagen.

Felix Hartmann: Wie funktioniert es im Ablauf? Die Seite beschreibt einen echten Incident durch: Um 2:47 Uhr nachts feuert ein PagerDuty-Alarm, die Fehlerrate beim Order-Status liegt bei 23 Prozent, 847 Fehler in zehn Minuten, aber keine Exception in den Logs. HyperProbe liest die verteilten Traces und folgt der Kette: Der Order-Service ist gesund, aber der Payment-Service darunter liefert 404. Zahlungen existieren im Payment-Gateway, aber nicht im System.

Felix Hartmann: Irgendwo upstream ist ein Schreibvorgang still gescheitert.

Lena Vogel: Dann setzt das System einen Probe auf den Webhook-Handler, Zeile 78, in webhooks.ts. Kein Redeploy, der Service läuft weiter. Um 2:50 Uhr feuert der Snapshot: Das Gateway sendet den Status PENDING, und der Code hat dafür gar keinen Fall. Das ist so ein klassischer Fall von Contract Drift – ein Drittanbieter schickt einen neuen Wert, und dein Parser kennt ihn nicht.

Felix Hartmann: Und das ist der Punkt, wo HyperProbe sagt: Wir decken genau die Fehler ab, die dich nie anpagem. Stille Fehler, die 200 zurückgeben mit falschem Body. Exceptions, deren Ursache weit weg vom Stacktrace liegt. Ausnahmen, die geschluckt werden, ohne dass ein Alert feuert. Race Conditions, bei denen man den Thread-Zustand im exakten Überlappungsmoment bräuchte. Und Business-Metriken, die sinken, ohne dass irgendetwas im Stack eine Exception wirft.

Lena Vogel: Die Sicherheitsfragen sind aber real, und die Community hat sie auch gestellt. Eine Stimme sagt sinngemäß: Read-only heißt nicht automatisch sicher. Der Probe hebt trotzdem live Variablenwerte – und die erste Frage jedes Security-Teams ist, was passiert, wenn ein Agent einen Frame anprobt, der eine Kreditkartennummer oder ein Session-Token enthält, und ob dieser Wert im Storage landet.

Felix Hartmann: Die Antwort der Hersteller darauf: Probes laufen in deiner eigenen Infrastruktur, selbst gehostet oder in einer privaten VPC. Nichts verlässt deine Umgebung. PII wird laut Angabe vor der Erfassung auf Agent-Seite redigiert, das Security-Team definiert, was beobachtbar sein darf. Jeder Probe landet in einem unveränderlichen Audit-Trail, und der Zugang ist approval-gated, bis du dem System vertraust.

Lena Vogel: Eine weitere Community-Stimme fragt aber: Wo ist der menschliche Approval-Schritt, wenn ein Agent um 2 Uhr nachts selbstentscheidend an einen Produktionsdienst rangeht? Das ist eine offene Frage, die im Quellmaterial nicht endgültig beantwortet wird. Und eine dritte Stimme sagt: "Zero overhead" macht in dem Satz viel Arbeit – ich hätte gern eine P99-Zahl daneben. Was gut ankommt, ist die 9,5-Minuten-Zahl, die gilt als das eigentlich überzeugende Detail.

Felix Hartmann: Für wen ist das also? Für Backend-Teams, die schnell shippen und ihre Agenten in Produktion haben. Hintergrund der Macher: Sie haben Jahre bei OYO und LimeTray Produktion gebaut und sagen, der Kontext, den Ingenieure im Kopf tragen, sei kritisch zuverlässigem Betrieb gewesen – und genau dieser Kontext schrumpfe mit Coding-Agenten rapide.

Lena Vogel: Und jetzt kommt der zweite Teil der Geschichte. Der Agent hat das Problem gefunden, super. Aber lernt er daraus auch etwas für das nächste Mal? Genau darum geht es bei Reflexio.

Felix Hartmann: Reflexio ist eine Lernplattform für KI-Agenten. Der Kernbefund der Macher: Agenten werden mit jedem Einsatz nicht besser. Selbst mit Memory – ein Agent, der gestern eine Aufgabe vermasselt hat, macht heute denselben Fehler, bei einem anderen Nutzer, weil nichts das verbindet, was in Produktion passiert ist, mit dem Verhalten beim nächsten Mal.

Lena Vogel: Die Gründer, Yi war vorher Tech Lead bei Meta und hat an der University of Washington unterrichtet, sagen, sie haben selbst erlebt, wie schmerzhaft es ist, diesen Loop manuell zu schließen: Traces lesen, Fehler finden, Prompts umschreiben – eine nie endende Arbeit. Reflexio beobachtet deshalb automatisch die Live-Traces des Agenten, lernt aus Erfolgen, Fehlern und Nutzerkorrekturen, und optimiert das Verhalten kontinuierlich.

Felix Hartmann: Ein schönes konkretes Beispiel von der Seite: Ein Nutzer schreibt: "Auf meiner Karte ist eine Abbuchung von 49,99 Dollar, die ich nicht kenne." Ohne Reflexio antwortet der Agent: "Ich habe die 49,99 erstattet." Zehn Minuten später kommt der Nutzer zurück: "Da war auch noch eine für 9,99." Mit Reflexio findet der Agent beide Abbuchungen auf einmal und fragt, ob beide erstattet werden sollen. Der Nutzer ist nach einer Konversation fertig, nicht nach zwei.

Lena Vogel: Und das System hat daraus zwei Learnings abgeleitet: Erstens, durchsuche das gesamte Fenster der letzten Abbuchungen, bevor du eine einzelne auflöst. Zweitens, zeige alles Unbekannte in einer Nachricht und frag, ob zusammen erstattet wird.

Felix Hartmann: Die Zahlen, die die Macher nennen – und das sind Fallstudienangaben, nicht unabhängig geprüft: 36 Prozent niedrigere Task-Failurerate, 57 Prozent weniger Tokenverbrauch, und verbesserte Antwortqualität in 47 Prozent der Interaktionen mit vernachlässigbaren Regressionen.

Lena Vogel: Was mich an Reflexio wirklich überzeugt – und auch in der Community Anklang findet – ist das Kontrollmodell. Jedes Learning ist sichtbar, rückverfolgbar zu den Beweisen dahinter, und umkehrbar. Du kannst es umschreiben, genehmigen, ablehnen oder löschen. Ein abgelehntes Learning wird sofort nicht mehr verwendet. Wenn du willst, dass der Agent nur nutzt, was du abgezeichnet hast, ist das eine Einstellung.

Felix Hartmann: Interessant ist auch das Alterungsmodell. Learnings werden ersetzt, wenn neue Konversationen ihnen widersprechen. Das Beispiel von der Seite: Im März gelernt, "Rückerstattungen innerhalb von 30 Tagen erlaubt". Im Juni wird die Refund-Window auf 14 Tage geändert – das März-Learning wird ersetzt und nicht mehr benutzt. Der Agent bleibt also nicht auf dem Stand hängen, an dem du ihn eingerichtet hast.

Lena Vogel: Es ist im Grunde ein Publish-Read-Loop: Dein Agent publiziert, was passiert ist, Reflexio extrahiert daraus, was anders laufen soll, und beim nächsten Lauf liest der Agent es zurück. Nichts wird retrainiert, keine Modellfeinjustierung. Die Integration läuft über SDKs mit Python, REST und CLI, und für Coding-Agenten gibt es einen Skill, den du Claude Code, Codex oder Cursor einfach geben kannst, der die Integration in dein Repo einbaut.

Felix Hartmann: Die kritischen Fragen aus der Community sind aber berechtigt. Eine Stimme fragt: Was, wenn die Korrektur eines Nutzers einfach schlechter Rat ist? Wenn jemand den Agenten fälschlich in die Irre führt und daraus eine allgemeine Regel wird, die dann für alle Nutzer gilt – wie fängt man das ab, bevor es sich ausbreitet? Gibt es einen Confidence-Schwellenwert oder muss ein Mensch jedes generalisierte Learning freigeben?

Lena Vogel: Genau da bleibt Offenheit. Die Quelle beantwortet nicht, wie Reflexio mit widersprüchlichem Feedback verschiedener Nutzer umgeht oder wie ein falsches Learning früh erkannt wird. Auf der Website steht immerhin, dass gelernte Verhalten vor dem Verlassen gegen eine Kontrollantwort bewertet werden – "validated before it counts" – und dass du definierst, was Erfolg bedeutet. Aber die konkrete Mechanik der Generalisierung ist nicht offen gelegt.

Felix Hartmann: Und noch eine feine Beobachtung aus der Community, die ich gut fand: "Ein Teil von mir denkt, es ist nur ein Loop mit Markdown-Dateien" – naja, so hat's zumindest einer formuliert, der seine eigenen Agenten so lernen lässt. Das zeigt halt, dass manche Leute das Problem selbst schon mit Bordmitteln angehen.

Lena Vogel: Bevor wir das Thema verlassen, noch ein zweiter Blick auf die größere Landschaft. Denn es gibt auch da oben Werkzeuge, die sich mit der Frage beschäftigen, wie man überhaupt hunderte Modelle nutzt, ohne in Account- und Kosten-Chaos zu versinken. Das Stichwort ist Experiential Labs.

Felix Hartmann: Experiential ist ein quelloffenes KI-Gateway, geschrieben in Rust, das sich zwischen deine Anwendung und die Modell-Anbieter schiebt. Ein Schlüssel für über 1000 Modelle – hosted Anbieter, eigene Provider-Keys, oder Modelle, die lokal oder in deiner eigenen Cloud laufen. Und wichtig: null Aufschlag auf die gerouteten Tokens, du zahlst den Preis des Anbieters. Das Gateway selbst ist frei und open source, verdient wird an hosted Inference und einem Pro-Plan.

Lena Vogel: Was es über ein reines Gateway hinaus hebt, ist die Intelligence-Schicht. Weil jeder Request ein einheitliches Trace-Format teilt, kann die Plattform Cache-Misses und verschwendete Tokens aufspüren, bessere Modelle empfehlen, Arbeit identifizieren, die asynchron oder gebatcht laufen sollte – und spezialisierte Modelle trainieren, die dir gehören.

Felix Hartmann: Zwei Case Studies von der Seite, wieder als Herstellerangaben: Ein Computer-Use-Agent, wo ein 9B-Modell aus einem Teacher-Modell destilliert wurde, das 1000 Tasks auf Mac-VMs machte, dann in geschlossener Simulation bewertet – 50 Prozent mehr Tasks erledigt als das untrainierte 9B, siebenmal schneller als Opus 4.8, bei 97 Prozent geringeren Kosten.

Felix Hartmann: Und eine Claims-Research-Studie: Ein 4B-Modell, mit GRPO auf dem öffentlichen AVeriTeC-Benchmark trainiert, auf 500 zurückgehaltene Claims angewendet – 9,4-mal schneller, bei 90 Prozent niedrigeren Kosten als Haiku 4.5.

Lena Vogel: Und es gibt ein Org-Dashboard: Ausgaben nach Agent, Person, Modell oder Tag, Keys mit Limits, die einmal vom Admin gesetzt werden und auf jedem Request durchgesetzt werden – also Schlüssel, die bei Erreichen des Limits pausieren. Sowie Log-Einträge mit Route, Fallback und Preis, den der Anbieter tatsächlich berechnet hat.

Felix Hartmann: Die Community hat einen Vergleich gezogen, den ich nicht bestätigen kann, aber ich zitier sie trotzdem als Stimme: Es sei wie "OpenRouter ohne die 5-Prozent-Aufschlag". Da muss man halt aufpassen, was man glaubt. Eine andere Stimme fragt, wie Experiential mit sensiblen Prompts und Traffic-Daten umgeht, wenn es aus der Nutzung lernt. Das ist eine echte, offene Frage.

Lena Vogel: Und die Macher geben selbst an, dass die Plattform seit einer Woche auf Hacker News ist, über 1000 Entwickler und 50 Firmen genutzt wurde und über 10 Milliarden Token täglich verarbeitet – wieder: Herstellerangaben, die du so oder so lesen kannst. Und zum Launch sind einige Modelle angeblich kostenlos bis Ende der Woche.

Felix Hartmann: Okay, fassen wir den ersten Block zusammen: HyperProbe gibt Agenten Augen in die Produktion, Reflexio gibt ihnen ein Gedächtnis mit Kontrollschaltern, Experiential gibt euch ein zentrales Routing mit Kostenkontrolle. Das sind drei Antworten auf dieselbe Grundfrage: Wie machen wir Agenten verantwortbar, wenn sie echte Arbeit in echten Systemen erledigen?

Lena Vogel: Und genau da schließt das nächste Thema an. Der Agent hat jetzt Werkzeuge, um Produktion zu debuggen und aus Fehlern zu lernen. Aber was ist mit dem Code, den er eigentlich schreibt? Denn Coding-Agenten sind, wie der Macher eines kleinen Plugins formuliert, "vielleicht ein bisschen zu gut" im Code schreiben. Es fehlt ihnen eine Stopp-Regel.

Felix Hartmann: Das Produkt heißt Ponytail – der Name kommt daher, dass das Logo ein gelangweilter Senior Developer mit Ponytail und Brille ist. Die Prämisse: Dein Agent greift nach fünfzig Zeilen, wo eine gereicht hätte. Das Beispiel auf der Seite: Statt einer 48-zeiligen CacheManager-Klasse mit eigener Speicherung und Lock einfach ein einzeiliger @lru_cache-Dekorator. Gleiches Verhalten, 48 Zeilen weniger, und keine Bugs in Code, der gar nicht existiert.

Lena Vogel: Die Stopp-Leiter geht in sieben Stufen. Schritt eins: Muss das überhaupt existieren? Spekulativer Bedarf – überspringen. Das ist YAGNI, "You Ain't Gonna Need It". Schritt zwei: Gibt es das schon im Codebase? Hilfsfunktion, Utility, bestehendes Pattern wiederverwenden. Schritt drei: Tut es die Standardbibliothek? Schritt vier: Deckt ein natives Plattform-Feature es ab – zum Beispiel ein input type=date statt eine Picker-Bibliothek.

Lena Vogel: Schritt fünf: Löst eine bereits installierte Abhängigkeit das Problem? Dann nutze sie, füge keine neue hinzu. Schritt sechs: Geht es in einer Zeile? Dann eine Zeile. Erst Schritt sieben: der minimale Code, der funktioniert.

Felix Hartmann: Die Benchmarks auf der Seite – Mediane über 12 Feature-Tasks auf einem FastAPI-Plus-React-Repo – geben an: 54 Prozent weniger Code, 22 Prozent weniger Tokens, 20 Prozent niedrigere Kosten, 27 Prozent schneller, bei angeblich 100 Prozent erhaltener Sicherheit. Also: Validierung, Fehlerbehandlung, Security und Accessibility würden nie weggelassen. Auch das sind Herstellerangaben.

Lena Vogel: Die Installation ist zwei Zeilen für Claude Code, und es gibt laut README Unterstützung für über 14 Agenten – Codex, Copilot CLI, Gemini CLI, OpenCode, Cursor, Windsurf, Cline, Kiro, Zed und mehr. Du kannst die Intensität steuern: lite baut, was du gefragt hast, und benennt die lazyere Alternative in einer Zeile. Full erzwingt die Leiter.

Lena Vogel: Und ultra – da gibts sogar ein "/ponytail ultra", "für wenn dein Codebase dir persönlich Unrecht getan hat", mit einem kleinen Emoji-Ausrufezeichen –, da wird YAGNI zum Extremismus, der Agent shipped den One-Liner und stellt den Rest der Anforderung selbst in Frage.

Felix Hartmann: Die Community liebt die Idee. Eine Stimme: "So eine einfache, offensichtlich benötigte Regel, ich bin überrascht, dass es die nicht schon überall gibt." Ein anderer sagt, er benutzt es mit Claude und es hält den Agenten fokussiert, schlank und weniger zum Overbuilden neigend. Aber es gibt auch eine kluge kritische Frage: Was ist mit False Positives?

Felix Hartmann: Wenn eine bestehende Stdlib-Funktion fast passt, aber nicht exakt – andere Edge-Case-Behandlung, leicht anderer Rückgabetyp – zwingt Ponytail den Agenten dann, das falsche Tool zu verbiegen, nur um neue Zeilen zu vermeiden? Oder weiß es, dass "Wiederverwendung" einen subtileren Bug einführen kann als frischer Code?

Lena Vogel: Das ist eine offene Frage, die im Quellmaterial nicht beantwortet wird. Und eine andere Stimme fragt, ob es eigentlich Zeit spart – die Annahme: Wenn der Agent etwas Fertiges findet, ist man netto schneller, weil die Suche nach wiederverwendbarem Code kürzer ist als das Generieren von Grund auf. Auch das ist unbeantwortet.

Felix Hartmann: Vom Minimalismus beim Code zum Minimalismus bei den Werkzeugen. Denn wenn man Agenten fragt, Feature-Flags zu einem Projekt hinzuzufügen, passiert oft Folgendes – und das ist die Ursprungsgeschichte von dif.sh: Der Maker David hat Claude Code gefragt, Flags hinzuzufügen. Der Agent kam an den Punkt, wo die meisten Flag-Tools einen Account, einen API-Key und so weiter wollen – und hat einfach aufgegeben und stattdessen `process.env.SHOW_NEW_CHECKOUT` in den Code geschrieben.

Lena Vogel: Das ist ein sehr ehrliches Detail, finde ich. Und dif.sh nimmt sich dem an, indem es Feature-Flags als Markdown-Dateien direkt ins Repo legt. Eine .md-Datei pro Flag oder A/B-Test, im Repo neben dem Code. Drin steht: Was macht es, warum existiert es, was habt ihr entschieden. Reviewed wird es in einem PR wie jeder andere Code-Change auch. Installiert wird es mit einem Befehl, kein Account, kein API-Key.

Felix Hartmann: Technisch läuft es so: `dif init` richtet einen dif/-Ordner ein, erzeugt eine config.yaml und fügt Anweisungen zu agents.md hinzu. Bei jedem Build generiert dif eine context.json, die der Coding-Agent beim Session-Start liest – wie eine Art CLAUDE.md für Experimente. Der Agent weiß dann, welche Flags aktiv sind, welche entfernt wurden und was schon probiert wurde. Neu angelegte Experimente lesen zusätzlich den Surface-Log, also das Protokoll, was eine bestimmte Oberfläche bisher gelernt hat.

Lena Vogel: Schön ist auch, dass A/B-Tests, Holdouts und gestaffelte Rollouts alle im selben Dateiformat leben. Verschiedenes Frontmatter, gleiche Form. Das reduziert die Konzepte, die man lernen muss.

Felix Hartmann: Ein paar echte Features stecken drin: dif build prüft, ob zwei Live-Tests auf denselben Nutzer treffen würden – der Build schlägt dann fehl, nicht die Produktion. Exclusion groups verhindern per Frontmatter-Zeile, dass ein Nutzer in zwei Experimente gleichzeitig gelockt wird. dif.track schickt Events entweder an deine Analytics – Segment, Amplitude, eigenes Warehouse – oder an dif Cloud, das den Lift für dich berechnet.

Felix Hartmann: Und dif conclude archiviert ein abgeschlossenes Experiment und schreibt den Entscheidungsblock.

Lena Vogel: Git bleibt die Quelle der Wahrheit, PR-Review ist der Freigabe-Flow. Das Cloud-Stück ist optional, für den Blick über Projekte hinweg und dafür, dass dif Änderungen vorschlagen kann – aber auch die kommen über PRs zurück. Das selbst-gehostete ist frei.

Felix Hartmann: Und jetzt die kritische Gegenposition, und die ist wirklich gut. Eine Community-Stimme sagt: Du hast nach der kritischen Version gefragt, also hier. Flags in Git heißt: Um einen zu flippen, braucht es einen Commit, ein Review und ein Deploy. Der Grund, warum Teams für einen Flag-Service zahlen, ist der Kill-Switch um 2 Uhr nachts – ohne all das. Für agentenorientierte Flags sei das ein fairer Trade. Für einen graduellen Rollout oder einen Incident sei es das nicht.

Felix Hartmann: Und: Markdown behebt das Problem toter Flags auch nicht, weil nichts reviewt wird, wenn sich nichts ändert – der Flag, den seit vier Monaten niemand angefasst hat, verzweigt trotzdem in Produktion.

Lena Vogel: Das ist eine ehrliche Abwägung, die man stehen lassen muss. Die Maker selbst bitten im Launch-Beitrag explizit um kritische Rückmeldungen: "Würdet ihr das nutzen? Wenn nicht, was würde euch stoppen? Und was nutzt ihr heute, womit wir besser sein müssten?" Das ist eine gute Haltung.

Felix Hartmann: Weitere Fragen aus der Community: Was passiert, wenn zwei Agenten in parallelen Branchen dieselbe Markdown-Flag-Datei anfassen – ein normaler Git-Merge-Konflikt, oder hilft dif da? Und: Bleibt die Dateistruktur überschaubar, wenn das Repo wächst? Beides offen.

Lena Vogel: Und das dritte Werkzeug in diesem Block schließt fast nahtlos an. Wenn Agenten Code schreiben, der kleiner und erklärbarer sein soll – Ponytail –, und Flags als Reviewbares im Repo liegen – dif.sh –, dann fehlt noch die Stelle, wo du eigentlich hinschaust und das Review machst. Genau dafür ist GitWarren.

Felix Hartmann: Der Macher beschreibt sich selbst: 15 Jahre professionell programmiert, zunehmend mit KI neben sich, vom Markt getrieben, mehr Output zu liefern. Er springt täglich zwischen fünf bis sieben gleichzeitigen KI-Sessions. Und die Engstelle sei der Code-Review-Prozess – genauer, der Ort, wo er die Reviews macht.

Lena Vogel: Sein Problem: Er arbeitet in Umgebungen, wo es keine Option ist, einen Ein-Schuss-KI-Output direkt ins Firmen-GitHub zu kippen. Bis etwas dort ankommt, muss es im Grunde bereit für Kollegen-Review sein. Also jonglierte er zwischen Terminals und IDEs und kopierte seine Kommentare über Änderungen seiner Agenten hin und her. Sein Fazit: "Ich brauche mein lokales GitHub – die GitHub-Review-Erfahrung, aber bevor ein Commit passiert ist, hier auf meinem Computer."

Felix Hartmann: Genau das ist GitWarren: eine lokale, PR-artige Review-App, die direkt mit deinem Working Tree arbeitet. Sie liest committed, staged, unstaged und untracked Änderungen – auch Dateien, die der Agent erstellt, aber nie zu Git hinzugefügt hat. Du kannst Inline-Kommentare machen, die Arbeit in echte Reviews organisieren, ohne irgendwas zu pushen. Die Kommentare leben in Threads an konkreten Code-Änderungen, damit man über Zeit verfolgen kann, was passiert.

Lena Vogel: Die Agenten sind nicht nur Objekt des Reviews, sondern Teilnehmer. GitWarren shipped einen MCP-Server über stdio – du zeigst Claude Code, Codex oder jeden anderen MCP-Client darauf, und der Agent bekommt dieselben 17 Tools, die die App selbst benutzt: Review öffnen, die Diskussion lesen, in einem Thread antworten, auf einer Zeile kommentieren, einen Thread auflösen.

Lena Vogel: Du kannst einen Agenten also bitten, seinen eigenen Diff zu erklären oder die Frage zu beantworten, die du auf Zeile 40 hinterlassen hast – und die Antwort bleibt im Review.

Felix Hartmann: Schön gelöst ist die Attribuierung: Maschinengeschriebene Kommentare sind immer als solche markiert, und der Toolname kommt aus dem MCP-Handshake, nicht davon, was das Modell sich heute für einen Namen ausdenkt. Zwei Agenten bekommen eigene IDs, damit man sie im Thread auseinanderhalten kann, ohne dass sie kooperieren müssen.

Lena Vogel: Und lokal heißt lokal: Kein Account, kein Login, nichts verlässt die Maschine. Reviews und Kommentare leben in einer einzigen SQLite-Datei. Lösch sie, und GitWarren ist weg. Die Repos bleiben unberührt. Jeder Branch-Name, Commit und Diff wird direkt von Git gelesen, wenn er angezeigt wird – nichts kann im Hintergrund veralten. Kostenlos und quelloffen unter GPL-3.0, macOS, Windows und Linux, Windows-Binary ist laut Macher noch nicht signiert.

Felix Hartmann: Die Community-Fragen zeigen, wo die Grenzen liegen könnten. Eine Stimme nutzt getrennte Git-Worktrees pro Agent-Task statt mehrere Agenten im selben Working Tree, und fragt: Kann GitWarren über mehrere Worktrees desselben Repos hinweg reviewen, oder ist es pro Instanz auf einen Working Tree beschränkt? Wenn Letzteres: Ist das eine bewusste Design-Entscheidung oder einfach nicht der erste Use Case?

Lena Vogel: Und eine andere Stimme fragt nach dem Kollisionsfall: Wenn zwei von den fünf bis sieben parallelen Sessions dieselben Dateien im selben Working Tree anfassen – zeigt GitWarren dann nur einen flachen Diff, egal wer was geändert hat, oder kann es markieren, dass zwei Edits kurz davor sind, sich zu beißen, bevor man überhaupt zum Review kommt? Beides offen.

Lena Vogel: Aber die Grundidee, dass man unstaged und untracked Änderungen reviewed, bevor überhaupt ein Commit existiert – das fand eine Stimme "einen viel natürlicheren Workflow".

Felix Hartmann: Man sieht also ein Muster: HyperProbe für Produktion, Reflexio fürs Lernen, Ponytail für weniger Code, dif.sh für nachvollziehbare Flags, GitWarren für lokales Review. Die Agenten-Infrastruktur reift sichtbar.

Lena Vogel: Und jetzt machen wir einen bewussten Sprung – weg vom Code, hin zu Dingen, die man abends auf dem Sofa nutzt. Und komischerweise geht es da um genau dasselbe Thema: Unverfälschtheit. Erinnerungen, die man nicht nachträglich glättet.

Felix Hartmann: Die erste App heißt at8pm – und der Name ist das Konzept. Es ist ein Journal, bei dem jeder Eintrag, den du heute schreibst, zu einer von dir eingestellten Zeit sperrt – standardmäßig 8 Uhr abends. Wenn er sperrt, ist Schluss: kein Bearbeiten, kein Umschreiben der Geschichte, kein leises Polieren dessen, was du in dem Moment wirklich gefühlt hast.

Lena Vogel: Der Macher beschreibt die Motivation schön: Er wollte etwas bauen, das festhält, wie man sich in dem Moment tatsächlich gefühlt hat – nicht, wie man sich hinterher erinnert, sich gefühlt zu haben. Die meisten Journaling-Apps erlauben Bearbeiten, Umschreiben, Löschen. Das ist nützlich, aber es macht es zu leicht, unabsichtlich die eigene Geschichte umzuschreiben.

Felix Hartmann: Technisch: Die Einträge synchronisieren über dein privates iCloud-Konto, nie über einen First- oder Third-Party-Server. Der Entwickler gibt an, dass keine Daten gesammelt werden. Du kannst mit Rich Text schreiben – fett, kursiv, unterstrichen, durchgestrichen – oder eine Sprachnachricht aufnehmen, die als Waveform angezeigt wird. Und seit Version 1.4 gibt es Squopes – quadratische Video-Notizen, direkt im Eintrag aufgenommen, mit Kamerawechsel davor. Dazu Fotos, Standort, Stimmungen.

Lena Vogel: Für den Alltag als Habit gibt es eine Streak-Ansicht und einen Lock-Ring, der zeigt, wie viel Zeit noch bleibt, bevor der heutige Tag abschließt. Der Datenschutz kann noch eine Schraube höher gedreht werden: Face ID für die ganze App. Es gibt einen freien Tier mit bis zu zwei Einträgen pro Tag, und einen Pro-Plan.

Felix Hartmann: Und hier wird's interessant – eine kleine Widersprüchlichkeit, die man erwähnen muss: Neben dem harten Sperr-Konzept gibt es optional "Unlock Credits". Damit kann man einen gesperrten Eintrag für 24 Stunden wieder editierbar machen, gegen Kauf im App. Die Preise laut App Store: 1,99 Dollar für ein 3er-Pack, Pro zwischen 0,99 und 3,99 Dollar im Abo, oder 29,99 Dollar.

Felix Hartmann: Das ist optional und nicht nötig für den Kern – aber es zeigt, dass selbst bei einem Produkt namens "honest journal" das Rückgängigmachen ein Bedürfnis ist, das man einkalkulieren muss.

Lena Vogel: Aus der Community: Eine Stimme lobt genau das Locking – "dass es standardmäßig sperrt, statt dich zu verführen, später zu editieren, ist das ganze Produkt". Ein anderer fragt aber: Was passiert bei Zeitzonenwechsel auf Reisen? Folgt die Sperrzeit der lokalen Zeit des Handys, oder bleibt sie am ursprünglichen Zeitzone verankert? Und noch eine fragt nach Android. Beides offen. Die App ist iPhone-only, braucht iOS 26.2 oder neuer.

Felix Hartmann: Von der persönlichen Ehrlichkeit zur familiären Erinnerung. Das zweite Produkt heißt Retold, und die Hintergrundgeschichte ist berührend. Der Gründer Karl hat es gebaut, weil seine Oma vor ein paar Jahren gestorben ist und er noch eine Voicemail hatte, die sie seiner Schwester hinterlassen hatte, und witzige Clips davon, wie sie versuchte, Alexa zu benutzen.

Lena Vogel: Und er sagt: Ihre echte Stimme zu hören, das hat etwas bedeutet. Aber die Dateien fühlten sich nicht wie etwas an, zu dem die Familie natürlich zurückkehren würde – nur anonyme Audiodateien in einem Telefonordner. Also baute er Retold.

Felix Hartmann: Die Idee: Du nimmst eine Geschichte auf, oder importierst eine alte Sprachnachricht. Retold behält die echte Stimme und zeichnet parallel dazu eine handgezeichnete kleine Filmsequenz, die den Leuten, Orten und Details folgt, wie sie erwähnt werden – "wackelige Strichmännchen, der Hund, der Platscher", wie es auf der Seite heißt, synchron zur Stimme. Dazu gibt es eine lesbare Buchversion, und alles landet auf dem Familienregal, das alle anschauen können.

Lena Vogel: Der Ablauf ist bewusst simpel: Der Familie das Handy in die Hand drücken, ein großer roter Knopf, keine Formulare, kein Tippen – einfach die Geschichte, so wie sie sie immer erzählt. Auf der Seite stehen Beispiele: "Der Tag, an dem Oma in den Kanal fiel", erzählt von Opa, von Oma bestritten. "Wie wir uns trafen, 1963" – der Tanzsaal, der falsche Bus, das richtige Mädchen. "Noch eine Geschichte, Oma" – Gute-Nacht-Geschichte aus 400 Kilometern Entfernung.

Felix Hartmann: Die Preise: Bis zu fünf Geschichten kostenlos, dann ein Abo – jährlich 39,99 Pfund, etwa 77 Pence die Woche, oder monatlich 5,99 Pfund, jederzeit kündbar. Laut Website gehört dir alles für immer, auch wenn du aufhörst zu zahlen. Die App ist auf iPhone im Beta, Android ist in geschlossener Testphase.

Lena Vogel: Die kritische Frage aus der Community ist die, die man bei so einem Produkt wirklich stellen muss: Das Quellmaterial ist oft eine Aufnahme von jemandem, der nicht mehr zustimmen kann, wie es nachträglich verwendet wird – besonders bei alten Voicemails von Verstorbenen. Was ist die tatsächliche Datenpolitik? Wird das Audio verarbeitet und dann gelöscht, unbegrenzt auf einem Server behalten, oder für etwas anderes benutzt als für den einen Familienfilm?

Felix Hartmann: Diese Frage ist im Quellmaterial nicht beantwortet. Es ist ein legitimer Punkt, und ich denke, ein Produkt wie das hier steht und fällt mit der Antwort darauf. Was die Macher anbieten, ist eher emotional als technisch argumentiert – und das ist fair, aber die Datenschutzfrage bleibt offen.

Lena Vogel: Okay, letzter Block, und dann sind wir durch. Der Alltag. Vier kleine Werkzeuge, jedes löst genau eine Reibung – und wir nehmen sie in einem Rutsch, weil sie sich schön vergleichen lassen.

Felix Hartmann: Fangen wir mit Filme an. Queuebrick nennt sich selbst "die Letterboxd-Alternative". Der Macher Zachary beschreibt es als ein kleines Herzensprojekt: schnelles, elegantes Film-Tracking, ohne die Werbung, mit durchdachter User Experience. Du suchst einen Film, bewertest ihn, stellst ihn in die Queue, rankingst, was du als nächstes schaust. Und TV-Serien sind von Anfang an mit dabei.

Lena Vogel: Was richtig praktisch klingt: ein Catch-all-Import, mit dem du Filme und Serien von fast überall importieren kannst. Das ist der Punkt, an dem die Community genau hinschaut, und die Frage ist gut: Letterboxd benutzt eine 5-Sterne-Skala mit Halbsternen, IMDb eine 10-Punkte-Skala, manche Tracker nur Daumen hoch/runter.

Lena Vogel: Wenn man jahrelange Ratings aus so einem System importiert – werden die Skalen proportional konvertiert, sodass die relativen Rangfolgen erhalten bleiben, oder wird alles grob auf die eigene Skala gemappt und man sitzt da und bewertet alles neu?

Felix Hartmann: Diese Frage ist offen. Eine andere Stimme lobt aber schon das Grundkonzept: "Ich mag die Idee, zu ranken, was ich als Nächstes schaue, statt eine riesige Watchlist zu haben, die ich nie benutze." Und es gibt einen Vorschlag für die Zukunft: eine geteilte Queue für Paare oder Freunde, in der alle Filme hinzufügen und abstimmen können, was geschaut wird – "statt 30 Minuten darüber zu streiten, was wir schauen".

Lena Vogel: Vom Sofa ins Auto. Das zweite Werkzeug heißt CommuteBar und löst ein Problem, das der Macher sehr konkret beschreibt: Er wollte losfahren, sah, dass die Straßen frei waren, dachte, er käme früher heim. Fünfzehn Minuten später kam der Stau – aber erst, als er schon draußen war. Was ihm fehlte, war ein schneller Indikator in Sichtweite, direkt neben der Uhr – dem Ort, den er eh immer anschaute.

Felix Hartmann: CommuteBar ist also eine macOS-App, die Live-Pendelzeiten in die Menüleiste legt. Kein App-Wechsel, kein extra Maps-Fenster. Du speicherst mehrere Ziele – Büro, Schule, Gym – und kannst sie automatisch für wiederkehrende Fahrten wechseln lassen. Es gibt "Bald losfahren"- und "Jetzt losfahren"-Indikatoren, optionale Benachrichtigungen, Routenvergleich, Stau-Alarme, verschiedene Verkehrsmittel. Keine Kalender-Events nötig, einfach ein gespeichertes Ziel anwählen und überwachen.

Lena Vogel: Datenschutz: Der Standort bleibt laut Angabe auf deinem Mac, keine Accounts, keine Logins. macOS 14 oder neuer, und – das fanden einige in der Community erfrischend – eine Lifetime-Lizenz, kein Abo. Eine Stimme lobt genau das: "einfache Idee richtig gemacht, das sollte in der Menüleiste leben statt als eigene App, die man öffnen muss".

Felix Hartmann: Eine gute praktische Frage aus der Community: Was passiert an einem Tag mit einem Zwischenstopp – Kind zur Kita bringen, dann zur Arbeit? Zeigt die automatische Zielwechsel-Funktion dann einfach das nächste gespeicherte Ziel in der Sequenz, oder muss man manuell umschalten? Offen. Und jemand schreibt, er nutzt sonst Waze auf dem Handy, während er noch am Computer sitzt – genau diese Lücke füllt es.

Lena Vogel: Vom Auto zurück an den Schreibtisch. Das dritte Werkzeug heißt PostBox und ist für alle, die in Figma designen und die Arbeit dann auf Social Media zeigen müssen – was, wie der Gründer Jason sagt, das ist, was er hasst. Er liebt das Designen, das Fixieren auf jedes Pixel. Was er nicht liebt: Formatieren und Staging der Designs für verschiedene Plattformen.

Felix Hartmann: Die Lösung ist charmant: PostBox verwandelt die MacBook-Notch – dieses kleine Schwarze oben im Display, das sonst nutzloser Raum ist – in eine Drag-and-Drop-Bühne. Du ziehst einen Export da hoch, schreibst die Caption einmal, und postest auf X, Bluesky, Threads, LinkedIn, Dribbble, Behance und Cosmos – mit Threads, Instagram und Pinterest in Arbeit.

Lena Vogel: Interessant ist der "Present"-Modus: Du kannst den Post art-directen, ohne Figma wieder zu öffnen – Geräte, Layouts, Hintergründe, Padding, alles direkt auf dem Bild. Es gibt keinen Export-Schritt, weil die Komposition selbst der Anhang ist. Das fand eine Community-Stimme "eine wirklich clevere Nutzung von totem Raum".

Felix Hartmann: Die kritische Frage ist die, die man direkt versteht: X, Instagram, Pinterest und LinkedIn wollen unterschiedliche Seitenverhältnisse und haben unterschiedliche Zeichenlimits für Captions. Passt PostBox den Crop automatisch an und kürzt die Caption pro Plattform – oder ist es überall derselbe Export und derselbe Text, und man akzeptiert auf manchen Plattformen einen etwas schiefen Crop? Diese Frage ist offen.

Felix Hartmann: Auch ob man Workflows für verschiedene Content-Typen – Portfolios, Ankündigungen – anpassen kann, bleibt offen.

Lena Vogel: Preise: kostenlos mit 5 Posts pro 30 Tagen, ohne Karte, für immer. Pro kostet 9,99 Dollar pro Monat oder 119,88 Dollar jährlich – mit unbegrenzten Posts, unbegrenzten Accounts pro Plattform, zwei Macs pro Lizenz. Fürs Sign-in: Man meldet sich auf der jeweiligen Plattform an, PostBox speichert die Session, nie das Passwort. Und macOS 26.2 oder neuer wird benötigt.

Felix Hartmann: Und dann der schönste Ausblick des Tages, und ich meine das ehrlich: BrickForgerAI. Type a prompt, get a brick set you can actually build. Du tippst, was du bauen willst – ein Raumschiff, ein Haus, ein Drachen – und bekommst ein Modell, das du wirklich kaufen und zusammenbauen kannst.

Lena Vogel: Der Macher erklärt schön, was das vom Rest unterscheidet: Die meisten "AI LEGO-Generatoren", die es schon gab, rendern ein hübsches Bild und nennen es fertig. Diese Teile kannst du nicht kaufen, das Modell nicht bauen. Also hat er die echte Pipeline gebaut – und betont: Die KI-Bild- und 3D-Generierung ist der einfache, zugekaufte Teil. Das eigentliche harte Problem war immer die Brick-Platzierungs-Engine.

Felix Hartmann: Was macht die Engine? Sie verwandelt die Form in ein Voxel-Grid, belegt es mit echten, käuflichen LEGO-kompatiblen Teilen – aus einer Bibliothek von derzeit 55 Teilen, inklusive verschiedener Steigungen und Kurven für glattere Oberflächen, und sie wächst. Die Nähte werden versetzt, damit es nicht auseinanderbricht wie ein loser Stapel. Dann läuft eine Strukturanalyse: Konnektivitäts-Graph, Gravitationslast, um schwache Stellen zu finden – und automatisch zu reparieren, bevor du es bekommst.

Lena Vogel: Laut Angabe kommen die meisten Modelle mit 100 Prozent Konnektivität und wenigen markierten Problemen durch BrickLink Studios Stability-Checker. Du bekommst eine .ldr-Datei, eine Teileliste und eine Schritt-für-Schritt-PDF-Bauanleitung. Teilgeometrie kommt aus der LDraw-Parts-Library, und wichtig: nicht affiliiert mit der LEGO Group, LEGO ist eine Marke ihres Eigentümers.

Felix Hartmann: Die Community wünscht sich direkt zwei Dinge: eine Teile-Kostenabschätzung, und – das ist wirklich eine gute Idee – eine Möglichkeit, das Modell an die Teile anzupassen, die man schon besitzt. "Build this using the bricks in my collection" würde das Ganze auf ein neues Level heben, sagt eine Stimme. Eine andere lobt, dass .ldr, Teileliste und PDF zusammen "aus etwas, das man anschauen kann, etwas machen, das man sich hinsetzen und bauen kann".

Lena Vogel: Preise: Der Free-Plan gibt 3 Credits im Monat, und du zahlst nur, wenn du die .ldr-Datei herunterladen willst. Es gibt Small-, Medium- und Large-Größen – 15, 22 oder 30 Studs.

Felix Hartmann: Und damit sind wir am Ende des Rundgangs. Von Agenten, die nachts Produktion debuggen und aus Fehlern lernen, über Werkzeuge, die ihren Code klein und reviewbar halten, zu Apps, die Erinnerungen unverfälscht lassen – und zu einer Hand voll Alltagshelfer, die genau eine Sache gut machen.

Lena Vogel: Wenn du eines der heute besprochenen Produkte ausprobierst, würd uns interessieren, was du daran auffällt – besonders bei den offenen Fragen: der Datenschutz bei HyperProbe und Retold, die Skalen-Konvertierung bei Queuebrick, der Kill-Switch-Trade bei dif.sh. Das sind die Punkte, an denen man wirklich sieht, ob ein Versprechen hält.

Felix Hartmann: Stimme zu. Danke fürs Zuhören, bis zum nächsten Mal!

Lena Vogel: Tschüss, und pass auf deinen Code auf – oder lass es lieber deinen Agenten machen.