Czy AI sprawdzi
się w systemach
wbudowanych?  

Dawno temu, gdy zaczęło robić się głośno o AI, myślałem, że istnieje jednak obszar, gdzie AI będzie miało pod górkę - embedded. Systemy wbudowane, mikrokontrolery, komunikacja z układami peryferyjnymi, bootloadery. To nie jest pisanie skryptów w Pythonie. Tu liczy się znajomość hardware'u, specyfiki konkretnych procesorów, i niuansów środowisk uruchomieniowych. Czułem, że to bastion inżynierskiego rzemiosła, który AI może co najwyżej obserwować z boku. Myliłem się. 

Co tak naprawdę zmieniło AI w pracy z kodem? 

Żeby zrozumieć, o czym mówię, warto cofnąć się o krok. Ludzie używają AI na bardzo różne sposoby. Jedni zadają pytania i dziwią się, że odpowiedzi są dziwne. Inni wiedzą, jak pytać, ale nie wiedzą, kiedy. Jeszcze inni automatyzują procesy, eksperymentują z wieloma agentami działającymi równolegle, albo trenują własne modele. To całe spektrum. 

U mnie AI weszło płynnie do codziennej pracy: automatyzacja powtarzalnych procesów, pisanie zapytań SQL, skrypty, do których nie miałbym cierpliwości. Oczywistości. Pisanie oprogramowania - zarówno front, jak i backendowego - testy, nowe funkcjonalności. To działa naprawdę dobrze, pod warunkiem, że wiemy co chcemy osiągnąć i jak to kontrolować. 

Mój senior powiedział kiedyś coś, co dobrze to opisuje: AI jest jak bardzo dobry junior. Szybki, sprawny, niestrudzony. Ale jeszcze nie senior. Wciąż potrzebuje nadzoru. No dobrze, ale embedded to inny świat. 

Kiedy przestałem się opierać? 

Miałem opór. Systemy embedded to nie jest środowisko, w którym można improwizować. Każdy procesor ma swoją specyfikę. Układy peryferyjne komunikują się na określonych zasadach. Środowisko uruchomieniowe bywa wybredne. Bez tej wiedzy nie ma efektu, niezależnie od tego, jak sprawne jest narzędzie. I właśnie dlatego długo odkładałem testy. 

Ale w końcu postanowiłem zaprząc AI do realnego projektu. Nie do podpowiedzi, nie do dokumentacji i researchu, tylko do realnej pracy. Zadziałało. I to bardzo dobrze. 

Klucz był taki sam jak zawsze: dobre zdefiniowanie problemu, opisanie założeń, dopracowany promptu, generacja  Markdown i uważna weryfikacja tego, co powstaje wychodzi. Gdy zrobi się to porządnie, można przerabiać istniejące projekty sprzętowe albo tworzyć je od nowa - na bazie wstępnie skonfigurowanych presetów lub już działających projektów - wyjmując z nich potrzebne fragmenty pod konkretny sprzęt i konkretny procesor. 

Co to znaczy w praktyce? 

Żeby nie być abstrakcyjnym - wyobraź sobie, że uruchamiasz nowe urządzenie embedded. Masz port debugowy. Chcesz sprawdzić, czy wszystko działa poprawnie. Do tej pory: piszesz testy, analizujesz komunikaty, poprawiasz, testujesz znowu. Cała pętla po stronie inżyniera. 

Teraz: definiujesz, co testować i określasz, na jakim porcie system będzie zwracał komunikaty. Agent przygotowuje zestaw testów, analizuje wyniki i proponuje poprawki na bieżąco. Inżynier nadzoruje i decyduje. Ale nie wykonuje całej tej żmudnej pracy. 

Inne przykłady: bootloader dla konkretnego procesora, działający po Modbus albo scalienie dwóch programów, działających wspólnym hardware w jeden spójny system. Kiedyś czasochłonne i szczególnie podatne na błędy. Dziś - coraz mniej. 

Dlaczego to jest ważniejsze niż się wydaje? 

Nie chodzi tylko o tempo pracy, ale o to, gdzie skupia się uwaga. 

Gdy agent przejmuje tę warstwę pracy, która jest powtarzalna i mechaniczna, inżynier może skupić się na tym, co naprawdę wymaga myślenia: definiowaniu problemu, weryfikacji wyników i podejmowaniu decyzji. To dziś fundament jego roli. Oszczędza czas i zmniejsza ryzyko pomyłek wynikających ze zmęczenia. 

Embedded długo opierał się takiemu wsparcie. Nie dlatego, że narzędzia były słabe, tylko dlatego, że specyfika tej pracy wymagała eksperckiej wiedzy, której nie da się zastąpić szablonem. 

AI tego nie zastąpi. Ale ktoś, kto tę wiedzę ma i potrafi dobrze ubrać ją w prompt  zyskuje nagle bardzo sprawnego pomocnika. 

Coraz częściej łapię się więc teraz nie na pytaniu "Kto to może zrobić?", tylko "Jak to najlepiej opisać agentowi?" 

To zmiana bardziej mentalna niż techniczna. I trudniejsza, niż się wydaje.