IA generativă schimbă o parte a dezvoltării încorporate — dar nu partea decisivă. Ce s-a deplasat, ce s-a accentuat și ce primiți ca beneficiar.
IA generativă poate produce astăzi drivere standard, automate de stare simple și cod boilerplate în SystemVerilog, VHDL, C sau Python. E real, util și a redus efortul pentru anumite sarcini de rutină.
De aici reiese o întrebare îndreptățită: ce mai aduce un dezvoltator experimentat de sisteme încorporate și FPGA în acest mediu?
Răspunsul este concret.
O IA este un executant rapid. Produce ce i se cere — nu ce este necesar. A cere unei IA «scrie-mi un driver UART» dă un driver UART. Dar nu cel care funcționează cu adevărat cu acest domeniu de ceas, această alocare de pini, această comportare temporală și această tratare a erorilor în mediul țintă.
Adevărata muncă de inginer nu este generarea de cod. Este redactarea unei specificații precise: ce trebuie să se întâmple exact, în ce condiții, cu ce toleranțe, cu ce comportare la eroare, în ce interval de temperatură, pe ce durată de viață.
O IA mai bună nu schimbă nimic. Dimpotrivă: cu cât instrumentele devin mai puternice, cu atât este mai decisiv să fie instruite corect.
O IA nu adaugă cerințe la care beneficiarul nu s-a gândit. Nu inventează cazuri speciale. Livrează exact ce este în specificație — și nimic în plus. Ce nu este specificat, lipsește în rezultat.
Astfel riscul se transferă complet asupra specificației înseși. O specificație neexperimentată descrie corect ce a cerut clientul și trece cu vederea tot ce autorul nu a trăit niciodată: rara defecțiune de senzor la anumite gradiente de temperatură, comportarea la brown-out simultan și blocarea magistralei I²C, un reset de watchdog în timpul unei secvențe de scriere flash, cuplajul electromagnetic pe cabluri lungi de senzor, comportarea la repornire după un reset neintenționat în timpul unei operații critice de scriere.
Astfel de puncte nu sunt cerințe ale clientului. Sunt cerințe pe care un dezvoltator experimentat le adaugă, știind că altfel n-ar figura nicăieri. O specificație este de aceea întotdeauna și un catalog de riscuri — iar adâncimea acestuia este proporțională cu experiența celui care o redactează.
În cadrul unei investigații de siguranță la un aparat de perfuzie, la care am fost chemat de un producător de dispozitive medicale, s-a manifestat o defecțiune relevantă pentru siguranță rezultată din apariția simultană a două defecte individuale: defecțiunea hardware a unui circuit de memorie și o rutină eronată de verificare pentru tocmai acel circuit. Fiecare defect în parte era gestionabil. Doar combinația a produs starea de eroare nedetectată.
Tocmai această analiză combinată trebuie adăugată activ într-o specificație. Din cerința «verifică memoria» un instrument generează o rutină de verificare. Din experiență rezultă cerința suplimentară ca eșecul rutinei de verificare însăși să nu conducă la o stare de eroare tăcută. Niciun instrument nu formulează această a doua cerință de la sine.
La acestea se adaugă capcanele apropiate de hardware, care nu se află în fișele tehnice, ci în mintea dezvoltatorilor care le-au mai vânat o dată:
Pentru majoritatea sarcinilor există mai multe soluții care funcționează în principiu. Dar doar puține îndeplinesc cerințele de siguranță, fiabilitate și durată de viață cerute de produsul concret.
Un sistem IA alege ce a fost frecvent în datele sale de antrenament. Un dezvoltator experimentat alege ce nu duce la catastrofă într-un sistem relevant pentru siguranță. Această decizie de selecție nu este un detaliu de implementare. Este adevărata inginerie.
În caz de daună legiuitorul cere dovada că produsul, la momentul punerii pe piață, corespundea stadiului tehnicii. Aceasta este condiția centrală pentru ca un producător să se poată argumenta în afara răspunderii pentru produs. Cu noua Directivă europeană privind răspunderea pentru produsele defectuoase și legea națională de transpunere care decurge din ea, această sarcină a probei este înăsprită explicit pentru software și produsele integrate cu software.
Stadiul tehnicii nu este o stare statică. Este ceea ce între profesioniști este considerat obișnuit — și se schimbă în prezent accelerat, deoarece noi instrumente și metode ridică standardul pieței în cicluri scurte.
Rezultă: cine dezvoltă astăzi un sistem încorporat trebuie să cunoască și să folosească metodele actualmente mai puternice. Cine nu o face, creează pentru beneficiarul său un risc de răspundere concret. Aceasta presupune tocmai un dezvoltator care stăpânește atât instrumentele consacrate, cât și pe cele noi și poate face alegerea corectă.
Folosesc instrumente IA acolo unde economisesc timp măsurabil fără a crea riscuri: prima schiță de boilerplate, generare de testbench-uri, documentație, verificarea lizibilității.
Nu le folosesc ca înlocuitor pentru:
Rezultatul: efort mai mic pentru munca de rutină, calitate constant ridicată la sarcinile care duc cu adevărat proiectul, și un proces de dezvoltare documentat care corespunde stadiului actual al tehnicii.
Mandatați un dezvoltator cu peste 35 de ani de experiență în FPGA și încorporate, care cunoaște instrumentele actuale și poate aprecia limitele lor. Nu primiți nici un «proiect generat de IA» și nici un «proiect fără IA». Primiți un sistem funcțional pentru care o persoană concretă își asumă responsabilitatea — și care, în caz de daună, poate fi demonstrat ca dezvoltat conform stadiului tehnicii.
Dacă aveți un proiect încorporat care cere tocmai această profunzime, să discutăm direct. Discuție inițială și estimare aproximativă sunt gratuite și fără obligații.