Nazwij obecny problem
Agent może zaproponować kilka architektur realizujących tę samą funkcję. Jedna użyje istniejącego kontrolera i relacji modelu. Inna doda interfejs, repozytorium i serwis. Każdy dodatkowy element ma koszt czytania, utrzymania i zmiany. Oceniaj go względem obecnego problemu.
Przed implementacją zapisz wymagania: co się zmienia, jakie dane są zapisywane i które zachowanie musi pozostać zgodne. Poproś agenta o wskazanie istniejącego mechanizmu, który może wykorzystać. Gdy pracujesz w frameworku, jego standardowe konstrukcje są częścią kontekstu projektu.
Uzasadnij abstrakcję rzeczywistą potrzebą
Abstrakcja wyodrębnia wspólną regułę lub ukrywa szczegół, z którego inne części kodu nie muszą korzystać bezpośrednio. Ma sens, gdy usuwa rzeczywiste powtórzenie albo nadaje złożonej logice czytelną granicę. Jednorazowy kod delegujący prostą operację do kolejnej klasy może utrudnić śledzenie wykonania.
Z drugiej strony powielanie ważnej reguły w kilku miejscach tworzy ryzyko rozbieżności. Przykładem w Kodivo jest obsługa postępu przez przeglądarkę i MCP. Oba wejścia muszą przestrzegać tych samych reguł lekcji. Współdzielenie tej logiki odpowiada istniejącej potrzebie.
Zapytaj agenta: „Które konkretne wywołania korzystają z tej abstrakcji? Jaką regułę centralizuje? Czy rozwiązanie bez niej pozostaje czytelne?”. Odpowiedź powinna odwoływać się do kodu i wymagań.
Oceń zależność szerzej niż przez instalację
Biblioteka może oszczędzić implementację złożonego mechanizmu, ale staje się częścią utrzymywanego systemu. Sprawdź zgodność z wersją środowiska, sposób aktualizacji, licencję i zakres konfiguracji. Ustal, czy podobną funkcję zapewnia już framework.
Poproś agenta o opis najprostszego wariantu opartego na obecnych narzędziach i uzasadnienie propozycji pakietu. Do obsługi protokołu z uwierzytelnianiem gotowa, utrzymywana integracja może mieć praktyczne uzasadnienie. Dodanie pakietu do jednej operacji na tablicy wymaga innej oceny.
Nie stosuj reguły „zawsze mniej klas” mechanicznie. Celem jest kod, którego odpowiedzialności można zrozumieć i bezpiecznie zmieniać. Liczba plików sama w sobie tego nie mierzy.
Zachowaj możliwość wycofania zmian
Przy większej zmianie ustal zgodność danych i kontraktów. Jeśli zmieniasz format odpowiedzi, sprawdź istniejących odbiorców. Migracja bazy może wymagać zachowania starych danych i kolejności wdrożenia, w której poprzednia wersja aplikacji nadal działa.
Zleć małe, działające etapy z testami właściwych granic. Poproś o wskazanie, co można wycofać, a jaka operacja mogłaby bezpowrotnie usunąć dane. Osobno oceń implementację, zgodność i uruchomienie na produkcji.
Jeśli te pojęcia są nowe, wróć do funkcji i warunków w poprzednich wpisach, a podstawy PHP przećwicz w Kodivo. Własnego agenta możesz poprosić o pobranie odpowiedniej lekcji przez MCP i wyjaśnienie reguły na małym przykładzie.
