Mentionsy

Więc im ja mam lepszy kod, im bardziej ustrukturyzowany poprawnie tak, żeby on był zrozumiały, tym lepsze odpowiedzi ja z tego LLM-a będę miał.

Bounded konteksty chyba też uwipukli, bo tu się świetnie idea Evansa tego, żeby zamknąć pewien spójny język w obrębie jakiegoś kontekstu, się świetnie łączy z LLM-ami.

LLM?

A teraz, jak mam, że tak powiem, LLM-a pod ręką i jestem w stanie w każdej chwili zapytać go, weź zerknij w ten kodzik i powiedz mi, jak działa to, powiedz mi, jak działa tamto, powiedz mi, jak działa siamto.

Zostanie automatycznie, z niego zostaną powyciągane te decyzje i LLM będzie mi w stanie przygotować draft tych wszystkich ADR-ów, czy może w ogóle możemy to szerzej traktować, to nie musi być Architecture Decision Record, to może być po prostu Decision Record, bo to mogą być decyzje,

Że my więcej zaczynamy dokumentować, ale rzeczy, które są wartościowe z punktu widzenia LLM-a.

Nie, wydaje mi się, że junior nie byłby w stanie tego tak zrobić w taki sposób, jak to jest teraz zrobione, bo jednak LLM-y naprawdę dobrze potrafią kategoryzować.

Ten LLM też nam się w którymś momencie może zgubić.

Bo też jest taki problem, jak robimy te transkrypcje tych spotkań i próbujemy z nich wyciągnąć rzeczy, to jest to, żeby też LLM się domyślił to, które w trakcie tego spotkania się zmieniły.

Więc ja tak mam, że na samym końcu robię takie, za LLM-a robię pewnego rodzaju podsumowanie, żeby potem zwrócić uwagę, że skup się na tej końcówce, bo tam są jakby te ostateczne decyzje, a następnie uzupełnić to tylko informacjami, które były jakby wypowiedziane we wcześniejszych częściach tego spotkania.

I potrafisz to wyciągnąć dobrze, to wyciągnięcie tego i wrzucenie tego do LLM-a powoduje, że on naprawdę zaczyna ci dawać fajne rezultaty.

Ja bym jeszcze wrócił do tego, co ty Łukasz powiedziałeś a propos tych podsumowań robionych dla LLM-a.

Dobre, żeby sobie tak faktycznie podsumować, ok, tak to rozumiemy, wszyscy się do tego zgadzają i nam to układa w głowie, a jednocześnie super ułatwia wyciąganie czegoś automatem, bo robimy tę robotę z LLM-a, on się nie musi domyślać, a dyskusje, no wiadomo, bywają burzliwe, w związku z tym to nie jest proste podsumowanie tekstu, tak, to nie jest dobrze napisany artykuł, który wystarczy zrobić z niego podsumowanie, z czym LLM-y sobie radzą świetnie.

Ten board, który mamy, na którym są te wszystkie nasze karteczki, nie wiem, może taski, rysunki i tak dalej, on się staje wejściem dla LLM, a on jest tym kontekstem.

Bo to będzie tak szczegółowe, że będzie pozwalało wykonać ten kod, tylko że w tym momencie chyba nie będzie nam tam potrzebny LLM, tylko kompilator, który zrobi to deterministycznie.

I tam LLM nie jest potrzebny.

Nie bardzo wierzę w to, że specyfikacje, które potem są za każdym razem LLMem przekładane na system, to jest rozwiązanie naszych problemów.

I moim zdaniem, to jest trochę podobnie jak Marcin, ja uważam, że nie dojdziemy do czegoś takiego, że specyfikacja będzie czymś wystarczającym, bo to by znaczyło, że tak, że pod spodem nie potrzebujemy LLM-a, który ją przełoży, tylko potrzebujemy czegoś deterministycznego, co pewnie mniej tokenów, skoro jesteśmy w stanie to zrobić w ten sposób, że musimy zmodyfikować trochę to podejście spec-driven, bo rzeczywiście zawsze wymagania były potrzebne, zawsze mieliśmy jakąś spec-kę.

I niestety dzisiejszy sposób korzystania z LLM-ów zabija moim zdaniem właśnie ten ostatni element, czyli tę pętlę zwrotną, którą ja dostaję

Albo klikam dalej, dalej, dalej, tak, pozwalam, pozwalam, pozwalam, aż mi tam ten LLM coś wygeneruje, a później mam bardzo dużego kodu i moje review polega na tym, że looks good to me.

Więc jeżeli mówię, że coraz lepiej będą generowały ten kod, LLM-y za nas, to z jednej strony to dobrze, ale z drugiej strony musimy wymyślić nowy sposób, żeby te cykle, te pętle feedbackowe, żeby one cały czas w tym naszym programowaniu były.

No bo ten LLM będzie się docelował, jeżeli dostanie tylko taką, że tak powiem, gołą speckę, która nie...

To samo będzie wtedy z takimi LLM-ami, w sensie z takimi projektami, które wychodzą spod ręki LLM-a.

Wydaje mi się, że LLM to nie powinno być narzędzie, które ma nas w stu procentach zastąpić, czy które ma stworzyć jakąś dodatkową warstwę abstrakcji, tylko to jest narzędzie, które ma nas wspomagać na każdym etapie, ale ciągle na każdym etapie nasze tutaj myślenie jest potrzebne.

Jesteśmy skazani na to, że no to LLM nam powie, LLM poprawi i potem co?

No właśnie, bo pojawia się coraz więcej, przynajmniej w moim feedzie na LinkedInie, takich postów, które właśnie mówią, że no właśnie, że ten clean code już nie jest taki istotny, że teraz jak już LLM-y produkują kod i LLM-y go czytają, to już nie musimy optymalizować kodu pod czytelność czy pod zrozumiałość.

Pytanie, czy jak on jest nieczytelny dla nas, to jest czytelny dla LLM-a.

On się znajdzie w kontekście LLM-a przy kolejnym naszym prompcie, przy kolejnej próbie wygenerowania czegoś.

Że zrobić sobie takie ćwiczenie myślowe, jak powinien wyglądać kod, który właśnie będzie, tak jak ty Marcin powiedziałeś, który będzie optymalnym kontekstem dla LLM-a, który go analizuje.

Szczególnie, że to już nie my piszemy ten kod, tylko ten kod jest pisany przez LLM, a my mu raczej mówimy, co tam będzie ewentualnie poprawiamy.

Ja już trochę, że tak powiem, wybiegam w przyszłość, jak już te LLM będą jeszcze lepsze.

LLM nie ma tej wiedzy.

Dla LLM-a może trochę więcej.

Więc im ja mam lepszy kod, im bardziej ustrukturyzowany poprawnie tak, żeby on był zrozumiały, tym lepsze odpowiedzi z tego LLM będę miał.

Największy sukces, ale nie sukces właśnie OpenAI, najlepszy tam LLM czy Anthropic, najlepszy model do kodowania, tylko te firmy, które używając AI były w stanie usprawnić procesy i usprawnić pracę czy działalność operacyjną rzeczywistych firm.

Ten kontekst, jeszcze lepsze informacje na wejściu do LLM-a, jak on ma coś wygenerować, że to nie jest już po prostu tylko jakaś tam słowno-muzyczny opis, tylko szereg ustrukturyzowanych różnych artefaktów, które po drodze powstały.

Ale na razie jakbyśmy się ograniczyli do tego, żeby jakiś przykład dać do tego aspektu domenowego, to jeżeli będziemy mieli ustrukturyzowany zestaw building blocków, którymi modelujemy, to on może być na wejściu, czyli możemy to dostarczyć LLM-owi do zakodowania, a potem jesteśmy w stanie przeanalizować kod

I to najlepiej deterministycznie, a nie LLM-em, żeby on nie był sędzią we własnej sprawie, tylko deterministycznie wyciągnąć te rzeczy, bo teraz jeżeli to będzie robił LLM, to on może się trzymać pewnych konwencji, co nam dużo ułatwi wyciąganie potem w deterministyczny sposób tego modelu domenowego z kodu i możemy sobie porównać.

To jeżeli mamy dobrą definicję właśnie tych rodzajów reguł i potrafimy wziąć tą regułę, dać ją LLM-owi i powiedzieć, ej, LLM jest kategoryzujący, mi tą regułę, do której ono tutaj grupy należy, to jak on już ją potrafi dobrze skategoryzować, a potrafi to robić, i później wiemy, a, a tego typu reguły to zamina tego rodzaju elementy konstrukcyjne, bo na przykład jak masz reguły wyliczeniowe, to to prawdopodobnie będzie jakaś strategia czy polityka, a jak masz reguły spójności, to to prawdopodobnie