Nie zmieniaj wzorca promptu — dla bezpiecznych, małych iteracji

Dlaczego małe zmiany często psują inne części

„Mała” zmiana rzadko pozostaje mała. Poprosisz o drobną poprawkę etykiety przycisku, a nagle layout strony się przesuwa, formularz przestaje walidować albo krok w kasie zachowuje się inaczej. Aplikacje to systemy powiązanych elementów. UI, logika, dane i integracje wzajemnie na siebie wpływają.

Częstą przyczyną są niejasne granice. Jeśli w żądaniu napiszesz „uproszcz zapisywanie”, wykonawca (człowiek lub AI) musi zgadnąć, co znaczą „uproszczenie”. Zgadywanie prowadzi do dodatkowych zmian: usuwania pól, zmiany kroków, przeredagowania copy albo modyfikacji walidacji. Inną przyczyną są ukryte zależności. Drobna zmiana UI może użyć komponentu pojawiającego się na pięciu innych ekranach.

Bezpieczna iteracja oznacza, że dostajesz jedną zamierzoną poprawkę, a wszystko inne pozostaje efektywnie niezmienione. Dla zespołu nietechnicznego oznacza to, że przepływ wciąż wygląda tak samo dla użytkowników, skrypty wsparcia nadal pasują do produktu, a raporty mają sens. Dla zespołu technicznego to brak niespodzianek w trasach, kształcie danych, kontraktach API czy zachowaniu w przypadkach brzegowych.

Aby to umożliwić, trzeba zamrozić to, co nie może się poruszyć. W praktyce zwykle obejmuje to krytyczne przepływy (dokładne kroki użytkownika), detale UI/UX (layout, odstępy, zachowanie interakcji), reguły biznesowe (cennik, uprawnienia, walidacja), zachowanie danych (co i kiedy się zapisuje) i integracje (zdarzenia analityczne, e-maile, płatności, zewnętrzne API).

Wzorzec „nie zmieniać” redukuje ryzyko, usuwając zgadywanie i utrzymując zmianę w wąskim zakresie. To nie gwarancja — wciąż może wystąpić dryf, jeśli oryginalne zachowanie było źle zdefiniowane, zmiana dotyka współdzielonych komponentów albo jeśli nie sprawdzisz rezultatu. Celem jest mniej niespodzianek i szybsze akceptacje.

Czym jest wzorzec „nie zmieniać”

Wzorzec „nie zmieniać” to prosty sposób na poproszenie o jedną konkretną aktualizację, jednocześnie wyraźnie blokując wszystko inne. Nazwyjesz jedną zmianę, której chcesz, a potem wypiszesz krótką listę elementów, które muszą pozostać identyczne po aktualizacji.

To ma znaczenie, bo modele często chcą być pomocne i refaktoryzują, zmieniają nazwy, reorganizują pliki albo „porządkują” logikę podczas edycji kodu. Nawet jeśli wynik nadal działa, te dodatkowe zmiany mogą wprowadzić błędy, zmienić zachowanie albo skomplikować review.

Porównaj dwa żądania:

„Ulepsz stronę ustawień.” To zaprasza do zmian projektowych, nowego copy, przesunięć layoutu i przeróbek logiki.

„Zmień tylko tekst etykiety z 'Phone' na 'Mobile phone'. Nie zmieniaj layoutu, walidacji ani zachowania zapisu.” To wąskie, testowalne i bezpieczniejsze.

Dobra lista zamrożeń zwykle obejmuje trzy obszary:

• Przepływy (journeys): kroki, które wykonuje użytkownik i jakie ekrany się pojawiają.
• Detale UI/UX: layout, odstępy, kolejność pól, położenie przycisków i zachowania interakcji.
• Reguły biznesowe i zachowanie danych: reguły walidacji, obliczenia cen, uprawnienia, zapisy do bazy i odpowiedzi API.

Kiedy używasz tego wzorca w narzędziu czatowym typu Koder.ai, iteracje zwykle przebiegają szybciej, bo model skupia się na pojedynczej edycji zamiast robić szerokie „ulepszenia”, o które nie prosiłeś.

Podstawowy szablon, którego możesz użyć

Ten wzorzec działa najlepiej, gdy twoje żądanie brzmi jak mały kontrakt: jeden jasny cel, lista zamrożeń i kilka sprawdzeń, które potwierdzą rezultat.

Skopiuj ten szablon i wypełnij nawiasy. Krótko, lecz konkretnie.

Goal (one sentence):
- Change: [describe the one small change you want]

Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]

DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -\u003e checkout -\u003e receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]

Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines

Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]

Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing

Przykład: jeśli chcesz zmienić kolor przycisku w kasie, celem jest „Zaktualizuj główny kolor przycisku checkout do #1A73E8.” Pozycje na liście DO NOT CHANGE powinny zamrozić cały przepływ checkoutu, tekst przycisku i obliczenia cen.

Jeśli używasz Koder.ai, taki format skraca review, bo możesz porównać checklistę akceptacji z podglądem i podsumowaniem zmian, zanim coś zaakceptujesz.

Jak zamrozić krytyczne przepływy, nie będąc nieprecyzyjnym

Kiedy prosisz o małą zmianę, nie mów „nie psuj nic”. Wymień dokładne podróże użytkownika, które muszą działać tak samo, od pierwszego kliknięcia do końcowego wyniku. Nie zamrażasz całej aplikacji, tylko te części, gdzie regresje bolą najbardziej.

Zacznij od listy krytycznych przepływów prostym językiem: logowanie (łącznie z resetem hasła), onboarding, checkout, ustawienia. Dla każdego przepływu opisz, jak wygląda „zrobione”. Przykład: „Użytkownik może się zalogować za pomocą e-maila i hasła, trafia na Dashboard i pozostaje zalogowany po odświeżeniu.”

Następnie zablokuj przypadki brzegowe, które się często pomijają. Zachowanie przycisku wstecz to klasyczne źródło dryfu: „Wróć z Checkout do Cart (nie do Home), a przedmioty w koszyku pozostają.” Wymień stany błędów („złe hasło pokazuje ten sam komunikat”), stany puste („brak projektów pokazuje ten sam tekst ekranu pustego”) i stany ładowania („spinner pojawia się w ciągu 200 ms, bez skoku layoutu”).

Jeśli wydajność i bezpieczeństwo mają znaczenie, zamroź je także. Jeśli o tym nie wspomnisz, model może „ulepszyć” przez dodanie dodatkowych wywołań, logowania czy zmian w auth.

Prosty sposób na to bez pisania powieści:

• Przepływy do zamrożenia: Logowanie, Rejestracja, Checkout, Ustawienia (bez nowych kroków, bez zmiany kolejności ekranów)
• Edge cases do zamrożenia: zachowania przycisku wstecz, komunikaty błędów, stany puste, zachowanie po odświeżeniu
• Zachowanie danych do zamrożenia: co jest zapisywane, kiedy jest zapisywane i gdzie pojawia się po przeładowaniu
• Bezpieczeństwo do zamrożenia: uprawnienia, sprawdzenia auth, limity zapytań, brak nowych publicznych endpointów
• Wydajność do zamrożenia: brak dodatkowych wywołań API w tych przepływach, czas odpowiedzi nie gorszy niż obecny

Opisz przepływ danych jednym zdaniem na punkt. Na przykład: „Adres zapisuje się tylko po naciśnięciu Zapisz, jest przechowywany w rekordzie profilu użytkownika i musi przetrwać wylogowanie/logowanie.” Taki poziom szczegółu zapobiega przypadkowemu autosave, nowym polom czy zmianom timingowym, które psują użytkowników.

Jak zamrozić detale UI i UX

Dryf UI zwykle występuje, bo model „pomocnie” porządkuje style, odstępy lub strukturę komponentów. Rozwiązanie jest takie samo jak przy logice: wymień, co ma pozostać identyczne, i określ jedną rzeczą, którą wolno zmienić.

Zablokuj widoczną strukturę. Wymień layout (kolumny/wiersze, nagłówek i stopkę), zasady odstępów (padding, gapy, wyrównanie) i zachowanie komponentów (hover, disabled, spinnery, komunikaty o błędach). Jeśli komponent ma specyficzne odczucie, powiedz to wprost: „Rozmiar przycisku, promień narożników i kolor muszą pozostać dokładnie takie same.”

Zachowanie responsywne wymaga jednoznacznych reguł. Jeśli nie wspomnisz mobilnych wariantów, narzędzie może je „ulepszyć”. Podaj breakpoints, na których ci zależy i co ma się dziać przy każdym z nich: kolejność stackowania, ukryte elementy, stałe paski, cele dotykowe.

Zamroź też słowa. Powiedz modelowi, że całe copy, etykiety, placeholdery i pomocnicze teksty mają pozostać niezmienione, z wyjątkiem tej jednej etykiety, którą edytujesz. To zapobiega cichym przeróbkom, które zmieniają sens.

Kompaktowy prompt do wklejenia w zgłoszeniu zmiany:

• Zachowaj identyczne: trasy/ekrany, kolejność nawigacji i zachowanie przycisku wstecz
• Zachowaj identyczne: siatkę layoutu, odstępy, fonty, kolory i stany komponentów
• Zachowaj identyczne: cały tekst i etykiety, z wyjątkiem: <the one string>
• Reguły mobilne: zachowaj obecne zachowanie przy <breakpoints>, nie przeładowuj innych sekcji
• Output: opisz każdą zmianę UI, którą wprowadziłeś, i wypisz pliki/komponenty dotknięte

Jeśli możesz, poproś o before/after screenshoty. Jeśli ich nie ma, poproś o krótki "UI diff" (co się przesunęło, co zmieniło rozmiar, co zmieniło kolor), żebyś mógł zaakceptować z pewnością.

Jak zamrozić reguły biznesowe i zachowanie danych

Reguły biznesowe to miejsce, w którym mała zmiana UI może wywołać cichą regresję. Zmiana etykiety może przypadkowo zaburzyć obliczenie, przejście statusu czy widoczność rekordu. Traktuj reguły i zachowanie danych jak zamrożony kontrakt.

Zacznij od wypisania kilku reguł, które najbardziej bolą, jeśli się zmienią. Formułuj je jak testy: wejścia, wyjścia i kto ma uprawnienia do działania.

Wypisz reguły, które nie mogą się zmienić

Zamiast „trzymaj ceny takie same”, doprecyzuj:

• Cennik: dokładny wzór, zaokrąglanie (w górę/w dół), waluta, zachowanie podatku/VAT i moment stosowania rabatów
• Uprawnienia: które role mogą tworzyć, edytować, usuwać, zatwierdzać, zwracać, eksportować lub widzieć wrażliwe pola
• Statusy: dozwolone stany i prawidłowe przejścia między nimi (i co je wyzwala)
• Obliczenia: sumy, prowizje, kredyty, limity oraz wszelkie caps/minima
• Zapisy danych: jakie tabele/rekordy są tworzone lub aktualizowane i co musi pozostać niezmienne

Dodaj jeden przykładowy numer, aby wyeliminować interpretacje. Na przykład: „Suma zamówienia 120 USD, zniżka 10% (stosowana przed podatkiem), podatek 8,25% od kwoty po zniżce. Oczekiwana suma = (120 - 12) * 1.0825 = 116,91 USD. Zaokrąglamy do 2 miejsc dziesiętnych tylko na końcowym wyniku.”

Wymień widoczność opartą na rolach, nie tylko działania. Przykład: „Agenci wsparcia widzą status zamówienia i e-mail klienta, ale nie pełne dane karty. Tylko administratorzy mogą występować o zwrot środków.”

Jeśli walidacje mają znaczenie, zamroź je wprost. Podaj dokładny trigger i komunikat użytkownika: „Jeśli data początkowa jest późniejsza niż końcowa, zablokuj zapis i pokaż: 'End date must be after start date.' Nie zmieniaj tego sformułowania.” (zachowaj tekst dokładnie, jeśli to wymóg)

Nie zapomnij o efektach poza aplikacją. Jeśli wysyłasz e-maile, webhooki lub wywołujesz API zewnętrzne, zamroź, co ma pozostać takie samo: nazwy eventów, pola payload, timing (natychmiastowy vs opóźniony) oraz idempotency (brak duplikatów przy retry).

Krok po kroku: jak zrobić jedną bezpieczną zmianę

Traktuj drobną aktualizację jak mini-kontrakt. Wzorzec najlepiej działa, gdy zmiana jest wąska, a wszystko inne wyraźnie zamrożone.

1. Napisz zmianę jako jedno testowalne zdanie. „Na stronie ustawień dodaj przełącznik do włączenia trybu ciemnego” jest testowalne. „Ulepsz UI ustawień” nie jest. Jeśli nie możesz tego przetestować w 30 sekund, to wciąż za szerokie.

2. Napisz listę zamrożeń dla elementów, które zaboli zmiana: przepływ użytkownika, kluczowe elementy UI, reguły biznesowe, zachowanie danych i wszelkie API lub tabele bazodanowe, które muszą pozostać takie same.

3. Dodaj checklistę akceptacji i krótki plan testu. To zapobiega „u mnie działa” niespodziankom. Uwzględnij sprawdzenia typu: nowy przełącznik widoczny, istniejące ustawienia nadal się zapisują i nic innego na stronie się nie przesunęło.

4. Przed rozpoczęciem edycji poproś asystenta, żeby powtórzył twoje ograniczenia. Niech potwierdzi, co się zmieni i co ma pozostać identyczne. Jeśli podsumowanie jest błędne, popraw prompt przed pozwoleniem na zmiany.

5. Poproś o najmniejsze możliwe wdrożenie: bez refaktorów, bez zmiany nazw, bez formatowania poza dotkniętymi liniami i bez aktualizacji zależności. Kupujesz jedną zmianę, nie całkowity remont.

Krótka lista kontrolna przeglądu:

• Zmieniono tylko żądane zachowanie
• Zamrożone przepływy i ekrany nadal pasują
• Reguły biznesowe i zapisy danych są bez zmian
• Testy (lub kroki manualne) przechodzą zgodnie z opisem
• Żadne „cleanup” commity nie wśliznęły się

To szczególnie dobrze działa w Koder.ai: wklej listę zamrożeń do Planning Mode, poproś o echo ograniczeń, potem wygeneruj najmniejszy patch.

Typowe błędy, które wciąż powodują dryf

Większość „małych” edycji idzie nie tak z tego samego powodu: żądanie chroni cel, ale nie zachowanie. Model może osiągnąć cel w nowy sposób, który cicho zmienia ekrany, logikę lub dane.

Jedną pułapką jest zamrażanie rezultatu („upewnij się, że onboarding jest prostszy”) zamiast kroków po kroku które użytkownik wykonuje. Inną jest napisanie „zostaw wszystko takie samo” i założenie, że system wie, co to znaczy.

Błędy, które najczęściej powodują dryf:

• Bycie zbyt abstrakcyjnym: chronisz intencję, ale nie chronisz klik-po-kliku przepływu i oczekiwanych rezultatów.
• Pomijanie edge-case’ów: stany puste, ładowania, błędy walidacji, odmowa dostępu, zachowanie offline.
• Łączenie zmian: dwie lub trzy poprawki w jednym żądaniu zwiększają ryzyko kompromisów i regresji.
• Nie definiowanie „identyczne”: ten sam layout UI, te same wywołania API, te same zapisy do bazy, te same e-maile/zdarzenia analityczne.
• Akceptowanie „na oko”: wygląda OK, ale nie weryfikujesz kluczowych ścieżek.

Mały przykład: prosisz, żeby „przycisk był bardziej widoczny” i zamrażasz jedynie kolor, ale zapominasz zamrozić stan disabled. Aktualizacja może włączyć przycisk zawsze, zmieniając zachowanie w sposób, który zauważysz dopiero później.

Pomaga być konkretnym w tym, co nie może się ruszyć. Przed akceptacją wykonaj szybki regresyjny przegląd:

• Przeprowadź główny przepływ end-to-end (ten, który zamroziłeś).
• Wywołaj przynajmniej jeden stan błędu i jeden stan pusty.
• Sprawdź uprawnienia (admin vs zwykły użytkownik) jeśli to istotne.
• Potwierdź efekty uboczne: rekordy tworzone/aktualizowane, powiadomienia wysłane, i metryki/logi niezmienione.

Jeśli coś się różni, to znak, że w żądaniu brakowało konkretnej pozycji do zamrożenia, a nie że ktoś „źle zakodował”.

Przykład: drobna poprawka UI bez zmiany workflowu

Częsta bezpieczna iteracja to drobne poprawki UI, gdzie workflow musi pozostać niezmieniony.

Scenariusz: founder ma prosty ekran rejestracji z krótkim formularzem (Imię, E-mail, Rozmiar firmy) i główny przycisk, który przesyła formularz i przekierowuje użytkownika na dashboard.

Dokładne żądanie zmiany (jedno zdanie): „Zmień nazwę głównego przycisku z 'Create account' na 'Continue' i zamień pole 'Company size' z pola tekstowego na dropdown.”

Teraz zastosuj wzorzec:

• Zamrożenie przepływu: przesłanie nadal tworzy konto, pokazuje te same komunikaty walidacji i kieruje użytkownika do tego samego następnego ekranu.
• Zamrożenie UI: układ strony, odstępy, kolory i położenie przycisku pozostają takie same.
• Zamrożenie danych: klucze i typy payloadu backendu nie zmieniają się; przechowywany format wartości rozmiaru firmy pozostaje taki, jak wcześniej.
• Zamrożenie reguł biznesowych: pola wymagane pozostają wymagane, a przycisk pozostaje wyłączony dopóki formularz nie będzie poprawny.
• Zamrożenie analityki: te same zdarzenia śledzące odpalają się przy submit i przy walidacyjnych błędach.

Cztery szybkie checki, które wykonasz w minutach:

• Tekst przycisku wyświetla „Continue” wszędzie (default, loading, disabled).
• Company size to dropdown z tą samą domyślną wartością jak wcześniej.
• Po wysłaniu użytkownik trafia na dashboard i konto zostaje utworzone.
• Istniejący użytkownicy edytujący profil widzą zapisany rozmiar firmy poprawnie.
• Brak nowych ostrzeżeń lub nieudanych testów w obszarze rejestracji.

Dobry asystent powinien powtórzyć listę zamrożeń, wyjaśnić niejasności (np. jakie opcje w dropdownie i jaką wartość należy zapisać) i przygotować minimalną zmianę. Powinien też zaznaczyć, czego specjalnie nie dotykał (routing, logika walidacji, shape payloadu).

Szybka lista kontrolna przed akceptacją aktualizacji

Zanim zaakceptujesz „małą zmianę”, zrób szybki przegląd, który szuka cichego dryfu. Celem nie jest pełne QA — to potwierdzenie, że aplikacja nadal zachowuje się tam, gdzie napisałeś „nie zmieniać”, poza jedną zamierzoną poprawką.

5 szybkich checków (10 minut)

Wykonuj je w tej samej kolejności za każdym razem. To uspokaja przeglądy i ułatwia wykrycie regresji.

• Krytyczny przepływ kończy się end-to-end: Zacznij w punkcie wejścia, którego używa prawdziwy użytkownik (login, strona główna, dashboard) i dokończ główne zadanie.
• UI wygląda identycznie poza zamierzoną zmianą: Otwórz kluczowe zamrożone ekrany. Sprawdź layout, etykiety przycisków, odstępy i nawigację.
• Reguły biznesowe nadal się zgadzają: Sprawdź 2–3 przypadki, które często się psują, np. obliczenia rabatu, uprawnienia roli lub przejścia statusów.
• Kształt danych jest niezmieniony: Upewnij się, że nie ma nowych pól, zmienionych nazw pól, usuniętych pól ani migracji.
• Integracje pozostały nietknięte: Upewnij się, że nie zmieniono endpointów ani payloadów (nazwy pól, pola wymagane, kody statusu).

Kiedy cofnąć i ponowić żądanie

Cofnij zmiany, jeśli jakikolwiek zamrożony element się zmienił, nawet jeśli aplikacja „wciąż działa”. Zmieniona etykieta, nowe pole lub nieco inna reguła to znak, że model posunął się za daleko.

Ponów żądanie z ściślejszymi ograniczeniami: powtórz jedną zmianę w jednym zdaniu, wymień zamrożone przepływy i ekrany po nazwie i dodaj "no schema changes, no endpoint changes, no behavior changes outside X." Jeśli używasz Koder.ai, snapshot przed testem ułatwia rollback jednym krokiem, gdy coś się przesunie.

Następne kroki: stosuj to w Koder.ai dla bezpieczniejszych iteracji

Jeśli budujesz w Koder.ai, wzorzec „nie zmieniać” najlepiej działa jako nawyk: jedna mała zmiana, wszystko inne zablokowane i prosty sposób powrotu, jeśli coś się przesunie.

Zacznij od krótkiej fazy planowania

Zanim poprosisz o zmianę, przejdź do Planning Mode i poproś asystenta, aby powtórzył zakres twojej prośby w prostych słowach. Niech powtórzy dwie rzeczy: (1) dokładną zmianę i (2) jasną listę zamrożeń (przepływy, detale UI i reguły biznesowe, które nie mogą się ruszyć).

Przydatny planning prompt: „Powtórz moje żądanie. Potem wypisz, co nie może się zmienić. Jeśli coś jest niejasne, zapytaj przed edycją.”

Chroń każdą iterację snapshotami

Traktuj każde zgłoszenie o zmianę jak checkpoint. Zrób snapshot przed aktualizacją, potem kolejny po weryfikacji. Jeśli coś pęknie, rollback jest szybszy niż łatanie błędnej zmiany.

Przykładowy workflow:

• Zrób snapshot: „Before - change button label only”
• Wykonaj planowanie i potwierdź listę zamrożeń
• Poproś o jedną zmianę i krótki summary w stylu diff
• Zweryfikuj checklistę (UI, przepływy, reguły, dane)
• Zrób snapshot: „After - verified”

Stosuj wzorzec w całym stacku

Koder.ai może generować web (React), backend (Go + PostgreSQL) i mobile (Flutter). Wzorzec pozostaje ten sam mimo różnic w kodzie. Zamrażaj elementy definiujące zachowanie, nie tylko pliki.

Jeśli zmieniasz endpoint backendu, zamroź kształt request/response, reguły walidacji i zapisy danych. Jeśli zmieniasz ekran mobilny — zamroź kolejność nawigacji, domyślne wartości pól i komunikaty o błędach. Jeśli zmieniasz logikę bazy, zamroź znaczenie istniejących wierszy i zadbaj o bezpieczne migracje.

Skopiuj szablon, wykonaj jedną małą zmianę dziś i weryfikuj ją checklistą zanim zaakceptujesz. Zachowaj szablon i używaj go dla kolejnych zmian, po jednej na raz.