Ich mag Werkzeuge, die mir Arbeit abnehmen. Ich mag es weniger, wenn ich anschließend drei Stunden damit verbringe, ihren Organisationsplan zu pflegen. Mein agentisches OpenClaw-Setup bewegt sich ziemlich genau zwischen diesen beiden Polen: Ein Agent für den normalen Austausch, einer für konkrete technische Projekte und einige Spezialisten mit bewusst begrenzten Aufgaben. Das klingt aufgeräumter, als es sich dann im Alltag wirklich anfühlt.

In diesem Artikel zeige ich, wie ich die Rollen aufteile, welche Modelle und Thinking-Stufen (Einstellungen für den Denkaufwand des Modells) ich aktuell verwende und warum ein gutes Briefing oft wichtiger ist als die nächste Agenten-Hierarchie. Dazu gehören auch die Stellen, an denen meine Erwartungen und die tatsächliche Laufzeit am liebsten aneinander vorbeireden. Vieles davon lässt sich auch ohne meine Rollenaufteilung nutzen: Gezielte Briefings, überschaubarer Kontext und eine klare Verantwortung bis zum geprüften Ergebnis.

Im Brotli Decoder von Google gibt es mit CVE-2026-111497 eine Schwachstelle, bei der ein speziell gestalteter Inhalt einen Schreibzugriff außerhalb vom vorgesehenen Puffer auslöst.
Betroffen sind die Versionen 1.0.3 bis 1.2.0, behoben ist die Schwachstelle in 1.0.10, 1.1.1 und 1.2.1. Da viele Laufzeitumgebungen und Bibliotheken Brotli einbinden, etwa Node.js und Python, dauert es, bis alle Anwendungen im Cluster aktualisiert sind.
Bei manchen Anwendungen ist bisher auch gar nicht ganz klar, ob diese betroffen sind, oder nicht.

Bis zur Klärung und Behebung des Problems kann ein Ingress Controller genutzt werden, um Requests abzuweisen, die einen als Brotli deklarierten Inhalt aufweisen.
Dieser Beitrag zeigt dazu eine einfache Regel für Traefik.

Nicht jede Organisation kann oder darf KI-Dienste in der Cloud nutzen. Sensible Daten, regulatorische Vorgaben, Souveränitätsanforderungen und abgeschottete Netze verlangen den Betrieb von Sprachmodellen im eigenen Haus.

Das ist technisch machbar, stellt aber eigene Anforderungen an Betrieb, Sicherheit und Compliance. Dieser Beitrag ordnet die wichtigsten ein.

Domain-Driven Design und generative KI werden oft getrennt betrachtet. Das eine gilt als Methodik für fachliche Modellierung, das andere als Technologiethema. Tatsächlich berühren sich beide an mehreren Stellen, und die Verbindung ist tragfähiger, als es auf den ersten Blick wirkt.

In diesem Beitrag ordnen wir die Schnittmengen ein und trennen dabei zwei Richtungen, die man nicht vermischen sollte.

Für ein internes Werkzeug mit REST-API sollte die Auslieferung als kleines, schnell startendes natives Binary erfolgen. Als Framework standen Spring Boot und Micronaut zur Auswahl, im Team gab es vor allem Spring-Erfahrung. Statt nach Bauchgefühl zu entscheiden, haben wir beide Kandidaten mit identischen Prototypen als GraalVM Native Image gebaut und vermessen. Die Messwerte und die Erkenntnisse aus dem Vergleich stellen wir in diesem Beitrag vor.

Bei der Anmeldung per sogenanntem Magic Link erhält der Benutzer einen Link, über den er sich ohne Passwort anmeldet. Der Link wird typischerweise per E-Mail zugestellt, der erforderliche Zugriff auf das Postfach tritt damit an die Stelle der Eingabe eines Passworts.
Spring Security bringt in neueren Versionen für dieses Verfahren mit dem One-Time-Token-Login eine fertige Unterstützung von Haus aus mit. In diesem Beitrag wird die Umsetzung mit dem aktuellen Spring Boot 4 und Spring Security 7 gezeigt. Dabei betrachten wir zwei Fälle: Links, die genau einmal genutzt werden können, so wie es typischerweise auch genutzt wird und auch von Spring direkt vorgesehen ist. Als Alternative wird eine Konfiguration für Links, die über einen längeren Zeitraum oder sogar dauerhaft funktionieren, vorgestellt. Für den zweiten Fall gehen wir auf die damit verbundenen Risiken, sinnvolle Einsatzszenarien und generelle Alternativen ein.
Eine lauffähige Beispielanwendung steht am Ende des Artikels zum Download bereit.

Im Beitrag Kubernetes Ops Hilfe mit lokalem LLM hat ein handgeschriebener OpenAI-kompatibler Proxy kubectl als Tool für ein lokales Sprachmodell verfügbar gemacht. Dabei wurde Open WebUI als Chat-Oberfläche genutzt, so dass eine interaktive Diagnose möglich wurde. llama.cpp bringt inzwischen zwei Dinge von Haus aus mit, die einen alternativen Aufbau möglich machen: eine eigene, in llama-server eingebettete Chat-Oberfläche und einen MCP-Client, der Werkzeuge über das Model Context Protocol (MCP) anspricht.
Dieser Beitrag zeigt, wie sich kubectl so über einen minimalen, selbst geschriebenen MCP-Server anbinden lässt, bewusst ohne auf ein fertiges MCP-Projekt zurückzugreifen, um die Prinzipien von MCP sichtbar zu machen. Im Ordner sample liegt dazu ein vollständiges, lauffähiges Docker-Compose-Setup. Für den produktiven Einsatz verweist der Beitrag am Ende auf etablierte Alternativen.

Bei der Neuinstallation eines Manjaro Linux Systems mit verschlüsselter Systempartition bestimmen zwei Eigenschaften der beteiligten Werkzeuge vor, wie die Installation mit modernem LUKS2 umgesetzt werden kann. Calamares, der grafische Installer von Manjaro, legt bei aktivierter Verschlüsselung lediglich einen Container im alten LUKS1 Format an. Der Bootloader GRUB kann dazu einen LUKS2 Container mit den heute üblichen Parametern nicht aufschließen.

Aus beidem folgt ein Ablauf, der von der Standardinstallation von Manjaro abweicht und effektiv auf ein Design hinausläuft, wie es auch beispielsweise Ubuntu umsetzt: /boot liegt unverschlüsselt auf einer eigenen Partition und bringt eine Ramdisk mit, die alles Notwendige zur Unterstützung von LUKS2 beinhaltet.

Dazu werden Partitionierung, LUKS2 Container und Dateisysteme einmalig von Hand vorbereitet, bevor der grafische Installer die eigentliche Installation übernimmt.

GraalVM Native Image übersetzt Java-Anwendungen vorab in ein natives Binary. Der Start dauert dann Millisekunden statt Sekunden, der Speicherbedarf sinkt deutlich, und zur Laufzeit wird keine JVM mehr benötigt. Für Anwendungen, die auf jedem Knoten eines Kubernetes-Clusters mitlaufen, sind das gute Argumente. Im konkreten Beispielprojekt, in dem sich ein schwer zu findender Fehler eingeschlichen hatte, ging es genau um Kubernetes Infrastruktur: Ein eigener CSI-Treiber wird als DaemonSet betrieben und belegt so Ressourcen auf jeder einzelnen Node.

Damit diese Optimierungen funktionieren, verschiebt Native Image Arbeit vom Programmstart in den Build. Dazu gehört die Klasseninitialisierung: Statische Initializer werden nicht zwangsläufig beim Start ausgeführt, sondern können bereits beim Bau des Binaries laufen. Deren Ergebnis wandert als fertiges Objektnetz in den sogenannten Image Heap. Keine Initialisierung mehr zur Laufzeit, keine Arbeit für einen Just in Time Compiler.
Das ist zum einen der Hebel für den Geschwindigkeitsgewinn, aber gleichzeitig eine Fehlerquelle, die in der klassischen JVM-Welt so nicht existiert. Was ein statischer Initializer ableitet und ermittelt, wird einmalig zum Buildzeitpunkt auf der Buildmaschine ausgeführt.

Die NullPointerException ist nach wie vor einer der häufigsten Laufzeitfehler in Java-Anwendungen. Das eigentliche Problem ist selten der einzelne vergessene Check, sondern dass an keiner Stelle festgehalten ist, welche Werte überhaupt null sein dürfen und welche nicht. Diese Information steckt bestenfalls im Kopf der Entwickler oder in der Dokumentation, aber nicht im Typsystem.

JSpecify ist ein herstellerübergreifender Satz von Annotationen, der genau diese Information ausdrückt. Mit Spring Framework 7 und Spring Boot 4 ist das gesamte Spring-API mit diesen Annotationen versehen. Damit die Annotationen nicht nur Dokumentation bleiben, braucht es ein Werkzeug, das sie prüft. Im Maven-Build übernimmt das Error Prone zusammen mit dem NullAway-Plugin von Uber.