Tydzień 3 (19.01.2026) – postęp w projekcie

Zaczęło się niewinnie. Silnik AI zwracał layout, który czasem miał dziwne przesunięcia w blokach. Logika wyglądała sensownie na pierwszy rzut oka, więc przez dwa tygodnie poprawiałem prompt, zmieniałem parametry, kombinowałem z wagami. Aż w końcu zajrzałem do kodu, który za to odpowiada.

Okazało się, że problem nie leżał w modelu AI. W ogóle. Warstwa transformacji prompta przed wysłaniem do modelu miała trzy różne mechanizmy walidacji, które sprawdzały to samo, każdy w inny sposób. Dwie równoległe ścieżki przetwarzania treści, które robiły identyczne operacje, tylko inną metodą – a na końcu i tak scalały wynik w jeden string. Do tego osobna warstwa logowania każdego kroku, która notowała wszystko, co się działo, na wypadek gdyby trzeba było debugować.

Kiedy to wyciąłem, layout przestał przesuwać bloki. Bo jedna z tych dublujących się ścieżek nadpisywała marginesy, które druga ścieżka ustawiła sekundę wcześniej. Nikt tego nie widział, bo logi były tak rozdmuchane, że nikt ich nie czytał.

Przeszedłem przez cały backend i powtórzyłem ten sam schemat. W każdym pliku zadawałem sobie pytanie: „co się stanie, jeśli to po prostu usunę?". W dziewięciu na dziesięć przypadków – nic złego. Kod działał dalej, czasem szybciej, czasem ciszej (bo przestał logować rzeczy, których nikt nie czytał).

Najbardziej zaskakujące było to, ile kodu powstało w formule „na wszelki wypadek". Trzy mechanizmy walidacji tego samego prompta – każdy wyglądał, jakby ktoś dodał go w ramach sprintu, nie sprawdzając, czy już istnieje. Dwie ścieżki transformacji, które różniły się tylko nazwą funkcji. Logowanie każdego kroku do osobnego pliku, które w praktyce generowało megabajty danych, których nikt nie analizował. Usunąłem trzy mechanizmy walidacji tego samego prompta i layout przestał się rozjeżdżać. Nikt nie zauważył, że coś zniknęło – poza tym, że strona wreszcie wyglądała tak, jak powinna.

Efekt czyszczenia? To, co siedziały dwa tygodnie w backlogu jako „błąd w layoutach", zniknęło w godzinę po wycięciu dublującej się ścieżki. Debugowanie, które wcześniej wymagało przekopania się przez trzy poziomy logów, teraz sprowadza się do jednego spojrzenia na komunikat błędu. Dla kogoś, kto używa narzędzia, oznacza to tyle, że jak AI wygeneruje layout i coś nie gra – nie trzeba debugować silnika. Poprawiasz prompt albo sekcję i dostajesz poprawkę od ręki. Chcesz sprawdzić, jak to wygląda w praktyce? Wrzuć brief na stronę MagicWP i zobacz, co zwróci.

Kierunek, jaki sobie obrałem: każda nowa funkcja przechodzi test – czy faktycznie coś zmienia dla kogoś, kto używa narzędzia? Jeśli odpowiedź brzmi „nie wiem" – nie wchodzi. W tygodniu trzecim nauczyłem się, że to, czego nie ma, często pomaga bardziej niż to, co jest. I tego zamierzam się trzymać.