Generatieve AI verandert een deel van de embedded ontwikkeling — maar niet het beslissende deel. Wat verschoven is, wat verscherpt is, en wat u als opdrachtgever krijgt.
Generatieve AI kan inmiddels standaarddrivers, eenvoudige toestandsautomaten en boilerplate-code in SystemVerilog, VHDL, C of Python genereren. Dat is reëel, dat is nuttig, en het heeft de inspanning voor bepaalde routinetaken verlaagd.
Daaruit volgt een gerechtvaardigde vraag: wat levert een ervaren embedded- en FPGA-ontwikkelaar in deze omgeving nog?
Het antwoord is concreet.
Een AI is een snelle uitvoerder. Ze produceert wat haar wordt opgedragen — niet wat nodig is. Wie een AI vraagt «schrijf me een UART-driver», krijgt een UART-driver. Maar niet die welke met dit klokdomein, deze pintoewijzing, dit timinggedrag en deze foutafhandeling in de doelomgeving daadwerkelijk werkt.
De eigenlijke ingenieursprestatie is niet het genereren van code. Het is het opstellen van een precieze specificatie: wat moet er precies gebeuren, onder welke voorwaarden, met welke toleranties, met welk gedrag bij fouten, in welk temperatuurbereik, over welke levensduur.
Betere AI verandert daar niets aan. Integendeel: hoe krachtiger de gereedschappen worden, des te beslissender wordt het ze juist te instrueren.
Een AI vult geen eisen aan waaraan de opdrachtgever niet heeft gedacht. Ze verzint geen bijzondere gevallen. Ze levert precies wat in de specificatie staat — en niets daarbuiten. Wat niet gespecificeerd is, ontbreekt in het resultaat.
Daarmee verschuift het risico volledig naar de specificatie zelf. Een onervaren specificatie beschrijft correct wat de klant heeft gevraagd en gaat voorbij aan alles wat de opsteller nooit heeft beleefd: de zeldzame sensoruitval bij bepaalde temperatuurgradiënten, het gedrag bij gelijktijdige brown-out en I²C-buslock, de watchdog-reset tijdens een flash-schrijfsequentie, de elektromagnetische koppeling bij lange sensorleidingen, het gedrag bij heropstart na een onbedoelde reset tijdens een kritische schrijfoperatie.
Dergelijke punten zijn geen klanteisen. Ze zijn eisen die een ervaren ontwikkelaar toevoegt, omdat hij weet dat ze anders nergens zouden staan. Een specificatie is daarom altijd ook een risicocatalogus — en de diepte van deze catalogus is evenredig met de ervaring van wie hem opstelt.
Bij een veiligheidsonderzoek aan een infuusapparaat, waarbij ik door een fabrikant van medische hulpmiddelen werd ingeschakeld, deed zich een veiligheidsrelevant falen voor dat ontstond uit het gelijktijdig optreden van twee afzonderlijke fouten: het hardwarematig falen van een geheugenchip en een gebrekkige controleroutine voor precies die chip. Iedere fout op zich was beheersbaar. Pas de combinatie produceerde de niet onderkende fouttoestand.
Het is precies deze combinatieanalyse die in een specificatie actief moet worden toegevoegd. Uit de eis «geheugen controleren» genereert een gereedschap een controleroutine. Uit de ervaring volgt de aanvullende eis dat ook het falen van de controleroutine zelf niet mag leiden tot een stille fouttoestand. Geen enkel gereedschap formuleert deze tweede eis uit zichzelf.
Daarbij komen de hardware-nabije valkuilen die niet in datasheets staan, maar in de hoofden van ontwikkelaars die ze al eens hebben moeten najagen:
Voor de meeste taken bestaan meerdere oplossingen die fundamenteel werken. Maar slechts enkele daarvan voldoen aan de eisen aan veiligheid, betrouwbaarheid en levensduur die het concrete product nodig heeft.
Een AI-systeem kiest wat in zijn trainingsmateriaal vaak voorkwam. Een ervaren ontwikkelaar kiest wat in een veiligheidsrelevant systeem niet tot een ramp leidt. Deze keuzebeslissing is geen implementatiedetail. Het is de eigenlijke engineering.
In geval van schade verlangt de wetgever het bewijs dat het product bij het in het verkeer brengen overeenstemde met de stand van de techniek. Dat is de centrale voorwaarde om als fabrikant uit de productaansprakelijkheid te kunnen argumenteren. Met de nieuwe EU-richtlijn productaansprakelijkheid en de daaropvolgende nationale uitvoeringswet wordt deze bewijsplicht voor software en software-geïntegreerde producten uitdrukkelijk aangescherpt.
De stand van de techniek is geen statische toestand. Het is wat onder vakmensen als gebruikelijk geldt — en hij verandert momenteel versneld omdat nieuwe gereedschappen en methoden in korte cycli de marktstandaard verhogen.
Daaruit volgt: wie vandaag een embedded systeem ontwikkelt, moet de actueel krachtigere methoden kennen en inzetten. Wie dat niet doet, schept voor zijn opdrachtgever een concreet aansprakelijkheidsrisico. Dat veronderstelt nu juist een ontwikkelaar die zowel de gevestigde als de nieuwe gereedschappen beheerst en de juiste keuze kan maken.
Ik gebruik AI-gereedschappen daar waar ze meetbaar tijd besparen zonder risico's te creëren: eerste schets van boilerplate, generatie van testbenches, documentatie, leesbaarheidstoets.
Ik gebruik ze niet als vervanging van:
Het resultaat: minder inspanning voor routinewerk, gelijkblijvend hoge kwaliteit op de taken die het project werkelijk dragen, en een gedocumenteerd ontwikkelproces dat overeenstemt met de huidige stand van de techniek.
U geeft een ontwikkelaar opdracht met meer dan 35 jaar ervaring in FPGA en embedded, die de actuele gereedschappen kent en hun grenzen kan inschatten. U krijgt geen «AI-gegenereerd project» en geen «AI-vrij project». U krijgt een werkend systeem waarvoor een concrete persoon de verantwoordelijkheid neemt — en dat in geval van schade aantoonbaar volgens de stand van de techniek is ontwikkeld.
Als u een embedded project heeft dat precies deze diepte vraagt, laten we daarover direct praten. Eerste gesprek en grove inschatting zijn kosteloos en vrijblijvend.