Skocz do zawartości

Pomocna odpowiedź

Napisano (edytowany)

Wstęp

Artykuł powstał w związku z dobrym odbiorem pierwotnego artykułu dostępnego tutaj.

claudevscodex.thumb.png.c132c2b4e1daf5eddacf787e100535dd.png
Które AI jest lepsze?

Po dłuższym użytkowaniu SI do tworzenia kodu, w tym aplikacji na komputer (Python, C++, C#) oraz embedded (C++, C) mogę śmiało stwierdzić, że dobrze poinstruowana SI wykonuje pracę na poziomie dobrego programisty średniego szczebla. Istotny szczegół: dobrze poinstruowana. Jeżeli wrzucimy do ChatGPT zapytanie "zrób aplikację XYZ" oraz damy rozbudowaną specyfikację... uzyskamy beznadziejne rezultaty.

Jak więc pracować z SI?

Primo

Ogólnodostępne chaty nadają się jedynie do szukania informacji i tworzenia pojedynczych algorytmów. Stworzenie aplikacji niestety wymaga wydania kilku cebulionów z kieszeni (99PLN/20€/20$ na miesiąc, w zależności od dostawcy). Oczywiście należy szukać SI z wbudowaną aplikacją do kodowania i względnie dużym limitem tokenów.

Więc jakie SI wybrać?

Miałem okazję korzystać z kilku. Jeżeli potrzebujemy tylko podstawowego podpowiadania składni to dobrym wyborem jest GitHub Copilot albo Cursor.

Jednakowoż chcąc tworzyć aplikacje "z niczego" należy wybrać jeden z wiodących modeli - najczęściej Codex albo Claude Code. Istnieje między nimi istotna różnica w stylu pracy. Z Codexem pracujemy metodą iteracyjną - dajemy mu proste zadania i rozbudowujemy aplikację krok po kroku, inaczej się pogubi w instrukcjach i zamiast aplikacji będziemy mieć potworka pokroju Bambu Studio. W przypadku Claude możemy poprosić go o zaplanowanie specyfikacji i zadanie pytań, gdy zauważy nieścisłości, co znacząco redukuje przypadki ekstrapolacji i założeń, które trzeba upilnować przy Codexie. 

firefox_VRd5MOALzP.thumb.png.40e02e4bcbfaa26e8b79413ad2909e7c.png
Przykładowa aplikacja Python FastAPI stworzona przy użyciu Codexa (prototyp dla klienta)

Jakość kodu między wiodącymi modelami jest zbliżona (poza Grokiem, który jest tym kolegą, co minimum raz na tydzień odegra jakąś głupią akcję). Wybór zależy tak naprawdę od naszego stylu tworzenia. Codex mimo tego, że zazwyczaj trzeba wykorzystać więcej wiadomości, by uzyskać podobny rezultat jest znacznie lepiej zoptymalizowany w kwestii zużycia tokenów, a więc 5-godzinna sesja jest całkiem trudna do wyczerpania przy normalnym użytkowaniu. W przypadku Claude nawet plany Max 5x po 100$ całkiem łatwo można wykorzystać w ciągu 1-2h.

Optymalizacja pamięci podręcznej

Warto wiedzieć, że dostawcy usług SI nie są laikami i modele posiadają pamięć podręczną (czyszczoną po pewnym czasie nieaktywności, zazwyczaj 5-30 minut). Należy mieć to na szczególnej uwadze, gdy pracujemy nad jakąś funkcjonalnością - najlepiej skupić się na jednej rzeczy i ją dopracować niż prowadzić równolegle kilka konwersacji.

Oczywiście tej pamięci nie należy również nadużywać. Standardowym założeniem jest, by jedna funkcjonalność była opisana w jednym bloku, ale można śmiało rozszerzyć to o funkcjonalności powiązane (np. WiFi oraz OTA dla ESP32). Dodatkowo jeżeli AI przeczytało jakiś kod powiązany (np. tworząc panel na powyższym zrzucie ekranu za każdym razem AI dotykało kodu menu nawigacyjnego, a więc można bez problemu było zrobić "wrzutkę" rodem z naszych ustaw i opisać np. zepsute podświetlenie jednego z pól).

Optymalizacja kontekstu

Jak wspomniałem pamięci podręcznej nie należy nadużywać. Problem jest prosty - każda rozmowa ma ograniczony kontekst (różny w zależności od modelu, zwykle 128K do 200K tokenów, z wyjątkiem w postaci Gemini, które ma pojemność aż 1M tokenów). Jeżeli przekroczymy 80% kontekstu jakość generowanych treści zaczyna spadać geometrycznie (model stara się uniknąć przepełnienia, za które był karany podczas nauki). Jeżeli za bardzo zbliżymy się do momentu zapełnienia całego kontekstu to model wykona kompresję treści (wyciągnie najistotniejsze informacje kosztem tokenów) i dopiero będzie kontynuował rozmowę. Oczywiście kończy się to utratą części informacji, a tym samym zwykle skutkuje odejściem od oryginalnego toru myślenia.

screenshot.thumb.png.021f0f3009d69f77ccac2e2ccec4c66b.png

GameFlow - aplikacja do integracji komputera i zewnętrznych akcesoriów DiY, Python

Poziom myślenia

Większość zaawansowanych modeli posiada poziom myślenia (Thinking Level), który standardowo jest ustawiony na poziomie średnim. Jeżeli chcemy, by model zrobił jakieś względnie banalne zadanie (typu uporządkowanie struktury plików w projekcie) możemy spokojnie przestawić go na poziom niski. Jeżeli pracujemy z zaawansowanymi algorytmami pokroju Spatial Hashing, to lepiej ustawić poziom wysoki.

Do projektów elektronicznych jednak najlepiej zostawić poziom średni i pracować iteracyjnie, by uniknąć potem bałaganu w kodzie (i konieczności pamiętania o przestawianiu ustawień) 😉 

Pliki AGENTS.MD i CLAUDE.MD

Agenci również często potrzebują stałych instrukcji (np. nie używaj instrukcji "goto"). W tym celu stosuje się pliki AGENTS/CLAUDE.MD (bo Claude Code jest wyjątkiem i jako jedyny model nie akceptuje standardowej nazwy). Takie pliki zawierają najczęściej najistotniejsze założenia, listy innych narzędzi konsolowych oraz wzmianki o sprzęcie czy architekturze projektu.

Jako, że najczęściej korzystam z Codexa i PlatformIO poniżej znajduje się mój podstawowy plik AGENTS.MD.

1. If any specification is not clear, contradicts itself or is ambiguous ask user for clarification.
2. Restrict all code to very simple control flow constructs—do not use goto statements, setjmp or longjmp constructs, or direct or indirect recursion.
3. Give all loops a fixed upper bound.
4. Do not use dynamic memory allocation after initialization.
5. No function should be longer than about 60 lines of code.
6. The code's assertions density should average to minimally two assertions per function. Assertions must be used to check for anomalous conditions that should never happen in real-life executions.
7. Each calling function must check the return value of nonvoid functions, and each called function must check the validity of all parameters provided by the caller.
8. The use of the preprocessor must be limited to the inclusion of header files and simple macros definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives must be kept to a minimum.
9. The use of pointers must be restricted. Specifically, no more than one level of dereference should be used. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations.
10. All code must be compiled, from the first day of development, with all compiler warnings enabled. All code must compile without warnings.
11. Use `sys_xxx` for system peripheral-related files (e.g. BLE or RF) and `fw_xxx` for firmware-only related files (e.g. session handling)
12. Use `N:/bin/bleid.exe uuid` for generating BluetoothLE UUIDs (`--help` option is available)
13. Ensure BLE devices are re-advertised after disconnected.
14. Author: H1M4W4R1
15. Folders: `drivers/` - for peripheral-related code, `systems/` for low-level systems `operation/` for user-level handling (HMI expect UI), `ui/` for user interface
16. Don't place headers in `src/`

Jeżeli ktoś zastanawia się skąd te założenia: NASA/JPL Power of 10. Oczywiście nieco zmodyfikowane pod projekty hobbystyczne i moje zastosowanie.

Ale czy SI można wykorzystać do wszystkiego?

Niestety nie. O ile tworzenie tekstu czy kodu (to w sumie też forma tekstu) jest jak najbardziej wykonalne, a tworzenie grafiki też działa już akceptowalnie dobrze, o tyle bardziej skomplikowane rzeczy są zdecydowanie na poziomie "raczkującym". Tworzenie grafik SVG jest do przyjęcia, często trzeba nieco poprawić ręcznie, ale to też forma kodu. Podobnie w przypadku modeli SCAD. Można powiedzieć, że w tych dwóch przypadkach SI da się używać, ale trzeba liczyć się z tym, że trzeba co nieco włożyć od siebie i poprawić.

Dużo gorzej SI radzi sobie z generowaniem modeli w np. Fusion 360 (też mają asystenta AI). Tego lepiej na ten moment nie dotykać, bo nie potrafi nawet stworzyć prostej zębatki na podstawie specyfikacji technicznej.

Muzykę AI też tworzy i robi to całkiem dobrze, ale osobiście uważam, że jest ona zbyt powtarzalna i monotematyczna, więc zaliczę to jako "AI robi to słabo".

Podsumowanie

Czy warto korzystać z AI? Przy obecnych cenach zdecydowanie tak. Trzeba brać, póki VC wkłada tam kasę i można używać narzędzi (i uczyć się) za pół darmo. Gorzej jak ceny staną się rynkowe, ale w takim przypadku wykorzystanie SI do tworzenia kodu nadal będzie miało sens. Jednakowoż do tego momentu najpewniej powstanie sprzęt i/lub modele, które umożliwią uruchamianie zaawansowanego SI na domowych komputerach.

Jak mówi znane przysłowie: "pożyjemy, zobaczymy".

Post Scriptum

Przykład, co obecnie można wykonać w ciągu jednego dnia (z "drobnymi" poprawkami dnia następnego) wykorzystując AI (ChatGPT Codex) można znaleźć tutaj:

 

Edytowano przez H1M4W4R1

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...