Narzędzia AI automatyzują generowanie kodu i testy dla programistów. To jest prosta odpowiedź, a to właśnie ten aspekt warto mieć na uwadze, gdy szum wokół tematu się nasila.
Uważam, że należy postrzegać to nie jako magię, ale jako przesunięcie ciężaru pracy. Narzędzie pisze pierwszy szkic kodu. Potrafi również tworzyć szkice testów, wypełniać mocki i pomagać w szybszym obsłużeniu prostych przypadków niż osoba wpisująca kod ręcznie. Oszczędza to czas na nudnych fragmentach. Nie usuwa jednak potrzeby myślenia.
Część dotycząca generowania kodu jest łatwa do zrozumienia. Programista dostarcza narzędziu podpowiedź (prompt), istniejący kod lub oba te elementy. Następnie narzędzie przewiduje prawdopodobny kod pasujący do wzorca. W praktyce oznacza to, że funkcje, małe klasy, szkielety testów oraz kod pomocniczy są często pierwszymi elementami, które narzędzie produkuje dobrze. Najlepiej radzi sobie, gdy zadanie jest wąskie, a kształt odpowiedzi jest jasny.
Testy są ciekawszą częścią. Narzędzia AI mogą tworzyć szkice testów jednostkowych, sugerować skrajne przypadki (edge cases) oraz generować pliki testowe wokół istniejącego kodu. Niektóre narzędzia pomagają też w szerszych sprawdzianach, takich jak testy API, testy przeglądarkowe czy konfiguracja CI. Główną wartością jest szybkość. Narzędzie może wygenerować początkowy zestaw testów, który programista następnie sprawdza i poprawia.
Ostatni punkt ma znaczenie. Wygenerowane testy nie są dowodem poprawności. Test może wyglądać kompletnie, a mimo to przeoczyć prawdziwy błąd. Traktuję wygenerowane testy jako szkic, a nie werdykt. Pomagają one szybko wypełnić przestrzeń, ale nadal wymagają weryfikacji względem zachowań, jakie oprogramowanie powinno wykazywać.
Istnieje też zwykła granica samego kodu. Narzędzia AI mogą odzwierciedlać to, co wygląda powszechnie, ale powszechne nie to samo co słuszne. Mogą wymyślić wywołanie API, przeoczyć przypadek brzegowy lub napisać test, który sprawdza tylko to, co robi kod, a nie to, czego potrzebuje użytkownik. Innymi słowy, wynik może być czysty, a mimo to błędny. To jest ten element, o którym zespoły zapominają, gdy pierwszy demko wygląda dobrze.
Najlepsze zastosowanie jest zazwyczaj lokalne i konkretne. Programista może poprosić o szkielety testów dla jednej funkcji lub poprosić o małą refaktoryzację z testami obok niej. Narzędzie jest mniej niezawodne, gdy zadanie obejmuje cały system, ukryte reguły lub duże repozytorium z wieloma zależnymi elementami. Kontekst pomaga, ale kontekst ma swoje limity. Model może korzystać tylko z tego, co widzi.
Dlatego narzędzia AI do kodowania dobrze współgrają z silnym procesem testowania, a nie zastępują go. Działają najlepiej, gdy projekt ma już jasne zachowania, dobre nazewnictwo i pewne istniejące testy. Wtedy narzędzie może rozszerzać system bez zgadywania zbyt wiele. Jeśli baza kodu jest niejasna, narzędzie nadal jest szybkie, ale sama szybkość nie kupuje zaufania.
Myślę też, że programiści powinni ostrożnie dobierać słowo „automatyzuj”. Brzmi ono ostatecznie. W praktyce narzędzia te automatyzują generowanie, a nie odpowiedzialność. Mogą zmniejszyć ilość ręcznego wpisywania i przyspieszyć pisanie testów. Nie ponoszą jednak odpowiedzialności za wynik. Osoba nadal musi decydować, czy kod jest bezpieczny, czytelny i zgodny z systemem.
To jest uczciwy kształt odpowiedzi. Narzędzia AI obecnie automatyzują większość pierwszego przebiegu dla kodu i testów. Są użyteczne, ponieważ obniżają koszt dotarcia do szkicu. Ich słabością jest ta sama cecha, która sprawia, że są szybkie. One zgadują. Dobry software nadal wymaga człowieka, który sprawdzi tę zgadywkę.
Dla czytelników The Model Log jest to wzorzec, do którego ciągle wracam: jeden praktyczny koncept AI, jeden działający przykład i jeden szczery rzut oka na to, co naprawdę działa.
