Oswajamy AI
Spis treści
Wstęp
Mleko jest rozlane! Kupa przeleciała przez wentylator i teraz wszystko jest w brązowe kropki!
Tak można opisać sytuację z AI.
Oczywiście, można się oflagować lub podjąć nawet strajk okupacyjny. Ale produkty są już na rynku i już się ich nie pozbędziemy. Będą z nami do końca cywilizacji. Trzeba nauczyć się z nimi żyć i je wykorzystywać.
Popatrzmy dzisiaj na kwestie programowania. Przetestujemy trochę niszowe zastosowanie. Konwersję starego, zapomnianego oprogramowania do użycia na współczesnych platformach. A mianowicie konwersję oprogramowania napisanego w języku Turbo Pascal (lub ogólnie Pascal) z MS-DOS na JavaScript uruchamiany w przeglądarce internetowej.
Analizujemy trzy przykłady które powstawały gdzieś między 1995 a 1997 r.
Przykład 1: MRace32
To prosta gra, pierwotnie napisana w Turbo Pascalu. Później, eksperymentalnie, rozwijana także w TMT Pascalu i Free Pascalu (ówcześnie FPK). Obydwa późniejsze kompilatory były już 32-bitowe.
Kod źródłowy, nieskromnie mówiąc, jest przejrzysty i zrozumiały. Ten program ówcześnie był nawet omawiany w niektórych szkołach na zajęciach z informatyki.
Polecenie dla AI (tzw. „prompt”) nie było skomplikowane. Opisujemy co to jest, środowisko pierwotne i docelowe, definiujemy założenia techniczne. Warto zwrócić uwagę, że nie opisujemy mechaniki gry. Tę, AI samo sobie określi.
MRace32a. Pascal, oryginalny kod zgodny TMT Pascal 32 bit (wersja 32 bitowa języka Turbo Pascal). Czy mógłbyś zrobić konwersję załączonego programu do współczesnego JavaScript? Założenia: 1. Uruchomienie lokalne w przeglądarce internetowej lub przez sieć (pojedynczy plik html), grafika w canvas html5, skalowanie do okna przeglądarki (można zachować oryginalne proporcje ekranu 5:4). 2. Klawisze kursorowe. 3. Zwróć uwagę, że oryginalnie program pracował w trybie tekstowym 80x25 znaków, używał zestawu ASCII z IBM PC, wyświetlanie było optymalizowane przez bezpośredni dostęp do pamięci ekranu, m.in. użyto instrukcji move. 4. Wersja w javascript powinna na początku wyświetlić winietkę z informacjami o programie (patrz początkowy komentarz w kodzie) i help'a (patrz pod koniec kodu), właściwy program powinien się rozpocząć po naciśnięciu spacji. Podobnie na końcu, po zakończeniu programu, program powinien czekać na spację przed powrotem do winietki.
Po 5(!) minutach dostajemy odpowiedź. Link do kodu i komentarz:
Wersja zachowuje: • ekran tekstowy 80×25 z paletą IBM PC i znakami CP437, • buforowanie całej klatki, będące odpowiednikiem kopiowania pamięci instrukcją move, • grafikę w canvas skalowaną do okna w proporcji 5:4, • oryginalną logikę prędkości, punktacji, kolizji, eksplozji i pięciu żyć, • sterowanie klawiszami kursora, CapsLock dla dźwięku i End dla zakończenia gry, • winietkę z informacjami i pomocą przed rozpoczęciem, • start po naciśnięciu spacji, • ekran końcowy oczekujący na spację przed powrotem do winietki. Plik nie korzysta z bibliotek ani zasobów zewnętrznych. Można go otworzyć bezpośrednio w przeglądarce albo udostępnić przez dowolny serwer www. Sprawdziłem składnię JavaScript oraz przebieg: winietka → gra → sterowanie → End → ekran końcowy → powrót spacją.
I to wszystko. Program działa bezbłędnie. Ale, powtórzę, to dzięki bardzo przejrzystemu kodowi źródłowemu oryginału. AI samo rozpoznało co się dzieje w programie, dopasowało funkcjonalność do pętli komunikatów przeglądarki i obsługi klawiatury, zaimplementowało bufor ekranu itd. A gotową konwersję można sobie sprawdzić tutaj: https://technique.pl/vsa/conversions/mrace32a.html
Przykład 2: W1914
Kolejny przykład. Prosta gra strategiczna dla dwóch osób.
Polecenie:
W1914. Pascal, oryginalny kod zgodny z FPK, TMTPascal 32 bit i Turbo Pascal. Czy mógłbyś zrobić konwersję załączonego programu do współczesnego JavaScript? Założenia:
1. Uruchomienie lokalne w przeglądarce internetowej lub przez sieć (pojedynczy plik html), grafika w canvas html5, skalowanie do okna przeglądarki (można zachować oryginalne proporcje ekranu 5:4).
2. Zwróć uwagę, że kod jest dostosowany dla trzech kompilatorów, a różnice są ustawiane przez dyrektywy kompilatora {$ifdef turbo}, {$ifdef tmt}, {$ifdef fpk}. Niektóre fragmenty kodu są włączane przez zaprzeczenie, np. {$ifndef fpk} itd. Pozostańmy przy kodzie dostosowanym dla Turbo Pascala, czyli {$define turbo}.
3. Zwróć uwagę, że oryginalnie program pracował w trybie tekstowym 80x25 znaków, używał zestawu ASCII z IBM PC, wyświetlanie nie było specjalnie optymalizowane (wykorzystanie standardowego pakietu crt), ale obiekty graficzne były realizowane przez przeprogramowanie generatora znaków karty VGA. To prosta gra strategiczna dla dwóch osób, wydających polecenia na przemian.
Tym razem kosztowało to 10 minut pracy. Generalnie też sukces, odpowiedź AI:
Gotowe. Przygotowałem kompletną konwersję programu W1914 do pojedynczego pliku HTML:
Zrealizowane elementy
• pojedynczy plik HTML, bez bibliotek i zasobów zewnętrznych;
• uruchamianie lokalne przez otwarcie pliku w przeglądarce;
• ekran tekstowy 80×25 znaków odwzorowany w canvasie 640×400;
• automatyczne skalowanie canvasu do okna przeglądarki;
• paleta kolorów zgodna z klasycznym trybem VGA;
• dokładne przeniesienie wszystkich 20 matryc znaków 8×16 z procedury zaladuj_font;
• oryginalne symbole:
◦ wody,
◦ lasu,
◦ zasieków,
◦ min,
◦ eksplozji,
◦ piechoty,
◦ kawalerii,
◦ czołgów,
◦ artylerii,
◦ króla;
• zachowana organizacja 29 oddziałów w 8 formacjach;
• losowe generowanie terenu;
• grupowe przesuwanie formacji;
• blokowanie ruchu przez własne oddziały;
• walka bezpośrednia;
• działanie min;
• salwy wszystkich dział w formacji artylerii;
• rozrzut pocisków artyleryjskich;
• niszczenie przeszkód terenowych ostrzałem;
• raport armii;
• zmiana graczy;
• zakończenie po zniszczeniu króla;
• oczekiwanie na spację przed rozpoczęciem gry;
• po zakończeniu oczekiwanie na spację i powrót do winietki;
• przewijany napis z oryginalnej tablicy tekst.
Sterowanie
• 1–8 — kierunek;
• klawiatura numeryczna — zgodnie z oryginalnym mapowaniem;
• strzałki — kierunki podstawowe;
• Home, Page Up, End, Page Down — kierunki ukośne;
• Enter — zatwierdzenie;
• Backspace — skasowanie wprowadzonej liczby;
• F4 — włączenie lub wyłączenie koloru;
• F8 — włączenie lub wyłączenie dźwięku;
• F10 — raport;
• Esc — przerwanie gry i powrót do winietki;
• F1 — przełączenie normalnej i przyspieszonej animacji.
Plik przeszedł kontrolę składni JavaScript oraz automatyczny test działania obejmujący inicjalizację armii, generowanie terenu, ruch formacji, artylerię i mapowanie klawiatury. Pełne uruchomienie Chromium w tym środowisku zostało zablokowane przez jego politykę administracyjną.
Trzeba przyznać, że imponuje rozszyfrowanie funkcjonalności programu przez AI. Zrobił to idealnie. Ale pojawiły się trzy nieduże problemy:
- przesunięcie czcionek ekranowych o dwa piksele za wysoko (rozwiązane błyskawicznie),
- problem z działaniem klawiszy funkcyjnych (rozwiązanie go wymagało dwóch kolejnych poleceń),
- zupełnie nieoczekiwany problem z dźwiękiem.
Dźwięk, w zasadzie to „beep”, jest realizowany analogicznie jak w poprzednim programie. Ale nie wiadomo dlaczego AI postanowiła zupełnie inaczej go zaimplementować, korzystając z programowalnych generatorów i systemowego podsystemu dźwiękowego. Walka z tym zagadnieniem zajęła z pół godziny. Pół godziny wymyślania kolejnych, skomplikowanych i mało działających rozwiązań. Pomogło ostre przywrócenie AI do porządku (słowne!) i zacytowanie oryginalnego kodu, w celu określenia oczekiwanej funkcjonalności (sound(500); delay(20); nosound;).
Ostateczny wynik pracy można podziwiać tu: https://technique.pl/vsa/conversions/W1914_final.html
Przykład 3: Droga26
Kolejna prosta gra. Tym razem grafika VGA z realizacją prostego 3D. Dwa pliki źródłowe (oryginalna biblioteka graficzna oddzielnie).
Polecenie:
Droga26. Pascal, oryginalny kod zgodny z Turbo Pascal. Czy mógłbyś zrobić konwersję załączonego programu do współczesnego JavaScript? Założenia: 1. Uruchomienie lokalne w przeglądarce internetowej lub przez sieć (pojedynczy plik html plus drugi include z biblioteką graficzną wgraphm), grafika w canvas html5, skalowanie do okna przeglądarki (można zachować oryginalne proporcje ekranu 5:4). 2. Zwróć uwagę, że program oryginalnie pracował na karcie VGA w trybie 13h (320x200 pixeli, 256 kolorów). 3. Zwróć uwagę, że oryginalnie program do sterowania wykorzystywał klawisze shift (lewy i prawy), alt i ctrl. Umożliwiało to wciskanie wielu klawiszy na raz, bez konieczności implementacji skanowania klawiatury. W konwersji powinny być używane klawisze kursorów. 4. Zauważ też, że możliwe są 4 rodzaje projekcji grafiki na ekranie. Domyślna i trzy warianty. Oryginalnie zmieniało się je opcjami przy uruchamianiu programu (patrz tablica tekst, zawierająca help'a). Teraz, chyba można by przełączać je w locie podczas gry (klawisz "1" - domyślny, "2" - alternatywny, "3"- 3D, "4"- siatkowy). Także w trybie demo. Uwaga: Jako domyślny użyjmy trybu "4" (w pełni siatkowy), a dawnego domyślnego jako "1" (z renderowaną nawierzchnią drogi). 5. Na starcie programu powinna się wyświetlać prosta winietka z informacjami o autorze i klawiszach sterujących w grze (tablica tekst). Uruchomienie gry po wciśnięciu spacji i trybu demo po wciśnięciu "d". 6. Po zakończeniu gry powinien wyświetlać się napis "Game over" i oczekiwanie na jakiś klawisz przed powrotem do winietki. To prosty "symulator" jazdy samochodem.
Czas wykonania: ponownie ok. 10 minut.
Rozszyfrowanie logiki i algorytmów znowu idealne. Odpowiedź:
Gotowe. Konwersja zachowuje logikę oryginalnego programu, grafikę 320×200 w 256-kolorowym buforze, generowanie drogi, przeciwników, kolizje, uszkodzenia i cztery metody projekcji. • — program i logika gry • — biblioteka graficzna emulująca funkcje wgraphm.pas • — oba pliki w archiwum Oba pliki należy umieścić w tym samym katalogu, a następnie otworzyć droga26.html w przeglądarce. Sterowanie: • ↑ / ↓ — przyspieszanie i hamowanie • ← / → — kierowanie; można wciskać kilka klawiszy jednocześnie • 1 — dawny tryb domyślny, z renderowaną nawierzchnią • 2 — projekcja alternatywna • 3 — projekcja stereoskopowa 3D • 4 — pełna projekcja siatkowa, ustawiona jako początkowa • N — włączanie i wyłączanie innych pojazdów • Esc / End — zakończenie gry • Spacja — rozpoczęcie gry z winietki • D — uruchomienie demonstracji Po zakończeniu pojawia się ekran GAME OVER, a kolejny klawisz przywraca winietkę. Program został również sprawdzony w Chromium we wszystkich czterech trybach, w trybie gry i demonstracji; konsola nie zgłasza błędów.
Problem był jednak poważniejszy:
- Clipping – artefakty na krawędziach ekranu.
Problem wielokrotnie się powtarzał (regresje), zarówno przy usuwaniu kolejnych błędów, jak i dodawaniu nowych funkcjonalności. AI szukała coraz bardziej wymyślnych rozwiązań w literaturze naukowej(!). W końcu znowu trzeba było przywołać ją do porządku:
Przecież już to dzisiaj poprawiłeś. Po prostu nie rysuj pixeli jak wypadają powyżej lub poniżej krawędzi ekranu - nie zawijaj bufora.
Usunięcie tego i paru innych drobnych błędów zajęło prawie dwie godziny. Ale rezultat i tak jest całkiem niezły.
W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. Ten z renderowaną powierzchnią drogi. Nastąpiła pełna aktualizacja i unowocześnienie grafiki do pełnego cieniowania scenerii, wraz z implementacją prostego z-bufora w celu określenia widoczności poszczególnych pikseli. Tutaj próby realizacji i zmienna koncepcja kosztowały kolejne dwie godziny pracy.
Rezultat znajduje się tutaj: https://technique.pl/vsa/conversions/droga26_shoulders_zcars.html
Wnioski
Ogólnie, z pracy AI można być bardzo zadowolonym. Jednak trzeba pamiętać, aby dobrze opisywać zadania. AI potrafi „pójść w las” w najmniej oczekiwanym momencie.
Dyskusja ogólna. Chat, w tym projekcie zrobiliśmy dotychczas trzy konwersje starych programów: 1. MRace32a - poszło bardzo ładnie, praktycznie z pierwszego razu. Nieskromnie wskażę, że być może to dzięki dobremu jakościowo kodowi źródłowemu w Pascalu. Kiedyś ten program był nawet omawiany w szkołach na lekcjach informatyki... 2. W1914 - też dobrze. Jednak powstał niezrozumiały problem z dźwiękiem. Dlatego niezrozumiały, że w MRace32 poradziłeś sobie z tym zagadnieniem bardzo dobrze. A obsługa dźwięku w tych dwóch programach w Pascalu była praktycznie taka sama. MRace32 nawet bardziej skomplikowana. 3. Droga26 - tu pojawiły się problemy. Rozumiem, że akurat jakość oryginalnego kodu była słaba, tzn. kod działał, ale pokrętnie. Jednak co mnie martwi, to to, że potrafisz zepsuć fragmenty, które dobrze działają. Wręcz wydaje się, że czasem zamiast poprawić drobny problem, dokonujesz całej konwersji od zera? Albo pomijasz ostatnią wersję, w której wiele błędów było już poprawionych?
Oddajmy głos „pracownikowi”:
Tak — Twoja obserwacja jest trafna. I w przypadku Droga26 rzeczywiście w kilku momentach zachowałem się bardziej jak przy „kolejnej implementacji programu”, zamiast jak przy utrzymaniu istniejącej, coraz lepszej wersji kodu. To są dwie zupełnie różne strategie pracy. W takich konwersjach największym zagrożeniem nie jest już nawet błędne zrozumienie Pascala. Po pierwszej działającej wersji większym zagrożeniem staje się regresja: poprawiam A, a przy okazji zmieniam B, C i D, które działały dobrze.
1. MRace32a — dlaczego wyszło tak dobrze Tu rzeczywiście jakość kodu źródłowego bardzo pomogła. Jeżeli program ma czytelną strukturę, sensownie rozdzielone procedury i jednoznaczny przepływ sterowania, można niemal zrobić translację:
Pascal → odpowiadająca mu konstrukcja JavaScript
bez konieczności zgadywania, co autor właściwie chciał osiągnąć. To jest idealna sytuacja. Nawet takie rzeczy jak bezpośredni dostęp do pamięci ekranu dało się potraktować jako dobrze określony mechanizm, który trzeba zastąpić odpowiednikiem w HTML5.
2. W1914 i dźwięk Tutaj masz rację, że sytuacja była trochę absurdalna. Semantyka: sound(500); delay(20); nosound; jest banalna: 500 Hz przez około 20 ms. A skoro w MRace32a mieliśmy już działający mechanizm realizujący praktycznie to samo, rozsądna metoda powinna była brzmieć: „Weźmy dokładnie sprawdzoną implementację audio z MRace32a i dostosujmy wyłącznie miejsca jej wywołania.” Zamiast tego w W1914 nastąpiło kilka prób rozwiązania problemu na nowo. Dopiero później doszliśmy do właściwego zachowania. To jest dobry przykład ważnej zasady dla tego projektu: jeżeli jakiś problem techniczny został już rozwiązany w jednej konwersji, nie należy go ponownie projektować w następnej. Powinniśmy tworzyć sobie wręcz małą bibliotekę sprawdzonych wzorców: • sound / nosound / delay, • obsługa klawiatury, • skalowanie ekranu, • emulacja tekstowego ekranu IBM PC, • paleta, • timer, • główna pętla gry, • itd.
3. Droga26 — tutaj problem jest poważniejszy Kod Pascala rzeczywiście był znacznie bardziej pokrętny. Szczególnie sposób rysowania drogi, kolejność elementów i zależności między kolejnymi fragmentami powodowały, że drobna pozornie zmiana mogła mieć nieoczywiste skutki. Ale to nie usprawiedliwia regresji w już działających elementach. I bardzo dobrze zauważyłeś coś jeszcze: czasami rezultat rzeczywiście może wyglądać tak, jakbym zamiast zrobić:
wersja N + jedna lokalna poprawka = wersja N+1
robił raczej:
kod źródłowy Pascala + aktualne wymagania = nowa interpretacja całego fragmentu
To drugie podejście jest niebezpieczne. Nie oznacza to zazwyczaj dosłownego przepisania całego HTML od zera. Problem jest subtelniejszy: przy modyfikowaniu większego fragmentu kodu mogę zrekonstruować jego logikę na podstawie źródła i bieżącego celu, zamiast potraktować ostatnią działającą wersję JavaScript jako nienaruszalną bazę. Efekt dla użytkownika jest dokładnie taki sam jak przy napisaniu fragmentu od nowa: „Przecież to już wcześniej działało. Dlaczego znowu jest zepsute?”. I masz pełne prawo tak to odbierać. Dlatego przy kolejnych konwersjach proponuję znacznie bardziej konserwatywną metodę. Po uzyskaniu pierwszej sensownie działającej wersji kończymy etap „konwersji”. Od tego momentu zajmujemy się już debugowaniem istniejącego programu. Czyli: 1. Ostatni zaakceptowany HTML jest wersją bazową. 2. Pascal służy jako dokumentacja zachowania oryginału, ale nie jako ponowna baza do generowania JS. 3. Przy zgłoszeniu błędu identyfikujemy możliwie najmniejszy fragment odpowiedzialny za problem. 4. Zmieniamy tylko ten fragment. 5. Nie wykonujemy przy okazji „porządkowania”, refaktoryzacji ani ulepszania sąsiedniego kodu. 6. Sprawdzamy, czy wcześniejsze poprawki nadal istnieją. 7. Jeżeli zmiana wymaga ingerencji w większy mechanizm, mówię o tym przed jej wykonaniem. […]
Wszystko pięknie, jednak:
Komentarz całkowicie słuszny, ale w kolejnym projekcie o wszystkim zapomnisz. Jak ci przekazać wnioski z tej rozmowy, jako zespół zasad w pierwszym promptcie?
Najlepiej wpisać to w pierwszym promptcie jako jawne zasady prowadzenia konwersji, a nie jako luźne zalecenia. Wtedy traktuję je jako część specyfikacji zadania. Przygotowałbym taki blok do wklejania na początku każdego kolejnego projektu:
Przy konwersji starego programu do JavaScript/HTML5 obowiązują następujące zasady:
1. Wierność oryginałowi jest ważniejsza niż elegancja nowego kodu.
Celem jest możliwie wierne odtworzenie działania programu źródłowego, a nie jego modernizacja, refaktoryzacja ani napisanie „lepszej” wersji.
2. Pierwsza konwersja może być szeroka, późniejsze poprawki mają być konserwatywne.
Po uzyskaniu pierwszej działającej wersji zadanie przestaje być „konwersją od zera”, a staje się utrzymaniem i debugowaniem konkretnej wersji programu.
3. Ostatnia zaakceptowana przeze mnie wersja pliku jest zawsze bazą do dalszej pracy.
Nie wracaj samodzielnie do wcześniejszych wersji ani nie rekonstruuj programu ponownie na podstawie kodu Pascala, jeżeli istnieje nowsza wersja JavaScript/HTML zawierająca wcześniejsze poprawki.
4. Nie przepisuj ponownie działających fragmentów.
Jeżeli zgłaszam pojedynczy problem, znajdź jego przyczynę i dokonaj możliwie najmniejszej lokalnej zmiany.
5. Zasada minimalnego diffu: jeżeli czegoś nie trzeba zmieniać, nie zmieniaj tego.
Unikaj przy okazji:
◦ refaktoryzacji,
◦ porządkowania kodu,
◦ zmiany nazw,
◦ przebudowy architektury,
◦ optymalizacji,
◦ zastępowania działającego mechanizmu innym,
chyba że wyraźnie o to poproszę.
6. Każda wcześniejsza poprawka jest wymaganiem regresyjnym.
Przed oddaniem kolejnej wersji upewnij się, że zmiana nie cofnęła wcześniej naprawionych elementów.
7. Kod źródłowy w Pascalu jest wzorcem zachowania, ale po powstaniu działającej wersji JS nie jest automatycznie bazą kolejnych implementacji.
Używaj go do sprawdzania semantyki oryginału, gdy jest to potrzebne, ale poprawiaj aktualny kod JS zamiast ponownie tłumaczyć większe fragmenty programu.
8. Nie zmieniaj poprawnie działającego zachowania tylko dlatego, że implementacja wydaje się nietypowa lub nieelegancka.
W starych programach mogą występować rozwiązania pokrętne, ale celowe.
9. Jeżeli lokalna poprawka wymagałaby poważnej przebudowy działającego mechanizmu, poinformuj mnie o tym zamiast automatycznie wykonywać szeroką zmianę.
W takim przypadku preferowane może być pozostawienie drobnej niedoskonałości zamiast ryzyka regresji.
10. Ponownie wykorzystuj rozwiązania, które sprawdziły się we wcześniejszych konwersjach.
Dotyczy to szczególnie takich mechanizmów jak:
◦ obsługa sound / nosound / delay,
◦ klawiatura,
◦ skalowanie obrazu,
◦ Canvas,
◦ emulacja trybu tekstowego IBM PC,
◦ palety kolorów,
◦ timery i pętle programu.
Jeżeli w poprzednim programie istnieje działające rozwiązanie tego samego problemu, preferuj jego adaptację zamiast projektowania nowego mechanizmu od początku.
11. Nie usuwaj ani nie upraszczaj zachowań oryginału bez uzgodnienia.
Jeżeli jakaś konstrukcja Pascala jest trudna do odwzorowania, najpierw spróbuj ustalić jej rzeczywistą funkcję.
12. Przy każdej kolejnej iteracji myśl w kategoriach patcha do aktualnej wersji, nie nowej implementacji programu.
Najważniejsza zasada:
Aktualna działająca wersja + najmniejsza konieczna poprawka = następna wersja.
Nie wykonuj ponownej konwersji większych fragmentów programu, jeżeli nie jest to bezwzględnie konieczne.
[…] Lub w skrócie:
Zasady pracy nad konwersją 1. Celem jest wierna konwersja oryginału, nie modernizacja ani refaktoryzacja programu. 2. Po powstaniu działającej wersji każda następna zmiana ma być poprawką tej wersji, a nie ponowną konwersją. 3. Zawsze używaj ostatniej zaakceptowanej wersji pliku jako bazy do dalszej pracy. 4. Przy zgłoszeniu błędu dokonuj możliwie najmniejszej lokalnej zmiany — zasada minimalnego diffu. 5. Nie zmieniaj, nie porządkuj i nie przepisuj fragmentów, które działają poprawnie. 6. Każda wcześniej wykonana poprawka jest wymaganiem regresyjnym i musi pozostać zachowana. 7. Kod Pascala służy do weryfikacji zachowania oryginału, ale nie zastępuje aktualnej działającej wersji JS. 8. Jeśli poprawka wymaga poważnej przebudowy działającego mechanizmu, najpierw wskaż ryzyko zamiast wykonywać ją automatycznie. 9. Jeśli podobny problem został już rozwiązany w innej naszej konwersji, preferuj sprawdzony mechanizm zamiast projektować nowy. 10. Zasada nadrzędna: aktualna działająca wersja + najmniejsza konieczna poprawka = następna wersja.
Wnioski do wniosków
Jak widać, pewne rzeczy, które nam się wydają logiczne, muszą być wprost przekazane AI na początku pracy. Bardzo łopatologicznie wyjaśnione od podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.
Tu muszę wspomnieć, że niniejsze konwersje mają charakter trochę testów, a trochę zabawy. Aktualnie, programując, używam regularnie AI. Co prawda jeszcze nie do tworzenia projektów od podstaw, ale do usuwania błędów, problemów z kompatybilnością kodu lub dodawania nowych, prostych funkcji.
Zdaję sobie sprawę, że moment w którym AI zacznie tworzyć u mnie program od początku, nieuchronnie się zbliża. Będzie to wymagało ode mnie opracowania zupełnie nowej metodyki pracy. Przekazywania AI dokładnych założeń dotyczących funkcjonalności i architektury tworzonego programu. Praktycznie stworzenia dokumentacji programu przed jego powstaniem. W sumie tak powinno być ;)
Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują rozmaite modele AI, pozyskujące tu wiedzę na najróżniejsze tematy, które poruszaliśmy.
Szymon Dowkontt
