Sechs Runden unabhängiger Tests: Härtung des Sensbench AI Builders

In der vergangenen Woche führte ein unabhängiger Dritter sechs Runden tiefgehender, adversarischer Tests gegen den Sensbench AI Builder und den Sensbench MCP (Model Context Protocol) Server durch. Ihr Auftrag war einfach: Versuchen Sie, es zu brechen. Sie generierten Projekte, kompilierten Firmware, wiederholten identische Prompts, stocherten in Caches, verbanden echte MQTT-Broker und prüften unsere Abrechnung. Hier ist, was passiert ist, was wir behoben haben und wie die Zahlen jetzt aussehen.

Wie die Tests durchgeführt wurden

Jede unten genannte Behauptung wurde in einer realen Umgebung verifiziert:

• Echte Kompilierung – jeder generierte Sketch wurde mit unserer tatsächlichen arduino-esp32-Toolchain (ESP-IDF-Build) kompiliert, nicht mit einem Linter oder einem Fake-Pass.
• Echtes MQTT – generierte Home-Assistant-Sketches wurden in den Simulator geflasht, mit einem echten öffentlichen MQTT-Broker verbunden und Ende-zu-Ende getrieben: mosquitto_pub ON → Geräte-Callback → Relais-Impuls → Status zurückveröffentlicht. Discovery-Nachrichten wurden auf homeassistant/switch/…/config erfasst.
• Cache-Semantik – identische Prompts, semantisch unterschiedliche Prompts, Board-Änderungen und Constraint-Änderungen wurden wiederholt, um zu verifizieren, dass zwischengespeicherte Antworten nur exakt zu der Anfrage passen, die sie erzeugt hat.
• Abrechnungsabgleich – jede Generierung und Kompilierung wurde mit dem Kontingent-Ledger abgeglichen: Erfolge abgerechnet, Cache-Treffer kostenlos, fehlgeschlagene Kompilierungen kostenlos.

Runde eins: Die ehrliche Zahl war 20 %

Die erste Runde war ernüchternd. Von fünf generierten Projekten konnten vier nicht kompiliert werden – darunter ein Garagentoröffner, eine der häufigsten realen Anfragen. Die Fehler waren klassische Anfängerfehler in C++: Hilfsfunktionen, die vor der Deklaration verwendet wurden, handgefertigte Protokollstapel, ein fehlender Bibliotheks-Include. Das Urteil war fair: „Die Pipeline ist echt, aber der Generator ist unzuverlässig.“

Was wir geändert haben

Statt zu argumentieren, haben wir Leitplanken in die Pipeline selbst eingebaut:

• Automatische Prototyp-Injektion – die Compile-Toolchain führt Arduinos Auto-Prototyp-Schritt nicht aus, also injizieren wir jetzt automatisch Funktionsprototypen an der richtigen Position vor jedem Compile.
• Interner Selbsttest-Compile – jedes generierte Projekt wird intern kompiliert, bevor es dem Benutzer überhaupt angezeigt wird. Wenn es fehlschlägt, wird der Compiler-Fehler zurückgemeldet und das Modell regeneriert, bis zu zweimal. Benutzer sehen nur verifizierte Ergebnisse.
• Ausgereifte Bibliotheken statt handgefertigter Stacks – MQTT verwendet jetzt die bewährte PubSubClient-Bibliothek; dem Modell ist es ausdrücklich verboten, das MQTT-Protokoll von Grund auf neu zu implementieren.
• Prüfung auf Vollständigkeit der Anforderungen – Kompilieren allein reicht nicht. Wenn der Prompt nach Home Assistant MQTT fragt, muss der Code tatsächlich einen funktionierenden MQTT-Client mit Subscribe/Publish/Callback-Logik enthalten – eine nur lokale Demo, die als das echte Ding getarnt ist, wird abgelehnt und neu generiert.
• Nur verifiziertes Caching – der Antwort-Cache speichert nur Projekte, die sowohl die Compile- als auch die Anforderungsprüfung bestanden haben. Das Wiederholen eines beliebten Prompts gibt immer den verifizierten Build zurück.
• Simulator-Realitätsregeln – generierte Sketches verwenden jetzt standardmäßig den echten Zugangspunktnamen des Simulators, einen erreichbaren Standard-MQTT-Broker, bidirektionale ON/OFF-Behandlung, beibehaltenen Anfangszustand für Home Assistant und exakte Sensortypen (ein Reed-Kontakt bleibt ein Reed-Kontakt).

Die Zahlen jetzt

• Erste Erfolgsquote bei realen Anfragen: 1 von 6.
• Erfolgsquote nach den Fixes, über wiederholte unabhängige Runden: 6 von 6 aufeinanderfolgende Kompilierungen + echtes MQTT-Logik – einschließlich Cache-Treffer-Antworten.
• Cache-Semantik-Tests: 6 Anfragen, keine Abweichungen. Identische Prompts geben byte-identischen Code zurück; geänderte Prompts, Boards oder Constraints generieren immer frisch.
• Ende-zu-Ende-MQTT: Gerät → Broker → Home-Assistant-artiges Abonnement → Befehl → Relais-Impuls → Statusveröffentlichung, alles über einen echten Broker bestätigt, einschließlich authentifizierter Broker.
• MCP-Server: 8/8 Tools Ende-zu-Ende ausgeführt; Kontingentabrechnung exakt abgeglichen (Erfolg abgerechnet, Cache-Treffer und Fehlschläge kostenlos).

Wofür wir weiterhin offen sind

Ehrliche Einschränkungen, die wir während der Tests dokumentiert haben:

• Die Home-Assistant-Integration ist standardmäßig manuelles MQTT (Discovery-Konfiguration wird veröffentlicht, aber die HA-Auto-Discovery-Einrichtung hängt von Ihrer HA-MQTT-Konfiguration ab).
• Die Simulator-Sandbox hat eine Ausgangs-Allowlist – einige öffentliche Broker sind erreichbar (z. B. broker.emqx.io), andere nicht. In unserer Dokumentation finden Sie, was funktioniert.
• Die Hardware-Auswahl entspricht der Anfrage semantisch, nicht immer wörtlich – das Modell kann eine äquivalente Sensorklasse wählen; wir weisen in den Notizen des generierten Plans darauf hin.

Warum dies veröffentlichen

Jeder kann ein Demo-Video veröffentlichen. Wir haben uns stattdessen dafür entschieden, den gesamten Bogen zu veröffentlichen: die fehlgeschlagenen Runden, die Fixes und die erneuten Tests – mit reproduzierbarer Methodik. Wenn Sie es selbst versuchen möchten, es zu brechen, ist der AI Builder für einen Build pro Tag kostenlos, und der Simulator läuft vollständig in Ihrem Browser. Der MCP-Server ist mit echter Kontingentabrechnung verfügbar. Bringen Sie Ihren eigenen Prompt, Ihren eigenen Broker, Ihre eigene Skepsis mit.

– Das Sensbench-Team