Claude Code vs Codex w embedded. Sprawdziłem, czy AI rzeczywiście zastąpiło programistów.

Pod każdą moją reklamą kursu STM32 ktoś musi wyskoczyć z tym samym tekstem: “po co komu kursy programowania, skoro AI już wszystko pisze”. Albo wariant: “embedded skończone, vibe coding zwycięża”. Najczęściej wpisuje to ktoś anonimowy z dwoma postami na koncie i absolutną pewnością siebie.

No to dobra. Sprawdźmy to.

Już nawet pytałem moich znajomych z software house’ów, czy oni jeszcze w ogóle zatrudniają programistów, czy już samo AI siedzi na krześle i programuje. Bo zgodnie z tym, co można przeczytać w komentarzach, programistów de facto już nie powinno być.

Postanowiłem zrobić to porządnie i w transmisji na żywo. Usiadłem z Claude Code od Anthropic i z Codexem od OpenAI i kazałem im napisać za mnie projekt na STM32. Dwie godziny. Dwa narzędzia. Jedno zadanie. Poniżej spisuję wszystko, co z tego wyszło, łącznie z miejscami, w których się wykładali, w których mnie zaskoczyli i w których zachowywali się lepiej, niż się spodziewałem.

Cały ten wpis jest oparty o doświadczenie i obserwacje, których poczyniliśmy wspólnie z widzami na tym Live: https://www.youtube.com/live/fDkElm7tjug

Zadanie testowe

Zadanie celowo dobrałem tak, żeby było realistyczne, ale niełatwe dla LLM-ów:

• Płytka NUCLEO-C562RE – nowiutka, dopiero co ją mam.
• Czujnik BMP280 po I2C – temperatura i ciśnienie.
• Wysyłka pomiarów po UART do terminala na komputerze.
• Pomiar raz na sekundę.
• Wersja blokująca (najprostsza możliwa, co by się AI nie spociło).
• Nowy HAL2 i CubeMX2 od ST.

I tu jest pies pogrzebany. HAL2 i CubeMX2 to świeży tool. Pełnego kodu HAL2 nie ma jeszcze publicznie na GitHubie (ST pracuje nad tym, żeby to upublicznić, ale na razie kod jest niedostępny). Czyli modele nie miały na czym się wytrenować. Mogły co najwyżej domyślać się przez analogię do HAL1.

BMP280 to z kolei klasyk – w internecie kodów do tego czujnika jest miliard. W swoim kursie przeorałem go na każdy możliwy sposób. Materiałów jest tyle, że LLM powinien go mieć w jednym palcu.

Czyli: całkowicie nowe API + niesamowicie znany czujnik. Idealny test, żeby zobaczyć, gdzie AI radzi sobie świetnie, a gdzie zaczyna konfabulować.

Część pierwsza: Claude Code

Claude Code od Anthropic to narzędzie, które uruchamia się w terminalu albo jako wtyczka do VS Code. Ja zdecydowałem się na uruchomienie w terminalu wewnątrz VS Code – jak się później okazało, to była dobra decyzja.

Plan mode – pierwsza pozytywna niespodzianka

Claude ma trzy tryby pracy:

• Plan mode – planuje, ale nie wykonuje zmian.
• Tryb domyślny – pyta o zgodę przed każdą akcją.
• Auto-accept / YOLO – jedzie sam, bez pytania.

Zacząłem od plan mode. Zadałem mu zadanie, dorzuciłem, że pracujemy na nowym HAL2 i CubeMX2, i że pierwszą wersję chcemy zrobić w trybie blokującym. Klepnąłem Enter.

I tu mi się Claude od razu spodobał. Nie pojechał na ślepo. Zadał kilka sensownych pytań:

1. BMP280 – I2C czy SPI?
2. Konfiguracja peryferiów – w CubeMX czy ręcznie w kodzie?
3. Format danych na UART – human readable, CSV, czy oba?
4. Jak często wysyłamy pomiary?
5. Czy chcemy interaktywny terminal?

Klepnąłem odpowiedzi. I poszedł działać.

Dwa agenty równolegle

Tu mnie pozytywnie zaskoczył. Claude odpalił sobie równolegle dwóch sub-agentów:

• Jeden badał strukturę projektu wygenerowaną przez CubeMX2.
• Drugi szukał odniesień do BMP w bazie kodu.

To jest funkcjonalność, o której wiedziałem teoretycznie (czytałem, że da się zrobić “orkiestrę agentową”), ale nie spodziewałem się, że Claude sam z siebie odpali równoległą eksplorację na takim z pozoru prostym projekcie. Robi to po to, aby zaoszczędzić czas. Bardzo fajnie 👌

Przy okazji wykrył coś, co mnie zaskoczyło: nowy CubeMX2 generuje niektóre aliasy bez prefiksu np. hi2c1. Czyli inaczej niż HAL1. Skąd on to wiedział? Albo zbadał wygenerowane pliki, albo coś z tego nowego Cube’a faktycznie już zna. Albo gdzieś już zdążył się tego nauczyć. Albo w połowie strzela, w połowie działa.

Plik CLAUDE.md – dokumentacja konwencji

Claude wygenerował dla projektu plik CLAUDE.md. To jest taka dokumentacja, która mówi mu, jak ma się zachowywać w tym konkretnym projekcie. Wpisał tam:

• Konwencje nazewnicze (zauważone na podstawie analizy kodu CubeMX2).
• Layout katalogów.
• Styl V1 – blocking, prostota nad elegancją.
• Brak FreeRTOS-a, brak DMA, brak przerwań w pierwszej wersji.
• “Magic numbers tylko tam, gdzie nie do uniknięcia”.
• “Komentarze tylko tam, gdzie ‘dlaczego’ jest nieoczywiste”.
• Power management BMP – forced mode zamiast normal. 👉 Tu akurat chyba pomylił z innym czujniek, ale ok.

Czyli sam przeanalizował projekt, sam zaproponował konwencje, sam zapisał je w pamięci dla kolejnych iteracji. To ma duży sens, bo dzięki temu w kolejnych sesjach nie muszę mu od nowa tłumaczyć, jak ma działać. Wystarczy, że w prompt mu rzucę “trzymaj się założeń z CLAUDE.md”.

Konfabulacja – pierwsza wpadka

Wszystko szło super, aż doszliśmy do GPIO. Claude oświadczył mi, że GPIO LED jest skonfigurowane jako output. A ja je przy generowaniu projektu niechcący pomyliłem i było jako input. Nawet nie wiedziałem, że pomyliłem tylko widzowie na chacie zwrócili mi na to uwagę 😇

Pytam go wprost: skąd ten output?

A on mi: “strzeliłem z pamięci na podstawie samej nazwy LD1”

Bardzo ładnie przeprosił. Zbiczowałem go i obiecał, że więcej nie będzie zakładać po nazwach. Zapisał to nawet w pamięci projektu.

Ale moment, w którym to się stało, jest kluczowy dla całego tego eksperymentu. Gdybym sam nie wiedział, jak to peryferium skonfigurowałem – polecielibyśmy z błędem dalej. Skompilowałby się, wgrał na płytkę, dioda by nie świeciła, a ja siedziałbym dwie godziny z analizatorem stanów i zastanawiał się, gdzie jest problem.

Dioda to pół biedy. A co gdyby to był np. sterownik silnika? Puścilibysmy jakieś zwarcie na odbiornik wysokoprądowy? Byłaby lipa, nie?

LLM zawsze będzie miał skłonność do wypełniania luk w wiedzy domysłami. To jest cecha tych modeli, nie błąd implementacji konkretnego narzędzia. I w embedded to gryzie szczególnie, bo tu drobny błąd (np. w konfiguracji pinu) to często godziny debugowania.

Co Claude napisał w kodzie

Po planowaniu Claude przeszedł do pisania. I pojechał z grubej rury. Nie szedł stopniowo, nie weryfikował po krok. Po prostu napisał wszystko od razu:

• Plik log.h i log.c – wrapper printf-like na UART, używa vsnprintf i listy argumentów (va_list).
• Plik bmp.h i bmp.c – pełna struktura z wszystkimi 12 współczynnikami kalibracyjnymi BMP280, init, read, kompensacje temperatury i ciśnienia (te pieprzone wzory z datasheeta), obsługa adresu I2C z przesunięciem na 8 bitów.
• Modyfikacje main.c – integracja, while z odczytem co sekundę.
• Aktualizacja CMakeLists.txt – dodanie nowych plików do kompilacji.

Wszystko obiektowo (struct dla BMP, status init, etc.). Po HAL-u standardowo. Wszystko wyglądało dobrze, ale szczerze mówiąc, podejrzewam, że to nie jest nic skomplikowanego, co Claude wymyślił sam – kodów do BMP280 w internecie jest tyle, że pewnie po prostu wziął typowy wzorzec.

Limity – druga wpadka, tym razem zabójcza

I tu nas dopadła brutalna rzeczywistość pracy z LLMami.

Pracowałem na planie Pro za 20 dolców miesięcznie. Model: Opus 4.6 (najbardziej zaawansowany na tamten moment – już wyszedł 4.7). Effort: xhigh (najwyższe możliwe rozumowanie).

Po jakiejś godzinie pracy zjadłem cały dzienny limit. Reset za kolejne dwie godziny. Tygodniowy limit zjedzony w 16% w jednej, krótkiej sesji.

Projekt Live się skończył nie dlatego, że projekt był skończony, tylko dlatego, że Claude przestał mi odpowiadać. Kod nigdy nie trafił na płytkę. Wiedziałem, że tokeny są w niewielkiej ilości, ale że aż tak?

To jest rzecz, o której nikt nie pisze w tych pięknych marketingowych i clickbaitowych filmach o “zastępowaniu programistów”. 20 dolców miesięcznie to zdecydowanie nie jest plan na pracę komercyjną. To jest plan na “potestować i zobaczyć”. Realna praca z Claude Code wymaga planu Max za 100 dolców miesięcznie, a pewnie i jeszcze wyżej (bo są dwa progi Max) i często też dokupowania extra usage.

Druga sprawa: te narzędzia są łase na tokeny. Robią wszystko, żeby ci limit jak najszybciej wjechał. Każdy status gita, każde sprawdzenie diffa, każde “let me think about it” – to są wszystko spalone tokeny. Trzeba to wkalkulować. Pewnie można to ograniczać w jakiś sposób i będziemy to odkrywali razem na moich kolejnych Live.

Podsumowanie Claude Code

Co potrafi dobrze:

• Plan mode z dopytywaniem o szczegóły – sensownie i bez głupot.
• Równoległa eksploracja projektu przez sub-agentów.
• Generowanie pliku CLAUDE.md z konwencjami – samodzielna analiza projektu i zapis reguł.
• Współpraca z Gitem – proponuje commity, robi je sam po akceptacji.
• Rozumie się na CMake – ogarnął, że trzeba ręcznie dodawać pliki do kompilacji.
• Od razu pisze całe moduły, dobrze zorganizowane (foldery, h+c, struktury, statusy).

Co spaprał:

• Konfabulacja – założył coś po nazwie zmiennej, zamiast sprawdzić w pliku.
• Pojechał z grubej rury – wszystko od razu, brak weryfikacji etapami.
• Spalił cały dzienny limit w godzinę pracy nad jednym czujnikiem.

Część druga: Codex (OpenAI)

Żeby nie kończyć streama po niecałej godzinie, widzowie zaproponowali sprawdzenie największego konkurenta Claude Code. Przesiadłem się zatem na Codex od OpenAA. Pierwszy raz w życiu go otwierałem (Claude’a już trochę testowałem wcześniej), więc tu uczyłem się na bieżąco z Wami.

Codex zainstalowałem jako dedykowaną wtyczkę do VS Code. To jest pierwsza różnica strukturalna: Claude działał w terminalu, Codex w wtyczce. Jak się póżniej okazało – miało to konsekwencje.

Stopniowe podejście

Codex zachował się dokładnie tak, jak sam prowadzę kursy z programowania STM32.

Swoją drogą – chwila autoreklamy – moje kursy:

• Kurs STM32 dla Początkujących
• Język C dla Mikrokontrolerów
• FreeRTOS na STM32 dla Początkujących
• STM32 Na Rejestrach

Zadałem mu to samo zadanie co Claude’owi. Zaczął myśleć. A potem zamiast pojechać z grubej rury, sam zaproponował:

Najpierw zróbmy proof of concept – odczytajmy tylko Chip ID z BMP, żeby zweryfikować, czy w ogóle komunikacja I2C działa. Dopiero potem dopiszemy resztę.

To jest dokładnie metodyka, której uczę w kursach. Najpierw sprawdź, czy się komunikujesz, dopiero potem dopisuj resztę. Bo jak coś nie działa po pełnej implementacji, to nie wiesz, czy problem jest w komunikacji, w odczycie kalibracji, w obliczeniach, czy w wysyłce po UART. A tak krok po kroku masz szansę wyeliminować większość problemów.

Czemu Codex tak zrobił, a Claude nie? Moja teoria: Codex prawdopodobnie uczył się na źródłach, które tak właśnie idą. Tutoriale z embedded często mają taki układ – chip ID, potem reszta. Claude zachował się jak ktoś, kto widział dużo kodu i potrafi cały odtworzyć z pamięci. Codex zachował się jak ktoś, kto widział dużo tutoriali i potrafi nas przez nie przeprowadzić.

Bardziej wylewny w komunikacji

Codex tłumaczył, co robi i dlaczego. Claude bardziej milczy i działa, Codex jest tutaj takim narratorem.

W swoim planie wypisał między innymi świeże źródła z forum ST Community sprzed miesiąca, których ja nawet nie znałem. Nie powiedziałem mu konkretnie, że ma szukać aktualnych dyskusji – sam się tym pochwalił w sekcji “źródła referencyjne” w planie. Faktycznie te wpisy na blogu ST były o aktualnym HAL2 i tym jak używać UART i I2C. Ekstra!

Ważne zastrzeżenie: w transkrypcji widać, że Codex te źródła wypisał w planie. Czy faktycznie z nich korzystał, czy tylko zalinkował – tego ze 100% pewnością nie wiem. Ale sama informacja o tym, że tam można szukać, była dla mnie wartościowa.

Gdzie pisze pliki

Tu wyłapałem różnicę między Claudem a Codexem.

Claude pisał w folderze user_modifiable – zgodnie z konwencją, w której CubeMX2 oddziela kod użytkownika od kodu generowanego. A przynajmniej tak mi się wydaje, że to folder na kod użytkownika, bo jeszcze dobrze nie znam tych nowości.

Codex pisał bezpośrednio w folderze root projektu, obok wygenerowanych folderów. Komentowałem to na live: “on mi tu pisze aplikację, zamiast pofolderować”. Nie wiem, czy to jest błąd, czy świadoma decyzja Codexa. Możliwe, że nie kojarzy nowej konwencji CubeMX2 i pisze “po staremu”. Albo trzeba wyraźnie to podkreślić w założeniach projektu.

Nie mniej w ten sposób gubi się ta separacja “kod użytkownika vs kod generowany”. W praktyce: jak wygenerujesz projekt ponownie z CubeMX2, to musisz ręcznie wyciągać swój kod z plików, żeby ci się nie nadpisał. Póki co nie wiemy jeszcze jak dobrze działa mechanizm “nienadpisywania” kodu użytkownika. ST bowiem zrezygnowało ze znaczników *USER CODE BEGIN/END*.

Codex i Git – problem

Tu Codex położył się na łopatki.

Próbował zrobić commita. Sprawdził status. Zrobił diff. Sprawdził config Gita. Sprawdził git log –oneline. Sprawdził head, tail -5. I tak w kółko. Zapętlił się. Nie potrafił zrobić commita z czym Claude nie miał żadnego problemu.

Szczerze mówiąc, nie wiem, co dokładnie tam nie zadziałało. Możliwe wyjaśnienia:

• PowerShell – mam Windowsa, terminal w VS Code domyślnie odpalał PowerShella. Codex próbował komend gitowych, ale coś mu nie szło.
• Brak terminalu – Claude działał w terminalu i miał bezpośredni dostęp do gita. Codex jako wtyczka VS Code – nie do końca tak samo.
• Sandbox – Codex prosił mnie o “setup agent sandbox”. Możliwe, że to jego sandbox jakoś izoluje go od Gita.

Sugestia z Waszego czatu: WSL. Albo: przejść na zwykły terminal. Tego nie testowałem na live, ale na pewno zrobię to przy okazji następnego.

W praktyce skończyło się tak, że ja sam wykonywałem komendy gitowe w GitBashu, a Codex mi je tylko podpowiadał. Czyli odwrotność tego, co miało być.

Codex i sprzęt – druga wpadka

Codex próbował sam uruchamiać kod na płytce, której fizycznie nie miał jak dotknąć, bo była niepodłączona 🥲

Najpierw zrobił build. Potem próbował skonfigurować debug preset. Potem próbował coś flashować. i tak w kółko. Nie dał znać, że jest coś nie tak. Palił tokeny, czyli to co uwielbia.

Musiałem mu wprost napisać: “ty masz tylko kod pisać, ja uruchamiam”. Inaczej dalej by próbował.

To jest ciekawa różnica. Claude nie próbował niczego uruchamiać – po prostu czekał. Codex z domyślnymi uprawnieniami “full access” (które trzeba samemu ustawić w sandboxie) jest bardzo aktywny. Jak nie powiesz mu “stop”, to próbuje wszystko, w tym rzeczy, których nie powinien.

BMP nie odpowiada – debugowanie z AI

Po wgraniu kodu na płytkę dostaliśmy: “BMP not found”.

Klasyk. Czujnik nie odpowiada. Tu Codex sam zaproponował kilka prawdopodobnych przyczyn:

• Sposób podawania adresu (przesunięcie 7-bit na 8-bit).
• Konfiguracja I2C.
• Zasilanie.
• Połączenia.

Sprawdziłem. Połączenia OK. Zasilanie OK. Czyli problem w komunikacji albo w adresie.

Sugestia z Waszego czatu: dopisz skaner I2C, będziemy mieli 100% pewności zamiast strzelania. Genialne, dzięki!

Codex poproszony i to – bardzo sprawnie dopisał skaner. Wgraliśmy. Skaner znalazł urządzenie pod innym adresem, niż Codex zakładał. Domyślny adres BMP280 zależy od stanu pinu SDO – jak SDO podpięte do GND, jeden adres, jak do VCC, drugi. Codex nie dopytał o tę konfigurację, tylko strzelił domyślny.

Po poprawce – temperatura i ciśnienie pojawiły się na terminalu. Reagowały na dotyk. Wartości się zmieniały. Czyli zadanie wykonane.

Ale zauważ: udało się tylko dlatego, że ja wiedziałem (a w zasadzie to wiedzieliśmy razem z chatem), jak działa BMP280 i jak go diagnozować. Bez tej wiedzy domenowej, “BMP not found” zostałoby na zawsze, bo skończyły by się nam tokeny. Codex bowiem miał plan, żeby podmieniać wartości adresu i próbować kolejny raz uruchamiać firmware.

Podsumowanie Codex

Co potrafi dobrze:

• Stopniowe podejście – proof of concept przed pełną implementacją.
• Wylewny w tłumaczeniach – tłumaczy, co i dlaczego robi.
• Wypisuje świeże źródła w planie (z forów branżowych).
• Diagnostyka – sensownie wymienia prawdopodobne przyczyny problemów.
• Po sugestii (skaner I2C) szybko reaguje i dopisuje pomocniczy kod.

Co spaprał:

• Git zapętlony – nie potrafił skutecznie zrobić commita w PowerShellu.
• Sam próbował flashować płytkę, której nie ma podpiętej.
• Pisze pliki w gołym folderze, gubiąc separację user/generated.
• Nie dopytał o adres I2C BMP280 – strzelił domyślny.
• Zjadł 96% tygodniowego limitu w jednej sesji (model GPT-5 z reasoning high).

Najważniejsze różnice między Claude a Codexem

Po dwóch godzinach pracy z obydwoma narzędziami widzę kilka istotnych różnic.

Styl pracy

Claude: szybko, z grubej rury, cały kod od razu, później debugowanie.

Codex: stopniowo, weryfikuje po każdym kroku, czeka na odpowiedź zanim pójdzie dalej.

To są dwie różne filozofie. Claude bardziej przypomina seniora, który wie, co robi, i pisze cały moduł na raz. Codex bardziej przypomina juniora, który chce się upewnić, że nie pisze niepotrzebnie.

W praktyce: jak chcesz zrobić nowy projekt od zera, Claude jest szybszy. Jak masz istniejący kod, w którym trzeba coś poprawić albo rozszerzyć krok po kroku, Codex jest bezpieczniejszy.

Ten obserwacja pasuje do komentarza, który padł na livie: “Codex jest dobry do poprawiania błędów i pracy na istniejącym kodzie, Claude jest świetny do tworzenia projektu od zera.” Po dwóch godzinach mogę to w jak narazie potwierdzić. Ale będę badał dalej 🙂

Komunikatywność

Claude: bardziej milczy. Działa, czasem napisze, co robi, ale często musisz go pytać “BTW, co robisz?” jeśli chcesz sie dowiedzieć co knuje. Oczywiście najpierw podczas planowania jest z nim dużo rozmowy, ale potem – działa.

Codex: bardziej rozmowny przez cały czas. Tłumaczy każdy krok, pisze “robię to, bo…”, “teraz przechodzę do…”. Trochę gorzej ma to pokazane, ale robi.

Codex jest przyjemniejszy w pracy, bo widzisz, co się dzieje. Claude jest szybszy, bo nie marnuje tokenów na narrację (ale i tak zjadł wszystkie zanim skończył projekt 😅).

Praca z narzędziami zewnętrznymi (Git, build, flash)

Claude: w terminalu działa świetnie. Git, CMake, build – wszystko ogarnia. Pyta o dostępy do komend systemowych. Możesz dać pozwolenie na stałe, albo poprosić żeby za każdym razem pytał o użycie.

Codex: w wtyczce VS Code zapętla się przy Gicie w PowerShellu. Próbuje sam flashować płytki, których nie ma. Spróbuję się w tym zagłębić – to musi działać samodzielnie.

Tu jest duży minus Codexa dla osób na Windowsie. Sugestia z czatu: WSL albo zwykły terminal.

Proszenie o pozwolenie

Claude: domyślnie pyta o zgodę przed każdą akcją (w trybie domyślnym).

Codex: w sandboxie z full access jedzie sam, bez pytania. Trzeba mu wyraźnie powiedzieć, czego ma nie robić i to czasami kilkukrotnie.

Dla osób, które chcą kontroli – Claude. Dla osób, które chcą tylko efektu – Codex.

Limity

Claude Pro 20$: jakaś godzina pracy na Opusie z xhigh effortem. Dzienny limit papa. Smutno.

Codex (plan ChatGPT Plus, prawdopodobnie z reasoning high): 96% tygodniowego limitu w jednej sesji. Projekt zakończony sukcesem.

Oba narzędzia są łase na tokeny. Trzeba wybierać model i effort rozsądnie. Czasem Sonnet (Claude) albo o5-mini (Codex) wystarczą.

Co z tego wynika dla nas, embeddowców?

Po dwóch godzinach pracy mam kilka ogólnych wniosków, które wykraczają poza porównanie samych narzędzi.

Wiedza domenowa to nadal warunek konieczny

Przez całe dwie godziny korygowałem AI średnio co kilka minut:

• Dobre piny na schemacie Nucleo (Claude zaproponował domyślne, ja zweryfikowałem na schemacie).
• Weryfikacja, czy GPIO jest input czy output (konfabulacja Claude’a).
• Odpowiedni tryb I2C i prędkość.
• Wykrycie problemu z adresem BMP280 (zależnym od SDO).
• Decyzja o tym, że ja flashuję płytkę, nie AI.
• Decyzja o tym, że nie używamy DMA / przerwań w pierwszej wersji.

Gdybym tej wiedzy nie miał, projekt by nie działał. A co gorsze – nie wiedziałbym dlaczego. AI strzeliłoby coś, co “powinno działać”, a w praktyce nie działa.

Vibe coding w embedded to droga do projektu, który “się buduje” i prawdopodobnie nie działa na sprzęcie. Musisz mieć wiedzę z zakresu embedded. Nic mnie tutaj jeszcze nie zastąpiło.

Embedded jest 10 lat za webówką

W webówce ktoś klepnie “zrób mi sklep” i dostanie sklep. Sam tak działam 😅 Frameworki są publiczne, dokumentacja jest wszędzie, kodów na GitHubie miliony.

W embedded klepniesz “odczytaj BMP280” i dostaniesz coś, co teoretycznie powinno działać, ale czujnik się nie odzywa, bo adres jest inny. A przynajmniej moje dotychczasowe doświadczenie na to wskazuje.

Dlaczego? Bo:

• Reference manuale to PDF-y po 3000 stron, których AI nie mieści w kontekście.
• Kodów na GitHubie jest mniej, są fragmentaryczne, często niedziałające.
• Każda płytka, każdy chip, każdy peryferiał ma swoje smaczki.
• Nowe narzędzia (HAL2, CubeMX2) jeszcze nie są jeszcze dobrze znane.

To nas chroni przed AI, ale to jest też ślepa uliczka, jeśli chce się wejść w embedded dziś z poziomu vibe codera. Bo materiałów, na których AI dobrze by się uczyło, po prostu nie ma w wystarczającej ilości. Ale to się zmieni z czasem – to więcej niż pewne.

Limity są realnym kosztem

Plan Pro Claude’a za 20$ to godzina pracy nad jednym czujnikiem. Plan ChatGPT Plus nie jest dużo lepszy.

Realna praca komercyjna oznacza:

• Plan Max Claude’a za 100$ miesięcznie lub więcej.
• Dokupowanie extra usage (Codex to wspiera, Claude też).
• Przemyślane zarządzanie kontekstem – wycinanie folderów, których AI nie ma czytać (np. CMSIS, architektury innych Cortexów).
• Wybór modelu i effortu pod konkretne zadanie – nie zawsze trzeba najmocniejszy Opus z xhigh effort.

To wszystko to jest nowa kompetencja dla programisty, której trzeba się nauczyć. Nie wystarczy wpisać “napisz mi kod” i czekać. Praca programisty nie jest usuwana – po prostu się zmienia.

Kontekst jest królem

Kilka rzeczy, które zauważyłem w tym kierunku:

• CLAUDE.md – plik z konwencjami projektu, do którego AI się odnosi.
• context7 – plugin do Claude Code, który zasysa dokumentację (sam jeszcze nie testowałem, ale czytam o nim same dobre rzeczy).
• Konwersja PDF-ów na markdown – bo markdown lepiej działa jako kontekst dla LLM-a niż PDF.
• Wycinanie zbędnych folderów w projekcie, żeby AI po nich nie chodziło i nie spalało tokenów.
• Skille i wtyczki – ekosystem wokół Claude’a i Codexa rośnie szybko.

Im lepszy kontekst dasz AI, tym lepszy kod ono napisze. Bez kontekstu – strzela na ślepo. Trzeba też wyraźnie podkreslić, że my na tym Live podeszliśmy z założenia tak jakbyśmy się absolutnie na niczym nie znali. No… czasem musieliśmy jednak korygować korzystając z ekspertyzy embedded 🙂

Moja wizja, co dalej

Tu jest moje gdybanie, możecie mnie za 3 lata sprawdzić.

Wydaje mi się, że agenty, których mamy teraz – Claude Code, Codex i ta cała reszta – to jest pierwsza iteracja. Wszystkie chodzą zdalnie, wszystko leci do chmury. I to się będzie zmieniać, bo widać dokładnie ten sam trend, który widzieliśmy w embedded.

Na Embedded World na przestrzeni kilku ostatnich lat było wyraźnie widać, że chmurowe AI przeszło na Edge AI – czyli wszystko uruchamiane lokalnie, na małym mikrokontrolerze. Moim zdaniem tak samo pójdzie z agentami programistycznymi.

Czemu? Bo cały segment enterprise dba o swoje IP, swoją wiedzę, swoją prywatność. Mniej lub bardziej dba, ale przynajmniej mówi, że dba. I oni będą naciskali, żeby takie narzędzia pojawiały się lokalnie, hostowane u nich na serwerach.

Strzelam, że pójdzie to dwoma falami:

1. Najpierw duże modele na grube serwery, które firmy będą sobie hostować same. Już teraz zaczynają się pojawiać małe lokalne modele jak Gemma 4 od Google’a. Mamy też kilka modeli od OpenAI, ale przede wszystkim setki modeli open-source gotowych do pracy od razu i za darmo. To jest pierwszy krok.
2. Potem małe modele wyspecjalizowane do programowania, które uruchomimy sobie na zwykłym pececie. Mniej mocy, ale ogarnią. I to będzie przełom dla osób, które nie chcą wysyłać kodu do chmury – zwłaszcza czyjejś.

Czyli Edge Agent AI. Tak jak w embedzie poszło Edge AI, tak z agentami pójdzie Edge Agent AI. Takie jest moje gdybanie.

I tu druga rzecz: praca programisty się zmieni, ale nie zniknie. Strzelam, że napewno nie w najbliższych 5 latach.

Ile z nami jest AI? Trzeci rok? Od trzech lat cały czas wszyscy mówią, że programiści są skończeni. I co? Od trzech lat są skończeni, a dalej jednak są między nami.

To trochę jak przejście z liczydła na peceta. Tylko że peceta trzeba umieć obsłużyć.

Co robimy dalej

Ten temat będę ciągnął dalej. Na kolejnych livach wracam do projektu z BMP280 – mamy jeszcze w planach wersję na przerwaniach, potem na DMA. Z Claude’em i Codexem. Sprawdzimy:

• Jak sobie radzą z bardziej złożonym kodem (DMA to nie jest blocking).
• Co potrafi zaproponować AI, a co trzeba mu wyraźnie powiedzieć.
• Jak konfigurować agentów, żeby się nie plątali (sugestia z czatu).
• Jak pracować z context7, skillami, MCP.
• Czy da się dorzucić im reference manual (skonwertowany na markdown).
• Jak oszczędzać tokeny.

Plus jeszcze chcę spróbować zrobić to samo na mniej popularnym czujniku. Bo BMP280 to klasyk – w sieci jest miliard kodów. Ciekawi mnie, jak AI sobie poradzi z czymś, czego nie ma w datasecie.

Przed nami wiele ciekawych odkrywczych godzin. Mam nadzieję, że będziesz mi towarzyszył.

👉 I jeszcze jedno – postawiłem dedykowany serwer Discord “AI w Embedded”. Po to, żebyśmy mogli wymieniać się doświadczeniami na żywo, a nie raz na dwa tygodnie. Temat jest szeroki, zmienia się szybko (każdy tydzień nowy model, nowe narzędzie) i jeden człowiek tego nie ogarnie sam.

Jeśli też testujesz te narzędzia w swoich projektach – wpadaj, podziel się tym, co działa, a co Cię wkurza.

Dołącz tutaj: https://linki.msalamon.pl/ai_embedded

Czyli zastąpiło, czy nie?

Na ankiecie na koniec live’a 90% z 60 osób zagłosowało, że AI nas jeszcze nie zastąpiło.

Dziwne, bo komentatorzy spod reklam są innego zdania. Pewnie po prostu nie przyszli na live. Albo AI ich zastąpiło również w oglądaniu gościa, któremu spamują w komentarzach 🙂

Moje zdanie po dwóch godzinach z Claude Code i Codexem? AI to świetny wspomagacz, ale jeszcze nie zastępca. Tak jak młotek nie zastąpił stolarza, tylko stolarza bez młotka. Praca programisty embedded się zmieni – tym, którzy się nie nauczą tych narzędzi, będzie ciężko konkurować. Ale wiedza o tym, jak działa hardware, jak konfigurować peryferia, jak debugować na sprzęcie – to wszystko zostaje. AI tego za nas nie zrobi.

Przynajmniej nie w tej iteracji.

I dlatego dalej będziemy się tego uczyć razem.

Daj znać w komentarzach, co u Ciebie. Czy używasz już AI do embedded? Co działa, a co Cię irytuje? Wpadaj na Discord. Zapisz się na kolejny live.

Do zobaczenia na żywo ✌️