Kategorie: Meinung

Ein 1,5-Milliarden-Dollar-Dienstleistungsunternehmen hat Anthropic im Mai angekündigt, aufgesetzt mit Blackstone, Hellman & Friedman, Goldman Sachs und weiteren Private-Equity-Häusern. Kein Modelltraining, keine Rechenzentren, sondern Ingenieure, die bei Kunden im Haus arbeiten und KI in bestehende Abläufe einbauen. OpenAI hat wenige Monate später nachgelegt: über 4 Milliarden Dollar für eine eigene Deployment-Firma, angeführt von TPG. In der Branche hat sich dafür ein Begriff durchgesetzt: DeployCo.

Tanay Jaipuria, Partner bei Wing, beschreibt in seinem Newsletter, wie diese Firmen entstehen, warum gerade jetzt und wie ihr Playbook aussieht. Er unterscheidet drei Ausprägungen, mehrere Motive und einen zweiten Weg, der ganz ohne Dienstleistung auskommt. Der folgende Text fasst seine Analyse zusammen und ordnet ein, was davon für Unternehmen relevant ist, die KI-Agenten integrieren wollen.

Wer verstehen will, was da passiert, kann an ein Kraftwerk denken. Das Modell liefert den Strom, aber im Gebäude liegen noch keine Leitungen, die Sicherungen sind falsch dimensioniert, und die Maschinen laufen auf einer anderen Spannung. Genau diese Zwischenetage — Verkabelung, Absicherung, Inbetriebnahme — ist das Geschäft der DeployCos. Und sie lässt sich schlecht automatisieren.

Was OpenAI, Anthropic und AWS konkret aufgebaut haben

Anthropic hat sein Vorhaben im Mai angekündigt: ein 1,5-Milliarden-Dollar-Unternehmen für KI-Dienstleistungen, aufgesetzt mit Blackstone, Hellman & Friedman, Goldman Sachs und weiteren Finanzinvestoren. Im Juli ging es als „Ode with Anthropic“ an den Start, gebaut auf der Übernahme von Fractional AI. Die Zielgruppe sind mittelgroße Unternehmen, der Einstieg läuft über die Portfoliogesellschaften der beteiligten Geldgeber. Der Aufbau folgt also keiner Produktlogik, sondern einer Vertriebslogik: Erst kommen die Portfoliogesellschaften der beteiligten Geldgeber, dann der Rest des Marktes.

OpenAI hat parallel die OpenAI Deployment Company angekündigt, die über 4 Milliarden Dollar einsammelte und mehrheitlich von OpenAI selbst gehalten wird. Sie startete mit der Übernahme von Tomoro und, so der Autor, mit über 100 forward deployed engineers vom ersten Tag an. Beide Konstruktionen ähneln sich: eine separat kapitalisierte Gesellschaft, ein zugekauftes Applied-AI- oder Serviceunternehmen als Kernteam, einige eigene Ingenieure aus dem Labor und die Portfolios der Geldgeber als erste Kundschaft. Auch die Hyperscaler spielen dieselbe Partitur — AWS hat Ende Juni eine Milliarde Dollar für eine eigene Einheit für forward deployed engineering zugesagt.

Der Diffusion Gap: mehr Fähigkeit als Anwendung

Warum braucht es überhaupt Menschen, wenn die Modelle doch so viel können? Der Autor nennt zwei Gründe. Der erste ist die Diffusionslücke, die Pat Grady beschrieben hat und die oft auch als capability overhang auftaucht: Die Modelle leisten deutlich mehr wertvolle Arbeit, als ihnen die meisten Organisationen tatsächlich übertragen. OpenAI hat versucht, das zu messen. In GDPval werden echte Arbeitsergebnisse aus vielen Wissensberufen von Fachleuten bewertet — und die Modelle lösen mehr als die Hälfte der Aufgaben besser als die menschlichen Experten. Zwischen dieser Fähigkeit und dem Alltag in den Unternehmen liegt ein Graben, und DeployCos sind ein Weg, ihn zu schließen.

Der zweite Grund ist Kultur und Organisation. KI in Betrieb zu nehmen heißt nicht, ein Modell laufen zu lassen. Es heißt, Zugang zu den richtigen Systemen zu bekommen, Workflows neu zu schneiden, Zustimmung quer durch die Abteilungen zu holen und die Art zu ändern, wie Menschen arbeiten. Diese Aufgaben liegen zwischen den Teams, sie sind selten das Kerngeschäft einer einzelnen Person, und ein Modell löst Abstimmung, Anreize und Vertrauen nicht von selbst. Deshalb boomt die Nachfrage nach Beratung, nur anders etikettiert. Accenture hat in den letzten drei Jahren rund 11,5 Milliarden Dollar an Aufträgen im Bereich generative KI verbucht. Palantir, das den forward deployed engineer vor über einem Jahrzehnt geprägt hat, wächst seit zwölf Quartalen in Folge beschleunigt, und CTO Shyam Sankar stichelte in der jüngsten Telefonkonferenz zu den Quartalszahlen, nur Palantir habe echte FDEs, alle anderen hätten bloß glänzende Sales Engineers.

Das Playbook der forward deployed engineers

Die eigentliche Arbeit folgt einem Muster, das sich über fast alle Anbieter wiederholt. Ein FDE setzt sich in den Kunden und beginnt mit wenigen Abläufen, die hohen Wert haben und trotzdem überschaubar sind — Aufgaben also, deren Ergebnis sich prüfen und verifizieren lässt. Er versteht den Ablauf, baut eine Agent-Harness, die das Modell an die Daten und Systeme des Unternehmens anbindet, und schreibt Evaluierungen, wo sie fehlen. Erst wenn der Agent eine Qualitätsschwelle erreicht, geht er in den Betrieb, und idealerweise entsteht eine Lernschleife, die ihn in Produktion weiter verbessert.

Bemerkenswert ist die Reihenfolge. Nicht die Architektur kommt zuerst, sondern der Ablauf beim Kunden, und nicht die flächendeckende Einführung kommt zuerst, sondern der eine Workflow, der sich beweisen muss. Das erklärt, warum AI-Deployment so personalintensiv bleibt: Jeder Kunde hat eigene Systeme, eigene Datenqualität und eigene Machtverhältnisse. Die Zwischenetage aus dem Kraftwerk-Bild lässt sich nicht allein als Standardprodukt verkaufen: Es bleibt viel Arbeit vor Ort, auch wenn die Anbieter gemeinsame Plattformen und Module darunterlegen.

Drei Typen von DeployCos im Vergleich

Die neuen AI-DeployCos lassen sich grob in drei Gruppen teilen. Horizontale Anbieter helfen beim KI-Deployment in vielen Funktionen und Branchen — dazu zählen die Ventures der Labore, aber auch Häuser wie Distyl und BrainCo, die gemeinsame Plattformen und Module gebaut haben, auf denen sie Agenten aufsetzen. Funktionsspezifische Anbieter wollen der vertraute Partner für genau eine Funktion über Branchen hinweg werden: Sierra und Decagon im Kundenservice, die inzwischen weiter ausgreifen, oder Lio im Einkauf. Branchenspezifische Anbieter bringen Agenten in eine einzige Industrie, etwa Tennr im Gesundheitswesen oder Happyrobot in der Logistik.

Unter der Haube sehen die letzten beiden Gruppen einander sehr ähnlich. Sie haben ein Kernsystem für wiederkehrende Abläufe ihrer Branche gebaut, doch bis der Agent beim einzelnen Kunden läuft, bleibt viel letzte Meile. Deshalb teilen sie ihre Teams: Die einen bauen das System, die anderen bringen Agenten in die Kunden und tragen Titel wie Agent Deployment, Forward Deployed Engineer oder Deployment Strategist. Ein offenes Geheimnis ist, dass viele vertikale KI-Anwendungsfirmen, die an große Unternehmen verkaufen, im Grunde ebenfalls DeployCos sind. Ihre Workflows sind so speziell, die Integrationen so individuell, die Evaluierungen so eigensinnig und das Change Management so aufwendig, dass sie zwangsläufig schwere FDE-Arbeit leisten.

Warum die Labore selbst mitmischen

Für die Modellhäuser kommen eigene Motive dazu. Deployment-Arbeit erzeugt lange Spuren darüber, wie echte Arbeit in Branchen tatsächlich abläuft. Die sind wertvoll, als Trainingsdaten oder schlicht als Einsicht, wo sich der nächste Modellsprung lohnen könnte. Zweitens liegen die Modelle der großen Häuser bei vielen Unternehmens-Workflows dicht beieinander. Wer eingebettet ist und die Agenten tatsächlich deployt, gewinnt eine Form von Bindung, die sich über Modellqualität allein nicht herstellen lässt. Drittens die Marktfrage: Wer Agenten baut und betreibt, kann für Ergebnisse bezahlen lassen statt für Tokens. Das erlaubt höhere Preise, als es reine Inferenz je rechtfertigen würde.

Der Rollup-Ansatz: kaufen statt einsteigen

Es gibt noch einen zweiten Weg, den der Autor nur anreißt, und er ist einen eigenen Text wert. Statt sich in ein Unternehmen hineinzusetzen, kann man es gleich kaufen und KI von innen einpflanzen. Long Lake hat gerade die Börsennotierung von Amex GBT für 6,3 Milliarden Dollar in eine Privatgesellschaft überführt, Sequence den Versicherungsmakler Baldwin für 7,7 Milliarden Dollar. Wer das Asset besitzt, kann Prozesse umbauen, KI direkt einziehen lassen und den gesamten Ertrag daraus behalten. Dafür ist dieser Ansatz kapitalintensiver und schwerer zu skalieren als das Dienstleistungsgeschäft.

Für Unternehmen, die eine KI-Einführung planen, verschiebt sich damit die entscheidende Frage. Ob die DeployCos von OpenAI und Anthropic den Markt dominieren oder die alten Häuser aus Beratung und Systemintegration, ist für dich als Verantwortliche zweitrangig. Relevant ist, dass die letzte Meile der KI-Implementierung im Unternehmen offenbar nicht verschwindet, sondern zur Dienstleistung mit Menschen, Namen und Terminen wird. Wenn du Angebote vergleichst, frag deshalb nicht nur nach dem Modell, sondern danach, wer tatsächlich bei dir im Haus sitzt, wie viele Workflows er zuerst anfasst und woran gemessen wird, dass sie funktionieren.

Das Muster ist unspektakulär und gerade deshalb robust. Modelle werden besser, aber sie schließen die Lücke zur eigenen Organisation nicht selbst, und sie verhandeln auch keine Zuständigkeiten. Die DeployCos sind im Kern eine Antwort auf diese Lücke. Das bedeutet konkret: KI-Agenten in Unternehmen zu integrieren bleibt vorerst ein Projekt mit Menschen darin, mit einem klar umrissenen ersten Ablauf und mit prüfbaren Ergebnissen — und wer das ernst nimmt, hat bessere Chancen als jemand, der auf den nächsten Modellstart wartet.

Quelle: tanayj.com

Ein Agent bekommt eine Spezifikation, generiert Code, schickt ihn durch Unit-Tests, Mutationstests und statische Analysen und übergibt am Ende der Pipeline das Ergebnis zur Freigabe. Zwischen der ursprünglichen Aufgabe und der Auslieferung hat kein Mensch eine Zeile gelesen. Robert C. Martin, Autor von Clean Code, hat diesen Ansatz öffentlich beschrieben: Er liest den von seinen Agenten erzeugten Code nicht mehr, sondern umgibt die Agenten mit strengen Einschränkungen – Tests, Gherkin-Szenarien, QA-Verfahren, Qualitätsmetriken, Mutationstests, Testabdeckung. Er sagt, so gewinne er Vertrauen in den erzeugten Code, weil dieser den ganzen Prüfparcours durchlaufen muss.

Aussagen bekannter Persönlichkeiten ändern sich schnell, und Martin hat sein Vorgehen inzwischen relativiert. Darum geht es hier nicht. Dem Softwareentwickler Mark Seemann geht es um eine andere Frage: Was bedeutet es für die Softwareentwicklung, wenn KI-Agenten Code Review teilweise ersetzen? Am besten erklärt man das mit einem Bild, das du kennst – der Sicherheitskontrolle am Flughafen. Niemand durchsucht jedes Gepäckstück von Hand. Stattdessen greifen mehrere Schleusen ineinander: Röntgen, Metalldetektor, Stichprobe, Hundestaffel. Keine Station ist unfehlbar, aber zusammen filtern sie den größten Teil der Gefahren heraus. So funktioniert eine gute Testpipeline.

Warum das Lesen von Code nie ein Garant war

Wenn du diese Analogie akzeptierst, wirkt die Vorstellung, den Code nicht mehr zu lesen, weniger radikal. Der erste Reflex lautet: Wie soll man wissen, ob der Code korrekt ist, wenn ihn niemand anschaut? Dieser Reflex stammt aus einer Zeit, in der das Lesen die einzige Kontrolle war. Programmierer machen Fehler. Wir schreiben Code im Glauben, dass er etwas Bestimmtes tut, und stellen später fest, dass er sich anders verhält – eine Nullreferenz, eine Schleife, die um eins daneben liegt, ein Zustand, der unerwartet verändert wird. Das passiert ständig.

Code Review gehört zu den wirksamsten Methoden, um solche Defekte zu finden. Die Fachliteratur – etwa Code Complete, zweite Auflage, Kapitel 21 – weist darauf hin, dass systematische Reviews einen erheblichen Teil der Fehler abfangen. Aber nicht jeden. Manche Fehler entkommen selbst einer disziplinierten Inspektion. Ein Mensch, der auf Code schaut, war also nie narrensicher. Wer heute verlangt, KI-generierten Code in jedem Fall durchzulesen, verlangt eine Sicherheit, die auch das menschliche Lesen nie geboten hat.

Software Engineering als Abfolge falsifizierbarer Vorhersagen

Dave Farley beschreibt in Modern Software Engineering eine Sicht auf das Fach, die sich mit Seemanns eigener deckt. Software Engineering läuft im Kern darauf hinaus, rasch Rückmeldung auf falsifizierbare Aussagen über das System zu bekommen. Eine Behauptung wie „diese Funktion liefert die Summe der Bestellungen“ wird nicht dadurch wahr, dass sie plausibel klingt, sondern dadurch, dass ein Test sie widerlegen könnte und es nicht tut. Das Prinzip gilt, egal ob ein Mensch oder ein Modell den Code getippt hat.

Ein verwandtes Thema ist der Umgang mit KI-Agenten, die wie Teams organisiert werden: Ein Agent schreibt automatisierte Tests, ein zweiter macht das Code Review, ein dritter prüft die Konsistenz mit den Anforderungen. Ist das ein unendlicher Regress – wer prüft am Ende den Prüfer? Unsere menschenzentrierten Praktiken sind genauso wenig perfekt. Auch die testgetriebene Entwicklung, für Seemann der wissenschaftlichste Zugang zur Softwareherstellung, kennt ihre Fehlerquelle: Der häufigste TDD-Fehler ist der Test, den du nicht geschrieben hast. Ein fehlender Testfall lässt das System unterbestimmt, und niemand merkt es.

Die Haftungsfrage: Wer unterschreibt, wenn niemand schreibt?

Ein vollständig agentengesteuertes Release ist leicht vorstellbar: Menschen sind beteiligt, aber nicht als Programmierer und nicht als Reviewer. Niemand blickt in den Code, das Team verlässt sich auf andere Qualitätssicherungstechniken. Angenommen, die Fehlerquote liegt dabei niedriger als in jedem vergleichbaren menschlichen Prozess – niedriger, nicht null. Auch dann gelangen Fehler in die Produktion. Viele sind harmlos: eine leicht verschobene Schaltfläche, eine Anzeige in der falschen Sprache, eine doppelt eintreffende Nachricht. Andere gehen weiter: falsch berechnete Rabatte, ein hängendes Signal, im schlimmsten Fall eine tödliche Fehlfunktion.

Sobald der Schaden groß genug ist, stellt sich die Frage nach der Verantwortung. Am leichten Ende steht der Mars Climate Orbiter, der 327,6 Millionen Dollar kostete, ohne dass ein Gesetz gebrochen wurde. Ein Softwareunternehmen, in dem ein solcher Fehler ohne Konsequenz bleibt, wäre die Ausnahme – irgendjemand trägt die Folge, im Zweifel ein Sündenbock. Sobald rechtliche Haftung ins Spiel kommt, geht es vor Gericht, und wie im Dieselskandal können einzelne Entwickler zur Verantwortung gezogen werden. Ob das fair ist oder die tatsächlichen Abläufe widerspiegelt, ist nebensächlich. Gerichte bilden sich ihre Auffassung davon, wer verantwortlich ist, unabhängig davon, wie Software entsteht.

Der Dialog, den Seemann ironisch entwirft, trifft es gut. Ein Angeklagter wendet ein, das LLM habe den Fehler geschrieben. Das Gericht antwortet sinngemäß, es könne kein Sprachmodell ins Gefängnis schicken, sehr wohl aber die Person, die das Release abgezeichnet hat. Wer über ein vollständig KI-gesteuertes Vorgehen nachdenkt, muss die Haftungsfrage von Anfang an mitdenken. Die Unterschrift unter der Freigabe bleibt ein menschlicher Akt, auch wenn die Zeilen darunter maschinell erzeugt wurden.

Menschen spielen die Wahrscheinlichkeiten – das Tesla-Beispiel

Ein Blick in ein anderes Feld hilft. Im Juni 2026 hat die dänische Verkehrsbehörde Færdselsstyrelsen das Tesla-FSD-System zugelassen, mit der Auflage, dass der Mensch hinter dem Lenkrad letztverantwortlich bleibt. Fahrer sollen den Verkehr beobachten und eingreifen, sobald eine gefährliche Situation droht. Die Prognose ist absehbar: Je besser das System funktioniert, desto sorgloser werden die Fahrer. Nach einigen Wochen am Steuer sitzen viele am Handy und achten kaum noch auf den Verkehr. Es geht meistens gut.

Und dann kommt selten ein Unfall. Nach aktuellem dänischem Recht droht dem Fahrer, wenn Menschen ums Leben kommen, eine Verurteilung wegen fahrlässiger Tötung – in der Regel Freiheitsstrafe. Ob der Auslöser ein Softwarefehler war, ändert daran nichts. Rechtlich liegt die Verantwortung an einer anderen Stelle, oft weil die Gesetzgebung der technischen Realität hinterherhinkt. Dasselbe Muster, erwartet Seemann, wird sich bei KI-gesteuerter Softwareentwicklung einstellen. Menschen werden auf die Wahrscheinlichkeit setzen, weil sie verlockend aussieht. Wie viel Aufwand du in Absicherungen steckst, spielt dabei kaum eine Rolle: Du kannst das ausgefeilteste Verifikationssystem aufbauen und trotzdem für Fehler haftbar sein.

Das führt zu einer unangenehmen Frage: Wie fühlst du dich dabei, LLM-generierte Software zu veröffentlichen? Bist du bereit, für eine KI ins Gefängnis zu gehen? Die Antwort verlangt eine Vorstellung davon, was Verantwortung künftig bedeuten soll.

Was das konkret bedeutet

Software Engineering ist vielleicht nicht das, was wir geglaubt haben. Genauer: Es ist nicht auf die Methoden festgelegt, die um menschliche Programmierer und Tester kreisen. Eine vollständig automatisierte Softwareherstellung ist denkbar, und sie kann mindestens so sicher arbeiten wie das, was wir heute kennen. Der nicht-technische Teil dieses Wandels könnte der schwierigere werden.

Während die Systeme zuverlässiger werden, bleibt der menschliche Begriff von Haftung und Verantwortung zurück. Wenn etwas schiefgeht, schreiben Unternehmen den Fehler dann als „niemandes Schuld“ ab? Behandelt man schwere Defekte vor Gericht als eine Art Unfall, vergleichbar einem technischen Gebrechen? Oder trägt wieder ein Mensch die Verantwortung – und wer soll das sein, wenn niemand den Code geschrieben hat?

Für die Praxis folgt daraus mindestens eines: Wer KI-generierte Software veröffentlicht, sollte nicht nur in Tests und Code Review durch KI-Agenten investieren, sondern auch in eine klare Antwort auf die Unterschrift. Wer zeichnet ab, wer haftet, wer dokumentiert, welche Prüfungen wann stattgefunden haben. Die Testpipeline ist das eine, die Nachvollziehbarkeit der Entscheidung das andere. Der Flughafenvergleich hilft bis zuletzt: Die Kontrollen mögen automatisiert sein, doch die Verantwortung für das, was durchgelassen wurde, trägt der Betreiber – nicht das Röntgengerät.

Quelle: blog.ploeh.dk

Warum braucht das Web ein eigenes Protokoll für KI-Agenten? Yoav Weiss hat in den vergangenen Monaten die WebMCP-Werkzeuge für Shopifys Storefront produktionsreif gemacht und ausgeliefert. Am 12. Oktober hat er in seinem Blog aufgeschrieben, warum er sich dafür entschieden hat. Der Text ist das Plädoyer eines Beteiligten: Weiss arbeitet inzwischen auch am Standardvorschlag mit und betont, dass er seine persönliche Meinung wiedergibt. Rückenwind sieht er durchaus – OpenAI hat WebMCP in ChatGPT Desktop eingebaut, Cloudflare unterstützt es –, zugleich läuft beim W3C noch die Prüfung durch die Technical Architecture Group, und WebKit lehnt den Ansatz ab. Was WebMCP technisch leistet, warum es laut Weiss über die Zukunft des Co-Browsings entscheidet und welche Fragen offen sind, schauen wir uns an.

Drei Wege, wie KI-Agenten mit Webdiensten interagieren

Weiss unterscheidet drei Muster. Das erste nennt er direkte Backend-Kommunikation: Der Agent ruft selbst die nötigen Schnittstellen auf, um ein Ziel zu erreichen; klassische MCP-Server von Webdiensten sind das bekannteste Beispiel. Beim zweiten Muster, dem Embedding, bettet der Agent Teile der Web-Erfahrung in seinen Chat ein und zeigt sie dem Nutzer – MCP Apps fallen in diese Kategorie. Das dritte Muster ist die direkte Interaktion im Browser, also Co-Browsing: Der Agent arbeitet parallel zu einer Browsersitzung, versteht die Seite über DOM- und Accessibility-Analyse sowie Screenshots und versucht, sie durch Klicks auf Buttons und Links zu automatisieren.

Diese Einteilung hat praktische Folgen. Weiss argumentiert, dass Co-Browsing das einzige Modell ist, in dem Entwickler und Nutzer die Kontrolle über die Erfahrung behalten und der Nutzer jederzeit vom Agenten übernehmen kann. Nur hier bleibe das Web auch tatsächlich das Web. Verlagert man dagegen alles in MCP-Server und eingebettete Widgets, wandert die Gestaltung der Erfahrung vom Website-Betreiber zum Agentenhersteller – ein Kontrollverlust, den Weiss nicht hinnehmen will.

Warum Co-Browsing gewinnen muss – und was WebMCP dafür tut

Zwischen Anspruch und Praxis liegt eine Lücke, und Weiss benennt sie offen. Keine der frühen Co-Browsing-Demos, die er gesehen hat und die auf DOM- oder Screenshot-Interaktion setzten, bot eine gute Nutzererfahrung. Sie wirkten langsam, führten dem Nutzer vor, wie der Agent sich durch die Seite tastete, und lieferten keine optimalen Ergebnisse. Man kann sich das wie einen Baumarkt vorstellen: Wer weiß, in welchem Gang die Schrauben liegen, ist in zwei Minuten fertig. Ein Helfer ohne Beschilderung läuft dagegen jede Reihe ab, öffnet Kartons und hält am Ende das falsche Gewinde in der Hand.

WebMCP setzt hier an. Die Website kann dem Agenten direkte JavaScript-Werkzeuge registrieren, die er aufrufen darf, um eine Aufgabe zu erledigen. Jedes Tool bringt ein explizites Eingabeschema mit, bald auch ein Ausgabeschema, dazu eine Beschreibung dessen, was es tut und wann es sinnvoll aufzurufen ist. Der Agent wählt dann gezielt das passende Werkzeug, statt sich wie ein Mensch durch Formulare und Klickstrecken zu arbeiten. So umgeht der Agent das langsame Tasten, das die frühen Demos so unangenehm machte; die direkte Interaktion wird laut Weiss deutlich schneller, besser und billiger.

Weiss beschreibt die Grundidee als einfach, das dahinterliegende Primitiv aber als mächtig. „WebMCP ist Web Performance für KI-Agenten im Web“, schreibt er. Nicht der Agent wird schlauer, sondern die Website wird für ihn schneller bedienbar. Nach Weiss’ Überzeugung würde das deutlich bessere Co-Browsing-Erlebnisse ermöglichen.

Was die ersten Messungen zeigen

Zahlen nennt Weiss aus zwei Quellen. Das Team von nekuda.ai hat gemessen, dass WebMCP zwischen 2,5- und 7,5-mal schneller und bis zu 47-mal günstiger arbeitet als andere Methoden der direkten Interaktion. Der Vergleich bezieht sich also nicht auf Menschen, sondern auf Agenten, die eine Seite selbst bedienen müssen. Wie die Messung aufgebaut war, beschreibt der Beitrag nicht.

Shopifys Checkout-Team, also ein Team von Weiss’ eigenem Arbeitgeber, führte ein ähnliches Experiment durch und kam auf 2,7-mal schnellere Abläufe bei 58 Prozent geringeren Kosten. Den WebMCP-Checkout-Support hatten Kollegen ergänzt, nachdem die Storefront-Werkzeuge standen. Auffällig ist die Erfolgsquote: 60 von 60 Versuchen gelangen über WebMCP, mit Browser-Automatisierung waren es 56 von 60.

Beide Zahlen stammen von Beteiligten, die WebMCP voranbringen wollen, und Versuchsaufbau, Aufgaben und Kostenrechnung sind im Beitrag nicht dokumentiert. Als allgemeingültig sollte man sie deshalb nicht lesen. Plausibel ist die Richtung trotzdem: Ein Tool-Aufruf liefert dem Agenten strukturierte Ergebnisse, während er bei der Browser-Automatisierung Screenshots und DOM-Ausschnitte deuten muss, die jeweils Rechenzeit und Token kosten.

Berechtigungen, Monitoring und Testbarkeit: die offenen Baustellen

So einfach die Grundidee ist, so viele Detailfragen hängen daran. Wer darf eigentlich Tools für eine Website registrieren? Bei dieser Frage hat sich nach Angaben von Weiss ein Permissions-Policy-Modell durchgesetzt, mit dem die Seite selbst entscheidet, welche Iframes Werkzeuge beisteuern dürfen. Außerdem sollen Tools für Agenten im Browser, für Erweiterungen und für Agenten innerhalb der Seite funktionieren – letztere potenziell aus einem Iframe einer fremden Domain. Jede dieser Varianten bringt eigene Sicherheitsfragen mit.

Offen ist auch, wie sich die Nutzererfahrung überhaupt überwachen lässt. Weiss nennt mehrere ungelöste Punkte: Welche Arten von Agenten sollen unterstützt werden? Wie bekommt man ein eindeutiges Signal vom Menschen? Wie testet man das Zusammenspiel über viele Browser und Agenten hinweg? Und wie schützt man Nutzer vor bösartigen Tools, die sich als hilfreich ausgeben? Diese Fragen werden nicht auf einmal beantwortet, sondern eine nach der anderen abgearbeitet.

Ein besonders praktisches Problem ist die Testbarkeit. Entwickler können ihre WebMCP-Implementierung heute mit dem webmcp-evals-Framework gegen einfache Modelle prüfen. Was fehlt, ist ein Weg, dieselben Tests gegen echte, repräsentative Agenten laufen zu lassen – also gegen Systeme, die einen eigenen Harness, einen Systemprompt und diverse Sicherheitsprüfungen mitbringen. Erst dann ließe sich verlässlich sagen, ob eine Website im Alltag wirklich gut funktioniert.

Bessere Websites statt Agenten?

Ein naheliegender Einwand lautet: Ist ein Agent, der durch die Seite navigiert, nicht bloß eine Krücke für schlechtes UX-Design? Würde eine bessere Produktsuche mit präziseren Kriterien nicht genügen, damit niemand durch 87 fast gleiche Produkte scrollen muss? Weiss gibt dem Einwand teilweise recht. Viele Händlerseiten lassen sich nicht nach jeder Eigenschaft filtern, die einem wichtig ist. Wer etwas sehr Bestimmtes sucht, etwa Trailrunning-Schuhe mit höchstens 5 Millimetern Sprengung oder leichte Ski zwischen 175 und 177 Zentimetern mit 80 bis 85 Millimetern Mittelbreite, scrollt ohne Agenten durch Produkte, liest Datenblätter und hofft, dass die Angabe überhaupt dasteht.

Damit ist für ihn aber nicht alles gesagt. Bei Heimwerkerprojekten lassen sich Material und Werkzeug meist online kaufen, und trotzdem hilft der Gang in den Laden, weil ein erfahrener Verkäufer den Überblick über das ganze Vorhaben gibt: was man für jeden Schritt braucht und wo man es bekommt. Agenten können ähnlich helfen, ein Projekt durchzudenken. WebMCP erlaubt Onlineshops nach Weiss, das Gegenstück zu diesem erfahrenen Verkäufer anzubieten.

WebMCP vs. HTML-Semantik: der Einwand von WebKit

Der grundsätzlichste Einwand kommt aus der Standardisierung selbst. In der laufenden Prüfung durch das W3C TAG und in der Ablehnung durch WebKit geht es um die Frage, ob JavaScript-Tools überhaupt nötig sind oder ob HTML-Semantik ausreicht. Die Sorge: Inhalte im Web könnten sich in „menschliche“ und „agentische“ Varianten aufspalten. WebKit betrachtet KI-Agenten als assistive Technologie und erwartet deshalb, dass sie für die Website unsichtbar bleiben; zusätzlich werden Missbrauchsrisiken genannt.

Weiss teilt diese Sorge teilweise, zerlegt sie aber in zwei verschiedene Risiken. Das erste ist Diskriminierung: Weil WebMCP-Aufrufe verraten, dass ein Agent beteiligt ist, könnten Websites agentische Nutzer benachteiligen. Dagegen hält er, dass Bot-Erkennung längst existiert und Websites solche Nutzer ohnehin aussperren könnten, wenn sie das wollten. Seine eigene Sorge liegt woanders: Ohne ein explizites Signal für „hier ist ein Mensch mit einem vertrauenswürdigen Agenten unterwegs“ werden agentische Nutzer fälschlich als Bots einsortiert, blockiert oder in schlechtere Varianten der Seite umgeleitet. Er hofft auf Web Bot Auth als Lösung für diesen Teil des Problems.

Das zweite Risiko ist semantische Divergenz, also unterschiedliche Fähigkeiten für agentische und nicht-agentische Besucher. Auch hier widerspricht Weiss: Solche Unterschiede gebe es bereits, etwa zwischen Nutzern mit und ohne JavaScript oder zwischen sehenden Nutzern und denen, die auf ARIA-Semantik angewiesen sind. Seiner Einschätzung nach entstehen diese Lücken aus Vernachlässigung, nicht aus Absicht. Entwickler hätten kein Interesse daran, komplett verschiedene Websites auszuliefern. Der Agent erspare einem Nutzer lediglich ein paar Umwege, das Ziel bleibe für alle dasselbe.

Aus dieser Argumentation folgt die Haltung zum Declarative WebMCP, das Formularsemantik wiederverwendet und erweitert. Weiss begrüßt den Vorschlag, sieht ihn aber als Ergänzung, nicht als Ersatz für imperative Tools. Nur Semantik für Agenten zu fordern, sei ungefähr so, als würde man JavaScript für überflüssig erklären, weil HTML ja alle Funktionen abbilden könne. Deklarative Aufrufe passen für einmalige Aktionen, doch viele Tools sind einzelne Schritte in einer längeren Aufgabe oder liefern dem Agenten nur Kontext – etwa eine Antwort aus den FAQ. Wer nach leichten Skiern mit 85 Millimetern Mittelbreite sucht, will das Ergebnis sehen und nicht dabei zuschauen, wie der Agent Kandidat für Kandidat durchblättert.

Was das für Shops bedeutet

Der Beitrag hat einen konkreten Hintergrund: Die Storefront-Werkzeuge von Shopify sind ausgeliefert, der Checkout-Support folgte. OpenAI hat WebMCP in ChatGPT Desktop integriert und die WebMCP Challenge ausgerichtet, Cloudflare unterstützt die Technik in Kitesurf und für seine Kunden, und Weiss’ eigener Vortrag auf dem W3C/GS1-Workshop zu Agentic Commerce kam nach seinen Worten sehr gut an. Beim Ausliefern stieß sein Team auf Lücken im Standardvorschlag, an deren Schließung er nun mitarbeitet. Wie WebMCP mit Zahlungen zusammenspielt, zeigt der Ansatz für Stripe-Zahlungen im Browser.

Für Händler ist ein Argument praktisch relevant. Ein Shop könnte einen eigenen Agenten ausliefern, das ist laut Weiss aber deutlich aufwendiger, und manche Nutzer wollen ohnehin lieber ihren vertrauten Agenten einsetzen als den eines Fremden. Mit WebMCP kann sich der Händler auf den Agenten des Kunden verlassen, der die Seite bedient, ohne die Intelligenz selbst liefern zu müssen. Zurück zum Baumarkt: Der Shop stellt keinen eigenen Helfer ein, er hängt eine Beschilderung auf, an der sich der Begleiter des Kunden orientiert.

Nüchtern betrachtet ist WebMCP kein fertiger Standard, sondern ein Vorschlag mit vielen offenen Fragen und einem gewichtigen Gegner in WebKit. Weiss’ Schluss ist entsprechend eine Überzeugung, keine Prognose: Er will, dass das Web als weitreichendste Computerplattform der Welt auch im Zeitalter der Agenten besteht. Dafür müsse Co-Browsing gewinnen, und WebMCP passe genau zu diesem Ziel – deshalb steckt er seine Energie hinein. Für Shopbetreiber heißt das vorerst: die Diskussion verfolgen und prüfen, welche Aufgaben ihres Shops sich als Werkzeug beschreiben ließen.

Quelle: blog.yoav.ws

Das Release, das heute Morgen ausgeliefert wurde, hat längst mitgeteilt, was damit nicht stimmt – den ganzen Tag schon, über mehrere Kanäle: in Logs, Traces, Session-Replays, Support-Tickets und Produktkennzahlen. Mit diesem Bild beginnt Boris Tane seinen Blogbeitrag vom 10. Oktober, und er zieht daraus eine zugespitzte Folgerung: Der einzige Grund, warum die Produktion noch immer Fehler hat, sei der Mensch, der diese Signale lesen, sortieren und an einen Coding-Agenten weiterreichen muss.

Tane kennt das Problem von innen. Er hat den größten Teil des vergangenen Jahrzehnts Observability-Werkzeuge gebaut und arbeitet heute an einem eigenen Produkt namens Polylane. Seine These: Selbstverbessernde Software ist unvermeidlich – Anwendungen, die ihre eigenen Signale lesen, entscheiden, was sich ändern soll, die Änderung ausliefern und prüfen, ob sie gewirkt hat. Zum ersten Mal, schreibt er, sei das nah genug, um es zu bauen.

Du erkennst die Kette wahrscheinlich wieder: Irgendwo fällt ein Fehler auf, irgendwer korreliert ihn mit anderen Beobachtungen, daraus wird ein Ticket, und am Ende promptet jemand einen Agenten, der daraus Code macht. Zwischen den Maschinen, die das Problem erzeugen, und den Maschinen, die es beheben könnten, steht ein Mensch als Übersetzer. Genau diese Rolle gerät jetzt unter Druck.

Der Feedback-Loop hat heute einen Menschen in der Mitte

Jede Signalquelle hat ihr eigenes Werkzeug und ihre eigene Zielgruppe. Ingenieure und SREs schauen in Observability-Plattformen wie Datadog, Produktmanager in Analytics-Tools wie Amplitude, Designer in Session-Replays wie FullStory, der Support in Zendesk. Wenn Nutzer in der Produktion auf Probleme stoßen, verteilt sich dieselbe Ursache über alle diese Systeme: Der Fehler landet im Tracing, der wütende Doppelklick im Replay, die Kennzahl sinkt im Dashboard, die Ticketzahl steigt im Helpdesk.

Niemand sieht das automatisch zusammen. Es braucht eine Person, die diese Beobachtungen bemerkt, sie gegeneinander legt, sie zu einer Beschreibung verdichtet und daraus eine Priorität ableitet. Erst danach beginnt die eigentliche Arbeit: Ein Ingenieur nimmt das Ticket, beschreibt das Problem einem Agenten und lässt sich den Fix generieren. Tane nennt das eine Umleitung, die keinen Sinn ergibt. Agenten lösen heute einige der schwersten Mathematikprobleme, vor denen die Menschheit je stand, aber das Sortieren von Fehlermeldungen hängt weiter an einem Menschen mit Zugriffsrechten auf fünf Dashboards.

Was ein „Meat Proxy“ ist

Für diese Zwischenrolle hat der Beitrag einen Begriff: Meat Proxy. Gemeint ist ein Mensch, dessen einzige Funktion darin besteht, Information zwischen zwei Maschinen zu tragen, die problemlos selbst miteinander reden könnten. Der Test ist einfach. Wenn du einen Screenshot von deinem Analytics-Dashboard machst, ihn in einen Coding-Agenten einfügst und schreibst, er soll untersuchen, warum diese Kurve fällt, und es beheben, dann bist du der Proxy. Das Dashboard hat die Daten, der Agent hat die Intelligenz, und du entscheidest, wann welcher Ausschnitt den Weg von A nach B nimmt.

MCP-Server und Connectors machen diesen Transport schneller, aber sie heben ihn nicht auf. Sie automatisieren das Kopieren, nicht das Auswählen. Welche Kennzahl überhaupt relevant ist, welcher Zeitraum betrachtet wird und wie das Problem in Worte gefasst wird — diese Entscheidungen bleiben beim Menschen. In dieser Auswahl steckt die eigentliche Arbeit, und genau dort geht Information verloren, weil niemand alle Signale gleichzeitig im Kopf halten kann.

Automatisierung kennt nur die Probleme, die schon jemand definiert hat

Der naheliegende Einwand lautet: Dann automatisiere den Proxy doch einfach. Tatsächlich gibt es reichlich Werkzeuge, die genau das versprechen, meist als Kombination aus Cronjob, Webhook und Prompt. Tane beschreibt, selbst so etwas gebaut zu haben: Jeder neue Fehler aus dem Error-Tracking wird untersucht und mündet in einen Pull Request, jede Warnung aus der Observability bekommt eine Analyse, bevor irgendwer seinen Laptop aufklappt. Das fühlt sich produktiv an, bis zu einem Punkt.

Denn solche Automatisierungen sehen nur, was jemand vorher für sehenswert erklärt hat. Sie erben sämtliche blinden Flecken des Systems, das sie auslöst. Irgendwer musste festlegen, auf welche Metrik alarmiert wird und welche Service-Level-Objectives gelten, und diese Festlegung ist zwangsläufig unvollständig. Das ist das Problem der unbekannten Unbekannten: Bekannte Fehler werden erkannt, weil jemand eine Regel dafür geschrieben hat. Unbekannte Fehler werden nie erkannt, weil nichts existiert, was sie erkennen könnte. Automatisierung in der Softwareentwicklung mit KI ist an dieser Stelle angekommen: Die Werkzeuge sind da, sie greifen nur zu kurz. Der Agent wird schnell darin, die Probleme zu beheben, die du ohnehin schon finden konntest. Die Probleme, die dich die meisten Kunden kosten, sind per Definition die anderen.

Software braucht Backpropagation

Hier hilft eine Analogie, die der Beitrag durchhält: Betrachte ein Stück Software wie ein neuronales Netz. Der Code sind die Gewichte und Schwellenwerte, jede Änderung daran ein Update dieser Gewichte. Nutzer interagieren damit, und was dabei entsteht — Traces, Klicks, Tickets, Kündigungen, Umsatz — ist die Ausgabe. Aus dieser Sicht zerfällt selbstverbessernde Software in zwei Phasen, und beide verhalten sich sehr unterschiedlich.

Die erste Phase ist der Vorwärtsdurchlauf: Absicht hinein, Code heraus. Diesen Teil haben Coding-Agenten weitgehend gelöst. Man kann heute eine recht komplexe Anwendung mit einem einzigen Prompt erzeugen, deployen und dabei Observability sowie Produkt-Tracking gleich mitverdrahten. Die zweite Phase ist die Backpropagation: die Ausgabe mit dem vergleichen, was man eigentlich wollte, die Lücke berechnen und sie durch das System zurückschieben, um die Gewichte anzupassen. Für eine Anwendung heißt das, alle Signale aus der Produktion zu lesen, sie auf den Code zu beziehen und diesen Code entsprechend zu ändern. Software, die sich selbst durch ihre eigenen Signale verbessert, entsteht genau hier.

Der Vorwärtsdurchlauf ist automatisiert, die Backpropagation läuft von Hand. Wöchentlich werden Dutzende Gewichts-Updates nach Produktion geschoben, aber der Gradient wird in einem Planungsmeeting berechnet — wenn es gut läuft wöchentlich, in manchen Unternehmen quartalsweise. Grundlage sind die Erinnerung der Produktmanager, eine Stichprobe von zwanzig Session-Aufzeichnungen und die drei lautesten Beschwerden. Würde man neuronale Netze so trainieren, käme nichts Brauchbares heraus.

Intelligenz ist billig, Fitness-Funktionen sind es nicht

Der Grund, warum die Backpropagation so lange manuell blieb, war ein Knappheitsproblem. Um einen Fehlerbericht zu lesen, die passenden Traces zu finden, sie mit Replays abzugleichen, die Wut eines Kunden zu verstehen und daraus eine Änderung abzuleiten, brauchte es Urteilsvermögen — und gutes Urteilsvermögen war teuer und rar. Diese Knappheit löst sich gerade auf. Intelligenz ist mittlerweile so billig, dass man sie nicht mehr abzählen muss: Sie kann jede Trace lesen, jede Sitzung ansehen, jedes Ticket und jedes Interviewtranskript auswerten und das alles in Minuten zusammenführen.

Was dadurch nicht billig wird, ist die Frage, woraufhin optimiert werden soll. Ein neuronales Netz ohne Verlustfunktion ist ein sehr teurer Zufallsgenerator. Die Backpropagation muss wissen, was „besser“ bedeutet, und diese Definition kann niemand an das System delegieren. Nach Einschätzung von Tane verschiebt sich die Aufgabe aller Beteiligten genau dorthin: Ingenieure, Produktmanager, Designer, Vertrieb und Support definieren die Fitness-Funktionen, gegen die das System optimiert. Der Beitrag ordnet das in einer Übersicht zu, die sich gut als Merkliste lesen lässt.

Rolle	Worauf optimiert wird	Beispielhafte Fitness-Funktionen
Ingenieurwesen	die Gesundheit des Systems	p99-Latenz, Fehlerraten, Verfügbarkeit, Kosten pro Anfrage, Kaltstartzeiten
Produkt	das Verhalten der Nutzer	Conversion, Aktivierung, Retention, Time to Value, Feature-Adoption
Design	die Nutzererfahrung	Aufgabenabschluss, Zeit pro Aufgabe, Rage Clicks, Abbrüche, verworfene Formulare
Vertrieb	Umsatz	Wachstum, Gewinnquoten, Expansion, Deal-Geschwindigkeit, Churn
Support	wie stark das Produkt weh tut	Ticketvolumen, Zeit bis zur Lösung, CSAT, doppelte Tickets

Die Schwierigkeit liegt weniger im Aufschreiben als im Abwägen. Diese Funktionen arbeiten gegeneinander: Ein schnellerer Checkout kann die Betrugserkennung schwächen, ein einfacheres Onboarding kann die Aktivierung von Power-Usern senken, ein Rabatt hebt den Umsatz und drückt die Marge. Zu entscheiden, wie stark jede Größe gewichtet wird, welche davon harte Nebenbedingungen sind und für welche Kunden man überhaupt optimiert, ist die eigentliche Arbeit. Im Kern ist es die Frage, was das Unternehmen erreichen will — präzise genug formuliert, dass eine Maschine darauf optimieren kann. Tane merkt an, dass genau das schon immer der schwierige Teil war.

Zwei Schleifen, ein Zeitplan

Was daraus konkret folgt, lässt sich in wenigen Zeilen beschreiben. Man gibt einem Cloud-Coding-Agenten Lesezugriff auf alle Signalquellen gleichzeitig — Observability, Produktanalytik, Session-Replays, Support-Tickets — und Schreibzugriff auf das Repository. Dann legt man das auf einen Zeitplan. Stündlich liest der Agent jeden neuen Fehler, jede Trace, jedes Replay und jedes Ticket der letzten Stunde, gruppiert, was nach demselben Problem aussieht, auch wenn es in verschiedenen Werkzeugen auftaucht, findet das Release, das es eingeführt hat, und öffnet einen Pull Request mit Fix und Belegen.

Täglich vergleicht derselbe Mechanismus den Vortag mit den vereinbarten Zielen: p99-Latenz im Checkout unter 300 Millisekunden, Fehlerrate unter 0,1 Prozent, Aktivierung über 25 Prozent, weniger als zwanzig Support-Tickets pro Tag. Für alles, was sich in die falsche Richtung bewegt, sucht er die Ursache im Code und öffnet einen Pull Request. Läuft alles im Rahmen, sucht er die Änderung, die diese Zahlen am wahrscheinlichsten als Nächstes bewegt — und öffnet auch dafür einen Pull Request. Observability und automatische Fehlerbehebung rücken damit so eng zusammen, dass die Grenze zwischen Beobachten und Handeln verschwindet.

Und sobald Software sich selbst verbessern kann, so Tane, kann sie auch die Maschinerie verbessern, die sie verbessert: bessere Observability, schärfere Erkennung, gründlichere Untersuchungen, bessere Fixes, jede Schleife zieht die nächste enger. Dafür müssten wir allerdings aufgeben, selbst das Steuer zu halten.

Das ist keine Zukunftsmusik, sondern eine Architektur, die sich mit heutigen Bausteinen zusammensetzen lässt. Tane baut mit Polylane genau daran, weil für ihn alle Software selbstverbessernd sein sollte. Für dich bedeutet das weniger, dass du morgen ersetzt wirst, und mehr, dass sich deine Arbeit verschiebt. Weniger Signale einsammeln, weniger Tickets sortieren, weniger Screenshots in Chatfenster kleben. Dafür mehr Klarheit darüber, was „besser“ überhaupt heißt, welche Nebenbedingungen unverhandelbar sind und welchen Teil des Systems du bewusst nicht optimieren lässt. Selbstverbessernde Software ist unvermeidlich — aber sie optimiert nur gegen das, was du ihr vorher gesagt hast.

Quelle: boristane.com

Warum beschleunigt KI nur die halbe Wissenschaft? Wer die Debatte der letzten Monate verfolgt, stößt auf ein Muster. Ideen, Literaturrecherche und Simulationen werden von Quartal zu Quartal günstiger. Herstellen, Messen und die Bestätigung durch ein zweites Labor stehen ungefähr dort, wo sie vor zehn Jahren standen. Meg McNulty kommt in einem ausführlichen Essay in ihrem Newsletter CipherTalk zu dem Schluss: Wie stark KI die Forschung beschleunigt, hängt weniger an der Qualität der Modelle als am Tempo der Überprüfung.

Man kann sich das als Trichter vorstellen: oben ein immer breiterer Zulauf, unten ein Auslass, der kaum mitwächst. Der Zulauf steht für das Erzeugen von Hypothesen, der Auslass für das Prüfen. McNulty hält diese Lücke für die eigentliche Engstelle und ihre Schließung für eines der am meisten unterschätzten Infrastrukturprobleme des kommenden Jahrzehnts. Im Folgenden geht es darum, woran das liegt, was heute schon funktioniert und was fehlt.

Verifikationselastizität und Amdahls Gesetz: zwei Maße für dasselbe Problem

McNulty schlägt vor, Forschungsfelder nach ihrer Verifikationselastizität zu sortieren. Die Frage lautet: Wie viel zusätzliche Prüfung lässt sich einkaufen, wenn Rechenleistung billiger wird? Software und formale Mathematik stehen ganz oben, weil sich ein Test dort millionenfach parallel ausführen lässt und in Sekunden antwortet. Simulationslastige Felder wie Strömungsmechanik, Teile der Chemie und der Chipentwurf liegen ebenfalls hoch, solange der Simulator gegen reale Messungen validiert ist. Bei Nasschemie, Biologie und Materialforschung fällt der Wert steil ab. Jede Prüfung verlangt dort ein physisches Ereignis.

Am unteren Ende stehen klinische Studien und langlaufende Forschung. Alle Rechenleistung der Welt hilft dort nicht weiter, weil die Zielgröße selbst Zeit braucht: Kein GPU-Cluster lässt einen Fünf-Jahres-Endpunkt früher eintreten. McNulty weist darauf hin, dass KI sich keine Daten herbeidenken kann, die niemand erhoben hat. Der Satz ist unspektakulär, aber er trifft den Kern.

Zur Einordnung zieht der Text Amdahls Gesetz heran, das aus der Parallelisierung von Rechnern stammt. Besteht ein Anteil f der Gesamtzeit eines Projekts aus Benchwork, ist die maximale Beschleunigung auf 1/f begrenzt — selbst wenn alles andere unendlich schnell würde. Bei achtzig Prozent Laborzeit liegt die Obergrenze bei 1,25. Man kann die Hypothesenproduktion verhundertfachen und gewinnt trotzdem nur ein Viertel. Billige Intelligenz lässt den Wert belastbarer Evidenz deshalb eher steigen als sinken.

Mathematik und Code als Ausnahme: Wenn Prüfen fast nichts kostet

In formaler Mathematik und im Programmieren existiert seit einiger Zeit genau die Rückkopplung, die anderswo fehlt. AlphaEvolve, ein Agent von DeepMind zur Algorithmenfindung, übergibt jedes geschriebene Programm an einen automatischen Bewerter. Der führt es aus, bewertet es, und die Suche konzentriert sich auf die Überlebenden. Dieser Kreislauf brachte eine Scheduling-Heuristik hervor, die rund 0,7 Prozent der weltweiten Rechenkapazität von Google einspart. Der Prüfschritt ist hier kein Kostenfaktor, sondern der Motor.

Der Dienst AXLE von Axiom macht dasselbe für die Mathematik. Er nimmt einen in Lean geschriebenen Beweis entgegen — Lean ist Software, die einen Beweis Zeile für Zeile prüft — und liefert ein Ja oder Nein zurück. Nach McNultys Angaben hat der Dienst mehr als 500 Millionen Anfragen bearbeitet, darunter die Läufe, mit denen AxiomProver alle zwölf Aufgaben des Putnam-Wettbewerbs 2025 löste, des härtesten Mathematikwettbewerbs für Studierende in Nordamerika. Lean für maschinell prüfbare Beweise ist damit kein Forschungsprojekt mehr, sondern laufender Betrieb.

Die von OpenAI behauptete Lösung des Navier-Stokes-Problems der Millennium-Preise arbeitete laut dem Essay mit rund 10.000 koordinierten Agenten, etwa 130 Milliarden Ausgabe-Tokens und 88 Stunden bis zum Ergebnis, plus 17 Stunden Modellzeit, um den Beweis in Lean prüfbar zu schreiben. Die Urheberschaft ist umstritten: Buckmaster und Alpöge veröffentlichten rund zehn Tage früher ein Ergebnis, und Buckmaster wirft OpenAI vor, auf seine privaten Codex-Sitzungen zurückgegriffen zu haben. Das Unternehmen bestreitet das.

Selbst im freundlichsten Fall hat die Prüfung Ränder. Lean bestätigt, dass der Beweis aus der formalen Aussage folgt. Ob die formale Aussage das Problem trifft, das jemand gestellt hat, bleibt ein menschliches Urteil. Das Clay-Institut verlangt zusätzlich eine Publikation und zwei Jahre Prüfung, bevor überhaupt ein Preis in Frage kommt. Jede Evaluation, jeder Benchmark und jeder Simulator teilt diese Schwäche: Jeder kann nur bestätigen, was jemand zuvor zu spezifizieren gedacht hat. Je weiter ein Feld von der formalen Mathematik entfernt liegt, desto größer der blinde Fleck.

Anthropic, GNoME und A-Lab: Die Suche schrumpft, das Messen nicht

Im vergangenen Monat richtete Anthropic nach McNultys Angaben rund 950 Claude-Agenten auf öffentliche DNA-Daten und ließ sie 21 Stunden lang nach ungewöhnlichen Reverse-Transkriptasen suchen, also nach Enzymen, die RNA in DNA umschreiben. Die Agenten sichteten mehr als 200.000 Kandidaten, markierten rund 3.500 Systeme und lieferten 20 ausformulierte Berichte ab. Einer beschreibt ein bislang unbekanntes System in Bakteriophagen-DNA, aufgebaut um ein bereits bekanntes Enzym, das neben einem Partnergen und einer Wiederholungssequenz sitzt, die niemand damit in Verbindung gebracht hatte. Die Anordnung erinnert entfernt an CRISPR.

Was das System tatsächlich tut, ist damit nicht geklärt. Das herauszufinden bedeutet Monate menschlicher Laborarbeit, und die Wissenschaftler bei Anthropic sitzen laut McNulty noch daran. Der Suchlauf war in Stunden erledigt, die Bedeutung des Fundes nicht.

Die Materialforschung zeigt dasselbe Muster in größerem Maßstab. GNoME von DeepMind sagte 2,2 Millionen Kristallstrukturen voraus, und Berkeleys autonomes A-Lab meldete in Nature Dutzende Synthesen. Unabhängige Kristallographen griffen anschließend einige Strukturzuordnungen und Neuheitsansprüche an. Eine Korrektur aus dem Jahr 2026 bestätigte 36 von 40 gemeldeten Erfolgen, stufte vier als nicht schlüssig ein und engte die Neuheitsaussagen ein. Die Roboter konnten Materialien schnell herstellen. Die Messungen mit ausreichender Sicherheit zu interpretieren, erwies sich als schwieriger.

Beide Geschichten haben dieselbe Form. Die Suche kollabiert auf Stunden oder Tage, alles danach bleibt in physischem und menschlichem Tempo. Bessere Modelle reißen diese Lücke nicht zu, sie weiten sie: Ein klügeres Modell heizt keinen Ofen schneller auf und lässt eine Zelle nicht früher teilen.

AlphaFold, Surrogate und drei Infrastrukturen, die zusammen wachsen müssen

Ein erster Ausweg besteht darin, einen Teil der Prüfung in Software zu verlegen. AlphaFold ist der bekannteste Fall. Trainiert auf den rund 100.000 einzigartigen Proteinstrukturen, die Menschen experimentell bestimmt hatten, sagt es Strukturen für Sequenzen voraus, die niemand kristallisiert hat — oft genau genug, um Fragen zu beantworten, für die früher Kristallographie nötig war. In unter einer Stunde statt in den Jahren, die eine Promotion für eine einzige Struktur braucht. Gelernte interatomare Potenziale, digitale Zwillinge von Fabriken und Reaktoren sowie Surrogat-Endpunkte in der Medizin versuchen denselben Zug.

Solche Surrogate hängen an drei Infrastrukturen, die gemeinsam wachsen müssen. Erstens Rechenleistung für Forschung, um das Surrogat zu trainieren und über riesige Kandidatenräume laufen zu lassen. Zweitens hochwertige experimentelle Daten als Trainingsgrundlage. AlphaFold existiert, weil jahrzehntelang Strukturen in die Protein Data Bank eingetragen wurden; die meisten Felder haben nichts Vergleichbares. Drittens Validierungsmessungen, die zeigen, wo dem Surrogat zu trauen ist und wo nicht.

Die Rückkopplung darin wird häufig übersehen. Bessere Surrogate senken die Zahl der nötigen physischen Experimente, sind aber selbst aus physischen Experimenten gebaut. Labore mit sauberen, gut dokumentierten Daten werden damit zu Zulieferern der Modelle, die später einen Teil ihrer Arbeit übernehmen. Wer massiv Rechenleistung aufbaut, ohne passende Daten- und Validierungskapazität, bekommt sehr schnelle Modelle, die sich über die physische Welt sehr sicher irren.

Verwaiste Hypothesen und die Geografie der Testkapazität

Für alles, was Software nicht klären kann, gilt eine grobe Buchführung, die McNulty als V mal p formuliert. V steht für die Zahl der Tests, die man tatsächlich fahren kann, p für die Wahrscheinlichkeit, dass eine getestete Idee richtig ist. KI flutet den oberen Teil des Trichters, was V nicht verändert. Sie hilft nur, wenn bessere Auswahl p hebt — und die meisten KI-generierten Kandidaten sind falsch oder abgeleitet. Die wertvollsten wissenschaftlichen Agenten werden jene sein, die das Experiment auswählen, das am ehesten verändert, was wir glauben. Darauf sind heutige Modelle kaum trainiert.

Der zweite Ausweg ist die Erhöhung von V. Eine Materialdoktorandin kann heute mit offenen Modellen und einer bescheidenen Clusterzuteilung in einer Woche Hunderttausende Kandidaten für Batterieverbindungen durchmustern und mit drei vielversprechenden herauskommen. Ein Zwei-Personen-Startup kann Proteine auf gemieteten GPUs entwerfen. Was beide kaum können, ist herausfinden, ob sie recht haben. McNulty nennt diese Fälle verwaiste Hypothesen: Manche verdienen ihre Verwaistheit, weil billige Ideen nicht automatisch gute sind, aber die brauchbaren stecken dazwischen, und es gibt derzeit keinen bezahlbaren Weg, sie herauszusortieren.

Die experimentelle Kapazität ist auf wenige Länder und Institutionen konzentriert. Die drei Batteriekandidaten derselben Doktorandin sterben also weit wahrscheinlicher ungetestet, wenn sie in Lagos arbeitet statt in Boston. Günstigere physische Werkzeuge könnten das verschieben: Tischgeräte für Tausende statt Millionen, 3D-gedruckte Reaktoren, Mikrofluidik, quelloffene Laborroboter und nach Experiment abgerechnete Cloud-Labore. McNulty vergleicht das mit dem Personal Computer, der Datenverarbeitung von einer Institution in ein Werkzeug verwandelte.

Heute entscheiden Laborbudgets darüber, welche Fragen überhaupt zu Experimenten werden, und dieser Filter wird teurer. Moore’s Law am Leben zu halten, kostet inzwischen mehr als das Achtzehnfache des Forschungseinsatzes der frühen siebziger Jahre, und Ökonomen sehen denselben Rückgang der Forschungsproduktivität quer durch die Disziplinen. Zugleich kommen disruptive Arbeiten überdurchschnittlich oft von kleinen Teams, und genau die können sich Tests am wenigsten leisten. Sinkende Testkosten greifen beide Probleme gleichzeitig an. Ob das gelingt, berührt allerdings auch biologische Sicherheitsfragen; Zugangskontrollen gehören deshalb von Anfang an dazu, nicht nachträglich.

Cloud-Labore, IGoR und die fehlende Vertrauensschicht

Einige Bausteine existieren bereits. OpenAI verband GPT-5 mit dem Cloud-Labor von Ginkgo Bioworks für zellfreie Proteinsynthese; über sechs Runden und 36.000 Reaktionsbedingungen senkte das System die Kosten für ein Referenzprotein um rund 40 Prozent. Jeder Entwurf passierte strenge programmatische Prüfungen, bevor er einen Roboter erreichte, weil ein plausibel lesbares Protokoll physisch unmöglich sein kann. Die Kampagne dauerte sechs Monate, und die Reaktionen gaben das Tempo vor.

IGoR, ein Programm der US-Behörde ARPA-H, finanziert eine Version davon für die Medizin: KI erkennt eine Lücke im Wissen, schreibt das Experiment und schickt es an ein qualifiziertes Labor, das es ausführen kann. McNulty malt sich das für jedes Feld aus. Ein Agent stößt auf eine Frage, die nur eine Messung klären kann, findet ein Labor, das sie erledigen kann, und bekommt die Daten zurück — mit Wiederholung durch ein zweites Labor, wenn das Ergebnis wichtig ist.

Die schwierige Ingenieursarbeit liegt in der Vertrauensschicht. Eine Pipette kann das richtige Volumen protokollieren und das falsche abgeben, Reagenzienchargen unterscheiden sich auf undokumentierte Weise, und ein Ergebnis ohne lückenlose Nachverfolgung ist womöglich wertlos, selbst wenn jedes Instrument korrekt gearbeitet hat. Cloud-Labore wie Emerald und geschlossene Kreisläufe wie der von Ginkgo lösen Teile davon innerhalb der eigenen Wände. McNulty hat aber nach eigener Aussage nichts gefunden, was über viele Einrichtungen und Experimenttypen hinweg funktioniert.

Wie ein solches Netz aussehen müsste, skizziert McNulty in vier Punkten: eine einheitliche Art, ein Experiment aufzuschreiben, damit dieselbe Anfrage in jedem qualifizierten Labor laufen kann wie derselbe Code in jeder Cloud; maschinenlesbare Kalibrier- und Herkunftsdaten, damit jedes Ergebnis mit dem Zustand des Instruments, der Geschichte der Probe und einer Unsicherheitsangabe ankommt; veröffentlichte Preise und Wartezeiten, damit sich ein Test budgetieren lässt wie Rechenzeit; und für wichtige Ergebnisse standardmäßig eine Wiederholung an einem unabhängigen Standort. Als erste Kunden sieht sie öffentliche Geldgeber, so wie NASA-Aufträge die kommerzielle Raumfahrt getragen haben, bevor private Nachfrage aufkam. Und weil auch ein autonomer Agent Experimente einreichen kann, müssen Zugangskontrollen für gefährliche Biologie und Chemie in der physischen Infrastruktur selbst verankert sein; das Urteilsvermögen eines Modells reicht als Barriere nicht.

Die Grenzen benennt sie ebenfalls. Manche Experimente brauchen schlicht Zeit: Korrosion lässt sich beschleunigen, manche Nebenwirkungen lassen sich früher sichtbar machen, aber solche Abkürzungen erfassen nicht immer, was über Monate oder Jahre tatsächlich passiert. Experimente an der Forschungsfront brauchen oft Instrumente, die es noch nicht gibt – LIGO und die National Ignition Facility waren wichtig, weil sie messen konnten, was nichts anderes messen konnte. Und ein standardisiertes Netz kann einen systematischen Fehler über Tausende Ergebnisse verbreiten. Als Ziel für das nächste Jahrzehnt nennt McNulty, eine belastbare Antwort auf einen breiten Teil experimenteller Fragen in etwa einer Woche zu bekommen, für rund tausend Dollar, für jeden qualifizierten Forschenden an jedem Ort.

McNulty plädiert nicht dafür, weniger Rechenleistung zu bauen. Jeder Abschnitt ihres Arguments setzt mehr davon voraus. Was sie fordert, ist ein zweiter Ausbau neben den Rechenzentren: ein Netz von Laboren, günstigeres Testgerät und eine gemeinsame Schicht für Nachvollziehbarkeit, damit eine Hypothese nicht daran scheitert, dass niemand sie messen kann. Das Labornetzwerk kommt zu den Rechenzentren hinzu, ersetzt sie nicht.

Wenn Intelligenz billig wird, steigt der Wert von Evidenz. Der Engpass verschiebt sich von der Idee zum Beweis. Ob KI die Wissenschaft beschleunigt, hängt deshalb nicht an der nächsten Modellgeneration, sondern daran, wie schnell sich das Prüfen skalieren lässt. Ohne Labore, Testgeräte und eine gemeinsame Schicht für Nachvollziehbarkeit bleibt die zweite Hälfte der Forschung stehen, wo sie ist.

Quelle: ciphertalk.substack.com