DevTalk #124 – O Nauce z Pomocą LLM-ów z Tomaszem Ducinem

Więc tutaj wyzwaniem jest to, żeby znaleźć jakiś sweet spot, w jaki sposób te rzeczy połączyć. Więc ja do tego podchodzę w taki sposób, jest taki uproszczony model, znaczy uproszczony, prosty model nabywania kompetencji. Świadoma kompetencja, świadoma niekompetencja, nieświadoma niekompetencja i nieświadoma kompetencja. Known, knowns, unknown, unknowns i tak dalej. Zasadniczo, jeżeli o czymś się nie ma bladego pojęcia, no to po prostu nawet nie wiesz, czego nie wiesz. Nieświadoma niekompetencja. I w tym momencie, kiedy byś na przykład wziął do ręki książkę, to owszem, można się nauczyć i oczywiście, że warto czytać książki, natomiast na samym początku może być takie zjawisko, że z tej książki zrozumiesz 20%, 30%, tak jak na przykład ludzie czytają przykładowo Evansa z DDD i tą niebieską książkę, no i się okazuje, że niewiele z niej rozumieją, sięgają po inne książki i tak dalej, i tak dalej, i tak dalej.

Jeżeli chodzi o tematy jakieś takie bardzo wysublimowane, bardzo trudne, wymagające wiedzy czy mentoringu top ekspert, to tam zdecydowanie książki, czy właśnie... mentoring, prezentacje jakichś tam największych specjalistów z naszej branży i tak dalej. Natomiast jeżeli chodzi o zrozumienie, w czym jest problem, to da się złapać taki entry level. Przy czym tutaj też trzeba... Trzeba bardzo rozróżnić, o jakiego typu zagadnieniu mówimy. Przykładowo, jeżeli na przykład mamy frontendowca, który nie bardzo ma pojęcie o bazach danych, czy o DevOpsie, czy o innych jakichś rzeczach, to teraz trzeba sobie zadać, czy na przykład o DDD, to trzeba sobie teraz zadać pytanie, jakiej jakości materiały są dostępne w sieci.

Czy na przykład są dobre materiały, które tłumaczą ddd, a to bardzo zależy od prompta, bo masz też w internecie bardzo dużo materiałów, które idą w taką ścieżką narracyjną, o co chodzi w ddd, żeby określić jakie masz tam bounded konteksty i siup do agregatu, gdzie całkowicie pomijasz w ogóle to, co jest najważniejsze, czyli na przykład wiesz tam strategiczna analiza, co z jaką w ogóle problematyką zajmuje się nasz produkt, nasz biznes, w jaki sposób w ogóle wydzielać granice, jak dystylować, bounded konteksty i tak dalej. I przechodzą od razu do kodu, gdzie pokazują kodzik, a to zupełnie nie o to chodzi. Tak zwane DDD uproszczone, co nie takie prosto do technikaliów, które mogą być pomocne jeśli chodzi o organizację kodu, natomiast nie rozwiązuje problemu, który ma być rozwiązywany przez DDD.

gdyby z DDD wyjebać taktyczne i zastawić strategiczne, to miałoby dużą wartość. Gdyby zrobić odwrotnie, to byłoby całkowicie bez sensu. Więc to jest tak, że w każdej z tych problematyk możesz się naciąć. Więc taki pierwszy, najważniejszy punkt, taki drogowy wskaz, to jest, czy w internecie jesteś w stanie znaleźć materiały z danej dziedziny, danego zagadnienia, które będą rzetelne i wartościowe. No i tutaj strasznie zależy. Ale z drugiej strony, na przykład back-endowiec, który chciałby się nauczyć na przykład, nie wiem, Reacta albo czegokolwiek innego, czy jest w stanie, na przykład, nie wiem, ma nawet problem w swoim jakimś własnym kodzie z jakimś tam technicznym, techniczny problem, szuka technicznego rozwiązania. Czy LLM mu pomoże? Z dużym prawdopodobieństwem tak. No bo to nie są rzeczy strasznie abstrakcyjne.

W sensie, żeby wychwycić na ile ja faktycznie to rozumiem, na ile ja się dałem zwieść tej ułudzie, że to wszystko jest takie proste, no to do tego trzeba wiedzy i kompetencji. Więc ja wychodzę z tego tak, że ucząc się danej rzeczy, na początku zrozumieć, gdzie jest punkt ciężkości, gdzie są problemy. Gdzie są problemy? Co jest trudne? Na przykład, jeżeli spytasz o DDD, co jest trudne, to niektórzy Ci na przykład powiedzą, że trudne jest wyznaczanie granic. Inni Ci powiedzą, trudne jest na przykład efektywne wyłuskiwanie informacji z biznesu od ekspertów domenowych, bo na przykład tych ekspertów... Na przykład organizacja jest nie do końca uporządkowana i na przykład nie ma przepływu informacji.