Fünf Sammlungen Agenten-Ratschläge, gegen ein ausgeliefertes Produkt geprüft

Innerhalb weniger Monate sind fünf sorgfältige Texte darüber erschienen, wie man für KI-Agenten baut. Ein Produktteam veröffentlichte fünf goldene Regeln. Ein Observability-Anbieter passte sein Platform-Engineering-Playbook an. Dieselbe Firma veröffentlichte einen Report mit echten Produktionszahlen. Drei Ingenieure schrieben ein Manifest mit zwölf Prinzipien. Eine Datenplattform dokumentierte vier Entwurfsmuster.

Zusammen sind sie zu fast allem normativ und gegen fast nichts gemessen. Nicht aus Nachlässigkeit: keiner von ihnen behauptet, seinen Rat an einem bestimmten Bau geprüft zu haben, denn dafür ist ein Prinzip nicht da.

Ich hatte einen bestimmten Bau. Also habe ich alle fünf dagegen laufen lassen, einen nach dem anderen, und das hier hat überlebt.

Die fünf, und was jede mich gekostet hat

Der Gegenstand ist jedes Mal dasselbe Produkt: ein Preisindex für GPU-Miete, LLM-Token und Strom im Großhandel, geplant in einer Vorgabe über 1.153 Zeilen, in drei Tagen und 57 Commits gebaut, und live.

• PostHogs fünf goldene Regeln. Vier hielten kostenlos, weil ein öffentlicher Index ohne Anmeldeschranke agentenfreundlich ist, ob jemand das Wort benutzt hat oder nicht. Die fünfte, Agenten wie echte Nutzer behandeln, war in der Dokumentation befolgt und in der Infrastruktur ignoriert: die Doku lud Agenten ein, ohne Schlüssel abzufragen, und 120 Anfragen in fünf Sekunden kamen alle mit 200 zurück, gegen eine Datenbank mit 100 Verbindungen für drei Projekte. Das vollständige Audit steht hier.
• Datadogs Golden Paths. Die Suche nach Läufen ohne Nachweise fand keinen. Sie fand vier, in denen die Nachweise vollständig waren, von einer Plattform durchgesetzt, und falsch, darunter eine Testsuite, die „43 passed" meldete, ohne etwas auszuführen. Der Text dazu.
• Datadogs State of AI Engineering. Ihre Zahl lautet, 5 Prozent der Modellanfragen scheitern. An einem kostenlosen Endpunkt, den ich vermessen habe, scheiterte überhaupt nichts, und drei von vier Modellen antworteten mit 512 Token und null Wörtern. Hier.
• Das Agentic Engineering Manifesto. Sein erster Wert zieht Steuern der Vorab-Spezifikation vor. Ich habe die andere Seite gekauft und es ist ausgeliefert, was ein Widerspruch ist und kein Befund. Hier.
• Databricks' Entwurfsmuster. Ihr Kontinuum ordnet nach abgegebener Entscheidung, und mein Bau liegt nirgends darauf: fünfzehn Agenten haben untersucht, einer hat Code geschrieben. Hier.

Was alle fünf gemeinsam haben

Jeder Text ist aus der Schicht geschrieben, in der seine Autoren arbeiten. PostHog von der Produktoberfläche, Datadog von der Plattform und aus aggregierter Telemetrie, das Manifest vom Prozess, Databricks von der Laufzeit.

Innerhalb der eigenen Schicht hat jeder recht. Was keiner kann, ist den Fehler sehen, der in einer anderen wohnt, und jeder ernste Defekt in meinem Bau wohnte in einer anderen.

Der fehlende Limiter war ein Versprechen der Produktoberfläche mit einer Folge auf der Plattformschicht. Die lügende Testsuite war ein Laufzeit-Cache, der sich korrekt verhielt, unter einem Vertrag, der auf der Prozessschicht formuliert war. Die leeren Antworten waren ein Verhalten der Modellschicht, für Plattform-Telemetrie unsichtbar. In jedem Fall hätte der Rat der Schicht, in der das Problem auftauchte, es nicht verhindert, weil das Problem nicht dort saß.

Das eine, das ich allen fünf hinzufügen würde

Könnte ich in jedes dieser Dokumente einen einzigen Satz schreiben, wäre es derselbe.

Jede Kontrolle muss einmal beim Scheitern beobachtet worden sein, bevor man ihr traut.

Nicht getestet. Beobachtet. Schreib die verletzende Eingabe, sieh zu, wie es rot wird, repariere es und sieh zu, wie es grün wird.

Dieser Satz ist es deshalb, weil er als einziger die Klasse von Defekten fängt, die keine der fünf Quellen sehen kann. Ein Gatter, dem man nie beim Scheitern zugesehen hat, ist von einer Verzierung nicht zu unterscheiden, und alles, was davon abhängt, einschließlich jedes Prinzips in diesen Dokumenten, ruht darauf.

In einem einzigen Repository hat das gefangen: eine Testsuite, die bestand, ohne zu laufen, zwei Lint-Regeln, die still wirkungslos waren, und eine Optimierung, die in Produktion messbar tot und in der Entwicklung grün war. Keines davon erzeugte einen Fehler. Alle erzeugten Nachweise.

Wie man normative Ratschläge liest

Drei Dinge würde ich heute anders machen, wenn eine gut begründete Liste von Prinzipien auftaucht.

• Frag, aus welcher Schicht sie geschrieben ist, und geh davon aus, dass sie für die anderen blind ist. Das ist kein Vorwurf an die Autoren, es ist eine Eigenschaft davon, irgendwo zu stehen.
• Such nach dem Abwägungsformat. Nur eine der fünf formuliert ihre Punkte als „X vor Y", und nur ihr konnte ich sauber widersprechen. Eine Liste von Anforderungen hat kein Vokabular dafür, dass zwei ihrer Punkte kollidieren, und wenn sie es tun, steht man allein da.
• Prüf die Punkte gegen etwas Ausgeliefertes, bevor du die Liste übernimmst. Vier von PostHogs Regeln kosteten mich nichts, weil das Produkt ohnehin so geschnitten war. Eine kostete einen Limiter, einen Edge-Cache, zwei subtile Fehler und einen Nachmittag. Listen sagen selten, welcher ihrer Punkte der teure ist, und es ist fast immer genau einer.

Next

Ich baue gerade eine kleine Probe, die prüft, ob eine Seite von einem Agenten wirklich benutzbar ist: ob es eine llms.txt gibt, einen Lesepfad ohne Schlüssel, ein Rate Limit mit Retry-After, maschinenlesbare Fehler und stabile Kennungen. Sie entsteht, weil der erste Text dieser Reihe eine Behauptung über mein eigenes Produkt aufstellt, die ein Leser derzeit glauben muss, und mir wäre lieber, er könnte sie prüfen.

Der Bau, gegen den diese fünf geprüft wurden, ist in dem Text über den einen Plan und seinen Lauf beschrieben, mitsamt Zahlen und Fehlern.

Wenn du diese Woche eine dieser Listen übernimmst: nimm den Punkt, bei dem du am sichersten bist, ihn schon zu erfüllen, und versuch es zu beweisen. Genau der wird falsch sein.