Generativ AI förändrar en del av den inbyggda utvecklingen — men inte den avgörande delen. Vad som har förskjutits, vad som har skärpts, och vad du som uppdragsgivare får.
Generativ AI kan numera producera standarddrivrutiner, enkla tillståndsmaskiner och boilerplate-kod i SystemVerilog, VHDL, C eller Python. Det är verkligt, det är nyttigt, och det har minskat insatsen för vissa rutinuppgifter.
Av detta uppstår en berättigad fråga: vad bidrar en erfaren utvecklare inom inbyggt och FPGA fortfarande med i denna miljö?
Svaret är konkret.
En AI är en snabb utförare. Den producerar det som den ombeds göra — inte det som behövs. Att be en AI «skriv mig en UART-drivrutin» ger en UART-drivrutin. Men inte den som faktiskt fungerar med just denna klockdomän, denna stiftallokering, detta tidsbeteende och denna felhantering i målmiljön.
Den egentliga ingenjörsinsatsen är inte att generera kod. Den är att skriva en precis specifikation: vad ska exakt ske, under vilka villkor, med vilka toleranser, med vilket beteende vid fel, i vilket temperaturområde, över vilken livslängd.
Bättre AI ändrar inget på detta. Tvärtom: ju kraftfullare verktygen blir, desto mer avgörande blir det att instruera dem rätt.
En AI fyller inte på krav som beställaren inte tänkt på. Den uppfinner inte specialfall. Den levererar exakt det som står i specifikationen — och inget därutöver. Det som inte är specificerat saknas i resultatet.
Därmed förskjuts risken helt till själva specifikationen. En oerfaren specifikation beskriver korrekt det kunden bett om och förbiser allt som författaren aldrig upplevt: det sällsynta sensorbortfallet vid vissa temperaturgradienter, beteendet vid samtidig brown-out och I²C-busslås, watchdog-reset under en flash-skrivsekvens, elektromagnetisk inkoppling på långa sensorledningar, beteendet vid omstart efter en oavsiktlig reset under en kritisk skrivoperation.
Sådana punkter är inga kundkrav. De är krav som en erfaren utvecklare lägger till, eftersom han vet att de annars inte skulle stå någonstans. En specifikation är därför alltid också en riskkatalog — och dess djup är proportionellt mot erfarenheten hos den som skriver den.
Vid en säkerhetsutredning av en infusionsapparat, dit jag kallades in av en tillverkare av medicintekniska produkter, framträdde ett säkerhetsrelevant fel som uppstod ur det samtidiga uppträdandet av två enskilda fel: hårdvarufel i en minneskrets och en felaktig kontrollrutin för just denna krets. Varje fel för sig var hanterbart. Först kombinationen gav det icke-upptäckta feltillståndet.
Det är just denna kombinationsanalys som måste läggas till aktivt i en specifikation. Ur kravet «kontrollera minnet» genererar ett verktyg en kontrollrutin. Ur erfarenheten följer det ytterligare kravet att även kontrollrutinens egen felning inte får leda till ett tyst feltillstånd. Inget verktyg formulerar detta andra krav på egen hand.
Därtill kommer de hårdvarunära fallgropar som inte står i datablad, utan i huvudena på utvecklare som redan har jagat dem en gång:
För de flesta uppgifter finns flera lösningar som i grunden fungerar. Men endast få av dem uppfyller kraven på säkerhet, tillförlitlighet och livslängd som den konkreta produkten kräver.
Ett AI-system väljer det som var vanligt i dess träningsdata. En erfaren utvecklare väljer det som inte leder till katastrof i ett säkerhetsrelevant system. Detta urvalsbeslut är ingen implementationsdetalj. Det är den egentliga ingenjörskonsten.
Vid skadefall kräver lagstiftaren bevis för att produkten vid utsläppandet på marknaden motsvarade teknikens ståndpunkt. Det är den centrala förutsättningen för att en tillverkare ska kunna argumentera bort produktansvaret. Med det nya EU-produktansvarsdirektivet och den nationella genomförandelagen som följer av det skärps denna bevisbörda uttryckligen för programvara och programvaruintegrerade produkter.
Teknikens ståndpunkt är inget statiskt tillstånd. Det är vad som bland fackmän anses vanligt — och förändras för närvarande accelererat eftersom nya verktyg och metoder höjer marknadsstandarden i korta cykler.
Av detta följer: den som idag utvecklar ett inbyggt system måste känna till och använda de mer kraftfulla metoderna som finns för närvarande. Den som inte gör det skapar för sin uppdragsgivare en konkret ansvarsrisk. Det förutsätter just en utvecklare som behärskar både de etablerade och de nya verktygen och kan göra rätt val.
Jag använder AI-verktyg där de mätbart sparar tid utan att skapa risker: första utkast av boilerplate, generering av testbänkar, dokumentation, läsbarhetskontroll.
Jag använder dem inte som ersättning för:
Resultatet: mindre insats för rutinarbete, jämnt hög kvalitet i de uppgifter som faktiskt bär projektet, och en dokumenterad utvecklingsprocess som motsvarar den aktuella teknikens ståndpunkt.
Du anlitar en utvecklare med mer än 35 års erfarenhet inom FPGA och inbyggt, som känner till de aktuella verktygen och kan bedöma deras gränser. Du får varken ett «AI-genererat projekt» eller ett «AI-fritt projekt». Du får ett fungerande system som en konkret person tar ansvaret för — och som vid skadefall bevisligen utvecklats enligt teknikens ståndpunkt.
Om du har ett inbyggt projekt som kräver just detta djup, så talar vi om det direkt. Förstasamtal och grov bedömning är kostnadsfria och utan förpliktelser.