L'IA generativa cambia una parte dello sviluppo embedded — ma non quella decisiva. Cosa si è spostato, cosa si è intensificato, e cosa ottiene il committente.
L'IA generativa è ormai in grado di produrre driver standard, semplici macchine a stati e codice di base in SystemVerilog, VHDL, C o Python. È reale, è utile, e ha ridotto il carico di certi compiti di routine.
Da qui sorge una domanda legittima: cosa aggiunge ancora uno sviluppatore esperto di embedded e FPGA in questo contesto?
La risposta è concreta.
Un'IA è un esecutore rapido. Produce ciò che le si chiede — non ciò che serve. Chiedere a un'IA di «scrivermi un driver UART» dà un driver UART. Ma non quello che funziona davvero con questo dominio di clock, questa assegnazione di pin, questo comportamento temporale e questa gestione degli errori nell'ambiente di destinazione.
La vera prestazione ingegneristica non è generare codice. È scrivere una specifica precisa: cosa esattamente deve accadere, a quali condizioni, con quali tolleranze, con quale comportamento in caso di errore, in quale intervallo di temperatura, su quale durata di vita.
Un'IA migliore non cambia nulla. Al contrario: più gli strumenti diventano potenti, più è decisivo istruirli correttamente.
Un'IA non aggiunge requisiti a cui il cliente non ha pensato. Non inventa casi particolari. Consegna esattamente quanto presente nella specifica — e nient'altro. Ciò che non è specificato manca nel risultato.
In tal modo il rischio si sposta interamente sulla specifica stessa. Una specifica inesperta descrive correttamente quanto il cliente ha richiesto e tralascia tutto ciò che chi la redige non ha mai vissuto: il raro guasto di un sensore con certi gradienti di temperatura, il comportamento durante un brown-out simultaneo e un blocco del bus I²C, un reset del watchdog durante una sequenza di scrittura flash, l'accoppiamento elettromagnetico su lunghi cavi di sensori, il comportamento al riavvio dopo un reset involontario durante un'operazione di scrittura critica.
Questi punti non sono requisiti del cliente. Sono requisiti che uno sviluppatore esperto aggiunge, sapendo che altrimenti non figurerebbero da nessuna parte. Una specifica è quindi sempre anche un catalogo dei rischi — e la profondità di tale catalogo è proporzionale all'esperienza di chi la redige.
Durante un'indagine di sicurezza su una pompa per infusione, alla quale sono stato chiamato da un fabbricante di dispositivi medici, è emerso un guasto rilevante per la sicurezza nato dall'occorrenza simultanea di due guasti singoli: il guasto hardware di un componente di memoria e una routine di verifica errata per proprio quel componente. Ciascun guasto in sé era gestibile. Solo la combinazione ha prodotto lo stato di guasto non rilevato.
È proprio questa analisi combinata che deve essere aggiunta attivamente in una specifica. Dal requisito «verificare la memoria», uno strumento genera una routine di verifica. L'esperienza aggiunge il requisito ulteriore che il guasto della routine di verifica stessa non deve portare a uno stato di guasto silenzioso. Nessuno strumento formula da solo questo secondo requisito.
Si aggiungono le insidie vicine all'hardware che non figurano nei datasheet, ma nella testa degli sviluppatori che le hanno già rincorse:
Per la maggior parte dei compiti esistono diverse soluzioni che funzionano fondamentalmente. Ma solo poche soddisfano i requisiti di sicurezza, affidabilità e durata di vita che il prodotto concreto richiede.
Un sistema di IA sceglie ciò che era frequente nei suoi dati di addestramento. Uno sviluppatore esperto sceglie ciò che non porta alla catastrofe in un sistema rilevante per la sicurezza. Questa decisione di selezione non è un dettaglio implementativo. È la vera ingegneria.
In caso di danno, il legislatore esige la prova che il prodotto, al momento della messa in circolazione, corrispondeva allo stato dell'arte. È la condizione centrale perché un fabbricante possa sottrarsi alla responsabilità da prodotto. Con la nuova Direttiva europea sulla responsabilità per danno da prodotti difettosi e la legge nazionale di recepimento che ne segue, questo onere della prova viene esplicitamente inasprito per il software e i prodotti integrati con software.
Lo stato dell'arte non è uno stato statico. È ciò che è considerato consueto tra gli esperti — e attualmente cambia in modo accelerato perché nuovi strumenti e metodi alzano lo standard di mercato in cicli brevi.
Ne consegue: chi oggi sviluppa un sistema embedded deve conoscere e impiegare i metodi più potenti attualmente disponibili. Chi non lo fa crea per il proprio committente un rischio di responsabilità concreto. Ciò richiede appunto uno sviluppatore che padroneggia sia gli strumenti consolidati sia quelli nuovi e sa effettuare la scelta giusta.
Uso strumenti di IA dove fanno risparmiare tempo misurabile senza creare rischi: primo abbozzo di codice di base, generazione di testbench, documentazione, verifica di leggibilità.
Non li uso in sostituzione di:
Il risultato: meno carico per il lavoro di routine, qualità costantemente alta nei compiti che effettivamente reggono il progetto, e un processo di sviluppo documentato conforme allo stato dell'arte attuale.
Incarica uno sviluppatore con oltre 35 anni di esperienza in FPGA ed embedded, che conosce gli strumenti attuali e ne sa valutare i limiti. Non ottiene né un «progetto generato da IA» né un «progetto privo di IA». Ottiene un sistema funzionante per il quale una persona concreta si assume la responsabilità — e che, in caso di sinistro, può essere dimostrato come sviluppato secondo lo stato dell'arte.
Se ha un progetto embedded che richiede esattamente questa profondità, parliamone direttamente. Primo colloquio e valutazione sommaria sono gratuiti e senza impegno.