Ponieważ GPT-3 i jego potomek, model Codex, nadal wykazują większą zdolność do interakcji z programowaniem i językami naturalnymi, pojawia się coraz więcej nowych potencjalnych przypadków użycia. Bram Adams, ambasador społeczności OpenAI znany ze swoich twórczych eksperymentów z algorytmami GPT-3 i Codex, wypuścił pod koniec 2021 roku jeden: Stenography, który wykorzystuje zarówno GPT-3, jak i Codex do automatyzacji irytującego zadania pisania dokumentacji kodu. Stenography odniósł natychmiastowy sukces, wprowadzając go na rynek jako produkt numer jeden dnia na popularnym portalu wprowadzania produktów na rynek Product Hunt. Adams wypróbował kilka potencjalnych przypadków użycia interfejsu API, zanim zawęził swoje pomysły do tego, który stał się jego nowym biznesem. „Myślę, że wiele z tych eksperymentów polegało na tym, że nieświadomie sprawdzałem, z czym może sobie poradzić model językowy taki jak GPT-3”. Poszukiwania Adamsa rozpoczęły się od pomysłu: „Co bym zrobił, gdybym mógł poprosić komputer o zrobienie czegokolwiek?” Zaczął eksplorować, „szperając w zakamarkach API OpenAI i sprawdzając, jak daleko może to zajść”. Wymyślił bota generującego poezję na Instagramie; wypróbował projekt dziennikarstwa selfpodcast, w którym użytkownicy rozmawiają z cyfrowymi wersjami siebie; pracował nad projektem tworzenia playlist muzycznych na Spotify w oparciu o preferencje użytkowników; i stworzył wiele innych projektów w służbie swojej ciekawości. Dzięki tej ciekawości „naprawdę wcześnie nauczyłem się rozumieć różne silniki GPT-3”. Dlaczego więc stenografia? „Dostałem całkiem dobry sygnał ze świata zewnętrznego, że może to być bardzo pomocne dla wielu osób”. Choć Adams cieszy się elegancją dobrze napisanego kodu, większość użytkowników GitHuba po prostu pobiera opublikowany kod i używa go: „Nikt tak naprawdę nie będzie podziwiał piękna, które umieściłeś w swojej bazie kodu”. Zauważył również, że świetne programy na GitHubie, które nie są dobrze udokumentowane, często nie są tak widoczne, jak na to zasługują: „Plik Readme [plik] jest pierwszą rzeczą, którą wszyscy widzą. Natychmiast przewijają w dół do tego.” Stenografia była próbą przemyślenia, w jaki sposób dokumentacja mogłaby ewoluować, aby stała się mniej irytująca dla programistów: „To trudne, ponieważ szczególnie w przypadku dokumentacji musisz uzasadnić to, co zrobiłeś. Mówisz więc: „Użyłem tej biblioteki, żeby to zrobić”. A potem zdecydowałem się użyć tego i dodałem tę funkcję, aby to zrobić.” Adams postrzega dokumentację jako sposób, w jaki ludzie mogą dotrzeć do innych osób w swoich zespołach, do siebie w przyszłości lub po prostu do zainteresowanych osób którzy natkną się na projekt. Jego celem jest uczynienie projektu zrozumiałym dla innych. „Zainteresował mnie pomysł, czy GPT-3 mógłby tworzyć zrozumiałe komentarze.” Wypróbował zarówno GPT-3, jak i Codex i był pod wrażeniem poziomu wyjaśnień z obu modeli. Następne pytanie, które zadał, brzmiało: „Jak sprawić, by było to naprawdę łatwe i przyjemne dla programistów?” Jak więc działa Stenografia i jak jej komponenty wykorzystują API OpenAI? Adams twierdzi, że na wysokim poziomie istnieją dwa główne procesy — analizowanie i wyjaśnianie — i każdy wymaga innej strategii. „W procesie analizowania spędziłem dużo czasu na zrozumieniu złożoności kodu, ponieważ nie wszystkie wiersze w kodzie są nawet warte udokumentowania”. Niektóre kody mogą mieć oczywisty cel, nie mieć wartości operacyjnej lub nie być już przydatne. Dodatkowo „duże” bloki kodu, sięgające ponad 800 linii, są zbyt trudne, aby model mógł je zrozumieć za jednym razem. „Trzeba byłoby rozbić tę logikę na wiele różnych kroków, aby móc dokładnie powiedzieć, że to właśnie robi to coś. Kiedy to zrozumiałem, zacząłem myśleć: „Jak mogę wykorzystać analizę składniową, aby znaleźć bloki, które są wystarczająco złożone, ale niezbyt skomplikowane?” Ponieważ każdy pisze kod inaczej, pozostaje tylko spróbować dołączyć do abstrakcyjnego drzewa składni i pracować z tym, co najlepsze. Stało się to głównym wyzwaniem architektonicznym warstwy analizującej. Jeśli chodzi o warstwę objaśnień, „jest to raczej cecha polegająca na tym, że GPT-3 i Kodeks mówią to, co chcesz, żeby powiedziały” – wyjaśnia Adams. Sposobem na osiągnięcie tego jest znalezienie kreatywnych sposobów zrozumienia odbiorców kodu i nakłonienie GPT-3 do przemówienia do nich. Warstwa ta „może próbować rozwiązać dowolne pytanie, ale może nie rozwiązać go ze stuprocentową dokładnością, jaką można uzyskać za pomocą kalkulatora. Jeśli wpiszesz dwa plus dwa równa się cztery, czasami otrzymasz pięć, ale nie musisz pisać wszystkich funkcji mnożenia, dzielenia i odejmowania. Te przychodzą za darmo.” Na tym polega kompromis z systemami probabilistycznymi: czasami działają, a czasami nie, ale zawsze zwracają odpowiedź. Adams radzi pozostać na tyle płynny, aby w razie potrzeby móc zmienić strategię. Adams podkreśla znaczenie prawdziwego zrozumienia problemu przed rozpoczęciem korzystania z API OpenAI. „W godzinach mojej pracy przyjdą ludzie i będą mieli ogromne problemy. Zapytają: „Jak zbudować statek rakietowy od podstaw, korzystając z podpowiedzi?”, a ja na to: „No cóż, na statek rakietowy składa się wiele elementów. GPT-3 nie jest panaceum. To bardzo potężna maszyna, ale tylko wtedy, gdy wiesz, do czego jej używasz.” Porównuje GPT-3 do języków programowania, takich jak JavaScript, Python i C: „Są przekonujące, ale tylko jeśli rozumiesz rekurencję i for i while oraz jakie narzędzia pomogą Ci rozwiązać konkretny problem. Dla Adamsa oznaczało to zadawanie wielu „metapytań technicznych”, takich jak „W czym pomaga posiadanie dokumentacji AI?” oraz „Czym w ogóle jest dokumentacja?” Radzenie sobie z tymi pytaniami było dla niego największym wyzwaniem. „Myślę, że wiele osób po prostu natychmiast rzuciło się do Davinci, aby rozwiązać swoje problemy. Ale jeśli potrafisz rozwiązać coś na mniejszym silniku, takim jak Ada, Babbage czy Curie, tak naprawdę poznajesz problem o wiele głębiej, niż gdybyś próbował rzucić na niego całą sztuczną inteligencję za pomocą Davinci”. twierdzi. Jeśli chodzi o budowanie i skalowanie produktu za pomocą API OpenAI, radzi używać „małych silników lub niskich temperatur, ponieważ nie można przewidzieć, jak będzie wyglądać końcowa zachęta (ani czy będzie ona ewoluować w czasie), co co próbujesz zrobić i kim jest Twój użytkownik końcowy, ale [dzięki] zastosowaniu mniejszych silników i niższych temperatur szybciej znajdziesz odpowiedzi na naprawdę trudne pytania”. Kolejnym wyzwaniem było przejście od własnych, samodzielnych eksperymentów do aplikacji uwzględniającej wszystkie różne warunki i sposoby pracy, z którymi mogą się spotkać użytkownicy. Teraz pracuje nad „znalezieniem różnych przypadków brzegowych”, aby lepiej zrozumieć, jak szybka musi być warstwa projektowa interfejsu API, jak często musi odpowiadać konkretnym żądaniem i jak współdziała z różnymi językami. Co dalej ze Stenografią? Teraz, gdy Adams zbudował produkt, z którego jest bardzo zadowolony, w 2022 roku planuje skupić się na sprzedaży i rozmowie z bazą użytkowników. „Stenografia nie będzie polegać tak bardzo na budowaniu, jak na prawdziwym doskonaleniu produktu i pokazywaniu go ludziom”.