Analiza i projektowanie aplikacji z wykorzystaniem LLM

Czym jest SDLC i z jakich faz się składa?

SDLC (Software Development Life Cycle), czyli cykl życia oprogramowania, to odpowiedź na jedno z podstawowych pytań stawianych w czasie wytwarzania oprogramowania: jak podzielić prace na etapy i jak je zorganizować? Model cyklu życia wprowadza fazy, określa czynności wykonywane w każdej z nich, ustala kolejność ich realizacji oraz produkty, które po każdej fazie powinny zostać.

Po co to wszystko? Model cyklu życia porządkuje przebieg prac, ułatwia planowanie zadań i monitorowanie ich realizacji. Ma to szczególne znaczenie wtedy, gdy projekt realizuje zespół, a nie pojedyncza osoba. Jeśli dopiero zaczynasz pracę w branży, potraktuj SDLC jak mapę. W każdej chwili powinieneś wiedzieć, w którym miejscu jesteś, co już powstało i co musi powstać, zanim pójdziesz dalej. Przykład takiej metodyki dotyczącej pierwszych faz SDLC można znaleźć na stronie: Metodyka projektowania oprogramowania. Wracając do tematu.

W przedstawianym „książkowym” podejściu do procesu wytwórczego wyróżniam następujące fazy:

1. Inicjacja – określamy cele biznesowe, ograniczenia, budżet, ramowy harmonogram i ryzyka. Tu zapada decyzja, czy projekt w ogóle ruszy.
2. Określenie wymagań – wspólnie z klientem konstruujemy zbiór wymagań zgodny z celami z fazy inicjacji. Zanim powstaną wymagania systemowe, przygotowuję koncepcję rozwiązania, w której procesy biznesowe „układają się” z architekturą.
3. Analiza – budujemy model logiczny systemu. Odpowiadamy na pytanie „co” system ma robić, a nie „jak”.
4. Projektowanie – opracowujemy szczegółowy opis implementacji: architekturę, interfejsy, model danych, wzorce.
5. Implementacja – kodujemy model projektowy w wybranym języku programowania.
6. Testowanie – sprawdzamy poprawność działania systemu i szukamy możliwie wielu błędów.
7. Wdrożenie – uruchamiamy system u klienta, migrujemy dane, szkolimy użytkowników.
8. Konserwacja – usuwamy błędy i dostosowujemy system do zmian prawnych oraz organizacyjnych.
9. Dokumentowanie – towarzyszy wszystkim fazom i pozwala śledzić oraz kontrolować podejmowane działania.

Fazy te nie muszą występować sekwencyjnie. Moim zdaniem dobra metodyka wytwarzania oprogramowania powinna być iteracyjna, czyli przyrostowo dostarczać produkty poszczególnych faz i pozwalać wracać do wcześniejszych etapów. Iteracyjność procesu wytwórczego to podstawa.

Gdzie w tym wszystkim jest miejsce na LLM?

Duże modele językowe (LLM, Large Language Models) dobrze radzą sobie z tym, co w pracy analityka i projektanta zajmuje najwięcej czasu, czyli z tekstem. Streszczają, porządkują, zadają pytania, proponują warianty i zamieniają opis słowny na notację. Nie zmienia to faktu, że zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle. LLM traktuję jako kolejne narzędzie wzmacniające pamięć i wyobraźnię, obok notacji i narzędzi CASE.

W dalszej części tekstu przechodzę przez wszystkie fazy i do każdej proponuję co najmniej dwa zastosowania LLM, z przykładowymi promptami i wynikami.

Jeden przykład na cały tekst: wypożyczalnia pojazdów

Wszystkie prompty w tym tekście dotyczą jednego, fikcyjnego projektu: aplikacji do rezerwacji online dla wypożyczalni pojazdów „Trasa”. Przykład jest celowo prosty, bo prawie każdy z nas kiedyś wypożyczał samochód i rozumie, o co w tym biznesie chodzi.

Zanim zadam modelowi jakiekolwiek pytanie, przygotowuję krótką kartę projektu. Wklejam ją na początku rozmowy albo zapisuję jako stały kontekst, żeby nie powtarzać jej w każdym prompcie:

KONTEKST PROJEKTU
Firma: wypożyczalnia pojazdów „Trasa”, 3 oddziały (Warszawa, Kraków, Gdańsk),
120 pojazdów osobowych i dostawczych.
Stan obecny: rezerwacje przyjmowane telefonicznie i mailowo, dostępność pojazdów
prowadzona w arkuszu Excel osobno w każdym oddziale, umowy drukowane
i podpisywane na miejscu.
Problemy: podwójne rezerwacje tego samego pojazdu, średnio 15 minut pracy
pracownika na jedną rezerwację, brak sprzedaży poza godzinami pracy oddziałów.
Pomysł: aplikacja internetowa do rezerwacji online z płatnością
i panelem dla pracowników oddziałów.
Ograniczenia: budżet 400 tys. zł, uruchomienie do 1 czerwca (przed sezonem letnim),
jeden informatyk w firmie, obecny system księgowy musi pozostać.

Dobry prompt analityczny ma u mnie zawsze pięć elementów:

• rolę – kim ma być model (analityk biznesowy, architekt, tester),
• kontekst – kartę projektu i artefakty z poprzednich faz,
• zadanie – jedno, konkretne, z nazwanym produktem,
• format wyniku – tabela, lista, PlantUML, Gherkin,
• zastrzeżenie – „nie zgaduj, brakujące informacje oznacz jako pytania”.

Ten ostatni element jest najważniejszy. Model, któremu nie pozwolisz powiedzieć „nie wiem”, wypełni luki zmyśleniami.

Pokazane niżej wyniki to przykładowe odpowiedzi modelu. Twój model może odpowiedzieć inaczej, a ten sam prompt uruchomiony dwa razy da dwa nieco różne wyniki.

Faza inicjacji

W fazie inicjacji LLM pomaga przede wszystkim nazwać cel i zobaczyć ryzyka, zanim wydamy pierwszą złotówkę. To faza, o której w praktyce często się zapomina, a w której zapadają jedne z najważniejszych decyzji.

Zastosowanie 1: doprecyzowanie celu i potrzeb biznesowych

Klient rzadko przychodzi z celem zgodnym z koncepcją SMART. Częściej przychodzi z rozwiązaniem („chcemy aplikację”). Model dobrze sprawdza się jako partner, który pomaga cofnąć się od rozwiązania do problemu.

Prompt:

Jesteś analitykiem biznesowym. Na podstawie kontekstu projektu:
1. Zaproponuj cel biznesowy zgodny z koncepcją SMART.
2. Zaproponuj potrzeby biznesowe, które opisują problem, a nie sposób rozwiązania.
3. Wypisz pytania, które muszę zadać sponsorowi, zanim uznam cel za ustalony.
Nie zgaduj brakujących liczb. Oznacz je jako „do potwierdzenia”.

Wynik:

Cel biznesowy: w ciągu 12 miesięcy od uruchomienia 40% rezerwacji klienci składają samodzielnie online (poziom 40% do potwierdzenia), a średni czas pracy pracownika na jedną rezerwację spada z 15 do 5 minut.

Potrzeby biznesowe:

• PB1: wyeliminowanie podwójnych rezerwacji tego samego pojazdu,
• PB2: ograniczenie ręcznej pracy pracowników przy przyjmowaniu rezerwacji,
• PB3: umożliwienie klientom rezerwacji poza godzinami pracy oddziałów.

Pytania do sponsora:

1. Ile rezerwacji miesięcznie obsługuje dziś każdy oddział i ile z nich to podwójne rezerwacje?
2. Kto jest właścicielem procesu rezerwacji: jedna osoba czy kierownik każdego oddziału?
3. Czy 1 czerwca to termin nieprzekraczalny, czy pożądany?
4. Czy zmiana obejmuje klientów firmowych z umowami ramowymi?
5. Jak dziś mierzony jest czas obsługi rezerwacji i kto potwierdzi wartość 15 minut?

Zwróć uwagę na dwie rzeczy. Model poprawnie odróżnił potrzebę od rozwiązania, ale wartości 40% nie zna i znać nie może. To decyzja sponsora, a pytania z listy trzeba zadać człowiekowi.

Zastosowanie 2: wstępny rejestr ryzyk

Rejestr ryzyk powstaje w fazie inicjacji i jest utrzymywany przez cały cykl życia projektu. LLM przydaje się tu jako generator punktu wyjścia, szczególnie gdy brakuje Ci doświadczenia z podobnych projektów.

Prompt:

Jesteś kierownikiem projektu. Na podstawie kontekstu projektu przygotuj wstępny
rejestr ryzyk. Dla każdego ryzyka podaj: opis, prawdopodobieństwo (N/Ś/W),
wpływ (N/Ś/W) i proponowaną mitygację. Uwzględnij ograniczenia z karty projektu.
Wynik podaj w tabeli. Maksymalnie 5 najważniejszych ryzyk.

Wynik:

ID	Ryzyko	Prawd.	Wpływ	Mitygacja
R1	Niedotrzymanie terminu 1 czerwca; start po sezonie obniża korzyści	Ś	W	Zakres minimalny na start (rezerwacja i płatność), reszta w kolejnych iteracjach
R2	Niska jakość danych o flocie w trzech osobnych arkuszach Excel	W	Ś	Porządkowanie danych przed migracją, jeden właściciel danych
R3	Integracja z systemem księgowym okaże się trudniejsza od założeń	Ś	W	Analiza interfejsów systemu księgowego już w koncepcji rozwiązania
R4	Jeden informatyk w firmie jako wąskie gardło odbiorów i utrzymania	W	Ś	Umowa utrzymaniowa z wykonawcą, dokumentacja administratora
R5	Pracownicy oddziałów będą nadal prowadzić Excela równolegle	Ś	Ś	Szkolenia, wyłączenie arkuszy w ustalonym dniu, wsparcie kierowników

W tej fazie model pomoże też przygotować szkic uzasadnienia biznesowego. Koszty i korzyści musisz jednak podać sam, bo ich wyliczenie przez model to zgadywanie.

Koncepcja rozwiązania

Koncepcja rozwiązania to pomost między wizją biznesową a analizą systemową, a LLM pomaga tu ocenić dokumenty wejściowe i szybko naszkicować procesy AS-IS oraz TO-BE. Jak sobie pościelesz, tak się wyśpisz, więc warto poświęcić temu etapowi czas.

Zastosowanie 1: ocena jakości dokumentów wejściowych

Pierwszy krok koncepcji to analiza artefaktów wejściowych. Sprawdzam, czy potrzeby mają właścicieli, czy cel jest SMART i czy potrzeba opisuje problem, a nie rozwiązanie. To praca według listy kontrolnej, czyli dokładnie taka, w której model jest cierpliwszy od człowieka.

Prompt:

Jesteś analitykiem. Oceń poniższy fragment dokumentu Wizja według kryteriów:
1. Czy potrzeby biznesowe odnoszą się do konkretnych procesów biznesowych?
2. Czy potrzeby biznesowe mają właścicieli?
3. Czy cel jest zgodny z koncepcją SMART?
4. Czy potrzeby opisują problem lub możliwość, a nie sposób rozwiązania?
Dla każdego kryterium podaj ocenę (spełnione / częściowo / niespełnione)
i uzasadnienie z cytatem z dokumentu.

Fragment dokumentu:
„Celem projektu jest wdrożenie nowoczesnej aplikacji mobilnej do rezerwacji.
Potrzeba: klienci chcą aplikacji. Projekt powinien zakończyć się jak najszybciej.”

Wynik:

Kryterium	Ocena	Uzasadnienie
Odniesienie do procesów	Niespełnione	Dokument nie wymienia żadnego procesu, np. rezerwacji, wydania czy zwrotu pojazdu
Właściciele potrzeb	Niespełnione	„Klienci chcą aplikacji” nie wskazuje osoby reprezentującej beneficjentów zmiany
Cel SMART	Niespełnione	„Jak najszybciej” nie jest terminem, brak miary sukcesu
Problem, a nie rozwiązanie	Niespełnione	„Wdrożenie aplikacji mobilnej” to rozwiązanie; problem (np. podwójne rezerwacje) nie został nazwany

Rekomendacja modelu: dokument skierować do uzupełnienia. Zgadzam się z nią, ale decyzję o zwrocie dokumentu podejmuje analityk, nie model.

Zastosowanie 2: szkic procesu AS-IS i TO-BE z notatek

Po rozmowie z kierownikiem oddziału zostają mi zwykle chaotyczne notatki. Model potrafi zamienić je w uporządkowany opis procesu, który potem przenoszę do notacji BPMN w narzędziu CASE.

Prompt:

Jesteś analitykiem procesów biznesowych. Z poniższych notatek ze spotkania
przygotuj opis procesu „Rezerwacja pojazdu” w stanie AS-IS: kroki, wykonawca
każdego kroku, używane narzędzie. Następnie zaproponuj proces TO-BE realizujący
potrzeby PB1–PB3 i wskaż, które kroki znikają, a które się zmieniają.
Oznacz miejsca, w których notatki są niejednoznaczne.

Notatki: „Klient dzwoni albo pisze maila. Pani Ania sprawdza w Excelu, czy auto
jest wolne. Jak jest, to wpisuje klienta i oddzwania. Czasem ktoś z Krakowa wpisze
to samo auto, bo było przestawione. Zaliczka przelewem, czekamy na potwierdzenie
z księgowości. Umowa drukowana przy odbiorze.”

Wynik:

Proces AS-IS:

1. Klient zgłasza chęć rezerwacji (telefon lub e-mail).
2. Pracownik oddziału sprawdza dostępność pojazdu w arkuszu Excel oddziału.
3. Pracownik wpisuje rezerwację do arkusza i potwierdza ją klientowi telefonicznie.
4. Klient wpłaca zaliczkę przelewem.
5. Księgowość potwierdza wpływ zaliczki (system księgowy).
6. Pracownik drukuje umowę przy odbiorze pojazdu.

Proces TO-BE:

1. Klient wybiera oddział, termin i klasę pojazdu w aplikacji.
2. System pokazuje dostępne pojazdy na podstawie jednej, wspólnej bazy floty (realizuje PB1).
3. Klient podaje dane i płaci zaliczkę online (realizuje PB3).
4. System potwierdza rezerwację e-mailem i przekazuje informację o płatności do systemu księgowego (realizuje PB2).
5. Pracownik widzi rezerwację w panelu i przygotowuje pojazd.
6. Umowa generowana jest z systemu przy odbiorze.

Zmiany: kroki 2, 3 i 5 z AS-IS przestają być wykonywane ręcznie. Krok 6 się zmienia.

Niejednoznaczności: nie wiadomo, co oznacza „auto było przestawione” (przeniesienie pojazdu między oddziałami?). Nie wiadomo, czy zaliczka jest obowiązkowa dla każdego klienta ani co się dzieje, gdy zaliczka nie wpłynie.

Ostatni akapit jest dla mnie najcenniejszy. Pytanie o przenoszenie pojazdów między oddziałami prowadzi wprost do przyczyny podwójnych rezerwacji. Model TO-BE i tak muszę uzgodnić z właścicielem biznesowym procesu, bo to on odpowiada za sposób jego zorganizowania.

Określenie wymagań

W fazie wymagań LLM najlepiej sprawdza się w dwóch rolach: jako pomocnik przy zamianie wymagań biznesowych na systemowe oraz jako tropiciel wyjątków i przypadków granicznych. Pamiętaj, że określanie wymagań to nie proste zbieranie, lecz proces konstruowania ich wspólnie z klientem. Tego dialogu model nie zastąpi.

Zastosowanie 1: wymagania systemowe z mapowaniem na wymagania biznesowe

Prompt:

Jesteś analitykiem systemowym. Na podstawie procesu TO-BE „Rezerwacja pojazdu”
i potrzeb biznesowych PB1–PB3 przygotuj listę wymagań funkcjonalnych (WF)
i niefunkcjonalnych (WNF). Każde wymaganie ma mieć: identyfikator, treść
w formie „System powinien…”, powiązaną potrzebę biznesową oraz kryterium
weryfikacji. Wymagania opisują zewnętrzne zachowanie systemu, nie sposób
realizacji. Wartości liczbowe, których nie znasz, oznacz „do ustalenia”.

Wynik:

ID	Wymaganie	Potrzeba	Kryterium weryfikacji
WF-01	System powinien prezentować pojazdy dostępne w wybranym oddziale i terminie	PB1, PB3	Pojazd z rezerwacją w danym terminie nie pojawia się na liście
WF-02	System powinien uniemożliwić zarezerwowanie pojazdu na termin pokrywający się z inną rezerwacją	PB1	Druga próba rezerwacji tego samego pojazdu kończy się komunikatem o braku dostępności
WF-03	System powinien umożliwić opłacenie zaliczki online	PB3	Po poprawnej płatności rezerwacja ma status „Potwierdzona”
WF-04	System powinien wysyłać klientowi potwierdzenie rezerwacji e-mailem	PB2	E-mail zawiera numer rezerwacji, termin, oddział i klasę pojazdu
WF-05	System powinien udostępniać pracownikowi listę rezerwacji jego oddziału	PB2	Pracownik widzi wyłącznie rezerwacje swojego oddziału
WF-06	System powinien przekazywać informację o płatności do systemu księgowego	PB2	Każda płatność ma odpowiadający zapis w systemie księgowym
WNF-01	Lista dostępnych pojazdów wyświetla się w czasie do ustalenia (propozycja: 2 s)	PB3	Pomiar przy obciążeniu do ustalenia
WNF-02	System jest dostępny dla klientów całą dobę, przerwy serwisowe w nocy	PB3	Dostępność miesięczna do ustalenia
WNF-03	Dane osobowe klientów są przetwarzane zgodnie z RODO	wszystkie	Przegląd z inspektorem ochrony danych

Taka tabela to dobry materiał na warsztat z klientem. Mapowanie na potrzeby biznesowe pozwala od razu sprawdzić, czy każda potrzeba jest adresowana i czy nie pojawiło się wymaganie, które nie służy żadnemu celowi.

Zastosowanie 2: przypadek użycia ze scenariuszami alternatywnymi

Jednym z najbardziej typowych błędów w tej fazie jest koncentrowanie się na sytuacjach typowych i pomijanie wyjątków. Zarówno użytkownicy, jak i analitycy mają tendencję do niezauważania sytuacji skrajnych. Model nie ma tego problemu, jeśli go o wyjątki wyraźnie poprosisz.

Prompt:

Jesteś analitykiem systemowym. Opracuj specyfikację przypadku użycia
„Zarezerwuj pojazd” realizującego wymagania WF-01 do WF-04. Podaj: identyfikator,
nazwę, aktorów, opis, warunki wstępne, warunki końcowe, scenariusz główny
oraz scenariusze alternatywne i wyjątki. Zwróć szczególną uwagę na przypadki
graniczne. Na końcu wypisz pytania do klienta.

Wynik:

• Identyfikator: PU-01
• Nazwa: Zarezerwuj pojazd
• Aktorzy: Klient (główny), System płatności, System księgowy
• Opis: Klient samodzielnie rezerwuje pojazd na wybrany termin i opłaca zaliczkę.
• Warunki wstępne: W wybranym oddziale istnieje co najmniej jeden aktywny pojazd.
• Warunki końcowe: Rezerwacja ma status „Potwierdzona”, pojazd jest zablokowany na wybrany termin, klient otrzymał potwierdzenie.

Scenariusz główny:

1. Klient wybiera oddział, datę i godzinę odbioru oraz zwrotu.
2. System prezentuje dostępne klasy pojazdów wraz z ceną.
3. Klient wybiera klasę pojazdu.
4. Klient podaje dane osobowe i dane prawa jazdy.
5. System prezentuje podsumowanie i kwotę zaliczki.
6. Klient akceptuje regulamin i przechodzi do płatności.
7. System płatności potwierdza płatność.
8. System zapisuje rezerwację jako „Potwierdzona” i wysyła e-mail z potwierdzeniem.
9. System przekazuje informację o płatności do systemu księgowego.

Scenariusze alternatywne i wyjątki:

• 2a. Brak dostępnych pojazdów: system proponuje inny oddział lub najbliższy wolny termin.
• 1a. Data zwrotu wcześniejsza niż data odbioru lub termin w przeszłości: system wyświetla komunikat i nie przechodzi dalej.
• 6a. W czasie wypełniania formularza inny klient zarezerwował ostatni pojazd z klasy: system informuje o braku dostępności i wraca do kroku 2.
• 7a. Płatność odrzucona: rezerwacja pozostaje w statusie „Oczekuje na płatność”, klient może ponowić płatność.
• 7b. Brak płatności w czasie do ustalenia: system anuluje rezerwację i zwalnia pojazd.
• 9a. System księgowy niedostępny: system ponawia przekazanie później; rezerwacja pozostaje potwierdzona.

Pytania do klienta:

1. Na jak długo system blokuje pojazd w oczekiwaniu na płatność?
2. Czy klient rezerwuje konkretny pojazd, czy klasę pojazdu?
3. Czy odbiór i zwrot mogą nastąpić w różnych oddziałach?
4. Ile czasu potrzeba na przygotowanie pojazdu między zwrotem a kolejnym wydaniem?
5. Jakie są warunki dotyczące wieku kierowcy i stażu prawa jazdy?

Scenariusz 6a to klasyczny przypadek, który umyka na warsztatach. Pytanie 2 dotyczy z kolei decyzji, która zmienia cały model dziedziny. Trzecim zastosowaniem, z którego korzystam regularnie, jest przegląd gotowej listy wymagań pod kątem sprzeczności i niejednoznacznych sformułowań typu „szybko” czy „intuicyjnie”.

Analiza

W fazie analizy LLM przyspiesza budowę modelu analitycznego: z wymagań i przypadków użycia przygotowuje szkic modelu dziedziny oraz modeli zachowania. Model analityczny odpowiada na pytanie „co system ma robić” i abstrahuje od szczegółów implementacji. Warto to modelowi napisać wprost, bo ma on skłonność do przedwczesnego wchodzenia w technologię.

Zastosowanie 1: szkic modelu dziedziny

Proszę model o wynik w notacji tekstowej PlantUML. Taki zapis mogę od razu wyrenderować, a potem przenieść do repozytorium w narzędziu CASE.

Prompt:

Jesteś analitykiem systemowym. Na podstawie przypadku użycia PU-01 i wymagań
WF-01 do WF-06 przygotuj model dziedziny jako diagram klas w PlantUML.
To model analityczny: tylko klasy biznesowe, najważniejsze atrybuty, powiązania
i liczności. Bez typów danych, kluczy, metod i szczegółów technicznych.
Pod diagramem wypisz założenia, które przyjąłeś.

Wynik:

@startuml
class Klient {
  imię i nazwisko
  e-mail
  telefon
  numer prawa jazdy
}
class Rezerwacja {
  numer
  termin odbioru
  termin zwrotu
  status
  kwota zaliczki
}
class KlasaPojazdu {
  nazwa
  cena za dobę
}
class Pojazd {
  numer rejestracyjny
  marka i model
  status
}
class Oddział {
  nazwa
  adres
}
class Płatność {
  kwota
  data
  status
}
class Umowa {
  numer
  data zawarcia
}

Klient "1" -- "0..*" Rezerwacja : składa
Rezerwacja "0..*" -- "1" KlasaPojazdu : dotyczy
Rezerwacja "0..*" -- "0..1" Pojazd : ma przydzielony
Pojazd "0..*" -- "1" KlasaPojazdu : należy do
Pojazd "0..*" -- "1" Oddział : stacjonuje w
Rezerwacja "0..*" -- "1" Oddział : odbiór w
Rezerwacja "1" -- "0..*" Płatność : opłacana przez
Rezerwacja "1" -- "0..1" Umowa : skutkuje
@enduml

Założenia modelu:

• Klient rezerwuje klasę pojazdu, a konkretny pojazd przydziela pracownik przed wydaniem.
• Odbiór i zwrot następują w tym samym oddziale.
• Jedna rezerwacja może mieć kilka płatności (zaliczka, dopłata).

Najważniejsza jest tu lista założeń. Każde z nich to decyzja biznesowa, którą model podjął za klienta. Moim zadaniem jest zamienić je z powrotem w pytania i potwierdzić z właścicielem procesu. Trzecia zasada modelowania mówi, że model powinien być zgodny z rzeczywistością, a tę zna klient, nie LLM.

Zastosowanie 2: stany rezerwacji i wykrywanie luk

Diagram stanów to jeden z artefaktów, przy którym najłatwiej znaleźć brakujące wymagania. Proszę model o tabelę przejść, bo łatwiej ją przejrzeć z klientem niż rysunek.

Prompt:

Jesteś analitykiem systemowym. Na podstawie PU-01 opisz cykl życia obiektu
Rezerwacja jako tabelę przejść: stan, zdarzenie, warunek, stan następny.
Następnie wskaż sytuacje biznesowe, których obecne wymagania nie obsługują.

Wynik:

Stan	Zdarzenie	Warunek	Stan następny
(początek)	Klient zatwierdza formularz	Pojazd z klasy jest dostępny	Oczekuje na płatność
Oczekuje na płatność	Płatność potwierdzona	–	Potwierdzona
Oczekuje na płatność	Upłynął czas na płatność	Limit czasu do ustalenia	Anulowana
Potwierdzona	Klient anuluje rezerwację	Przed terminem odbioru	Anulowana
Potwierdzona	Pracownik wydaje pojazd	Umowa podpisana	W realizacji
Potwierdzona	Klient nie zgłosił się po pojazd	Czas oczekiwania do ustalenia	Niezrealizowana
W realizacji	Pracownik przyjmuje zwrot	–	Zakończona

Luki wskazane przez model:

• brak wymagań dotyczących zwrotu zaliczki przy anulowaniu,
• brak obsługi zmiany terminu potwierdzonej rezerwacji,
• brak obsługi przedłużenia najmu w trakcie jego trwania,
• brak reguł dla zwrotu pojazdu po terminie, co wpływa na dostępność dla kolejnego klienta.

W ten sposób jedna tabela wygenerowała cztery tematy na kolejne spotkanie z klientem. To dobry przykład iteracyjności: analiza odsyła nas z powrotem do wymagań.

Projektowanie

W fazie projektowania LLM pomaga porównać warianty architektury i udokumentować decyzje projektowe w UML. Model projektowy odpowiada na pytanie „jak” i jest ściśle związany ze środowiskiem implementacji. Dużą rolę odgrywają tu wymagania niefunkcjonalne oraz kompromisy między nimi.

Zastosowanie 1: warianty architektury i kompromisy

Dobrą praktyką jest przygotowanie dwóch wariantów rozwiązania. Model przygotuje je w kilka minut, pod warunkiem że dostanie ograniczenia projektu.

Prompt:

Jesteś architektem IT. Dla systemu rezerwacji wypożyczalni „Trasa” porównaj dwa
warianty architektury: modularny monolit oraz mikrousługi. Uwzględnij ograniczenia
z karty projektu (termin 1 czerwca, budżet 400 tys. zł, jeden informatyk)
oraz wymagania WF-02, WNF-01 i WNF-02. Wynik podaj w tabeli z kryteriami
i zakończ rekomendacją z uzasadnieniem. Wskaż, czego nie wiesz.

Wynik:

Kryterium	Modularny monolit	Mikrousługi
Czas do uruchomienia	Krótszy: jedno wdrożenie, jedna baza	Dłuższy: infrastruktura, komunikacja między usługami
Ochrona przed podwójną rezerwacją (WF-02)	Prosta: sprawdzenie i blokada w jednej transakcji bazy	Trudniejsza: spójność między usługami wymaga dodatkowych mechanizmów
Utrzymanie przez jednego informatyka	Realne	Mało realne bez zespołu utrzymaniowego
Skalowalność	Wystarczająca dla 120 pojazdów i 3 oddziałów	Wysoka, lecz niewykorzystana przy tej skali
Koszt infrastruktury	Niższy	Wyższy
Rozbudowa w przyszłości	Moduły (rezerwacje, flota, płatności) można później wydzielić	Gotowa od początku

Rekomendacja: modularny monolit z wyraźnym podziałem na moduły Rezerwacje, Flota, Płatności i Integracja księgowa. Przy tej skali działalności i jednym informatyku mikrousługi podnoszą koszt oraz ryzyko terminu, nie dając korzyści.

Czego nie wiem: jaki interfejs udostępnia system księgowy, jaki jest spodziewany ruch w sezonie i czy firma planuje ekspansję na kolejne oddziały.

Rekomendacja jest rozsądna, ale to architekt bierze za nią odpowiedzialność. Model nie zna Twojej organizacji, kompetencji zespołu ani umów z dostawcami.

Zastosowanie 2: diagram sekwencji dokumentujący decyzje projektowe

Najważniejsze jest, aby w języku UML doprecyzować architekturę, interfejsy oraz sekwencje komunikatów pomiędzy komponentami. Diagram sekwencji w PlantUML model generuje sprawnie.

Prompt:

Jesteś projektantem systemu. Dla wariantu „modularny monolit” przygotuj diagram
sekwencji w PlantUML dla scenariusza głównego PU-01 wraz z wyjątkiem 6a
(brak dostępności w chwili zatwierdzenia). Uczestnicy: Klient, Aplikacja web,
Moduł rezerwacji, Baza danych, Bramka płatności, System księgowy.
Pod diagramem wypisz decyzje projektowe, które z niego wynikają.

Wynik:

@startuml
actor Klient
participant "Aplikacja web" as Web
participant "Moduł rezerwacji" as Rez
database "Baza danych" as DB
participant "Bramka płatności" as Pay
participant "System księgowy" as Ksi

Klient -> Web : zatwierdza rezerwację
Web -> Rez : utwórzRezerwację(oddział, termin, klasa, klient)
Rez -> DB : sprawdź dostępność i zablokuj pojazd (jedna transakcja)
alt pojazd dostępny
  DB --> Rez : blokada założona
  Rez --> Web : rezerwacja „Oczekuje na płatność”
  Web -> Pay : zainicjuj płatność zaliczki
  Pay --> Klient : formularz płatności
  Klient -> Pay : płaci
  Pay -> Rez : powiadomienie o wyniku płatności
  Rez -> DB : zmień status na „Potwierdzona”
  Rez -> Klient : e-mail z potwierdzeniem
  Rez ->> Ksi : informacja o płatności (asynchronicznie)
else brak dostępności
  DB --> Rez : brak wolnych pojazdów
  Rez --> Web : komunikat o braku dostępności
end
@enduml

Decyzje projektowe:

• Sprawdzenie dostępności i blokada pojazdu odbywają się w jednej transakcji bazy danych (realizacja WF-02).
• Wynik płatności przychodzi jako powiadomienie z bramki, a nie z przeglądarki klienta.
• Komunikacja z systemem księgowym jest asynchroniczna, z ponawianiem (realizacja wyjątku 9a).

Taka dokumentacja pozwala po roku szybko odświeżyć wiedzę o sposobie działania rozwiązania. W fazie projektowania korzystam z LLM także przy szkicu logicznego modelu danych i kontraktów interfejsów. Zawsze sprawdzam wtedy zgodność z modelem dziedziny, bo niewielkie zmiany w dziedzinie powinny oznaczać niewielkie zmiany w projekcie.

Implementacja

W fazie implementacji analityk i projektant używają LLM głównie do dwóch rzeczy: do przełożenia projektu na zadania programistyczne oraz do sprawdzenia, czy kod jest zgodny z wymaganiami. O generowaniu kodu przez modele napisano już bardzo wiele, dlatego skupiam się na styku analizy i programowania.

Zastosowanie 1: zadania programistyczne z kryteriami akceptacji

Prompt:

Jesteś analitykiem pracującym z zespołem programistów. Na podstawie PU-01,
tabeli stanów rezerwacji i decyzji projektowych rozpisz realizację wymagania
WF-02 na zadania programistyczne. Każde zadanie: tytuł, krótki opis, powiązane
wymaganie, kryteria akceptacji. Nie dodawaj funkcji spoza wymagań.

Wynik:

Zadanie 1: Blokada pojazdu przy tworzeniu rezerwacji (WF-02)

Sprawdzenie dostępności i założenie blokady w jednej transakcji bazy danych. Kryteria akceptacji:

• dwie równoczesne próby rezerwacji ostatniego pojazdu z klasy kończą się jedną rezerwacją i jednym komunikatem o braku dostępności,
• rezerwacje w statusie „Anulowana” i „Niezrealizowana” nie blokują pojazdu.

Zadanie 2: Zwolnienie blokady po upływie czasu na płatność (WF-02, wyjątek 7b)

Mechanizm cykliczny anulujący nieopłacone rezerwacje. Kryteria akceptacji:

• rezerwacja nieopłacona w ustalonym czasie otrzymuje status „Anulowana”,
• pojazd wraca do puli dostępnych w tym samym terminie.

Zadanie 3: Komunikat o braku dostępności w chwili zatwierdzenia (WF-02, wyjątek 6a)

Obsługa sytuacji, w której pojazd został zajęty w trakcie wypełniania formularza. Kryteria akceptacji:

• klient widzi komunikat i wraca do listy dostępnych klas,
• dane wpisane w formularzu nie są tracone.

Dopisek „nie dodawaj funkcji spoza wymagań” jest w prompcie celowo. Bez niego model chętnie dorzuci program lojalnościowy i powiadomienia SMS, o które nikt nie prosił.

Zastosowanie 2: przegląd kodu pod kątem zgodności z wymaganiami

Przegląd kodu to jedna z praktyk, które w implementacji warto podkreślać. Model potrafi zestawić kod z wymaganiami i tabelą stanów, czego klasyczne narzędzia do analizy kodu nie robią.

Prompt:

Jesteś doświadczonym programistą. Sprawdź, czy poniższa funkcja jest zgodna
z wymaganiem WF-02, tabelą stanów rezerwacji i decyzją projektową o blokadzie
w jednej transakcji. Wskaż błędy i przypadki graniczne. Nie przepisuj kodu.

def czy_dostepny(pojazd_id, odbior, zwrot, rezerwacje):
    for r in rezerwacje:
        if r.pojazd_id == pojazd_id:
            if odbior < r.zwrot and zwrot > r.odbior:
                return False
    return True

Wynik:

1. Funkcja nie uwzględnia statusu rezerwacji. Rezerwacje „Anulowana” i „Niezrealizowana” nadal blokują pojazd, co jest niezgodne z tabelą stanów.
2. Funkcja tylko sprawdza dostępność, ale niczego nie blokuje. Dwa równoczesne żądania mogą otrzymać wynik „dostępny” i obie rezerwacje zostaną zapisane. To niezgodne z decyzją projektową i z WF-02.
3. Przypadek graniczny: zwrot o 10:00 i kolejny odbiór o 10:00 funkcja uznaje za poprawne. Wymagania nie określają czasu na przygotowanie pojazdu między najmami (pytanie otwarte z PU-01).
4. Brak sprawdzenia, czy termin odbioru jest wcześniejszy niż termin zwrotu.

Punkt 3 pokazuje, jak błąd w kodzie okazuje się w rzeczywistości luką w wymaganiach. Takie znaleziska wracają do analityka, a nie do programisty.

Testowanie

W fazie testowania LLM zamienia specyfikację na przypadki testowe i podpowiada dane dla przypadków granicznych. Formalna specyfikacja wymagań powinna stanowić podstawę dla testów, więc im lepsze przypadki użycia, tym lepszy wynik. Wcześniejsze wykrycie błędów znacząco obniża koszt ich naprawy.

Zastosowanie 1: przypadki testowe z przypadku użycia

Prompt:

Jesteś testerem. Na podstawie przypadku użycia PU-01 przygotuj scenariusze
testów akceptacyjnych w formacie Gherkin (po polsku). Uwzględnij scenariusz
główny oraz wyjątki 6a i 7b. Przy każdym scenariuszu podaj identyfikator
wymagania, które weryfikuje.

Wynik:

# language: pl
Funkcja: Rezerwacja pojazdu online

  # WF-01, WF-03, WF-04
  Scenariusz: Poprawna rezerwacja z opłaconą zaliczką
    Zakładając, że w oddziale Kraków jest dostępny pojazd klasy „Kompakt”
      w terminie 10–12 lipca
    Kiedy klient rezerwuje klasę „Kompakt” w oddziale Kraków na 10–12 lipca
    I opłaca zaliczkę online
    Wtedy rezerwacja ma status „Potwierdzona”
    I klient otrzymuje e-mail z numerem rezerwacji

  # WF-02, wyjątek 6a
  Scenariusz: Ostatni pojazd zajęty w trakcie wypełniania formularza
    Zakładając, że w oddziale Kraków jest dostępny jeden pojazd klasy „Kompakt”
      w terminie 10–12 lipca
    I klient A wypełnia formularz rezerwacji na ten termin
    Kiedy klient B potwierdza rezerwację tego pojazdu na ten sam termin
    I klient A zatwierdza swój formularz
    Wtedy klient A widzi komunikat o braku dostępności
    I w systemie istnieje dokładnie jedna rezerwacja na ten pojazd i termin

  # WF-02, wyjątek 7b
  Scenariusz: Anulowanie rezerwacji nieopłaconej w terminie
    Zakładając, że klient utworzył rezerwację w statusie „Oczekuje na płatność”
    Kiedy upływa czas przeznaczony na płatność
    Wtedy rezerwacja ma status „Anulowana”
    I pojazd jest ponownie dostępny w tym terminie

Scenariusze w tej postaci czyta zarówno klient, jak i programista. Identyfikatory wymagań pozwalają sprawdzić pokrycie: wymaganie bez scenariusza to wymaganie nieprzetestowane.

Zastosowanie 2: dane testowe dla przypadków granicznych

Prompt:

Jesteś testerem. Dla funkcji sprawdzania dostępności pojazdu zaproponuj zestaw
danych testowych opartych na wartościach granicznych. Istniejąca rezerwacja:
pojazd WA 12345, odbiór 10 lipca 10:00, zwrot 12 lipca 10:00.
Dla każdego przypadku podaj nowy termin i oczekiwany wynik. Jeśli oczekiwany
wynik zależy od nieustalonej reguły biznesowej, napisz to.

Wynik:

Nr	Nowy termin (odbiór – zwrot)	Oczekiwany wynik
1	8 lipca 10:00 – 9 lipca 10:00	Dostępny
2	9 lipca 10:00 – 10 lipca 10:00	Zależy od reguły o czasie przygotowania pojazdu
3	9 lipca 10:00 – 10 lipca 10:01	Niedostępny
4	10 lipca 12:00 – 11 lipca 12:00	Niedostępny (termin w całości wewnątrz rezerwacji)
5	9 lipca 10:00 – 13 lipca 10:00	Niedostępny (termin obejmuje całą rezerwację)
6	12 lipca 10:00 – 13 lipca 10:00	Zależy od reguły o czasie przygotowania pojazdu
7	12 lipca 10:00 – 12 lipca 09:00	Błąd walidacji (zwrot przed odbiorem)

Przypadki 2 i 6 znowu wracają do tego samego otwartego pytania. Jeśli jedno pytanie pojawia się w analizie, w przeglądzie kodu i w testach, to znak, że trzeba je wreszcie zadać klientowi. Testy akceptacyjne i tak wykonuje przyszły użytkownik, bo to on odbiera system.

Wdrożenie

Przy wdrożeniu LLM pomaga zaplanować migrację danych i przygotować materiały dla użytkowników. Kluczowa jest tu strategia migracji danych oraz zarządzanie zmianą organizacyjną, a oba tematy bywają odkładane na ostatnią chwilę.

Zastosowanie 1: plan migracji danych z arkuszy Excel

Prompt:

Jesteś analitykiem odpowiedzialnym za migrację danych. Trzy oddziały prowadzą
osobne arkusze Excel z kolumnami: auto, rejestracja, klient, telefon, od, do, uwagi.
Przygotuj listę kontrolną migracji do modelu dziedziny (Pojazd, Klient,
Rezerwacja, Oddział). Wskaż typowe problemy jakości danych i sposób ich wykrycia.

Wynik:

1. Inwentaryzacja: zebrać aktualne wersje arkuszy z trzech oddziałów i ustalić datę zamrożenia danych.
2. Mapowanie kolumn: „auto” i „rejestracja” na Pojazd, „klient” i „telefon” na Klient, „od” i „do” na Rezerwacja, arkusz źródłowy na Oddział.
3. Kontrola duplikatów pojazdów: ten sam numer rejestracyjny w dwóch arkuszach (możliwy skutek przenoszenia pojazdów między oddziałami).
4. Kontrola duplikatów klientów: ta sama osoba zapisana na różne sposoby, porównanie po numerze telefonu.
5. Kontrola formatów: daty zapisane jako tekst, brak godzin odbioru i zwrotu.
6. Kontrola kolizji: nakładające się rezerwacje tego samego pojazdu wykryte jeszcze przed migracją.
7. Decyzja o kolumnie „uwagi”: co z niej trafia do systemu, a co zostaje w archiwum.
8. Migracja próbna, uzgodnienie liczby rekordów z kierownikami oddziałów i dopiero potem migracja właściwa.

Zastosowanie 2: materiały szkoleniowe dla pracowników oddziałów

Z przypadków użycia i projektów ekranów model przygotuje instrukcję stanowiskową napisaną językiem pracownika oddziału, a nie analityka. Prompt jest prosty: podaję przypadek użycia „Wydaj pojazd”, proszę o instrukcję krok po kroku na jedną stronę i o listę najczęstszych pytań. Wynik sprawdzam z jednym pracownikiem oddziału, zanim trafi do wszystkich.

Konserwacja

W utrzymaniu LLM najbardziej przydaje się do analizy wpływu zmian i do porządkowania zgłoszeń. Koszty utrzymania systemu mogą wielokrotnie przekroczyć koszty jego wytworzenia, więc każde przyspieszenie w tej fazie ma znaczenie.

Zastosowanie 1: analiza wpływu zmiany

Prompt:

Jesteś analitykiem systemowym. Klient zgłasza zmianę: „Odbiór i zwrot pojazdu
mają być możliwe w różnych oddziałach”. Na podstawie dokumentacji (wymagania
WF-01 do WF-06, PU-01, model dziedziny, tabela stanów, diagram sekwencji)
wskaż artefakty, które wymagają zmiany, i opisz zakres zmiany w każdym z nich.

Wynik:

Artefakt	Zakres zmiany
Model dziedziny	Rezerwacja otrzymuje dwa powiązania z Oddziałem: odbiór i zwrot. Założenie „ten sam oddział” przestaje obowiązywać
WF-01	Dostępność zależy od tego, w którym oddziale pojazd będzie się znajdował po poprzednim zwrocie
WF-05	Pracownik musi widzieć także rezerwacje ze zwrotem w jego oddziale
PU-01	Krok 1 rozszerzony o wybór oddziału zwrotu; możliwa dopłata za zwrot w innym oddziale
Tabela stanów	Bez zmian w stanach; przejście „przyjęcie zwrotu” zmienia oddział stacjonowania pojazdu
Testy	Nowe scenariusze dostępności dla pojazdu zwracanego w innym oddziale
Migracja i dane	Pojazd potrzebuje historii oddziału stacjonowania

Taka analiza jest możliwa tylko wtedy, gdy dokumentacja istnieje i jest aktualna. Model nie przeanalizuje wpływu zmiany na artefakty, których nikt nie utrzymuje.

Zastosowanie 2: porządkowanie zgłoszeń z eksploatacji

Zgłoszenia użytkowników model grupuje w tematy, odróżnia błędy od próśb o zmianę i wskazuje powiązane wymagania. Dziesięć zgłoszeń „nie mogę zarezerwować auta na weekend” może okazać się jednym błędem w regule dostępności. Klasyfikację modelu traktuję jako propozycję, którą zatwierdza osoba odpowiedzialna za utrzymanie.

Dokumentowanie

Dokumentowanie towarzyszy wszystkim fazom, a LLM zdejmuje z zespołu najbardziej żmudną jego część: zapisywanie decyzji i pilnowanie spójności.

Zastosowanie 1: rejestr decyzji projektowych

Prompt:

Jesteś architektem. Z poniższej notatki przygotuj wpis do rejestru decyzji
projektowych: kontekst, decyzja, rozważane warianty, konsekwencje.

Notatka: „Ustaliliśmy z Tomkiem, że księgowość dostaje dane o płatnościach
asynchronicznie, bo ich system bywa niedostępny wieczorami. Bez tego rezerwacje
by się wysypywały.”

Wynik:

• Kontekst: System księgowy bywa niedostępny w godzinach wieczornych, a rezerwacje online składane są całą dobę (WNF-02).
• Decyzja: Informacja o płatności przekazywana jest do systemu księgowego asynchronicznie, z ponawianiem.
• Rozważane warianty: wywołanie synchroniczne w trakcie rezerwacji (odrzucone, bo niedostępność księgowości blokowałaby sprzedaż).
• Konsekwencje: Dane w księgowości mogą pojawić się z opóźnieniem. Potrzebne jest monitorowanie nieprzekazanych płatności i procedura na wypadek długiej awarii.

Zastosowanie 2: kontrola spójności dokumentacji

System powinien być opisany przez zbiór spójnych, wzajemnie uzupełniających się modeli. Po każdej zmianie proszę model o porównanie artefaktów: czy każdy stan z tabeli stanów występuje w przypadkach użycia, czy każde wymaganie ma test, czy nazwy klas w modelu dziedziny zgadzają się z nazwami w wymaganiach. To praca, której człowiek nie lubi i przy której się myli.

Podsumowanie: zalety, pułapki i rola analityka

LLM przyspiesza pracę w każdej fazie cyklu życia oprogramowania, ale nie zdejmuje z nikogo odpowiedzialności za wynik. Tak w skrócie oceniam to narzędzie po przejściu przez cały proces na przykładzie wypożyczalni.

Zalety wsparcia LLM

• Szybki pierwszy szkic. Lista ryzyk, przypadek użycia czy diagram sekwencji powstają w minuty. Czas zaoszczędzony na pisaniu można przeznaczyć na rozmowę z klientem.
• Wyjątki i przypadki graniczne. Model systematycznie wskazuje sytuacje nietypowe, które ludzie pomijają, bo występują rzadko.
• Pytania zamiast odpowiedzi. Najcenniejszym wynikiem wielu promptów była lista pytań do klienta i lista założeń.
• Spójność między artefaktami. Mapowanie wymagań na potrzeby, testów na wymagania i kodu na projekt przestaje być pracą, na którą nigdy nie ma czasu.
• Tłumaczenie między językami. Model sprawnie zamienia notatki na proces, proces na wymagania, wymagania na Gherkin, a przypadki użycia na instrukcję dla użytkownika.
• Niższy próg wejścia. Osoba początkująca dostaje wzorzec artefaktu i może uczyć się na konkretnym przykładzie ze swojego projektu.

Na co trzeba uważać

• Zmyślenia podane pewnym tonem. Model wypełnia luki prawdopodobnie brzmiącą treścią. Wartość 40% czy czas odpowiedzi 2 s wyglądają wiarygodnie, a nikt ich nie ustalił. Dlatego w każdym prompcie każę oznaczać niewiadome.
• Brak znajomości Twojej organizacji. Model nie zna strategii firmy, portfolio projektów, polityki ani ludzi. Zna tylko to, co mu wkleisz.
• Pozorna kompletność. Ładnie sformatowana tabela sprawia wrażenie skończonej pracy. Dziewięć wymagań z modelu to punkt wyjścia do warsztatu, a nie specyfikacja.
• Rozwiązanie zamiast problemu. Model chętnie dopisuje funkcje i technologie, o które nikt nie prosił. To prosta droga do rozrostu zakresu.
• Niepowtarzalność wyników. Ten sam prompt daje różne odpowiedzi. Artefakt staje się obowiązujący dopiero wtedy, gdy trafi do repozytorium po przeglądzie.
• Poprawność notacji. Wygenerowany PlantUML czy BPMN bywa składniowo poprawny i merytorycznie błędny. Trzeba znać notację, żeby to zauważyć.
• Poufność danych. Dokumenty klienta, dane osobowe i tajemnice przedsiębiorstwa nie powinny trafiać do narzędzi, na które organizacja nie wyraziła zgody. Sprawdź zasady u siebie, zanim wkleisz pierwszy dokument.
• Rozleniwienie. Jeśli model myśli za Ciebie od pierwszego dnia pracy, nie nauczysz się oceniać jego wyników.

Dlaczego analityk jest w tym procesie ważny

Przejdź jeszcze raz przez przykłady z tego tekstu. Pytanie o czas przygotowania pojazdu między najmami wróciło trzy razy: w przypadku użycia, w przeglądzie kodu i w danych testowych. Model za każdym razem je zauważył, ale ani razu na nie nie odpowiedział. Odpowiedź zna kierownik oddziału, a zdobyć ją, uzgodnić i zapisać musi analityk.

Określanie wymagań to dialog, w którym klient i wykonawca wspólnie konstruują zbiór wymagań. Różni interesariusze mają sprzeczne cele i mówią różnymi językami o tych samych problemach. Rola analityka i projektanta polega na poszukiwaniu i uzgadnianiu kompromisów. Model nie usiądzie z pracownikami oddziału, nie zauważy, że sponsor i użytkownicy chcą czegoś innego, i nie weźmie odpowiedzialności za decyzję.

Analityk w pracy z LLM pełni więc trzy role. Dostarcza kontekst, bez którego model zgaduje. Weryfikuje wynik z rzeczywistością, czyli z ludźmi i procesami. Odpowiada za to, co ostatecznie trafia do dokumentacji i do programistów.

Jeśli zaczynasz pracę w branży, moja rada jest prosta. Najpierw naucz się, jak wygląda dobry przypadek użycia, dobry model dziedziny i dobre wymaganie. Dopiero wtedy LLM stanie się dla Ciebie tym, czym powinien być: narzędziem wzmacniającym pamięć i wyobraźnię, a nie ich zamiennikiem.