Jaki problem pomaga rozwiązać kod generowany przez AI w pracy z blockchainem? Pozwala skrócić czas poświęcony na powtarzalne i wolne fragmenty tworzenia kontraktów inteligentnych oraz dApp, dzięki czemu inżynierowie mogą przeznaczyć więcej czasu na logikę, przeglądy kodu i ocenę ryzyka.
Brzmi to prosto. Tak właśnie jest. Trudnym elementem jest wiedza, co AI może bezpiecznie zrobić, a czego nie powinno się mu przypisywać jako odpowiedzialności.
W inżynierii blockchain koszt złej linii kodu jest wysoki. Mały błąd może zmienić salda, naruszyć kontrolę dostępu lub otworzyć drogę dla atakującego. Dlatego narzędzia AI są przydatne tylko wtedy, gdy działają w ramach procesu z ludzkim przeglądem i jasnym źródłem prawdy.
Myślę o AI w tym kontekście jak o stażystce z bardzo szybkimi rękami i słabym osądem. Potrafi pisać szkice, przepisywać, podsumowywać i dostrzegać wzorce. Nie może jednak ponosić odpowiedzialności ani rozumieć zasad biznesowych stojących za każdym kontraktem, chyba że zasady te zostaną wyraźnie sformułowane.
Gdzie kod AI naprawdę pomaga
Największe korzyści płyną z nudnej pracy. AI dobrze radzi sobie z generowaniem pierwszych wersji szablonowego kodu, testów, komentarzy, kodu łączącego migracje oraz kodu opakowującego. Może też pomóc w reformatowaniu starego kontraktu, wyjaśnieniu działania funkcji lub przekształceniu luźnego pomysłu w punkt wyjścia.
Ma to znaczenie w blockchainie, ponieważ stos technologiczny składa się z wielu małych elementów. Mamy tu kod kontraktów, skrypty wdrożeniowe, obsługę ABI, przepływy portfela, indeksowanie oraz fixture’y testowe. Narzędzie, które redukuje wpisywanie tekstu i częste przełączanie kontekstu, może przyspieszyć cały proces.
Pomaga również w przygotowaniu do przeglądu kodu. Często używam AI, aby przeformułować, co dana funkcja robi, używając prostego języka. Ułatwia to sprawdzenie, czy kod zgadza się z intencją, co jest prawdziwym celem tej pracy.
Dlaczego liczba ma mniejsze znaczenie niż wzorzec
Ludzie lubią czyste procenty. Czterdzieści procent brzmi precyzyjnie. W praktyce rzeczywista wartość nie tkwi samej w liczbie. Wartość polega na tym, że AI może usunąć dużą część mechanicznej pracy, gdy zadanie jest wąskie, a reguły są jasne.
Ta korzyść nie pochodzi z magii. Wynika z wykorzystania AI tam, gdzie przestrzeń odpowiedzi jest ograniczona. Funkcja pomocnicza transferu tokenów, stub testowy lub rutina parsująca to zupełnie inny problem niż nowy projekt konsensusu lub kontrakt chroniący realne aktywa.
W momencie, gdy logika staje się wrogia, narzędzie zmienia się z pomocnika w zagrożenie. Systemy blockchain z założenia są narażone na złe dane wejściowe. Atakujący badają przypadki brzegowe. Szukają założeń. Nie obchodzi ich, że model brzmiał pewnie.
Workflow, który zazwyczaj działa
Najczystszy wzorzec jest prosty. Człowiek definiuje intencję. AI pisze szkic kodu. Człowiek sprawdza kod pod kątem zgodności z intencją i źródłem prawdy. Następnie testy i przegląd decydują, co przetrwa.
Ten proces jest wystarczająco wolny, by być bezpiecznym, i wystarczająco szybki, by mieć znaczenie. Zachowuje również architekturę w rękach ludzi. AI może zasugerować kształt rozwiązania, ale nie wie, które zmiany stanu muszą być atomowe, jakie kontrole należą do łańcucha, a które części powinny znajdować się poza nim.
Tutaj wiele zespołów popełnia cichy błąd. Pozwalają modelowi uzupełniać luki, które powinny zostać zdefiniowane wcześniej. Rezultat wygląda produktywnie, dopóki kod nie zetknie się z rzeczywistym ruchem, realnymi pieniędzmi lub wrogą siecią.
Mały przykład
Weźmy prostą funkcję pomocniczą transferu tokenów. Celem człowieka jest: przesuń tokeny tylko wtedy, gdy nadawca ma wystarczające saldo, a następnie zapisz zmianę w sposób przejrzysty.
AI może napisać pierwszą wersję. Może zapisać sprawdzanie salda, odejmowanie, dodawanie oraz przypadek testowy. To oszczędza czas. Ale człowiek nadal musi sprawdzić reguły przepełnienia, emitowanie zdarzeń, kontrolę dostępu oraz dokładne zachowanie w przypadku błędu.
Tu model robi to, w czym jest dobry. Daje szkielet. Inżynier decyduje, czy szkielet pasuje do zasad kontraktu. Jeśli nie, szkielet jest odrzucany. Szybki kod jest bezużyteczny, jeśli jest to błędny kod.
Gdzie AI zawodzi w pracy z blockchainem
AI jest słabe w zakresie ukrytego kontekstu. Nie wie, która niezmienna właściwość (invariant) ma znaczenie, chyba że kod lub specyfikacja to mówią. W blockchainie niezmienna właściwość to wszystko. Reguły dotyczące podaży, reguły własności, reguły uprawnień i reguły kolejności muszą pozostawać prawdziwe od początku do końca.
Jest też słaba w myśleniu wrogo, jeśli nie zostanie poproszona o odpowiednią strukturę. Model może napisać kod, który przechodzi test happy-path, a nadal przeoczyć ryzyko reentrancy, wyścig warunków (race condition) lub błędne założenie dotyczące zaufania do wywołującego. To nie są rzadkie przypadki brzegowe. To jest praca.
Istnieje też społeczna pułapka. Gdy kod wygląda na wypolerowany, ludzie zaczynają mu ufać zbyt wcześnie. Płynne wyniki mogą ukrywać płytkie rozumowanie. Traktuję to jako sygnał ostrzegawczy, a nie zaletę.
Jak wygląda dobre użycie
Dobre użycie zaczyna się od jednego źródła prawdy. Może to być specyfikacja, notatka dotycząca projektu kontraktu lub plik testowy definiujący zachowanie. AI powinno pracować na podstawie tego źródła, a nie je zastępować.
Dobre użycie utrzymuje ludzi w pętli w odpowiednich momentach. Model może przyspieszyć pisanie szkiców, ale ludzie nadal odpowiadają za architekturę, przegląd i ostateczną decyzję. To nie biurokracja. To sposób na utrzymanie uczciwości systemów, gdy stawka jest realna.
Dla zespołów blockchain oznacza to, że AI jest przydatna, gdy celem są bezpieczniejsze kontrakty inteligentne, klarowniejsza architektura i lepszy osąd operacyjny. Nie jest przydatna, gdy ludzie oczekują, że przejmie ona odpowiedzialność. Odpowiedzialność nie może zostać zlecona na zewnątrz. Łańcuch nie obchodzi, kto poczuł się produktywnie.
To jest prawdziwa lekcja. Kod generowany przez AI może przyspieszyć rozwój blockchaina, ponieważ usuwa mechaniczne tarcie, ale tylko ludzki osąd może chronić niezmienna właściwość i wskazywać miejsca, w których wyglądający mądrze szkic wciąż jest błędny. Teraz widzisz, dlaczego workflow się poprawia, skąd wynika korzyść i dlaczego to samo narzędzie może pomóc lub zaszkodzić w zależności od tego, jak ściśle jest kontrolowane.
O tego rodzaju praktycznej pracy z AI lubię pisać w The Model Log, gdzie jedna użyteczna koncepcja, jeden działający przykład i jedna szczera analiza tego, co faktycznie działa, mają większe znaczenie niż hałas.
