Wpływ GenAI na programistów i automatyzację programowania

Krzysztof Kempiński
kkempin’s dev blog
9 min read5 days ago

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Grigorijem Dudnikiem o wpływie GenAI na programistów i automatyzację programowania.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to AI developer rozwijający wieloagentowy system Clean Coder, którego używa do półautomatycznego pisania kodu w startupie takżyli.pl, w którym to zresztą pełni rolę CTO. Kontrybuował do Microsoft AutoGen, popularnego frameworku do orkiestracji AI agentów. Autor Tinder GPT, autonomicznego asystenta do aplikacji randkowych. Poza tematami agentowymi robi badania nad stworzeniem myślącego robota, uruchamiając duże modele językowe na jednopłytkowych komputerach. Moim i Waszym gościem jest Grigorij Dudnik.

Cześć, Grigorij, bardzo miło mi gościć Cię w podcaście.

Cześć, Krzysiek. Dzięki za zaproszenie.

To przyjemność po mojej stronie. Dzisiaj w podcaście po raz kolejny poruszamy ważny, modny i gorący ostatnio temat wpływu generatywnej sztucznej inteligencji na programistów i na proces wytwarzania oprogramowania. Dzisiaj natomiast nieco taką inną perspektywę, mam wrażenie, poruszymy z Grigorijem, właśnie agentową: tego, jak możemy my jako programiści wspomóc się AI agentami, aby ten proces wytwarzania programowania przebiegał szybciej, sprawniej i łatwiej na koniec dnia. Więc myślę, że bardzo ciekawy temat.

Grigorij ma dużo praktycznego doświadczenia właśnie z nie tylko AI, ale również agentami, więc fajnie będzie usłyszeć od osoby, która ma tego typu doświadczenia, jak AI w takim wydaniu może nam programistom pomóc.

Zanim do tego jednak przejdziemy, to chciałbym Cię, Grigorij, zapytać, czy słuchasz podcastów i czy może jakieś ciekawe audycje na Twojej playliście goszczą?

Tak, jest kilka podcastów, których albo słucham okazjonalnie, albo przynajmniej słuchałem w przeszłości. I na pewno Twój podcast jest tutaj warto wymienienia.

Dziękuję.

Tak, bo pokazuje różne odległe zakątki branży IT, o których nawet nie wiedziałem, a też z ciekawością się dowiedziałem o ich istnieniu w ogóle i o tym, jak wyglądają. Poza tym warto wymienić tutaj podcast Cyberświat Matusza Chroboka, który w dosyć taki prosty, przyjemny do posłuchania sposób, też zrozumiały dla osób nietechnicznych, tłumaczy o nowinki technologiczne każdego tygodnia. Też Pierwsze kroki w IT Mateusza Bogolubowa, który to ma podcast dosyć zbliżony do Ciebie formatem, lecz skupia się na osobach początkujących i osobach się przebranżawiających. Oraz Automatyzacja i AI w biznesie Jakuba Masztalskiego, który dla osób biznesowych tłumaczy, w jaki sposób wdrożyć AI w swoim biznesie i kiedy warto to robić.

Właściwie to każdy podcast, w którym akurat kiedyś miałem okazję wziąć udział, myślę, że jest zdecydowanie warty polecenia, na pewno jest ciekawy dla mnie i cóż, zapraszają tam samych fajnych gości.

Konkretna lista rekomendacji, dzięki za to jak najbardziej się pod tym podpisuję i też mogę polecić właśnie te audycje. Dobrze Grigorij, to chciałbym Cię na początku zapytać o to, jaki jest stan AI agentów, głównie związanych z automatyzacją programowania, bo na tym się tutaj skupiamy na połowę roku 2024. Jakiego typu frameworki mamy do dyspozycji, jak one wypadają, czy da się je jakoś porównać do siebie?

Właśnie, bo tutaj ten temat agentów się, nie wiadomo, bardzo szybko się rozwija, więc tutaj warto właściwie zacząć od definicji, czym właściwie są ci agenci. Otóż teraz agenci są takim buzzwordem właściwym na wszystko, co ma jakieś ???04:19 w środku, a się mówi, że jest agentem, lecz w moim rozumieniu taki agent się różni od takiego zwykłego pipeline’a LLM-owego tym, że w zwykłym pipelinie mamy do czynienia z góry ustaloną strukturą. Czyli mamy jakiegoś LLM-a, po którym mamy wywołanie jakiegoś narzędzia, potem znowu jakiegoś LLM-a, forsujemy wyjście tego LLM-a i w zależności od tego, co mamy na wyjściu, to wywołujemy znowuż albo to, albo tamto narzędzie.

Lecz w przypadku agenta mamy do czynienia z takim zapętleniem wywołań tego LLM-a. Czyli np. dajemy mu zadanie, w naszym przypadku mówimy o programowaniu, więc też dajemy mu zadanie, że musi zedytować jakiś kod, I ten agent w pierwszym wywołaniu LLM-a patrzy, że dobra, że jest taki kod, teraz zmienia funkcję numer 1 i wywołuje narzędzie do zmiany funkcji numer 1 na jakąś lepszą. Zmienia ją, potem wywołuje kolejny raz znowuż tego LLM-a, zmienia funkcję numer 2, powiedzmy, potem jest kolejna iteracja, tam dodaje funkcję numer 3 itd., aż do samego końca. Czy to zadanie, czy pieniędzy na rachunku naszego dostawcy LLM-ów.

Tak że tacy agenci są używani do różnych celów, od jakichś domowych automatyzacji do dużo poważniejszych, jak programowanie na przykład. I swojego agenta można stworzyć za pomocą takich frameworków jak AutoGen, CrewAI lub LangGraph, lub też napisać go samemu na piechotę w języku programowania.

Ale w ostatnim czasie też się pojawiło sporo takich frameworków stricte do programowania, agendowych frameworków, które stricte programują i które robią to dobrze. Ponieważ mają takie wyspecjalizowane narzędzie, stricte do tego, mają bardzo dobrze przemyślane przepływy informacji też wewnątrz tego frameworka i uwzględniają różne wady i zalety, głównie wady tegoż LLM-a i robią coś, żeby jednak tę wadę zniwelować. Tak że to są takie narzędzia jak Devin, OpenDevin, SWE-agent, Aider lub tworzony przeze mnie Clean Coder.

I tego jest całkiem sporo w ostatnim czasie. Właściwie to znam osobiście wielu kolegów, którzy też tworzą jakiegoś takiego agenta do programowania. I tutaj nawet miałem ostatnio taką dygresję, czemu właściwie tak jest, że jest sporo agentów do programowania, a nie ma np. agentów do tworzenia jakichś innych czynności inżynierskich, jak inżynieria mechaniczna, elektroniczna, czy inne. I dochodzę do wniosku, że jednym z powodów jest to, że stworzenie narzędzia do pisania kodu jest po prostu łatwiejsze. Elementy też są wytrenowane do pisania kodu.

Ale drugi taki powód, najważniejszy, myślę, że jest taki, że osoby, które się znają na AI i są zdolne stworzyć taki framework, też są programistami już z automatu. Lecz mało jest takich osób, które by się znały na AI, a też przy okazji np. znały się na tej inżynierii mechanicznej i były w stanie taki framework do tego stworzyć.

Tak że tutaj warto też powiedzieć o takim czymś jak SWE Benchmark, czyli narzędziu do ewaluacji takich frameworków do programowania. Jest to zestaw zadań programistycznych, prawdziwych issuesów z GitHuba. W wersji mini jest to 300 zadań, za pomocą których możemy przetestować nasz framework. I w tej chwili największy score, największy wynik z tego SWE benchmarka otrzymał framework Aider z wynikiem 26,33%. Czyli taki AI potrafił w trybie w pełni autentycznym rozwiązać niewiele ponad 1/4 dosyć prostych zadań.

Oczywiście warto tutaj też powiedzieć, że w chwili wydania tego podcastu myślę, że ten wynik już będzie inny. Też jeśli mnie zapytasz, ile tych punktów SWE dostałby Clean Coder, to powiem Ci, że nie wiem, bo akurat, żeby mieć swój framework w tym, to musiałbym albo wszystkie te 300 przykładów jakoś ręcznie przepuścić przez Clean Codera, albo napisać jakiś dodatek, który by zautomatyzował to testowanie i też poświęcić na to sporo czasu, więc pewnie, jak można się domyślić, wolałem jednak się skupić na faktycznie rozwijaniu tego frameworka i tworzeniu rzeczy, które są przydatne na produkcję, niż na po prostu ewaluację.

Tak że tacy agenci są używani do różnych celów, od jakichś domowych automatyzacji do dużo poważniejszych, jak programowanie na przykład. I swojego agenta można stworzyć za pomocą takich frameworków jak AutoGen, CrewAI lub LangGraph, lub też napisać go samemu na piechotę w języku programowania.

Ale w ostatnim czasie też się pojawiło sporo takich frameworków stricte do programowania, agendowych frameworków, które stricte programują i które robią to dobrze. Ponieważ mają takie wyspecjalizowane narzędzie, stricte do tego, mają bardzo dobrze przemyślane przepływy informacji też wewnątrz tego frameworka i uwzględniają różne wady i zalety, głównie wady tegoż LLM-a i robią coś, żeby jednak tę wadę zniwelować. Tak że to są takie narzędzia jak Devin, OpenDevin, SWE-agent, Aider lub tworzony przeze mnie Clean Coder.

Jasne, rozumiem. 1/4 to z jednej strony dobrze, z drugiej strony dość jeszcze daleko, jeśli chodzi o to, czym się nas straszyło jeszcze jakiś czas temu, czyli zastąpieniem AI programistów. Myślę, że póki co nam to nie grozi. Co prawda, co jakiś czas pojawiają się takie głosy, ale jako branża chyba już zrozumieliśmy, że AI to jest jakiś rodzaj pomocy, to jest jakiś rodzaj wsparcia podczas programowania, a niekoniecznie zagrożenie. To jest oczywiście temat na zupełnie inną dyskusję, natomiast myślę, że dojrzewamy jako branża i rozumiemy, że to jest po prostu rodzaj narzędzia.

I wspomniałeś tutaj o tym, że wykorzystujesz tego typu rozwiązania do pisania kodu produkcyjnego, jakby nie było tak, bo w Twoim startupie wykorzystujesz AI agentów. Chciałbym Cię zapytać, czy to jest narzędzie, które jest już na tyle gotowe, na tyle dojrzałe, żeby wykorzystywać właśnie je do pisania kodu produkcyjnego? Bo możemy sobie o generatywnej sztucznej inteligencji myśleć jako o rodzaju pomocy przy rozumieniu już napisanego kodu, żeby nam wyjaśniła, jak coś działa. Możemy użyć do napisania komentarzy, do napisania testów, do przetłumaczenia z jednego języka na drugi. To jest oczywiście bardzo pomocne, chociażby przy nauce programowania. Natomiast zastanawiam się, czy ta dojrzałość tych rozwiązań jest już na tyle duża, by pisać w nich kod produkcyjny.

Bardzo ciekawe to, co powiedziałeś. Po pierwsze tutaj skomentuję też, że ta 1/4 została uzyskana w trybie pełni autonomicznym, ale np. w przypadku Clean Codera on jest jednak skupiony na produkcji rzeczy produkcyjnych i tutaj nieraz jest potrzebna właśnie ta ingerencja ludzka, czyli pomaganie mu, sugestia, że coś musi zrobić inaczej, coś tam zrobił jednak nie tak, prośba, żeby coś poprawiał. To jest mega ważny element, taka akceptacja ze strony człowieka. Więc jest niestety jeszcze potrzebna. Niestety albo stety, to już zależy, jak kto na to patrzy.

Więc co do w ogóle historii powstania Clean Codera, to było tak, że zostałem jakiś czas temu CTO w startupie takżyli.pl i miałem zadanie napisania aplikacji webowej. Sama aplikacja nic innowacyjnego nie wnosiła, czyli po prostu aplikacja zwykła, która ma frontend we VUE i backend w FastAPI, lecz innowacyjne właśnie było to podejście, że stwierdziłem, że napiszę to za pomocą AI. Bo są ci agenci, to wystarczy, że wezmę pewnie jakiegoś autogena, dam mu parę narzędzi do kodowania i zaraz już cała aplikacja będzie gotowa.

Tak myślałem na początku, jednak niestety aż tak kolorowo nie było. Musiałem zmienić wiele frameworków po drodze, musiałem dodać dużo funkcjonalności, spotkałem się z wieloma problemami, z którymi, jak czytam swoją drogą, spotkali się też twórcy np. tego Aidera czy innych popularnych frameworków i też dlatego myślę, że akurat ten SWE score dla Clean Codera to wcale mniejszy od tych score’a by nie był, bo też tutaj zostało stosowane podobne rozwiązanie, więc w jaki sposób taki Clean Coder radzi sobie z zagadnieniami produkcyjnymi?

Otóż większość kodu w tym startupie, tak myślę, że z 80–90% napisałem za jego pomocą. Więc to już o czymś świadczy, że jednak używam go całkiem aktywnie. I z takimi zadaniami prostymi, gdzie po prostu mamy coś albo relatywnie prostego do zrobienia, albo mamy do czynienia z czymś powtarzalnym, czyli że już jakaś strona jest zrobiona i musimy na podobnych zasadach stworzyć też jakąś kolejną stronę, to z takim czymś radzi sobie raczej bezproblemowo, po prostu trzeba akceptować wszystko, jak leci, co on proponuje i będzie gotowe.

Z zadaniami bardziej skomplikowanymi, wymagającymi jakiejś takiej kreatywności, pomyślunku z jego strony, to już bywa różnie. Czasami też sobie radzi bez problemu, czasami nie radzi sobie w ogóle i trzeba po prostu tam pisać to ręcznie. Jednak w zdecydowanej większości jest tak, że radzi sobie, ale trzeba mu pomagać. Po prostu proponuje jakiś plan i trzeba mu zasugerować, że w tym planie ten punkt jest do zmiany, ten do wywalenia, to coś zrób inaczej. Przejdźmy z nim kilka iteracji edycji tego planu. Później też jak pisze ten kod, to czasami zasugerować, żeby użył jakiegoś innego narzędzia czy coś.

Więc tak, ostatecznie robię te zmiany, lecz z pomocą człowieka. Tak że tak, są potrzebne pewne nakłady czasowe czasami, ale jak już to działa, jak już siedzimy przy komputerze i patrzymy, jak właściwie same te zmiany się wprowadzają, kod sam się zmienia, pliki same się pojawiają, dzieje się po prostu magia.

I to jest też ciekawe, bo często jest tak, że to, co on proponuje, właściwie by zadziałało. Mógłbym zaakceptować, tak jak leci to, co on chce, lecz te zmiany nie byłyby takimi zmianami optymalnymi. Czyli np., jak miałem za zadanie dodanie podstrony projektu, był taki element rodzicielski, który miał kilka takich stron, podstron dzieci. I trzeba było stworzyć kolejne to dziecko. Było zrobione tak, że ten element rodzicielski robił request do backendu i otrzymywał jakieś tam dane i potem wysłał te dane do tych stron dziecięcych. I nasz Clean Coder z jakiegoś powodu akurat przegapiał ten element rodzicielski i nie dodał sobie go do kontekstu, więc zaczął tworzyć ten element dziecka tak od zera i zaproponował, żeby w tym elemencie dziecka właśnie dodać ten request do backendu.

Zadziałałoby to i owszem, lecz nie byłoby to optymalne, gdybyśmy w każdym elemencie dziecka robili osobny request do backendu. Lepiej zrobić jeden, a dobrze. Tak że ta część związana z planowaniem architektury jest tutaj niezwykle ważna i przede wszystkim tutaj, jak widzimy, człowiek jest bardzo potrzebny.

👉 Czytaj dalej: https://porozmawiajmyoit.pl/poit-252-wplyw-genai-na-programistow-i-automatyzacje-programowania/

--

--

Krzysztof Kempiński
kkempin’s dev blog

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.