Dowiedz się, jak używać wzorca „nie zmieniać”, by wprowadzić jedną niewielką poprawkę, zamrażając kluczowe przepływy UI, reguły biznesowe i krytyczne zachowania, tak aby nic innego nie uległo zmianie.
„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.
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:
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ś.
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.
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:
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.
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:
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ą.
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.
Zamiast „trzymaj ceny takie same”, doprecyzuj:
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).
Traktuj drobną aktualizację jak mini-kontrakt. Wzorzec najlepiej działa, gdy zmiana jest wąska, a wszystko inne wyraźnie zamrożone.
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.
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.
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.
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.
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:
To szczególnie dobrze działa w Koder.ai: wklej listę zamrożeń do Planning Mode, poproś o echo ograniczeń, potem wygeneruj najmniejszy patch.
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:
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:
Jeśli coś się różni, to znak, że w żądaniu brakowało konkretnej pozycji do zamrożenia, a nie że ktoś „źle zakodował”.
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:
Cztery szybkie checki, które wykonasz w minutach:
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).
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ą.
Wykonuj je w tej samej kolejności za każdym razem. To uspokaja przeglądy i ułatwia wykrycie regresji.
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.
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.
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ą.”
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:
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.
Używaj go zawsze, gdy chcesz wprowadzić jedną konkretną zmianę i zależy ci, by wszystko inne pozostało bez zmian. Jest szczególnie przydatny przy checkoutach, uwierzytelnianiu, rozliczeniach lub w każdym przepływie, gdzie drobny dryf powoduje realne problemy użytkowników.
Bo elementy aplikacji współdzielą komponenty, dane i reguły. Drobna edycja UI może dotknąć współużywanego komponentu, co przesunie layouty gdzie indziej, zmieni walidację lub payload API bez natychmiastowego zauważenia.
Napisz jeden jasny cel, a potem wypisz, co musi pozostać identyczne po zmianie. Kluczowe jest zamrożenie zachowania (przepływy, reguły, dane, integracje) i widocznych detali UI, a nie tylko stwierdzenie „nie psuj nic”.
Krótko, ale konkretnie: krytyczne przepływy, detale UI/UX które nie mogą się przesunąć, reguły biznesowe, zachowanie danych i integracje. Jeśli nie potrafisz nazwać tego, co ma zostać takie samo, model będzie zgadywał, a zgadywanie powoduje dryf.
Zamroź najmniejszy obszar, który cię chroni. Na przykład: zamroź checkout i jego współdzielone komponenty, ale nie cały projekt, jeśli zmieniasz etykietę na jednej stronie.
Wypisz podróże użytkownika krok po kroku i zdefiniuj, co znaczy „zrobione”. Dodaj typowe edge-case’y: zachowanie przyciski "wstecz", komunikaty o błędach, stany puste i odświeżania, żeby przepływ pozostał identyczny tam, gdzie użytkownicy to zauważą.
Wyraźnie zamroź strukturę widoczną: layout, odstępy, stany komponentów (hover/disabled/loading) i cały tekst oprócz jednego ciągu, który edytujesz. W przeciwnym razie modele „posprzątają” style lub przepiszą teksty, co może zmienić znaczenie lub układ.
Zamroź kontrakty: kształt request/response, reguły walidacji, uprawnienia, obliczenia oraz co i kiedy jest zapisywane. Dodaj jeden przykład liczbowy dla wrażliwych reguł (np. wyliczeń cen), żeby nie było miejsca na interpretację podczas implementacji.
Poproś o checklistę akceptacji, którą szybko uruchomisz, plus krótkie podsumowanie zmian w stylu diff. Potem przejdź zamrożone przepływy end-to-end, wywołaj przynajmniej jeden stan błędu i sprawdź, czy dane i integracje nie uległy zmianie.
Zrób snapshot przed zmianą, wykonaj fazę planowania, w której asystent powtórzy zakres i listę zamrożeń, zastosuj najmniejszy patch i po weryfikacji zrób snapshot po zmianie — rollback będzie błyskawiczny, jeśli coś się przesunie.