Sei cicli di test indipendenti: rafforzare il Sensbench AI Builder

Nell’ultima settimana, una terza parte indipendente ha eseguito sei cicli di test approfonditi e avversari contro il Sensbench AI Builder e il server Sensbench MCP (Model Context Protocol). Il loro compito era semplice: provare a romperlo. Hanno generato progetti, compilato firmware, rieseguito prompt identici, esplorato le cache, collegato broker MQTT reali e controllato la nostra fatturazione. Ecco cosa è successo, cosa abbiamo corretto e come appaiono i numeri ora.

Come sono stati eseguiti i test

Ogni affermazione di seguito è stata verificata in un ambiente reale:

• Compilazione reale — ogni sketch generato è stato compilato con la nostra toolchain arduino-esp32 (build ESP-IDF), non con un linter o un finto passaggio.
• MQTT reale — gli sketch Home Assistant generati sono stati caricati nel simulatore, collegati a un broker MQTT pubblico reale e guidati end-to-end: mosquitto_pub ON → callback del dispositivo → impulso relè → stato pubblicato. I messaggi di discovery sono stati catturati su homeassistant/switch/…/config.
• Semantica della cache — prompt identici, prompt semanticamente diversi, cambi di scheda e cambi di vincoli sono stati riprodotti per verificare che le risposte in cache corrispondano solo alla richiesta esatta che le ha generate.
• Riconciliazione della fatturazione — ogni generazione e compilazione è stata riconciliata con il registro delle quote: successi addebitati, hit in cache gratuiti, compilazioni fallite gratuite.

Primo ciclo: il numero onesto era il 20%

Il primo ciclo è stato umiliante. Su cinque progetti generati, quattro non compilavano — incluso un apriporta da garage, una delle richieste più comuni nel mondo reale. I fallimenti erano errori classici di C++ per principianti: funzioni helper usate prima della dichiarazione, stack di protocollo fatti a mano, include di librerie mancanti. Il verdetto era giusto: “la pipeline è reale, ma il generatore è inaffidabile.”

Cosa abbiamo cambiato

Invece di discutere, abbiamo costruito protezioni nella pipeline stessa:

• Iniezione automatica dei prototipi — la toolchain di compilazione non esegue il passaggio di auto-prototipo di Arduino, quindi ora iniettiamo automaticamente i prototipi delle funzioni nella posizione corretta prima di ogni compilazione.
• Compilazione di auto-verifica interna — ogni progetto generato viene compilato internamente prima di essere mostrato all’utente. Se fallisce, l’errore del compilatore viene reimmesso e il modello rigenera, fino a due volte. Gli utenti vedono solo risultati verificati.
• Librerie mature invece di stack fatti a mano — MQTT ora usa la libreria collaudata PubSubClient; al modello è esplicitamente vietato reimplementare il protocollo MQTT da zero.
• Controlli di completezza dei requisiti — compilare non basta. Se il prompt richiede Home Assistant MQTT, il codice deve effettivamente contenere un client MQTT funzionante con logica subscribe/publish/callback — una demo solo locale spacciata per la cosa reale viene rifiutata e rigenerata.
• Cache solo verificata — la cache delle risposte memorizza solo progetti che hanno superato sia i controlli di compilazione che quelli dei requisiti. Ripetere un prompt popolare restituisce sempre la build verificata.
• Regole di realtà del simulatore — gli sketch generati ora usano per impostazione predefinita il nome del punto di accesso reale del simulatore, un broker MQTT predefinito raggiungibile, gestione bidirezionale ON/OFF, stato iniziale mantenuto per Home Assistant e tipi di sensore esatti (un reed switch rimane un reed switch).

I numeri ora

• Tasso di superamento iniziale su richieste reali: 1 su 6.
• Tasso di superamento dopo le correzioni, in cicli indipendenti ripetuti: 6 su 6 compilazioni consecutive + logica MQTT reale — incluse le risposte da cache.
• Test semantici della cache: 6 richieste, nessuna discrepanza. Prompt identici restituiscono codice byte-identico; prompt, schede o vincoli modificati generano sempre codice nuovo.
• MQTT end-to-end: dispositivo → broker → sottoscrizione stile Home Assistant → comando → impulso relè → pubblicazione stato, tutto confermato su un broker reale, inclusi broker autenticati.
• Server MCP: 8/8 strumenti esercitati end-to-end; fatturazione delle quote riconciliata esattamente (successi addebitati, hit in cache e fallimenti gratuiti).

Di cosa siamo ancora trasparenti

Limitazioni oneste documentate durante i test:

• L’integrazione con Home Assistant è MQTT manuale per impostazione predefinita (la configurazione di discovery viene pubblicata, ma la configurazione di auto-discovery di HA dipende dalla configurazione MQTT del tuo HA).
• La sandbox del simulatore ha una lista bianca in uscita — alcuni broker pubblici sono raggiungibili (es. broker.emqx.io), altri no. Controlla la nostra documentazione per ciò che funziona.
• La selezione dell’hardware corrisponde semanticamente alla richiesta, non sempre alla lettera — il modello può scegliere una classe di sensore equivalente; lo segnaliamo nelle note del piano generato.

Perché pubblicare questo

Chiunque può pubblicare un video demo. Noi abbiamo scelto invece di pubblicare l’intero arco: i cicli falliti, le correzioni e i nuovi test — con metodologia riproducibile. Se vuoi provare a romperlo tu stesso, l’AI Builder è gratuito per una build al giorno e il simulatore gira interamente nel tuo browser. Il server MCP è disponibile con contabilità delle quote reale. Porta il tuo prompt, il tuo broker, il tuo scetticismo.

— Il team Sensbench