Lo sviluppo software con agenti AI è uscito dalla fase delle dimostrazioni: secondo la Stack Overflow Developer Survey 2025, l’84% degli sviluppatori usa o conta di usare strumenti di intelligenza artificiale nel proprio lavoro, e il 51% dei professionisti li usa tutti i giorni. La fiducia però resta indietro: nella stessa indagine, soltanto il 3,1% degli intervistati dichiara piena fiducia nei risultati, e il 45,7% ammette di non fidarsi.
In Cubit il tema è stato affrontato a partire da un problema interno. In un progetto hardware le informazioni utili esistono già (schemi elettrici, netlist, distinta base, layout, decisioni di progetto) e servono a molte funzioni: al firmware, alla meccanica, agli acquisti e, oggi, agli agenti AI. Spesso però restano leggibili soltanto da chi usa lo strumento di progettazione. Da questo limite è nato il PCB Viewer: un visualizzatore EDA sviluppato, documentato e collaudato da un gruppo di agenti LLM, con un solo ingegnere a definire requisiti, vincoli e criteri di accettazione. Lo strumento oggi è in uso in azienda.
Un progetto Altium Designer consultabile tramite browser
Il PCB Viewer è un applicativo web che apre i progetti Altium Designer veri e propri nei formati PcbDoc, SchDoc, PrjPcb e PcbLib: per consultarli non serve avere installata la suite di progettazione. Il progetto si carica come archivio, con riconoscimento automatico del formato e risoluzione dei parametri. Il layout a più layer si esplora in due dimensioni, pad per pad e pista per pista; gli schematici si scorrono foglio per foglio, con le net in evidenza; la scheda si può esaminare in 3D, ricostruita dai modelli STEP del progetto. Attorno al rendering ci sono gli strumenti del lavoro quotidiano: la ricerca per componente e per net, le evidenziazioni con riferimento incrociato fra schematico e PCB, le misure, i pannelli di dettaglio su oggetti, layer e componenti.
L’architettura separa le responsabilità: un backend Python governa il rendering e i servizi, un microservizio .NET legge i file di Altium Designer e ne ricava geometrie, schematici, parametri di progetto e modelli tridimensionali. Le funzioni specialistiche, come connettività, schematico e vista 3D, sono add-on che si attivano sopra un nucleo comune. Per il 3D la scena viene assemblata sul server, dai modelli STEP convertiti in GLB, con un ripiego componente per componente quando un modello manca. Il progetto è partito dal formato ODB++ ed è stato esteso ai file di Altium Designer in un secondo tempo; anche l’esercizio segue una disciplina da prodotto, con collaudo e produzione su ambienti separati. All’origine c’è l’esigenza interna detta sopra: analizzare, fare debug e documentare i progetti elettronici anche fuori dal reparto di progettazione.
Costificazione della distinta base su più fornitori
La parte economicamente più rilevante è il modulo di costificazione. Per ogni componente, il sistema confronta le offerte di più fornitori – prezzo unitario, minimo d’ordine, multipli, scaglioni di prezzo e, dove pesano, vincoli di confezionamento – e affianca al costo teorico, calcolato sulle quantità della distinta, il costo reale del primo ordine, che di quei vincoli tiene conto. Nel progetto mostrato nelle immagini la distinta conta 69 componenti, un prezzo è stato trovato per il 97% di essi, e lo scostamento fra i due costi si legge riga per riga.
È il tipo di funzione che distingue uno strumento di ingegneria da una demo. Il valore sta nella semantica del calcolo: il minimo d’ordine che scatta oppure no, il confezionamento che costringe a comprare più pezzi del necessario, lo scaglione di prezzo che si applica alla quantità davvero ordinata. Chi in fase di preventivo si ferma al costo teorico, quello scostamento non lo vede; su queste regole sono state scritte le specifiche del modulo e le sue verifiche.
L’API che rende l’hardware leggibile agli agenti
La funzione con l’impatto maggiore sul lavoro quotidiano è la meno appariscente: il backend espone design e netlist anche attraverso un’API, e rende interrogabile da programma un patrimonio tecnico che nel progetto Altium Designer esiste già, in un formato però pensato per chi disegna. Connessioni, piedinature, componenti sui singoli bus: una volta disponibili in forma strutturata, queste informazioni servono agli agenti AI dell’azienda per generare e verificare codice firmware partendo da un riferimento certo, con un livello di contesto che prima richiedeva passaggi manuali. Sulla distinta, un confronto semantico affidato a un modello linguistico aiuta ad abbinare i componenti.
Con l’API il visualizzatore passa da strumento di consultazione a piattaforma di accesso al dato di progetto, e il passaggio fa da ponte fra le discipline: chi scrive firmware consulta layout, schematici e netlist; chi segue la meccanica e la dissipazione termica usa la vista 3D; gli acquisti lavorano sulla distinta; gli agenti passano dall’API. Le decisioni restano all’ingegnere; a diminuire è il lavoro di ricopiatura, con la classe di errori che si porta dietro.
L’organizzazione dello sviluppo
Per chi volesse ripetere l’esperienza, il metodo conta più del risultato: è la parte che si trasferisce. Il lavoro è cominciato prima della piattaforma, con un sistema di conoscenza condivisa: memoria atomica e RAG accessibili a tutti gli agenti, sotto una politica di versioning aziendale. Lo sviluppo è stato poi condotto da agenti LLM coordinati da un solo ingegnere, responsabile di requisiti, vincoli e criteri di accettazione, con un approccio Test-Driven Development: i test, derivati dai criteri di accettazione, vengono scritti prima del codice, e gli agenti lavorano sia nello sviluppo sia nella review, sotto supervisione.
Per il modulo di costificazione, il contratto dati è stato scritto e congelato prima di aprire il lavoro in parallelo: una specifica vincolante, che nessun gruppo di lavoro poteva reinterpretare a modo suo. Ogni agente ha lavorato in una propria copia del codice, su file che non si sovrapponevano a quelli degli altri, con modifiche piccole e verificabili; il coordinatore ha rieseguito le verifiche di integrazione e ha aperto la richiesta di merge solo quando i criteri di accettazione risultavano soddisfatti.
Intorno al progetto valgono le regole di qualunque commessa software ben gestita: ogni attività ha la propria issue e il proprio branch, nessun agente esegue merge in autonomia sul branch principale, ognuno ha un’identità riconoscibile nel controllo di versione, e un lavoro si dice finito soltanto dopo una verifica concreta e documentata. Priorità, scelte architetturali e merge finale restano alle persone.
Le stesse regole varrebbero per un gruppo di persone al lavoro in parallelo sullo stesso codice; con gli agenti sono state applicate alla lettera. Dentro questi confini l’AI moltiplica la capacità di esecuzione dell’ingegnere, e ogni passo resta controllabile.
Il sistema di ricerca multi-agente di Anthropic
Lo schema con un coordinatore e più agenti specializzati si ritrova certamente anche fuori da Cubit. Anthropic lo documenta per il proprio sistema di ricerca multi-agente: nelle valutazioni interne riporta un vantaggio del 90,2% rispetto al singolo agente, consumando però circa quindici volte i token di una normale conversazione. Sono numeri di un caso specifico, e i costi vanno valutati progetto per progetto. A trasferirsi è la struttura di controllo: la divisione fra chi coordina e chi esegue, con contratti espliciti fra le parti, rende il risultato verificabile, non soltanto plausibile, per la stessa ragione per cui nelle commesse di ingegneria si tengono separati chi scrive la specifica, chi esegue e chi collauda.
Validare prima di proporre
Il PCB Viewer resta uno strumento interno; il racconto pubblico è arrivato oggi, quando la piattaforma era già in uso. Ciò che Cubit propone ai clienti è il metodo, con le competenze che il progetto dimostra: integrazione hardware-software, sviluppo agentico, valorizzazione del patrimonio tecnico aziendale. Queste tecnologie sono state messe alla prova su un problema proprio, con dati e costi propri, prima di diventare una proposta.
La differenza fra un processo di sviluppo con agenti AI e una sperimentazione isolata sta nella struttura: requisiti e criteri di accettazione scritti prima, perimetri e contratti durante, verifica indipendente alla fine. Le competenze si validano prima e si raccontano poi.
