Falar ist ein Sprechtrainer für europäisches Portugiesisch. Du sprichst mit Ana, einer Lehrerin aus Lissabon, und sie antwortet laut, korrigiert dich und merkt sich, welche Fehler du immer wieder machst. Seit dem 1. Oktober ist die App im internen Test bei Google Play.

Die Architekturentscheidung, die alles andere bestimmt: Das Handy spricht direkt mit OpenAIs Realtime API, über WebRTC. Mein Backend legt den Anruf an und hält den API-Schlüssel, aber das Audio läuft nie hindurch. So bleibt die Antwortzeit bei etwa einer Sekunde, und nur so habe ich es geschafft, dass das Modell tatsächlich hört, wie jemand ein Wort ausspricht, statt eine Mitschrift davon zu lesen.

Es heißt aber auch: Der teuerste Teil des Systems läuft auf einem Gerät, das ich nicht kontrolliere, über eine Verbindung, die ich nicht sehe, auf meine Rechnung.

Am 5. Oktober habe ich CaptureDesk veröffentlicht. Eine kleine Electron-App: Loom hat keinen Desktop-Client für Linux, und beim Aufnehmen im Browser gibt es keine Kamerablase, die über anderen Fenstern schwebt, kein Zeichnen auf dem Bildschirm und keine globalen Tastenkürzel. CaptureDesk verpackt Looms Record SDK und ergänzt genau das.

Bevor ich das Repository auf öffentlich gestellt habe, bin ich es auf Sicherheit durchgegangen und habe drei echte Probleme gefunden. Einer der Fixes: Der lokale Server der App lauscht nur noch auf 127.0.0.1 statt auf allen Schnittstellen.

Am nächsten Tag habe ich es noch einmal gelesen. Der Server beantwortete weiterhin jede Webseite, die im Browser des Nutzers offen war. Die Bindung an Loopback hatte diese Tür nicht geschlossen. Sie hatte sie nur schmaler gemacht.

Ich lasse Claude Workflows schreiben und auf meine n8n-Instanz ausrollen. Keine Vorschläge, die ich von Hand reinkopiere. Echte workflow.json, hochgeladen über eine Pipeline, laufend gegen echte Kalender, echte Postfächer, echte Tabellen.

Wovor ich Angst hatte, war nie schlechter Code. Schlechter Code scheitert laut, meistens beim ersten Lauf, und dann behebst du ihn.

Zuletzt habe ich ein Ergebnis aus dem Lab berichtet: Die Sandbox hält, aber das Modell ist es, das den Leak stoppt. In einer intakten microVM hat die Egress-Allow-List nichts beigetragen, als Daten über einen Host abflossen, den sie offen halten musste. Das Einzige, was den Leak tatsächlich gestoppt hat, war das Alignment des Modells.

Die naheliegende Rückfrage darauf war: Wie prüfe ich das an meinem eigenen Setup?

Zuletzt habe ich argumentiert, dass alle Agent-Sandboxes auf der falschen Achse vergleichen: Die Isolationsgrenze ist weitgehend gelöst, und die Sicherheitsfrage, die zählt, beginnt erst, wenn die Wand hält. Das hier ist das erste Experiment von hinter dieser Wand.

Ein kurzer Feldbericht aus einem Lab, das ich zur Sicherheit autonomer KI-Coding-Agenten in microVM-Sandboxes betreibe. Alles hier lief auf eigener Hardware, gegen eigene Secrets und eigene Infrastruktur. Ein halbes Dutzend Experimente an einem Tag, und das interessante Ergebnis ist kein Exploit. Es ist die Frage, wo die Kontrolle, die einen Datenabfluss tatsächlich stoppt, am Ende sitzt.

Wenn du dich damit beschäftigt hast, KI-Agenten sicher zu betreiben, kennst du den Vergleich: Firecracker vs. gVisor vs. normale Container vs. volle VMs. microVMs booten in Millisekunden, Container teilen sich den Host-Kernel, gVisor liegt dazwischen; Firecracker treibt vieles an, und mehrere Produkte bauen ihre Sandboxes darauf. Die ganze Debatte dreht sich um die Isolationsgrenze: wie hart ist die Wand zwischen Agent und Host?

Was mir dabei immer wieder auffällt: Diese Wand ist weitgehend gelöst, und sie ist nicht der Ort, an dem Agenten tatsächlich gefährlich werden.

Allen Lernenden eine gemeinsame Umgebung zu geben ist billig und elend. Eine Person zerlegt sie, und alle stehen. Allen eine feste, immer laufende Instanz zu geben ist sauber und teuer. Dieser Beitrag handelt von einer dritten Möglichkeit: produktionsnahen Sandboxes pro Person auf AWS, die auf Abruf hochkommen, sich selbst aufräumen und etwa die Hälfte dessen kosten, was fest dimensionierte Instanzen kosten würden.

Ein Deploy, der um 02:00 die Produktion zerlegt, sollte nicht darauf warten, dass ein Mensch aufwacht, ein Dashboard liest und sich für ein Rollback entscheidet. Wenn du definieren kannst, was "kaputt" bedeutet, und zwar so, dass dein Monitoring es messen kann, dann kann die Pipeline die Reißleine selbst ziehen. Dieser Beitrag zeigt Schritt für Schritt, wie Observability so in das Deployment verdrahtet wird, dass eine SLO-Verletzung ein automatisches Rollback auslöst.

"Lass die KI das reparieren" ist ein guter Weg, aus einem kleinen Vorfall einen großen zu machen. Der Aufwand in der Incident-Bearbeitung liegt aber meist nicht in der Behebung. Er liegt im Zusammentragen: Logs ziehen, Deploy-Historie prüfen, Metriken korrelieren, rekonstruieren, was sich geändert hat. Dieser Teil lässt sich gefahrlos automatisieren. Dieser Beitrag beschreibt einen Runbook-Executor, der das Zusammentragen und das Vorschlagen automatisiert und bei allem Destruktiven einen Menschen davorstellt.

Am schnellsten bremst man ein Team aus, indem man es auf Infrastruktur warten lässt. Wenn jeder neue Service vier Stunden Handarbeit in der GCP-Konsole bedeutet, sammeln Engineers ihre Anfragen, wechseln währenddessen den Kontext und bauen still und leise Sonderfälle. Dieser Beitrag handelt davon, dieses Ritual durch einen Golden Path zu ersetzen: einen geebneten, meinungsstarken Weg, der eine produktionsnahe Umgebung in unter 45 Minuten bereitstellt, im Self-Service.