DevTalk Trio S03E07 – Taktyczne wzorce projektowe vs. LLM
Jakub Kubryński, Łukasz Szydło i Kuba Pilimon w kolejnym odcinku DevTalk Trio! Dziś rozmawiają o tym, dlaczego faza projektowania to wciąż domena człowieka i jak mądrze używać LLM-ów, żeby nie produkować pięknie wyglądającego, ale bezużytecznego kodu. Niby szeroki temat, który przewija się ciągle i wszędzie, ale z tego odcinka dowiesz się: Czy LLM potrafi samodzielnie […] The post DevTalk Trio S03E07 – Taktyczne wzorce projektowe vs. LLM appeared first on DevTalk.
O tym możemy też później pokazać, ale nie chcę też zdominować tą odpowiedzią całości, bo mamy ileś tam czasu. Może nam pomóc przy fazie projektowania, ale w inny sposób niż przy fazie implementowania, w diametralnie inny sposób, zadawając pytania i tak dalej. To jestem ciekawy, co... To mi się wydaje, że ogólnie jakby faza implementacji w przypadku, kiedy używamy LLM-ów, to jest taka... Bardzo prosta, pochodna fazy specyfikacji. Jeżeli oczywiście są ludzie, którzy robią mód YOLO, czyli mówią do LLM-a weź mi to napraw albo weź mi to zrób, no to to nie zadziała. Natomiast z mojego doświadczenia w ogóle jest tak, że jeżeli... Pracuję z LLM, to ja często w ogóle nie za bardzo sprawdzam tą fazę implementacji, bo tam po prostu za dużo się dzieje i liczę, że po prostu mój proces, moje skille i mój workflow w cloudzie powoduje, że ta zgodność pomiędzy fazą specyfikacji a fazą implementacji jest praktycznie nieskończona.
I to nie jest tak, że jakby ktoś robi na YOLO, to jest to wyrzucenie. Nie, jest pewien konkretny use case, gdzie YOLO, idziemy do przodu. Ale w momencie, kiedy rzeczywiście zaczynamy wchodzić w takie bardziej skomplikowane rzeczy, no to moim zdaniem Nie ma innego wyjścia, jak tylko używać gotowych klocków, no bo jakoś z tym LLM trzeba gadać i trzeba gadać z nim tak, żeby mieć właśnie w głowie tą taką dłuższą perspektywę czasu, że ja nie tylko muszę zrobić coś, co działa na teraz, ale coś, co będzie też działało później. Więc ja na to patrzę dokładnie w taki sam sposób, jak do tej pory pracowaliśmy z zespołami, bo oni wypracowali się tak samo. Siadamy do Miro, rysujemy sobie karteczki, wrzucamy sobie reguły, projektujemy sobie agregaty, robimy sobie, w którymś momencie dochodzimy do jakiegoś tam design level event stormingu. A potem to jest właściwie tylko zaznacz te karteczki, wyeksportuj do specyfikacji tekstowej, właściwie wygeneruj, bo jeżeli już mamy te skille porobione do tego, żeby później ci agenci wiedzieli w jakim stylu zaimplementować konkretny building block, no to moim zdaniem to jest...
Jak bardziej przetwarzanie danych, to jeszcze troszeczkę inne. Ale chodzi mi o to, że zawsze mamy jakąś taką skończoną ilość tych elementów. Jeżeli my je potrafimy nazwać, a następnie to, co Kuba mówił, jesteśmy w stanie sobie napisać skille, które każdy z tych klocuszków w jakiejś tam naszej stylówie potrafią być wykonane, to właśnie tutaj mamy jakby tę powtarzalność. Zaczynamy budować sobie ten proces w taki sposób, że Nie muszę za każdym razem myśleć, co mi ten agent tym razem wygeneruje. Wygeneruje mi dokładnie to, co sobie z tych klocuszków poukładam. Jasne. Ale zobaczcie jedną rzecz, że jeżeli chodzi o wzorce projektowe, czy to używamy LLM-ów, czy nie używamy, sama implementacja wzorca jest turbo banalna. Problemem jest to, żeby zauważyć, że w tym miejscu ten wzorzec musisz zrobić, bo każdy głupi wie, jak się implementuje wizitora.
embeddable albo właśnie value objectem, który jesteśmy w stanie gdzieś wrzucić. Raczej jedzie na YOLO, czyli dodaje tam 15 kolumn I tak dalej. Raczej właśnie nie wyłapuje tego, że tutaj da się poprawić ten kod value object. Drugie pytanie, czy to ma teraz znaczenie? Jeżeli to LLM pisze ten kod, to czy mnie boli to, że tam nie ma value objecta albo jest? To ja odniosę się do pierwszego pytania, bo ja mam troszkę inne wrażenie, że może mi w tym pomóc i trochę się chciałbym skupić na tym, co powiedzieliście obaj. Łukasz mówiłeś o tym, że skille implementacyjne to jest prosta rzecz, bo najpierw i tak masz fazę projektowaną i użyłeś przykładu, że robisz na milo karteczki. Nie mówiłem, że prosta, powiedziałem, że... Wtórna, łatwiejsza może tak.
Łatwiejsza niż ta część projektowana za pomocą karteczek. Kuba Ty mówił z kolei, że stosowalność wzorca To jest zabior game changer albo niestosowalność, a nie sama faza implementacyjna, czyli gdzieś tam ten ciężar, że tak powiem, intelektualny w Waszych wypowiedziach był w tym samym miejscu, bym powiedział. Czyli na fazie implementacyjnej. I teraz z mojego doświadczenia Mogę użyć też takiego narzędzia do tego, żeby zadało mi pewnego rodzaju meta pytania. Ja na przykład używam sobie kilku różnych skilli do tego, żeby zobaczyć przykładowo. Nie wiem, masz listę comment, nie? Zablokuj slot, zwolnij slot, wyłącz zasób, zdefiniuj slot. Sztampowy przykład jak już tam dostępność zasobów. Czyli taka klasyczna walka o zasoby.
Rozpoznawane przez różnego rodzaju narzędzia. I znowu jest to szybsza praca niż to, co do tej pory musiałem robić. Ale game changer dopiero jest wtedy, kiedy takiego skilla użyje człowiek, który powiedzmy tych pytań wbudowanych naturalnie nie ma. Gdzieś tam czai mniej więcej o co chodzi, ale za pomocą pewnego rodzaju wizarda może dostać na przykład takie rozwinięcie tego problemu, o którym przed chwilą powiedziałem z tymi zasobami, że masz tę parę konfliktujących się komend. Niech to będzie ten zdefiniuj slot i zablokuj slot. To się wzajemnie konfliktuje z jakiegoś powodu, nieważne z jakiego. Weźmy taki przykład. W teorii taki konflikt istnieje i na macierzy widać, że istnieje, bo ktoś przecież może blokować slot, który jest właśnie w fazie definicji, ale teraz pozostaje pytanie domenowe, które naturalnie projektant by zadał zawsze. Czy ten konflikt jest realny? Czy może proces biznesowy w naszej organizacji akurat się tak układa i sprawia, że te dwie komendy nigdy nie trafią do systemu w tym samym czasie?
Bo na przykład coś się dzieje, jakieś definicje do dziesiątej, a od dziesiątej dzieje się już coś innego i mogę dopiero włączać zasoby. I mogę mieć po prostu zwykłego skilla, który mi takie pytania pomoże zadać. Ja i tak muszę na nie samo odpowiedzieć za pomocą prawdopodobnie ekspertyzy kogoś, kto wie lepiej, ale sam fakt, że ja je zadaję powoduje, że ta faza implementacji będzie później jeszcze prostsza. A tutaj sobie pomagam w fazie projektowania. Jeżeli nauczę... Czyli to, co zrobiłeś, to de facto takie drzewko decyzyjne, które zawsze sam sobie zadawałeś, przeniosłeś do skilla, tak? Czyli ono jest teraz reużywalne i to nie ty prowadzisz LLM-a za rękę, mówiąc mu weź pod uwagę to, weź pod uwagę to, weź pod uwagę to, tylko masz skilla, który robi to odwrócenie kontroli i zadaje tobie te...
Te poszczególne pytania. Pewnie te pytania powinny być różne w zależności od tego, o jakim wzorcu rozmawiamy. I trochę inaczej to robić tu, trochę inaczej robić tu. Tylko znowu tutaj wbiję taką szpileczkę, bo tutaj znowu już zakładamy, że wybraliśmy jakiś wzorzec. I teraz z mojego doświadczenia problemem jest to, Żeby LLM zaczaił, że w ogóle tutaj o takim wzorcu warto myśleć. Jak już wiemy, że jest wzorzec X, to zaimplementowanie jego, zadanie pytań jest proste. Wiemy, którego skilla załadować. Problem jest taki, żeby ten LLM wyczaił, że tutaj tak naprawdę to może rozwiązać agregat, a to może rozwiązać fabryka, to może rozwiązać coś.
I teraz tutaj jest moim zdaniem największa zagwozdka. Żeby właśnie AI wpadł na to, że w ogóle warto się zainteresować jakimś wzorcem. I że to, co mamy tutaj tak naprawdę, jakbyśmy sobie poprzenazywali, to właśnie mamy albo jakiś archetyp, albo jakiś wzorzec i tak dalej. Tu jest ciężko zmusić LLM-a i napisać na tyle generyczne skille, Żeby one same na to wpadły. Ja nawet patrząc, jak LLM pracuje z modelami danych, to on często te modele danych przekombinowuje. Po co nam w ogóle ta tabelka? Zróbmy bez tej tabeli łączącej, zróbmy to i to. Super pomysł, bo wiecie, LLM zawsze mówi, że jesteśmy genialni, ale sam na to nie wpada właśnie. To takiego skilla też będzie, powiem Ci. Skilla, który stara się oczywiście za pomocą heurystyk i jakichś tam podpowiedzi klasyfikować Ci rodzaje problemów, z którymi masz do czynienia.
Aha, to wydaje mi się, że to jest dobry kandydat na agregat albo na jakieś inne rzeczy. Rzeczywiście też mam skilla klasyfikacyjnego podobnie jak Kuba, tylko że ja mam skilla, który klasyfikuje reguły do wzorców taktycznych. Najczęściej jak ludzie opowiadają, jak są jakieś warsztaty z tymi... Z osobami z biznesu. To oni się posługują najczęściej regułami, tak? Oni nie mówią tymi wzorcami taktycznymi i tak dalej. To jest jakby nasza rola, żeby to wszystko przekształcić. Więc taki skill klasyfikacyjny, tak? Tylko pewnie trochę coś innego następuje klasyfikacja, nie? Ale mówię... No dobra, ale zobaczcie, że wydaje mi się, że trochę w innym kierunku w ogóle idziemy, bo Łukasz mówi, że ty modelujesz w taki sposób i tak dalej. Super, tylko moje pytanie jest po cholerę, ty masz modelować, skoro mamy LLM.
I my teraz pracujemy w skill panelu nad takim właśnie... Agentem, który nazywa się Skill Panel Guru i który właśnie ma wiedzieć, znać całą architekturę taką, wiesz, korporacyjną, wiedzieć co robi, który system, czemu, jak to one są ze sobą powiązane itd. Po to, żeby być w stanie próbować rozdelegowywać, oddelegowywać, dystrybuować pracę do poszczególnych agentów, poszczególnych... Taktyczne wzorce projektowe vs. LLM
Bo zobacz, to co powiedział Pilo, że on mając swojego skilla, jakby jest w stanie dać tego skilla osobie, która nie umie w agregaty i ten skill zadaje odpowiednie pytania, zmusi tą osobę do zastanowienia się na ile ten niezbiednik tutaj faktycznie trzeba chronić. A na ile ten niezmiennik występuje tylko w teorii i nigdy się nie rzeczywistni, to na ile właśnie cała praca z wzorcami taktycznymi może być oddelegowana do LLM łącznie z wykrywaniem i aplikowaniem tych wzorców w odpowiednich miejscach? A na ile to jest coś, co przynajmniej na dzisiaj jeszcze zostaje w głowie modelarza czy projektanta? Ja bym to podsumował tak, że moim zdaniem może pod warunkiem, że jest human in the loop, który jakby na samym końcu zerknie sobie na tą speckę i zobaczy, ok, tak, to co zostało zaproponowane ma sens.
Pokazano wszystkie 12 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.
Jakub Kubryński, Łukasz Szydło i Kuba Pilimon w kolejnym odcinku DevTalk Trio! Dziś rozmawiają o tym, dlaczego faza projektowania to wciąż domena człowieka i jak mądrze używać LLM-ów, żeby nie produkować pięknie wyglądającego, ale bezużytecznego kodu. Niby szeroki temat, który przewija się ciągle i wszędzie, ale z tego odcinka dowiesz się: Czy LLM potrafi samodzielnie […]
The post DevTalk Trio S03E07 – Taktyczne wzorce projektowe vs. LLM appeared first on DevTalk.