W poprzednich wpisach wspominałem o przekazywaniu kontekstu i dzieleniu pracy na mniejsze etapy. Tym razem pójdziemy o krok dalej.
Zanim pozwolisz LLM-owi kodować, sprawdź, co właściwie zamierza zrobić.
Brzmi banalnie, ale potrafi oszczędzić sporo czasu, tokenów i późniejszego sprzątania.
Nie zawsze potrzebujesz pełnej specyfikacji
Istnieje podejście nazywane spec-driven development, w którym przed rozpoczęciem implementacji przygotowujemy dokładną specyfikację rozwiązania.
Ma to sens, szczególnie przy większych i bardziej przewidywalnych zadaniach. Nie zawsze jednak chcemy podchodzić do pracy aż tak restrykcyjnie.
Czasem mamy jedynie ogólny pomysł i chcemy trochę poddać się fantazji. Zobaczyć, co zaproponuje AI, poznać możliwe rozwiązania albo znaleźć kierunek, którego sami wcześniej nie braliśmy pod uwagę.
Problem w tym, że fantazja LLM-a nie zawsze kończy się tam, gdzie powinna 😅
Najpierw plan, później kod
W takiej sytuacji warto postąpić podobnie jak w pierwszym wpisie: przekazać LLM-owi możliwie pełny kontekst zadania.
Różnica polega na tym, że zamiast od razu prosić o implementację, prosimy go o przygotowanie planu.
Może to być osobny plik Markdown zawierający opis proponowanego rozwiązania. Dzięki temu przed rozpoczęciem kodowania możemy sprawdzić, czy model właściwie zrozumiał zadanie i czy nie popłynął za bardzo pod względem architektury.
A potrafi popłynąć.
Nawet gdy podamy dobry kontekst, LLM może zaproponować rozwiązanie, które teoretycznie działa, ale zupełnie nie pasuje do projektu. Może stworzyć niepotrzebne abstrakcje, ominąć istniejące mechanizmy albo upchnąć pół aplikacji w trzech plikach.
Kod może być poprawny. Problem w tym, że później ktoś będzie musiał go utrzymywać. Najczęściej będziesz to Ty.
Plan mode czy zwykły plik Markdown?
Klienci CLI jak Codex czy Copilot, najczęściej posiadają osobny tryb planowania. Model analizuje wtedy zadanie i przygotowuje plan bez wprowadzania zmian w kodzie.
Osobiście przez długi czas wygodniej pracowało mi się w normalnym trybie i z planem zapisanym w osobnym pliku Markdown. Mogłem spokojnie go przeczytać, poprawić, dopisać komentarze i dopiero później rozpocząć implementację.
Ostatnio powoli przekonuję się również do dedykowanego trybu planowania, ale samo narzędzie nie jest tutaj najważniejsze.
Niezależnie od tego, czy korzystasz z plan mode, pliku Markdown, czy zwykłej rozmowy, nadal musisz jasno powiedzieć LLM-owi, co powinno znaleźć się w planie.
Co powinien zawierać plan?
Ja najczęściej proszę o trzy rzeczy:
- workflow całego rozwiązania,
- listę plików, które model zamierza utworzyć lub zmodyfikować,
- krótkie wyjaśnienie odpowiedzialności każdego pliku.
Przy każdym pliku chcę zobaczyć jego pełną ścieżkę oraz maksymalnie dwa zdania opisu.
Przykładowa instrukcja może wyglądać tak:
Na podstawie przekazanego kontekstu przygotuj plan implementacji. Nie pisz jeszcze kodu.
Opisz workflow działania rozwiązania, a następnie wskaż wszystkie pliki, które zamierzasz utworzyć lub zmodyfikować.
Dla każdego pliku podaj pełną ścieżkę oraz opisz jego zawartość w maksymalnie dwóch zdaniach.
Taki plan jest wystarczająco szczegółowy, żeby szybko wychwycić problemy, ale jednocześnie nie zamienia całego procesu w pisanie kilkunastostronicowej specyfikacji.
Co daje weryfikacja planu?
Przede wszystkim możesz sprawdzić, czy proponowane rozwiązanie pasuje do architektury projektu.
Od razu zobaczysz, czy LLM:
- wykorzystuje istniejące komponenty,
- poprawnie rozdziela odpowiedzialności,
- tworzy pliki w odpowiednich katalogach,
- nie wprowadza niepotrzebnych warstw,
- właściwie rozumie cały workflow.
Jeśli plan jest błędny, poprawiasz kilka akapitów tekstu zamiast kilkuset linii kodu.
To znacznie tańsze niż pozwolenie modelowi na pełną implementację, a następnie tłumaczenie mu, że właściwie wszystko zrobił dobrze — tylko kompletnie nie tak, jak powinien.
Plan nadal trzeba sprawdzić
Sam fakt, że LLM przygotował plan, nie oznacza jeszcze, że plan jest dobry.
Trzeba go przeczytać, zakwestionować i porównać z rzeczywistą architekturą projektu. Warto szczególnie uważać na rozwiązania, które brzmią wyjątkowo elegancko, ale wymagają przebudowania połowy aplikacji.
LLM bardzo chętnie stworzy nową warstwę abstrakcji. Albo trzy. W końcu to nie on będzie później debugował ten kod w piątek o 16:47.
Dlatego traktuję plan jako propozycję, a nie gotową decyzję architektoniczną.
Podsumowanie
Nie zawsze potrzebujesz kompletnej specyfikacji. Warto zostawić trochę miejsca na eksplorację i pomysły proponowane przez AI.
Nie oznacza to jednak, że należy od razu pozwolić modelowi implementować pierwsze rozwiązanie, które przyjdzie mu do głowy.
Najpierw poproś o plan. Sprawdź workflow, strukturę plików i podział odpowiedzialności. Dopiero gdy zaproponowane rozwiązanie ma sens, pozwól LLM-owi rozpocząć kodowanie.
Kilka minut poświęconych na weryfikację planu może oszczędzić znacznie więcej czasu podczas późniejszego review i refaktoryzacji.