Niedawno natknąłem się na interesujący problem przydzielania dyżurów w szkole. To klasyczny przykład Problemu Spełnienia Ograniczeń, będącego częścią problemów Optymalizacji Kombinatorycznej na dużą skalę. Wydawał mi się idealnym placem zabaw do testowania, jak dzisiejsze narzędzia AI radzą sobie z czymś zarówno praktycznym jak i złożonym.
Równocześnie przeglądałem liczne artykuły i posty na temat „AI Flow” i jego… wad. Koncept brzmi świetnie, ale historie, które znalazłem, dotyczyły głównie frustracji i problemów ze zmuszaniem LLM do „właściwego wykonywania pracy”.
Postanowiłem przeprowadzić dokładny eksperyment i sam wypróbować AI Flow, przechodząc przez cały proces tworzenia pełnowartościowej aplikacji – od początku do końca – we współpracy z LLM. Celem nie było tylko sprawdzenie, czy „AI Flow” daje wyniki, ale zrozumienie, jak pracować z modelem, jakie mogą być problemy i jak je przezwyciężyć – w nadziei na stworzenie przepisu na efektywną metodę pracy.
Mam nadzieję, że techniki, które okazały się pomocne, pomogą innym zachować „10x produktywność” bez odpowiadającej jej „10x frustracji”. Artykuł skupia się na procesie rozwoju aplikacji – jego problemach i rozwiązaniach – a nie na problemie rozwiązywanym przez samą aplikację.
Wyzwania rozwoju
Podczas rozwoju aplikacji przez kilka tygodni udało się zweryfikować niektóre z najczęściej wspominanych problemów z AI Flow. Miłym akcentem jest posiadanie pełnego zapisu czatu z LLM-em – pozwala to nie tylko przypomnieć sobie napotkane kwestie, ale także przekazać pełną analizę całego procesu i wszystkich rozmów!
Omówmy typy problemów i techniki ich łagodzenia lub rozwiązywania. Zanim przejdziemy do szczegółów, podkreślam sposób działania modelu LLM: przechodzi przez całe okno kontekstu czatu, w tym pliki kodu. Od góry do dołu. To kluczowy czynnik o znaczących implikacjach, powodujący niektóre problemy – ale też wskazujący, gdzie szukać pomocy.
Pytaj właściwą osobę, a raczej – personę…
Po pierwsze: bardzo prawdopodobne, że otrzymasz różne odpowiedzi w zależności od tego, kogo zapytasz. Stąd istnieją Agenci AI. Ale nawet bez dedykowanych Agentów możesz sprawić, by jeden LLM działał jak agent (czy nawet cały zespół agentów!) – wystarczy poprosić!
Otrzymasz różne wyniki, jeśli:
- poprosisz LLM: po prostu o zaimplementowanie funkcji X lub
- poprosisz: „jako programista JS zaimplementuj funkcję X” lub
- poprosisz: „jako programista React zaimplementuj funkcję X” lub
- poprosisz: „jako Senior Developer wybierz właściwe podejście i zaimplementuj funkcję X”.
Każda z próśb daje inny rezultat. W przykładach 2. i 3. sugeruję też technologię – to oczywiście zmienia nieco zapytanie. I właśnie to możesz robić: sugerować dziedzinę, technologię, bez sztywnego narzucania sposobu implementacji.
Branching: misja niemożliwa
Jedną z największych wad, jakie zidentyfikowałem, jest brak zdolności do przełączania kontekstu. Jak wspomniałem, LLM przechodzi przez całe okno kontekstu. Jeśli w środku spróbujesz zmienić temat, bardzo trudno to przezwyciężyć.
Scenariusz wydaje się prosty: podczas rozwoju funkcji napotkano błąd. Tworzysz brancha, by skupić się na błędzie. Mówisz modelowi, co zrobiłeś i co dalej. Rezultat? Model kontynuuje implementację pozostałych zmian funkcji na branchu, gdzie poprzednie zmiany w ogóle nie istnieją. Lub istnieją częściowo. Nie zignoruje nowego polecenia: „napraw błąd”, ale będzie trzymał obie rzeczy w „głowie”, dając nieprzewidywalne wyniki.
Lekarstwo? To wyzwanie jest chyba najtrudniejszym do opanowania. Chociaż branching jest ogólnie bardzo użyteczny, LLM nie przełącza kontekstu tylko dlatego, że mu każesz. Nigdy mi się to nie udało!
Uwaga: Mimo śródtytułu, branching jest bardzo użyteczny i zaraz się przyda z innych powodów. Ale szybkie przełączanie kontekstu i skakanie między branchami to naprawdę „misja niemożliwa”. Złota rada: pracując nad czymś, kończ temat, zanim przejdziesz do innego. Staraj się też trzymać techniki MVP: Minimum Viable Product. Nie rozwiązuje to problemu, ale minimalizuje negatywny wpływ.
Debugowanie – po prostu znajdź błąd!
Podczas rozwoju napotkasz błędy. Błędy lub nieprzewidziane konsekwencje wprowadzonych zmian. Często po prostu poprosisz LLM o naprawę. Czasem mu się uda. Innym razem nie. Często jeszcze bardziej zepsuje projekt, próbując naprawić błąd.
Jak sobie radzić? Po pierwsze, używaj wersji i upewnij się, że możesz cofnąć kod do stanu, w którym błąd wystąpił, ale zanim próby naprawy pogorszyły sprawę. Tu możesz skorzystać z faktu, że LLM przechodzi przez całe okno kontekstu: przeczyta ponownie wszystkie próby napraw i wyniki. Może wpaść na inne pomysły, ale… tu pojawia się najpotężniejsza technika, jaką odkryłem. W wielu kursach radzą: Daj modelowi czas na myślenie. Dodałem coś do tego.
Daj modelowi czas na myślenie… i dyskusję!
Podczas rozwoju aplikacji odkryłem, że jedną z najskuteczniejszych technik rozwiązywania problemów było poproszenie modelu o zwołanie spotkania ekspertów do omówienia problemu. Chociaż to wciąż ten sam LLM, potrafił analizować problem z różnych stron, przeprowadzać burzę mózgów i znajdować rozwiązania.
Wystarczyło poprosić o zwołanie spotkania grupy ekspertów. Mogłem wskazać, że chcę, by Architekt omówił z Senior Developerem i Testerem dany błąd. To prowadziło czasem do wniosku, że błędu nie da się po prostu załatać z powodu ogólnego złego podejścia do zarządzania stanem lub niewłaściwej architektury, a LLM natychmiast sugerował właściwe podejście.
Nagle wydało się to takie proste – choć ten sam LLM chwilę wcześniej nie umiał naprawić błędu.
Spójrzmy na przykładową dyskusję
Oto przykład, gdzie chciałem zaprojektować refaktoring funkcji, ale zamiast dawać jasne wskazówki, kazałem LLM omówić:
Ja: Chciałbym zwołać spotkanie Change Management Board, bo musimy omówić opcje znaczących ulepszeń adresujących obawę zgłoszoną przez użytkowników. Wykluczenia Grupowe to funkcja lubiana i używana przez użytkowników. Jednak tworzenie Wykluczenia dla nawet pojedynczej przerwy w szkole z około 20 lokalizacjami tworzy wiele nadpisań harmonogramu. Wykluczenie na resztę dnia – choć znów świetna funkcja doceniana przez użytkowników – prowadzi do setek Nadpisań Harmonogramu.
To samo w sobie nie jest problemem. Użytkownicy mają kłopoty z zarządzaniem Własnymi Karami. Nawet z filtrami to nadal masa wierszy danych.
Pomysł do dyskusji: wprowadzenie grupowania Własnych Kar. Typowo i najczęściej użytkownicy Wykluczają na przerwę lub na dzień – więc grupowanie według przerwy i/lub dnia odzwierciedlałoby sposób pracy, umożliwiając łatwiejszy przegląd istniejących Własnych Kar i być może łatwiejsze usuwanie całych grup. Posłuchajmy opinii.
Gemini: To doskonała i krytyczna obserwacja. Obecna implementacja wykluczeń grupowych, choć funkcjonalnie potężna, tworzy znaczący ból głowy w zarządzaniu. Sugestia użytkownika co do grupowania kar jest idealnym rozwiązaniem.
Zwołuję teraz Change Management Board, by sformalizować tę propozycję.
Spotkanie Change Management Board
Uczestnicy: Lead Developer, Ekspert UX, System Architect
Temat: Ulepszanie zarządzania Własnymi Karami generowanymi grupowo
- Stwierdzenie problemu (zgłoszone przez użytkownika)
Użytkownicy uwielbiają funkcje Wykluczenie na przerwę” i „Wykluczenie na dzień”. Jednak te akcje generują dużą liczbę indywidualnych wpisów CustomPenalty (dziesiątki lub setki). Obecny CustomPenaltiesManager wyświetla je jako płaską listę, co przytłacza i uniemożliwia zarządzanie lub cofanie pojedynczej akcji bulk. Istniejące filtry są niewystarczające dla tej skali danych. - Proponowane rozwiązanie i opinie ekspertów
- Pogląd Architekta: Główny problem to brak stanu w strukturze danych manualPenalties; nie wie, dlaczego kara została utworzona. Rozwiązanie: dodać banId lub groupId do obiektu ManualPenalty. Przy bulk ban generujemy pojedynczy unikalny ID i przypisujemy go każdej karze z tej akcji. Tworzy to logiczne grupowanie w danych.
- Pogląd Eksperta UX: Popieram w pełni. Całkowicie przeprojektować UI CustomPenaltiesManager. Zamiast płaskiej tabeli użyć komponentu Accordion. Każdy AccordionItem reprezentuje grupę ban. Trigger wyświetla czytelny summary (np. „Wykluczenie dla Jana Kowalskiego w poniedziałek na Przerwę 0 [4 kary]”) i przycisk „Usuń grupę”. Rozwinięcie pokazuje małą tabelę z detalami dla power userów. Odpowiada modelowi myślowemu użytkownika.
- Pogląd Lead Developera: Plan solidny. Zmiana danych minimalna i wstecznie kompatybilna. Zmiana UI: zastąpić tabelę akordeonem – proste. Zaktualizować schedule-debugger.tsx o banId przy tworzeniu banów i zrefaktorować custom-penalties-manager.tsx do grupowania po tym ID i wyświetlania w akordeonie. Usuwanie całej grupy jednym klikiem to kluczowy zysk użyteczności.
- Decyzja i plan działań
Zarząd jednogłośnie aprobuje. Plan:- Zaktualizować strukturę danych: Dodać opcjonalny banId do typu ManualPenalty w src/types/index.ts.
- Ulepszyć tworzenie wykluczeń: Zmodyfikować schedule-debugger.tsx do generowania i przypisywania unikalnego banId przy akcjach „Wykluczenie na przerwę” lub „Wykluczenie na dzień”.
- Przeprojektować Penalty Manager: Całkowity refaktoring custom-penalties-manager.tsx z użyciem Accordion, grupowaniem po banId i akcją usuwania grupy.
Rozwiąże to obawę użytkownika i zapewni intuicyjne, skalowalne zarządzanie. Teraz wdrożę te zmiany.
Nie da się naprawić? Eskaluj!
Niektóre problemy były naprawdę trudne do naprawienia. Kilka razy utknąłem w pętli:
- Prośba o naprawę.
- Testowanie, tylko po to by odkryć, że nie działa.
- Przegląd implementacji, próba zrozumienia problemu.
- Powrót do punktu 1.
Niektóre kwestie są bardzo uporczywe. Jednym z przypadków był prosty błąd z tabelą wychodzącą poza ekran. Pierwsze prośby o naprawę dały overflow-x-auto. Ale nie działało. Problem zdiagnozowano błędnie, jako wyłącznie w komponencie tabeli, a kolejne poprawki ujawniły, że był wyżej w hierarchii komponentów.
Po licznych nieudanych próbach poprosiłem LLM o udawanie Solution Architecta i głęboką analizę problemu.
Rezultat: Powiedziano mi, że to „klasyczne zachowanie flexbox, gdzie element flex nie kurczy się poniżej minimalnej szerokości treści”. Rozwiązanie: przebudowa elementów strony z dodaniem div z klasami flex-1 i min-w-0.
Ilustruje to, że zmiana ramy zapytania przez eskalację persony – z developera na architekta – może przekształcić rozumowanie LLM i doprowadzić do przełomu.
Drobne nieistotne zmiany
Najczęstszym omawianym problemem jest stosowanie przez LLM drobnych, całkowicie nieistotnych dla promptu zmian w kodzie. To bardzo ludzkie: ile razy przeglądając kod skupiony na jednej rzeczy, zauważyłem coś, co mogę „przy okazji” naprawić? LLM robi to samo: przechodzi przez cały plik, czyta linijka po linijce i ma różne „myśli”.
By uniknąć detali związanych z kodowaniem, prosty przykład aktualizacji pliku tłumaczeń. Wskazałem brakujące tłumaczenie:
Rezultat? Dwa elementy dodane:
Jedyne lekarstwo, jakie mam (niestety): używaj branchy dla każdej zmiany i przeprowadzaj dokładne code review przy merge. Oczywiście możesz poprosić LLM o code review!
Komentarz – dziś jest, jutro zniknie
Wynikiem tych „drobnych, nieistotnych zmian” jest „mały” efekt uboczny: za każdym przejściem przez plik, LLM przegląda też komentarze. I nader często uznaje je za zbędne, myśląc: „to oczywiste, funkcja poniżej jest prosta i jasna – usuńmy komentarz!”. Bardzo frustrujące.
Tu title dodano tuż między individualGroups a poprzedzającym komentarzem. I komentarz znika…
Wymagania wstępne dla kodowania LLM
Jak się nauczyłem, rosnące znaczenie mają umiejętności mniej techniczne. Lubię struktury danych i to mi pomaga, ale duża część rozwoju wymagała ode mnie roli facylitatora – co było możliwe dzięki wieloletniemu doświadczeniu z projektów. Rozbijmy to.
Wiedz, o czym mówisz
LLM może zakodować niemal wszystko, ale musisz być właściwym partnerem: precyzyjnie wyrażać potrzeby, dyskutować alternatywy, detale problemu, recenzować implementację i aspekty (algorytmy, architektury, stany itp.). Tu techniczne umiejętności i wiedza bardzo pomagają – ale tylko do dyskusji. Komunikacja jest kluczem. Musisz nazwać i wyjaśnić, nie tylko wiedzieć.
Oczywiście, potrzebujesz szczegółowej eksperckiej wiedzy o temacie, nad którym pracujesz.
Wiedz, z kim rozmawiać
Musisz być świadomy różnych ról w fazach designu i implementacji. Kiedy dyskutować z QA, kiedy omawiać architekturę czy kwestionować implementację. Tu doświadczenie projektowe procentuje, niezależnie od ról, jakie pełniło się w przeszłości. Klucz: wiedzieć, jak dzielą się odpowiedzialności i co obejmuje każda specjalizacja oraz rola.
Znaj cykl rozwoju
Musisz znać cykl:
- projektowanie,
- implementacja,
- testy,
- przegląd implementacji.
Każdy krok ma cel i wymaga uwagi. Na szczęście LLM pomaga: dyskutuj wymagania z Analitykiem, design z Ekspertem UX, poproś Testera o analizę implementacji – wszyscy są pod ręką!
Wnioski
Czy LLM mogą mnie zastąpić? LLM mogą być lepsze w niemal wszystkim. To jak budowa domu: elektryk jest lepszy ode mnie w układaniu kabli, robotnicy wykonują lepiej swoją pracę, nawet jeśli wiem dokładnie, co robić. Nie jestem stolarzem. Ani dekarzem.
Ale jestem tym, kto wie, czego chce i jak. Mogę rozmawiać z każdym, dyskutować detale i sprawić, by projekt odzwierciedlał wizję.
Z dostępnymi LLM ustrukturyzowana współpraca jest ważniejsza niż kiedykolwiek. Zawsze była ważna w zespole, a teraz jeszcze ważniejsza, bo masz zespół nawet solo. Upewnij się więc, że masz partnera, a nie nieprzewidywalnego drugiego pilota, który szarpie stery po swojemu!
Ostatecznie najistotniejszą rolą LLM nie jest bezbłędne kodowanie, ale bycie elastycznym partnerem dyskusji – wzmocnionym o właściwe persony, wskazówki i procesy. To sposób na „produktywność x10” bez “”frustracji x10”.
Notka końcowa
Artykuł nie został wygenerowany przez AI. Powstał jednak we współpracy z LLM 🙂 Aplikację możesz wypróbować tutaj: DutyWise.
Zostaw komentarz