AI Picks der 20. KW

Die Woche war abermals mordsergiebig. Gefühlt gab es auch noch eine viertel Million neuer Repos auf GitHub. Aber wenn man sich die alle anguckt, ist man nächstes Jahr noch nicht fertig – und der Hype ist meistens eh überschätzt. Hier die Sachen, die hängen geblieben sind.

Agent View und /goal für Claude Code

Anthropic hat in Claude Code 2.1.139 zwei Features ausgerollt, die in Kombination tatsächlich Sinn ergeben: Agent View bündelt alle laufenden Sessions in einem einzigen CLI-Dashboard – wer bisher mit drei Terminal-Tabs und einer mentalen Strichliste gearbeitet hat, was gerade läuft und was auf Input wartet, bekommt jetzt einen sauberen Überblick mit Status pro Session. Und der /goal-Command erlaubt, eine Bedingung als Endpunkt zu setzen, woraufhin Claude weiterarbeitet, bis diese erreicht ist – inklusive eines unabhängigen Supervisor-Modells (Haiku), das nach jedem Turn überprüft, ob das Ziel tatsächlich erfüllt wurde.

Auf dem Papier: hands-free productivity. In der Praxis ein Pattern, das man von Codex CLI quasi zeitgleich kennt – OpenAI hat persistente - /goal Workflows für Codex CLI ebenfalls im Mai gepusht, nur einen Tick früher. Dass die Anthropic-Variante zeitgleich mit einer Verdopplung der Fünf-Stunden-Rate-Limits kommt, ist kein Zufall. Längeres, weniger überwachtes Arbeiten soll zum Standard werden.

Aber Zitat eines Bekannten meinerseits:

Ich wollte schon immer einen Agent unkontrolliert tagelang laufen lassen und mich hinterher über fünfstellige Rechnungen freuen.

Genau diese Sorge ist nicht aus der Luft gegriffen. Die /goal-Dokumentation selbst empfiehlt explizit, einen Turn-Cap mitzugeben und keine open-ended kreativen Goals über Nacht laufen zu lassen. Berichte über 14-Stunden-Sessions auf Max 20x mit $200-Verbrauch ohne Hard-Limit gibt es bereits. Wer kein API-Budget mit Hard-Cap dahinter hat, sollte sich die Status-Anzeige für den Token-Spend zur Gewohnheit machen.

Heißt für mich: /goal ist sinnvoll für klar abgrenzbare Aufgaben mit verifizierbarem Endzustand – eine Migration, bis alle Test-Calls grün sind, ein Backlog abarbeiten, ein Refactor mit definierten Acceptance Criteria. Für „mach mal was Schönes“ ist es das verkehrte Werkzeug. Und ohne Max-Account, ohne saubere Rate-Limit-Strategie und ohne Turn-Cap ist es die schnellste Methode, sich selbst zu überraschen, wenn die nächste Rechnung kommt.

Programmatic Credits ab dem 15. Juni

Passend dazu: Anthropic hat angekündigt, dass alle bezahlten Claude-Pläne ab dem 15. Juni einen monatlichen, dedizierten Credit-Topf für programmatische Nutzung bekommen. Die Ankündigung von ClaudeDevs auf X liest sich auf den ersten Blick wie ein Geschenk: Subscription-Rate-Limits werden ab dann für interaktive Nutzung reserviert, programmatische Nutzung (Agent SDK, claude -p, Claude Code GitHub Actions, Drittanbieter-Apps auf dem Agent SDK) bekommt ein eigenes Budget. Credit einmal pro Monat beanspruchen, läuft automatisch leer, Rest wird über Usage Credits zu API-Raten abgerechnet – oder pausiert, wenn man die ausgeschaltet hat.

Die Beträge nach Plan:

Pro: $20
Max 5x: $100
Max 20x: $200
Team Standard: $20/seat
Team Premium: $100/seat
Enterprise: variiert nach Seat-Typ

Beanspruchen einmalig, läuft mit dem Billing Cycle ab, kein Rollover.

Was das ist, wenn man die Marketingblase wegnimmt: Anthropic bläst zur Attacke. Und sie haben einen guten Grund. Codex hat im Q1 2026 erheblich aufgeholt – GPT-5.3-Codex liegt auf Terminal-Bench 2.0 bei 77,3 Prozent gegen Claudes 65,4 Prozent, und in den einschlägigen Reddit- und HN-Threads dominiert seit Wochen ein Thema: Claude-Code-Limits. Bei Codex Plus für $20 hören Heavy User auf, von Wand-an-Wand-Limits zu reden, bei Claude Pro fangen sie genau dort an. Dazu kommen öffentliche Wechsel-Statements von Entwicklern, die ein Jahr lang Claude Code als Daily Driver hatten.

Passenderweise bläst Sam Altman direkt zum Gegenangriff in einem Beitrag auf X. Elmos x.com als Bühne für solche Hahnenkämpfe ist so wunderbar stumpf – das ist dieses „When shit hits the fan“, wie der Amerikaner sagt. Man möchte weggucken, kann aber nicht.

Für mich, der nicht wechselt: Die Trennung interaktiv vs. programmatisch ist sauber gedacht. Wer Claude Code im Terminal nutzt und parallel ein paar GitHub Actions oder eigene Skripte laufen lässt, kennt das Problem, dass beides aus demselben Topf zieht. Das ist jetzt entkoppelt. Was es nicht ist: ein wesentlich größerer Topf. Wer den Pro-Plan voll ausreizt, hat danach 20 $ obendrauf für SDK-Krams – kein Geschenk, aber eine klarere Buchhaltung.

Antigravity, neu gelesen

Der Titel des How-To-Geek-Stücks – „Google Antigravity beats Claude at coding, but only if you stop acting like a programmer“ – ist klassischer Clickbait, aber die These dahinter hat einen wahren Kern: Antigravity ist nicht als besseres VS Code gedacht, sondern als Orchestrierungs-Layer. Wer es behandelt wie einen Editor mit AI-Funktion, frustriert sich an Rate-Limits und kontraintuitivem Verhalten. Wer dagegen die Manager View ernst nimmt – Goal definieren, Planning Mode laufen lassen, mehrere Agenten parallel auf Backend, Frontend und Tests ansetzen, anschließend Reviews fahren – holt aus Gemini 3.x deutlich mehr raus.

So weit die wohlwollende Lesart. Die unwohlwollende: Genau diese Arbeitsweise ist eine Lernkurve, die viele nicht mitgehen wollen. XDA Developers berichtet von Testern, die Antigravity tatsächlich zu ihrem Produktiv-Setup machen – allerdings auch mit dem Hinweis, dass es ein Ressourcen-Hog ist. DataCamp merkt nüchtern an, dass Antigravity noch in Preview ist, keine dokumentierte Compliance-Zertifizierung hat und Google bekanntlich nicht für Produkt-Konstanz bekannt ist.

Ganz hotter Take: Die These „besser, wenn man umdenkt“ stimmt für eine bestimmte Sorte Workflow – Greenfield-Projekte, größere Refactors, parallele Tracks. Für tägliches Hin und Her zwischen Files, schnelles Debugging und Codebase-Navigation ist das Manager-View-Paradigma overkill. Und der Punkt, an dem Antigravity unangefragt File-Associations übernimmt, ist für mich allein schon Grund, es nicht zur Standard-IDE zu machen.

Persönliche Anmerkung: Mir ging das übergriffige Verhalten von Antigravity extrem auf die Nerven – Übernahme als Standardeditor sämtlicher relevanter Dateitypen, die vorher VS Code zugeordnet waren, und das ohne nachzufragen – ich habe das Ding sang- und klanglos wieder deinstalliert. Aber: Ich habe Verständnis für Menschen, die gerne damit arbeiten. Ich bin eher der Terminal-CLI- und VS-Code-Mensch (allerdings auch erst geworden nach jahrelanger Sublime-Text- und TextMate-Nutzung).

Peekaboo

Kommt von Peter Steinberger (OpenClaw) und ist ein macOS-Automatisierungs-Toolkit – diesmal aber explizit für AI Agents: pixel-genaue Screenshots, Accessibility-Tree-Auslese, GUI-Steuerung über Click/Type/Scroll/Menü, plus MCP-Server für Codex, Claude Code und Cursor. Die Idee, die Steinberger auf X selbst formuliert hat: Playwright, aber für den Mac und für Menschen wie Agenten.

Das ist die Welle, die gerade alle reiten: Claude Cowork, Perplexity Personal Computer, OpenAIs Operator, Anthropics Computer Use dazu Antigravitys eingebauter Browser. Tools, die dem LLM nicht nur Code, sondern den ganzen Rechner geben. Peekaboo ist ein gut gemachter Eintrag in die Liste – die Releases v3.0 (9. Mai) und v3.1 (11. Mai) bringen native action-first Automation und einen Daemon für bursty Workloads, der Code wirkt durchdacht.

What could possibly go wrong? Wer Peekaboo (oder eines der anderen Tools) installiert, gibt Screen Recording und Accessibility Permissions an einen Prozess, der LLM-Outputs in Mausklicks und Tastatureingaben übersetzt. Prompt Injection wird damit nicht mehr ein Problem für das Chat-Fenster, sondern für das Betriebssystem. Wenn ein Agent eine maliziöse Webseite öffnet und die Seite den Agent dazu bringt, im Hintergrund den Schlüsselbund zu durchsuchen, gibt es keinen Schutzwall mehr dazwischen. Steinberger weiß das natürlich auch Peekaboo bringt eine permission-aware Bridge mit –, aber die generelle Diskussion zu Sandbox, Allowlists, Egress-Kontrolle steht für die ganze Tool-Klasse erst am Anfang. Womit wir (fast) nahtlos beim nächsten Pick landen:

GitHub baut ein Immunsystem für MCP

Klingt erst mal groß, ist im Kern aber präziser: GitHub hat laut The New Stack Dependency Scanning für seinen MCP-Server in Public Preview geschickt und Secret Scanning auf GA gehoben. Die Engines dahinter sind nicht neu – die laufen seit Jahren in GitHub Advanced Security – aber sie sind jetzt als MCP-Tools für Coding-Agents wie Claude Code, Cursor und Codex zugänglich. Konkret: Der Agent kann per Natural-Language-Prompt einen Scan auslösen („scan my changes for secrets"), der MCP-Call geht an GitHubs Backend, strukturierte Ergebnisse kommen zurück – und das bevor irgendwas committet wird.

Wichtig zu verstehen, was da gescannt wird und was nicht: Geprüft wird der Code, an dem der Agent gerade arbeitet – inklusive aller Dependencies und Inhalte aus externen Frameworks, npm-Packages, fremden Quellen, sobald sie im Workspace landen. Das ist die Code-Hygiene-Seite. Nicht geprüft werden andere MCP-Server selbst, deren Tool-Descriptions, Skills-Files oder der Agent-Loop. Tool Poisoning, Prompt Injection in Tool-Descriptions, malicious Skills, Cross-Server Manipulation – diese MCP-spezifischen Angriffsvektoren sind eine andere Baustelle, die Snyk Agent Scan und ähnliche Tools wie Medusa oder Rigour abdecken.

Ich hätte schwören können, die Meldung hätte ich vor sechs Monaten schon mal gelesen, aber sie ist von dieser Woche. Wahrscheinlich, weil die Branche das Thema seit über einem Jahr in Slides und Konferenz-Talks vor sich herträgt und es jetzt erst in Serie geht.

Sind wir ehrlich: MCPs sind für sich genommen schon ein Security Nightmare – aus diversen Gründen, und Code-Hygiene ist nur einer davon. Was GitHub liefert, schließt die altbekannten Klassiker (Secrets im Repo, vulnerable Deps) im Agent-Workflow ab. Das ist die low-hanging fruit, die Headline „Immunsystem für MCP" ist entsprechend verkaufsfreudiger als der tatsächliche Scope. Reicht es allein? Natürlich nicht – die MCP-spezifischen Probleme bleiben offen, dafür braucht es andere Tools. Aber es ist ein wichtiger Anker, gerade weil GitHub für viele Teams ohnehin Pflicht-Knotenpunkt im Workflow ist und der Reibungsverlust bei der Adoption nahe null liegt.

Pydantic AI – die Außensicht

Von Pydantic AI höre ich ehrlicherweise zum ersten Mal, was angesichts der schieren Menge an Agent-Frameworks nicht überrascht. Also: Was ist das, was kann es, und was bringt es im Vergleich zu LangChain, LangGraph, CrewAI, Agno und Marvin?

Wenn man die Vergleichsstücke der letzten Monate liest, kristallisiert sich eine recht klare Positionierung heraus: Pydantic AI ist das Type-Safety-zuerst-Framework. Wer bereits FastAPI/Pydantic-Stacks fährt, bekommt einen Agent, der sich anfühlt wie der Rest der Codebase – generische Agent[Deps, Output]-Typen, RunContext-basierte Tools, native Async-Streams, minimale Abhängigkeiten. Ein direkter Vergleich derselben Chat-App über vier Frameworks. kommt auf rund 160 effektive Code-Zeilen für Pydantic AI gegenüber 170 für LangChain, 280 für LangGraph und 420 für CrewAI. Bei den Cost-Benchmarks aus Speakeasys Übersicht ist Pydantic AI deutlich Token-effizienter als CrewAI.

Wo es seine Grenzen hat: Multi-Agent-Orchestrierung ist nicht eingebaut, das muss man selbst zusammenstecken oder LangGraph/CrewAI nehmen. Built-in-Auth, RBAC, Guardrails, Prompt-Injection-Detection auf Framework-Ebene gibt es ebenfalls nicht – wer SOC 2 oder HIPAA auf Framework-Ebene braucht, ist mit LangSmith oder Vellum besser bedient.

Hier nur mal grob das Bild der Wettbewerber:

LangChain: das Schweizer Taschenmesser. 70+ Provider, riesiges Ökosystem, sehr schnell für Prototyping. Preis: tiefe Abstraktionsschicht, die beim Debuggen zur eigenen Konstruktion wird.
LangGraph: explizite State-Machines, Checkpoints, Human-in-the-Loop. Overkill für simple Agents, Pflicht für komplexe Workflows mit Cycles.
CrewAI: Multi-Agent-Teams mit Rollen, Goals, Backstories. Intuitiv, aber Token-teuer (Agenten unterhalten sich gerne miteinander), und Production-Features reifen noch.
Agno: opinionated, Batterien inklusive (Session-Memory, Reasoning Tools, Observability), wirkt sauber dokumentiert. Preis: weniger Flexibilität.
Marvin und DeepAgents: kleinere Player; Marvin ist eher Toolkit-/Tasking-Layer, DeepAgents kopiert Claude-Code-Architektur.

Steile These ohne Eigenerfahrung mit Pydantic AI: Wer schon Pydantic in seinem Stack hat und einen einzelnen, testbaren Agent baut, ist mit Pydantic AI vermutlich näher dran an seinem üblichen Schreibgefühl als mit allem anderen. Wer Multi-Agent will, fängt eher bei CrewAI oder LangGraph an. Wer LangChain bereits produktiv hat und keine Lust auf Migrationsschmerz, bleibt da, wo er ist – aber wundert sich nicht, wenn das Debugging-Erlebnis suboptimal bleibt.

Markdown Experience Guidelines (MDXG)

Vercel hat wieder was rausgehauen: MDXG, eine Spezifikation samt VS-Code-Extension, die Markdown-Dateien in navigierbare Multi-Page-Experiences verwandelt. H1/H2-Überschriften splitten das Dokument in virtuelle Pages, die Spec selbst lässt die konkrete Umsetzung der Page-Navigation offen – Sidebar, Dropdown, Command Palette, Geste.

Grundsätzlich ist eine bessere Zugänglichkeit für Markdown sinnvoll und auch wünschenswert. Allerdings: Markdown ist selbst ohne Parser relativ einfach zu lesen und zu verstehen. Und wenn ich so was lese wie:

Virtual pages. H1 and H2 headings split a document into navigable pages. A single markdown file becomes a multi-page experience. No file splitting, no config, no build step.

Page navigation. The user can see all pages, jump to any page, and tell which page they're on.

bekomme ich Angst, dass die Leute anfangen, damit ihre Slides zu bauen – und das kann niemand wirklich wollen. Vercels Geschichte mit Markdown ist eng mit MDX verbunden, einem Format, das JSX in Markdown einbaut. MDXG ist konzeptionell weiter weg, aber im selben Universum: Markdown soll nicht mehr nur Text sein, sondern Erfahrung.

Heißt für mich: Für lange Tech-Dokumentation hat das einen klaren Use Case – wenn die README dreitausend Zeilen hat, ist „flach scrollen“ tatsächlich nicht mehr die beste UX. Für 90 Prozent der Markdown-Files (READMEs unter 200 Zeilen, Blog-Drafts, Notizen) ist eine zusätzliche Spec eine Lösung für ein Problem, das man nicht hat.

Interaction Models – Thinking Machines macht Echtzeit

Mira Muratis Thinking Machines Lab hat sein zweites öffentliches Lebenszeichen abgegeben und legt direkt ein technisches Manifest hin: Statt klassischer Turn-basierter Modelle (du sprichst, das Modell wartet, das Modell antwortet) bauen sie ein Modell, das in 200-Millisekunden-Mikro-Turns parallel Audio, Video und Text verarbeitet – inklusive der Möglichkeit, den Nutzer zu unterbrechen, wenn dieser einen Fehler gerade live macht. Der Twist: Interaktivität ist nicht über VAD-Komponenten (Voice Activity Detection) drangetackert, sondern Teil der Modellarchitektur selbst. TML-Interaction-Small ist ein 276B-MoE mit 12B aktiven Parametern. Erste Berichte aus dem Latent Space und bei VentureBeat ordnen es als ernsthafte Konkurrenz zu GPT-Realtime-2 und Gemini 3.1-Flash ein.

Es liest sich so wunderbar nach schöner neuer Welt mit ganz viel Marketingsternchen für die Fußnoten. Womit wir bei den Benchmarks wären: Thinking Machines zeigt 77,8 auf „FD-bench v1.5“ gegen 54,3 für Gemini und 47,8 für GPT-Realtime-2.0. Schön. Aber – herstellereigene Werte, keine unabhängige Drittmessung. „FD-bench v1.5“ taucht in der Form auch nirgends sonst im Diskurs auf; das wirkt wie eine eigene Bench, auf der man die eigenen Stärken misst. Wenn Benchmarks lügen ist hier wieder der relevante Reflex.

Was technisch real interessant ist: Encoder-free Early Fusion (kein dediziertes Whisper davor, alles wird gemeinsam von Grund auf trainiert) und die Multi-Stream-Architektur. Wenn das hält, was die Demos versprechen, ist das die erste greifbare Architektur-Antwort auf die alte „Her"-GPT-4o-Demo, die nie wirklich in dieser Form ausgeliefert wurde. Wenn nicht, ist es eine sehr schön gemachte Forschungsvorschau.

Substanz ist da, mehr als ich nach der Marketing-Tonalität erwartet hatte. Aber bis unabhängige Benchmarks (Open-Source-Eval-Suites, Drittanbieter-Vergleiche) das bestätigen, behandle ich die Zahlen als das, was sie sind: Hersteller-Selbstvermessung mit gut gemachter Doku. Spannender wird sein, ob die Architektur in irgendeiner Form geöffnet oder lizenziert wird – sonst bleibt es ein Forschungsschaufenster.

Grok kann jetzt auch Skills

Memeburn berichtet, xAI habe Grok Skills bekommen – also wiederverwendbare Workflow-Bausteine analog zu Claude Skills und OpenAI GPTs.

Ich kenne wirklich niemanden, der Grok ernsthaft nutzt. Außer vielleicht den KI-Spezial-Experten, die mit Clickbait-Videos auf YouTube bei jeder neuen LLM-Version – Anbieter egal – erzählen, dass es das „andere“ aktuell most-hyped Modell in den Schatten stellt.

Skills sind eine sinnvolle Abstraktion, kein Zweifel. Dass Grok sie jetzt auch hat, ändert nichts daran, dass die Adoption außerhalb der X-eigenen Bubble dünn ist und das Modell in den meisten Vergleichen (Coding, Reasoning, agentische Workflows) nicht in der Spitzengruppe spielt. Wer eine Skills-Pipeline bauen will, hat mit Claude oder Codex aktuell die deutlich produktivere Umgebung. Wer Grok sowieso schon nutzt, freut sich vermutlich – alle anderen können das hier weiterscrollen.

Claude for Small Business

Anthropic hat Claude for Small Business angekündigt – ein KMU-zugeschnittenes Bundle mit Integrationen für QuickBooks, Google Workspace, HubSpot, DocuSign und Microsoft 365. Haben die bei Anthropic eine Wette verloren? Es hört nicht auf.

Das sieht auf den ersten Blick sehr auf den US-amerikanischen Markt zugeschnitten aus. QuickBooks, HubSpot und DocuSign sind im typisch deutschen KMU-Umfeld quasi nicht vorhanden – DATEV, Lexware, SevDesk, Pipedrive, FastBill spielen hier die größere Rolle. Microsoft 365 ist drin, das ist gut, denn da gab es ja schon letzte Woche etwas. Google Workspace ebenfalls, was für die kleinere, jüngere KMU-Schicht relevant ist.

Da ist nichts in Stein gemeißelt, und da können durchaus noch SaaS-Anbieter mit ins Boot geholt werden. Anthropic merkt offensichtlich, dass die KMU-Schicht der nächste Wachstumshebel jenseits der Developer-Bubble ist, und positioniert sich entsprechend früh. Für den deutschen Markt ist das aktuell mehr Signal als Substanz – wenn die DATEV-Integration kommt, reden wir weiter (zum Thema DSGVO schweigen wir jetzt einfach mal). Bis dahin bleibt es ein US-Bundle mit Microsoft 365 als Brückenkopf.

How AI Models Perceive Brands

Der WordLift-Artikel knüpft an Anthropics Forschung zu Natural Language Autoencoders (NLAs) an – einer Technik, die interne Modell-Aktivierungen in menschenlesbaren Text übersetzt. Übertragen aufs Marketing: Wenn man herausbekommen kann, wie ein Modell intern eine Marke repräsentiert (welche Konzepte, Emotionen, Konkurrenten dabei mitschwingen), bekommt man Brand Perception auf einer Ebene unter dem, was das Modell explizit sagt.

Und genau darum ist das relevant: Klassische Brand-Perception-Studien fragen Menschen oder lesen Reviews. AI-mediated Brand Discovery passiert aber zunehmend an einer anderen Stelle – im Kontext-Fenster eines LLMs, das auf eine Kaufberatungs-Frage antwortet. Wenn das Modell deine Marke gar nicht „kennt“ (weil zu wenig Trainingsdaten), oder sie nur in einem bestimmten kulturellen Cluster verortet (siehe die arXiv-Studie zu Cultural Encoding in LLMs), hast du in dieser Discovery-Phase einfach keinen Platz an der Bar.

Hier wird es spannend – und genau hier setzt der WordLift-Artikel zu Recht den Hebel an: Das Training selbst und die Menschen, die für die Annotation zuständig waren, hinterlassen kulturelle Footprints. Modelle aus US-Trainingsdaten erkennen US-Marken überproportional. Chinesische Modelle erkennen chinesische Marken überproportional. Deutsche Mittelständler tauchen in beiden eher selten auf, es sei denn, sie sind international groß genug, um in den Quellen prominent zu sein. Das ist keine Verschwörung – das ist Datenverteilung. Aber für die Marketing-Strategie heißt das: Sichtbarkeit in AI-Antworten ist nicht (nur) eine Frage von SEO, sondern eine Frage davon, wo dein Markenname in welchen Sprachen mit welchen Konzepten in den Trainingsdatensätzen verknüpft ist.

Für Marken hierzulande ist das aktuell weniger eine ausgereifte Strategie und mehr eine Diagnose-Phase. Aber wer 2026 noch glaubt, AI-Sichtbarkeit sei dasselbe wie SERP-Sichtbarkeit, hat den Anschluss schon verpasst. Und der NLA-Hebel – schauen, was ein Modell intern mit deiner Marke verknüpft – ist eines der wenigen technisch fundierten Mittel, dieser Frage näherzukommen, statt sie nur zu raten.

FAQPage Markup im GEO-Zeitalter

Noch ein WordLift-Beitrag zu einem ganz anderen Thema hat genau in der Woche das richtige Timing – am 7. Mai 2026 hat Google FAQ Rich Results komplett deprecatet. Search Console-Reporting endet im Juni, API-Support im August. Das schönste Zitat aus dem Artikel:

abuse it, lose it.

Ein wichtiger Unterschied, der in der allgemeinen Aufregung gerne untergeht – und genau den dröselt der WordLift-Artikel sauber auf: FAQPage-Markup (das Schema.org-Vokabular als JSON-LD auf der Seite) und FAQ Rich Result (die ausklappbare SERP-Darstellung) sind zwei verschiedene Dinge. Mein Stand bisher: Google hatte 2023 die Rich-Result-Darstellung auf autoritative Government- und Health-Sites reduziert. Das war korrekt – für die Rich Results. Das Schema selbst war nie tot. Bestätigt von Google selbst im Update der eigenen Doku am 7. Mai: das Markup darf bleiben, es schadet nicht, und es wird weiterhin zum Verständnis der Seite genutzt.

Der eigentlich interessante Teil: Was passiert mit AI Search? Bingbot indexiert FAQPage-Markup weiterhin, und Bing ist eine der Retrieval-Quellen für ChatGPT Search und Microsoft Copilot Grounding. PerplexityBot liest strukturierte Daten ebenfalls. Ob FAQ-Markup AI-Overview-Zitate konkret begünstigt, ist empirisch nicht klar belegt – Google äußert sich dazu nicht direkt, und unabhängige Korrelations-Studien fehlen. Aber als billige Defensivmaßnahme („maschinenlesbare Q&A-Struktur“) und als zusätzliches Signal für andere Retrieval-Engines bleibt es valide.

Wer FAQ-Markup für Rich Results gebaut hat, kann es behalten oder entfernen, der SERP-Effekt ist eh weg. Wer aber GEO ernst nimmt, behält es – nicht als Wunderwaffe, sondern als saubere Strukturierung dort, wo der Content ohnehin Q&A ist. Was es definitiv nicht mehr ist: eine billige Methode, mehr SERP-Real-Estate zu kriegen. Diese Tür ist nach sieben Jahren Missbrauch endgültig zu, und das war absehbar. Genau das ist auch der Punkt von „abuse it, lose it“.

WiWo: „Das sind die besten KI-Modelle“

Da bin ich in meinem Home Feed über einen Artikel der WirtschaftsWoche gestolpert, und herje, das muss ich einfach mal loswerden.

Auf bereits am Boden Liegende soll man ja nicht eintreten – aber das ist Altpapierjournalismus at it finest. Quellen verlinken? Warum denn. Mehrere Benchmarks heranziehen statt einen einzigen Index? Brauchen wir nicht. Methodik hinterfragen? Bekommen wir nicht bezahlt. Das liest sich nicht nur wie KI-Slope, ich fürchte, der ganze Artikel ist auch ein Ergebnis dessen.

Ironie an der Sache: Die WiWo stützt sich auf den Artificial Analysis Intelligence Index, und der ist eigentlich ein durchaus sauberer Composite-Score (daher kann ich meine Kritik mit den fehlenden, mehreren Benchmarks etwas relativieren) – v4.0 seit 6. Januar 2026, zehn Evaluations (GDPval-AA, τ²-Bench Telecom, Terminal-Bench Hard, SciCode, AA-LCR, AA-Omniscience, IFBench, Humanity's Last Exam, GPQA Diamond, CritPt), vier gleichgewichtete Kategorien (Agents, Coding, Scientific Reasoning, General) und ein 95-Prozent-Konfidenzintervall von unter ±1 %. Wer sich die Methodik anschaut, sieht ein Profil pro Modell, keine 1D-Wertung. Die WiWo presst aber genau das in ein einzelnes 1D-Ranking („Intelligenzwert 57“), als wäre das der IQ-Test für Sprachmodelle. Genau diese Verflachung kritisiert Sebastian Raschka in seiner Architecture Gallery sauber: Die 57 von Claude Opus 4.7 ist nicht dieselbe 57 wie die von Gemini 3.1 Pro Preview – das sind zwei verschiedene Profile, die zufällig dieselbe gewichtete Summe ergeben.

Dazu kommen die Standard-Marker, die einen oberflächlichen Schnellschuss verraten: keine einzige Verlinkung zur Primärquelle (weder zu Artificial Analysis noch zum Stanford AI Index Report 2026, beides explizit referenziert), keine Erläuterung, was „(max)“, „(xhigh)“ oder „Preview“ eigentlich bedeuten. Modelle wie „Gemini 3.1 Pro Review“ stehen so im Text – ob das ein Lapsus ist oder die WiWo wirklich glaubt, Google habe ein „Review“-Modell veröffentlicht, weiß ich nicht. Mein Bauchgefühl tendiert zur 2. Variante.

Ich werfe mal meinen Hut in den Ring: Wer im Jahr 2026 solche Artikel baut und dabei genau einen Composite-Score, keine unabhängige Verlinkung und keinen Hinweis auf die zugrundeliegenden Trade-offs liefert, hat den Anschluss verpasst: an die KI-Welt und ans eigene journalistische Handwerk gleich mit. Und dann wundern die sich, dass ihnen Abonnenten und Verkaufszahlen wegbrechen.

Gartner: Souveräne Cloud nur in USA und China möglich

Das ist mal eine saubere Bankrotterklärung – von außen, durch jemanden, der weiß, wovon er spricht. Gartner-VP-Analyst Douglas Toombs hat auf der „IT Infrastructure, Operations & Cloud Strategies“-Konferenz in Sydney erklärt, dass vollständige digitale Souveränität derzeit kaum außerhalb der USA und Chinas erreichbar sei. Heise hat das Ganze nüchtern referiert, das Schlüsselzitat lautet:

Derzeit gibt es keine geeigneten nicht-US-amerikanischen Alternativen zu den großen Hyperscalern – außer in China, wo der Schutz geistigen Eigentums Bedenken aufwirft.

Toombs ist nicht irgendwer, der mal eben einen Marktkommentar raushaut. Über 20 Jahre Hands-on-IT, davon zehn in der Hosting- und Managed-Services-Branche, vor Gartner unter anderem Lead Architect Global Hosting Engineering bei PSINet – der Mann kennt als Vendor und Customer beide Ufer und weiß, wovon er spricht. Wenn jemand mit dieser Vita sagt, dass es strukturell außerhalb der beiden Pole nicht geht, dann ist das nicht Hyperscaler-Marketing, sondern Diagnose. Toombs verweist unter anderem auf die französischen Sovereign-Cloud-Versuche Andromède, Numergy und Gaia-X als warnende Beispiele: viel Dokumentation, wenig praktisches Ergebnis.

Besonders interessant: Es geht Gartner nicht nur um den Speicherort der Daten. Technologische Souveränität umfasse, so Toombs, auch „die Kontrolle über Cloud-Infrastruktur, Management-Software, Sicherheitsmechanismen, Supportprozesse und die zugrunde liegenden Lieferketten“. Aha. Wobei das Thema Management-Software wäre ja sogar lösbar – die Welt steht voll mit Open-Source-Stacks für Cloud-Management. Aber Lieferketten, Halbleiter, Tooling-Tiefe, eingespielte SRE-Praxis? Das lässt sich nicht in einem Förderprogramm zaubern.

Und dann der Punkt, der in der allgemeinen Souveränitäts-Debatte gerne untergeht – Exit-Strategien. Zitat aus dem Heise-Stück:

Besonders kritisch sieht Gartner die fehlenden Exit-Strategien vieler Cloudkunden. Organisationen müssten klar festlegen, unter welchen Bedingungen sie einen Anbieter verlassen. Wer das versäume, schaffe Folgeprobleme und bringe seine Teams in eine kaum lösbare Lage, warnte Toombs. Nötig seien konkrete Auslöser, feste Budgets und realistische Zeitpläne.

Das ist kritischer, als man so glaubt. Auch deshalb, weil ein Exit nicht zwangsläufig selbst motiviert sein muss. Der Anbieter kann dir kündigen – aus regulatorischen Gründen, aus Compliance-Gründen (gut, die Wahrscheinlichkeit dafür ist nicht so hoch), weil deine Branche plötzlich auf irgendeiner Sanktionsliste landet, weil bestimmte Workloads in der Region nicht mehr gefahren werden dürfen. Der Anbieter kann auch wegbrechen – Insolvenz, M&A, Geschäftsmodell-Pivot. Auch für diese Fälle braucht es einen funktionierenden Exit-Plan, und die Erfahrung zeigt: Den haben die wenigsten. Wer das versäumt, schafft genau die kaum lösbare Lage, die Toombs beschreibt – selbst für den Fall, in dem einem die Entscheidung abgenommen wird.

Als Strategien nennt Gartner Sovereign-Cloud-, Hybrid- und Multicloud-Ansätze, plus zwei Konzepte mit hörbar resignierten Namen: „Shelter in Place“ (bewusst beim Anbieter bleiben trotz bekannter Risiken) und „Hide in Plain Sight“ (Daten segmentieren oder stärker verschlüsseln). Letzteres klingt nach Risikomanagement, ersteres ein bisschen nach „Augen zu und durch“. Beides ist legitim, beides ist aber auch ein Eingeständnis, dass die strukturelle Abhängigkeit nicht weggeht – nur weil die Powerpoint mit „digitale Souveränität“ überschrieben ist.

Claude Code: Wochenlimits +50 % – die dritte Eskalation in fünf Wochen

Wie weiter oben im Pick zu den Programmatic Credits schon angerissen – Anthropic meint es ernst, und der Druck muss real sein. Sonst würden die das Marketing für Claude Code nicht so hochfahren. Gestern hat @ClaudeDevs auf X angekündigt:

Claude Code weekly limits are increasing 50%, now through July 13. Live now for all Pro, Max, Team, and seat-based Enterprise users.

Zur Einordnung: Das ist nicht die erste Maßnahme dieser Art, sondern die dritte in fünf Wochen. Pasquale Pillitteri rekonstruiert die Sequenz sauber: am 16. April die „Claude 2x“-Off-Peak-Promo, am 6. Mai die Verdopplung der Fünf-Stunden-Limits plus komplette Abschaffung der „Peak Hours“ für Pro und Max, und jetzt am 13. Mai die wöchentliche +50 %. Free-Plan natürlich ausgeschlossen, Promo läuft bis 13. Juli, also exakt zwei Monate. Stackt mit der Vorwoche.

Drei aufeinanderfolgende Capacity-Bumps in fünf Wochen sind keine Routine-Optimierung – das ist eine defensive Bewegung gegen den anhaltenden Codex-Druck. Drei Minuten nach dem offiziellen Tweet hat ein anderer Account das ungeschminkt formuliert:

This puts Claude Code rate limits on par with Codex. I cancelled my Max plan twice over rate limits

„On par with Codex“ ist exakt die Lesart, die Anthropic selbst nicht aussprechen wollte, die der Markt aber sofort übernommen hat.

Wo die zusätzliche Kapazität herkommt, ist auch erklärt: Anthropic hat sich Compute bei SpaceX besorgt – „all“ der Kapazität aus Colossus 1, also rund 300 MW und über 220.000 NVIDIA-GPUs, sollen direkt in Pro- und Max-Plans fließen. Das wirft ein interessantes Licht auf den weiter oben skizzierten Hahnenkampf zwischen Sam Altman und Elon Musk auf X: Während OpenAI sich öffentlich mit Elmo duelliert und Altman zum Gegenangriff bläst, kauft Anthropic im Hintergrund Compute bei Musks Firma ein. Lieferantenpolitik aus dem Drehbuch eines mittelguten Tarantino-Films – oder die nüchterne Erinnerung daran, dass im KI-Geschäft am Ende der Strom regiert, nicht das Statement.

Für mich, der weiterhin nicht wechselt – auch das hatten wir schon weiter oben: Die Limit-Erhöhungen sind willkommen, ändern aber nichts an der Grundsatzfrage aus dem Programmatic-Credits-Pick. Dort werden die Töpfe getrennt, hier wachsen sie selbst. Das ist die zweite Halbzeit derselben Defensiv-Strategie – und solange sie hält, profitieren Heavy User unmittelbar. Wie lange Anthropic dieses Tempo durchhält, ist die offene Frage.

Grok Build – jetzt hat auch xAI ein CLI

Ein eigenes CLI zu bauen ist 2026 das neue „ne eigene Smartphone-App haben“. Wer hätte gedacht, dass die Kommandozeile im Jahr 2026 nach Christus noch mal hip wird? Elmos AI-Bude möchte auf den Zug aufspringen, auch wenn Grok aktuell nicht berühmt für Coding- und agentische Fähigkeiten ist (hatten wir sogar weiter oben schon mal).

Konkret: xAI hat gestern Grok Build in Early Beta gestartet – ein agentisches CLI für Coding-Aufgaben, exklusiv für SuperGrok-Heavy-Abonnenten. Plan Mode, Subagents (bis zu acht parallel), Headless-Modus mit -p-Flag, ACP-Support, native Worktree-Integrationen. Unter der Haube läuft Grok 4.3 mit einer angeblichen 16-Agent-Heavy-Architektur und einem zwei Millionen Token großen Context Window. Das ist auf dem Papier ordentlich – zwei Millionen Token reichen für ziemlich große Codebases.

Der Preis hat es allerdings in sich: SuperGrok Heavy kostet rund 300 Dollar im Monat, womit sich xAI klar an Power-User und professionelle Entwickler richtet. Zum Vergleich: Claude Code Max 20x liegt bei 200 Dollar, Codex Plus bei 20 Dollar. Wer mit dem Argument „großes Context Window“ auf 300 Dollar pro Monat hochwill, muss sehr klar machen, dass der Rest der Pipeline mithält – also Modellqualität, Tool-Use, Reasoning, Fehlerquote, Latenz. Und genau das ist bei xAI bisher die Achillesferse: Grok 4.3 ist in den einschlägigen Coding- und Reasoning-Benchmarks nicht in der Spitzengruppe.

Heißt für mich: Die Architektur (Plan Mode, Subagents, ACP, große Context Window) ist nicht uninteressant, das Preisschild macht es zur Nischen-Angelegenheit. Wer SuperGrok Heavy ohnehin abonniert hat – aus welchem Grund auch immer – probiert es aus. Alle anderen warten ab, ob Grok Build in unabhängigen Vergleichen gegen Claude Code oder Codex liefert, oder ob es ein weiterer Eintrag in die Liste der CLIs wird, die mehr Demo als Daily Driver sind.

Google Agent Skills – zwei Repos, ein Konzept

Ja, warum denn auch nicht. Ich hatte mir schon Sorgen gemacht, gar nichts von Google selbst diese Woche. Google Skills ist der Pick – aber dazu eine kleine Korrektur, weil die Geschichte etwas verzweigter ist, als es auf den ersten Blick scheint.

Es gibt zwei Repos, nicht eines: Erstens das oben genannte google/skills – aktuell 13 Skills, alle für Google Cloud (Gemini API in Agent Platform, AlloyDB, BigQuery, Cloud Run, Firebase, GKE und ein paar Well-Architected-Framework-Rezepte). Mit 4,6k Sternen schon ordentlich gestartet, aber thematisch eng auf Google-Cloud-Produkte begrenzt und mit dem Hinweis „This repository is under active development“ versehen. Zweitens google-gemini/gemini-skills (das bisher völlig an mir vorbeigegangen ist) – konkreter, mit drei dedizierten Skills für die Gemini API (gemini-api-dev, gemini-live-api-dev, gemini-interactions-api), Performance-Zahlen aus eigenen Evaluierungen (96 % korrekte API-Code-Generierung mit Gemini 3.1 Pro) und einem zugehörigen MCP-Server unter gemini-api-docs-mcp.dev. Stand 14. Mai: 3.500 Sterne auf Github.

Was den eigentlichen Story-Punkt ausmacht: Beide Repos verwenden agentskills.io als gemeinsame Spec. Das ist dasselbe Format, das auch Anthropic mit Claude Skills etabliert hat. Die Installation läuft entweder über Vercels skills CLI oder die Context7 CLI, beide installieren Skills aus beliebigen GitHub-Repos. Heißt: Skills sind dabei, ein cross-vendor Standard zu werden – Anthropic, Google, Vercel, Context7 ziehen am gleichen Strang, und auch xAI ist mit den eigenen Skills für Grok (siehe weiter oben) auf den Zug aufgesprungen.

Mein Take: Das interessantere Repo ist google-gemini/gemini-skills, weil es genau die Knowledge-Gap adressiert, die jedes LLM hat – nämlich die Frage, wie man heute Code gegen die Gemini API schreibt, ohne in zwei Jahre alten SDK-Patterns hängen zu bleiben. Das google/skills-Repo ist hingegen aktuell noch eher ein Aufschlag und thematisch eng. Beides zusammen ist aber ein klares Signal: Skills werden zur Default-Form, in der Modellhersteller Best Practices an Agents weiterreichen. Wer eigene Pipelines baut, sollte das Format jetzt verstehen, nicht erst, wenn die fünfte Plattform es übernommen hat.

Damit hätten wir diese Woche auch wieder abgehakt. Über 5.000 Wörter – Pamphlet-Niveau. Und wenn die Branche so weiter pusht, wird's ab Juni dann ein Buch.