Dostępnik o intuicyjnym kodowaniu
Dzisiaj dostępność będzie tylko dodatkiem do głównego tematu, czyli vibe coding. Opowiem Ci, jak korzystam ze sztucznej inteligencji przy programowaniu.
Od wielu lat miałem pomysły na różnego rodzaju aplikacje. Barierą było to, że nie umiałem programować. To się zmieniło jakiś rok temu i teraz mogę - z pewną taką nieśmiałością - stwierdzić, że już jestem. Dostałem zatwierdzenie od Piotra Osipy, więc to chyba prawda. Jak to się stało?
Uczyłem się programowania od Chata GPT. Wybrałem język Python, bo chciałem tworzyć narzędzia oparte o AI, a ten język jest do tego chyba najodpowiedniejszy. Zaczynałem od prostych rzeczy. Pytałem na przykład, jak napisać pętlę, jak wczytać plik tekstowy i o takie prościzny. Stopniowo poznawałem składnię, a potem biblioteki, API, aż wreszcie Jupytera, Pandas i inne technologie. Chat GPT był nieskończenie cierpliwy i mogłem go pytać o wszystko. On na moje życzenie generował kod, modyfikował i wyjaśniał. Zebrałem solidne podstawy, żeby samemu zacząć pisać. Oczywiście mój kod sypał błędami i wyjątkami, ale kopiowałem zawartość terminala do Chata GPT, a on w prosty sposób wyjaśniał, gdzie nawaliłem. I tak szło do przodu. A wtedy pojawił się "vibe coding".
Co to jest vibe coding?
Vibe coding to nowy paradygmat programowania. Opiera się na wykorzystaniu sztucznej inteligencji do generowania kodu na podstawie opisów problemów językiem naturalnym. Zamiast tradycyjnego pisania kodu linia po linii, podaję AI ogólne wytyczne, a model językowy tworzy rozwiązanie, które mogę następnie testować i udoskonalać.
Wygląda to niby tak samo, jak wcześniejsza praca z Chatem GPT, ale są też istotne różnice. Zamiast opierać pracę na pliku z kodem, mogę pracować z całym środowiskiem. AI może generować plik z zależnościami, dokumentację techniczną, a przede wszystkim - nie muszę samemu pilnować kodu, żeby go prawidłowo wstawić. Przeglądam propozycje wstawki i klikam na przycisk akceptowania, a kod trafia w odpowiednie miejsce w edytorze. Mogę też wstawić plik readme.md do folderu projektu i wskazać go jako źródło do planowania pracy. Wygląda to na magię, ale Sapkowski, Pratchett i inni uczą nas przecież, że z magią trzeba uważać.
Czy to działa, czy nie działa?
Na tak postawione pytanie odpowiem - działa, ale nie zawsze i nie do końca. Działa całkiem dobrze w przypadku stosunkowo prostych aplikacji i prototypowania, ale w przypadku bardziej zaawansowanych AI sama nie poradzi. Nie potrafię wyznaczyć granicy między tymi sytuacjami, więc posłużę się przykładami z ostatnich tygodni.
Edytowanie metadanych w plikach PDF
Robię sobie taki mały projekt na boku, o którym napiszę więcej, jak już będzie o czym pisać. Elementem tego projektu jest przetworzenie kilkuset plików PDF. Chcę wykorzystać metadane z tych plików, w tym przede wszystkim tytuł, autora i datę publikacji. Chcę mieć taki katalog plików z najważniejszymi informacjami. Sęk w tym, że większość z tych plików jest źle przygotowanych i nie mają tych metadanych lub są źle wprowadzone. Muszę zatem wykonać ręczną robotę polegającą na edycji metadanych, a zatem potrzebuję jakiegoś narzędzia.
Przejrzałem ich sporo, ale były niedostępne lub komercyjne, a do pojedynczej roboty nie kupię Acrobat Pro. Zniechęcony przypomniałem sobie o vibe coding i zagoniłem do pracy mojego asystenta.
Napisałem instrukcję i zrozumiał w mig, czego potrzebuję. W ciągu kilku minut miałem działające narzędzie. Tyle że nie było dla mnie dostępne. Wspomniałem o tym w kolejnej instrukcji, a asystent zaproponował zmiany w bibliotece graficznej. Pokazał sposób implementacji, więc tylko się zgodziłem na proponowane zmiany. Jednak aplikacja nadal nie była dostępna. Kolejna instrukcja ode mnie dotyczyła zmiany biblioteki graficznej na Streamlit. Po tej iteracji aplikacja nie tylko działała prawidłowo, ale też była dostępna, przynajmniej w zakresie jaki daje Streamlit.
Całość trwała może z kwadrans i to było zdecydowanie krócej, niż wcześniejsze poszukiwania, instalowanie i sprawdzanie aplikacji. Asystent sam zasugerował rozsądne zmiany w zarządzaniu plikami do konwersji.
Czy ta aplikacja jest porządnie napisana? Oczywiście że nie, ale na moje potrzeby jest wystarczająca, bo robi swoją robotę. Używam jej w swoim systemie operacyjnym i nie udostępniam innym, więc co za problem? Z drugą aplikacją już nie jest tak łatwo.
KoREKtor do analizy ogłoszeń rekrutacyjnych
Razem z Agatą Gawską podjęliśmy się stworzenia aplikacji, która będzie analizować ogłoszenia o pracę i wskazywać rzeczy do poprawienia. Będziemy o niej opowiadać podczas AutomaticA11y, więc tu skupię się na tym, gdzie to intuicyjne kodowanie się sprawdziło, a gdzie nie bardzo. Tym razem w punktach:
Obsługa matrycy, która jest głównym paliwem aplikacji. Musiałem ręcznie przetworzyć tabelę z Woda do pliku CSV. Było z tym trochę roboty, bo musiałem też uwzględnić zmiany w strukturze samej matrycy. Tworzenie ramki danych z tego pliku CSV oddałem już asystentowi, który sobie z tym świetnie poradził.
Na podstawie matrycy i treści ogłoszenia trzeba było przygotować prompt. Wykorzystałem bibliotekę Langchain do stworzenia szablonu, ale do rozwiązania pozostawało formatowanie wyjścia. Na początek wdrożyłem to za pomocą dość prymitywnej metody dodawania treści pytań do promptu i sprawdziłem, że trochę działa. Na wyjściu miał być format JSON, a nie zawsze tak było. Poradziłem się asystenta, a on odkrył dla mnie bibliotekę Pydantic, a do tego sam zaimplementował zmiany. Teraz działało perfekcyjnie.
Wyświetlanie wyników zrobił według instrukcji, ale to nie było to, o co mi chodziło. Poprawiłem ręcznie po nim i wtedy było już świetnie. Eksportowanie do formatu Word zrobiłem ręcznie, bo tak było szybciej i pewniej. Instruowanie asystenta krok po kroku byłoby żmudne i wciąż trzeba byłoby to testować. Ja wiedziałem jak to zrobić, więc po prostu zrobiłem to sam.
Wczytywanie plików DOCX i PDF zleciłem asystentowi, ale przekombinował. Tu też pokazało się pewne ograniczenie samych modeli, ponieważ nie znają najnowszych implementacji, przez co korzystają z przestarzałych wywołań i importów. O tym napiszę nieco dalej. Ostatecznie napisałem te moduły sam, bo nie mogliśmy się dogadać.
Największym wyzwaniem okazało się utworzenie API. Aplikacja miała otrzymywać treść ogłoszenia, a zwracać JSON do wyświetlenia. Ten plik był zmodyfikowaną wersją matrycy, opartą o wyniki uzyskane z modelu sztucznej inteligencji. Tworzenie API przerosło asystenta lub ja nie potrafiłem mu tego jasno wyjaśnić. Kombinował z socketami, kolejkowaniem i innymi sposobami, a czas naglił. Dopiero gdy wskazałem mu bardzo konkretne rozwiązanie, to jakoś sobie z tym poradził Chociaż i to nie jest do końca prawda, bo musiałem po nim sporo poprawiać.
Podsumowując - asystent lub agent chyba jednak nie poradzi sobie sam z napisaniem bardziej zaawansowanej aplikacji. Ewentualnie ja nie umiem tego sprawić.
Jakich narzędzi używam?
Moim podstawowym edytorem jest Visual Studio Code. Sam edytor jest dobrze dostępny, przemyślany i stabilny. Od pewnego czasu jest w nim wmontowany Copilot, czyli właśnie taki asystent kodowania. Staram się z niego nie korzystać, bo zawiódł mnie zbyt wiele razy. Jednak VS Code ma możliwość dodawania rozszerzeń i jedno z nich mogę spokojnie polecić. Jest to Cody, które w bardzo przemyślany sposób wspomaga programowanie. Drugim rozszerzeniem, które testuję dopiero od kilku dni, jest Gemini. To jest asystent od Google i jego zaletą jest to, że jest bezpłatny. Na razie się z nim oswajam, chociaż wygląda dość dobrze. Póki co - Cody u mnie rządzi.
Jestem świadomy istnienia edytora Cursor, czyli edytora zaprojektowanego wprost do kodowania wspomaganego sztuczną inteligencją. Mam nawet zainstalowany i od czasu do czasu go używam. Jednak jego dostępność jest gorsza, niż czystego VS Code, chociaż Cursor opiera się na tym pierwszym.
Od pewnego czasu sprawdzam agenta Codex od OpenAI. Ma interfejs terminalowy, co dość lubię. Natomiast opiera się na tym samym modelu AI co Copilot, a przynajmniej tak to wygląda. Zdarza mi się zatem, że prototypuję w Codex i modyfikuję w VS Code.
Teraz kilka słów o modelach. Już wcześniej wskazałem, że modele od OpenAI radzą sobie dość słabo. Na pewno są narzędzia uzupełniające braki w ich wiedzy, ale ja tu piszę o surowym modelu, a właściwie modelach. Dla mnie królem kodowania jest Claude 3.7, chociaż nawet wcześniejsza wersja 3.5 jest lepsza od modeli OpenAI. Warto nadmienić, że modele 3.5 i 3.7 różnią się bardzo od siebie, w tym także ceną za tokeny. Trzeba więc w sercu i portfelu podjąć decyzję. Nie mam jeszcze wyrobionego zdania o Gemini, tym bardziej że nie nadążam nad wersjami. Wydaje się jednak, że wygrywają aktualnością, a z kodowaniem także radzą sobie dobrze.
Dostępność i kodowanie asystowane
Jak mają się te metody do dostępności? Ja dostrzegam tu 2 ważne obszary: dostępność samych narzędzi oraz dostępność generowanego kodu. w obu obszarach dostrzegam spore problemy.
Dostępność edytorów to przede wszystkim problem dla mnie i innych osób mających istotne ograniczenia fizyczne. Mam ograniczony dostęp do części z nich, nad czym ubolewam. Radzę sobie jak mogę, ale generalnie w środowisku AI dostępność nie jest dostrzeganym problemem. Świadczą o tym problemy w 2 najpopularniejszych bibliotekach graficznych do prototypowania: Gradio i Streamlit. Nie da się w nich stworzyć dostępnej aplikacji, bo nie ma do tego narzędzi. Nie da się w nich nawet zdefiniować języka interfejsu, a renderowane ramki danych są prawie nie do obsłużenia. Podobnie jest z interaktywnymi tabelami w Chacie GPT, a obejściem jest poproszenie o wygenerowanie pliku CSV. Dużo jest tu do zrobienia.
Co do dostępności generowanego kodu, to sprawa jest bardziej skomplikowana. AI potrafi generować dostępny kod, ale trzeba o to specjalnie poprosić. Sama z własnej woli raczej o to nie zadba. Szkoda, bo to mógłby być ten gigantyczny wkład w tworzenie dostępnych aplikacji i treści. Innym problemem jest to, że czasem asystentowi tylko się zdaje, że zapewnia dostępność. Tak było w przypadku opisanego wcześniej edytora metadanych. Upierał się przy modyfikowaniu intefeejsu i wciąż nic z tego nie wychodziło. Tylko że AI jest bardzo perswazyjna i może spokojnie przekonać programistę, że już jest dobrze, chociaż wcale tak nie jest.
Okazuje się zatem, że potwierdza się to co zazwyczaj. AI może wybitnie pomóc i przyśpieszyć pracę, ale efekty musi sprawdzić człowiek. Inaczej będzie z tego kiszka z wodą.
Wieści o dostępności
Wojtek Kutyła znowu będzie rozsyłał swój newsletter. Mam nadzieję, że częściej niż ostatnio. Tu możesz go zasubskrybować.
Na jesieni odbędzie się kolejna edycja Sensorycznie i na serio. Pewnie znowu w Krakowie, chociaż Magda chce opanować także obecną stolicę, więc kto wie... Obok SINS jest także hackathon i zapowiada się, że jego głównym tematem będzie EAA. Ja zamierzam być z moimi pomysłami i takimi niepewnymi kompetencjami w sztucznej inteligencji i programowaniu w Pythonie. Jeżeli chcesz do mnie dołączyć, pilnuj informacji na ten temat.
AutomaticA11y jest już za tydzień i nie będę Cię zanudzał kolejnymi informacjami. Po wszystkim podzielę się moimi wrażeniami oraz filmami, jeżeli już będą. A na ten moment życz mi szczęścia i trzymaj kciuki.
Mam jednak jeszcze 1 miły obowiązek. Informuję, że na kawy otrzymałem łącznie 3536,10 zł od 60 osób i zgodnie z deklaracją przeznaczam te środki na kawę dla osób, które będą ze mną na AutomaticA11y. Poczęstunek będzie się składał z kilku innych elementów, więc nie krzycz jeżeli wydam też na kanapki i herbatę. Ta kwota nie wystarczy na pokrycie pełnego kosztu, ale mamy też zamożnego sponsora, który dorzuci się do tego. A jeżeli nadal chcesz dorzucić się do kawy dla mnie, to jak zwykle możesz to zrobić tutaj. Wrowadzili też możliwość darowizn cyklicznych, więc to też jest ciekawa opcja. Mniej, a za to regularnie...
Rafał Charłampowicz będzie na AutomaticA11y opowiadał o robotach. Jeżeli chcesz go poznać także od innej strony, to zajrzyj tutaj.
A na deser - wygenerowany na podstawie tego Dostępnika podcast. Daj znać, czy to mądry pomysł i czy go kontynuować.
I to by było na tyle. Dzisiaj jest święto pracy, więc odpoczywaj sobie na słoneczku. Ja wciąż dopinam sprawy organizacyjne i czekam na 8 maja na wielkie spotkanie. Trzymaj się.