Zielony zestaw testów to nie przegląd
Testy sprawdzają przypadki, o których ktoś pomyślał. Agent zmieniający zachowanie może zostawić wszystkie testy zielone, bo luźno utrwalały stare zachowanie albo bo nic nie pokrywało tej ścieżki. Zielony wynik dowodzi, że zmiana się uruchamia, a nie że jest poprawna.
To samo dotyczy schludnego streszczenia: opis pracy agenta to twierdzenie tego samego systemu, który wprowadził zmianę. Czytaj diff, nie notkę wstępną, i traktuj testy jako jeden z kilku sygnałów.
Zaczynaj od czystego, odwracalnego stanu
Przed pierwszym promptem: zrób commit lub schowaj pracę, utwórz gałąź i dokładnie wiedz, jak wrócić. Agent z dostępem do terminala może uruchamiać migracje, przepisywać konfigurację i usuwać pliki; odwracalny punkt startu zamienia wypadek w niedogodność.
Jeśli zadanie dotyka danych regulowanych lub poufnych, użyj jednorazowej kopii projektu i rozmowy bez sekretów. Warunki i dokumentacja danych dostawcy decydują, co opuszcza twój komputer — przeczytaj je, zamiast zakładać granicę.
Czytaj diff w kolejności, w której boli
Dużą wygenerowaną zmianę najlepiej przeglądać w świadomej kolejności, a nie od góry do dołu.
- Punkty wejścia: trasy, handlery, uprawnienia i wszystko, co zmienia kto do czego dociera.
- Dane: schemat, migracje, serializacja i zapytania, zwłaszcza to, co usuwa lub nadpisuje.
- Konfiguracja: zmienne środowiskowe, kroki builda, CI i ustawienia wdrożenia.
- Reszta: nazwy, struktura, duplikacja i kosmetyczne zmiany, które powiększają diff.
Potem przeczytaj dodane testy i zapytaj, czego nie obejmują. Agent, który napisał i kod, i test, może zapisać to samo nieporozumienie dwa razy.
Zależności, sekrety i linie, których nikt nie czyta
Nowe zależności to najcichsze ryzyko wygenerowanego patcha: znajomo brzmiąca nazwa pakietu, wersja znikąd, lockfile przepisany w całości. Sprawdź, co dodano, dlaczego i czy projekt nie miał już czegoś, co wystarczało.
Szukaj poświadczeń, tokenów i wewnętrznych adresów URL, których nie powinno być w commicie, i sprawdź, czy logi nie wypisują teraz danych klientów. To właśnie te linie przegląda się pobieżnie — i dokładnie te, przy których agent nie ma powodu być ostrożny: optymalizuje pod żądanie, nie pod twój model zagrożeń.
Kiedy to wyrzucić
Jeśli diff jest większy niż zadanie, jeśli nie umiesz wyjaśnić fragmentu bez zgadywania albo zmiana leczy objaw, a nie przyczynę, usuń gałąź. Zaczęcie od węższego żądania kosztuje mniej niż utrzymywanie kodu, którego nikt nie rozumie.
Ta sama zasada dotyczy promptu: lista kontrolna z naszego przewodnika po Manus i porady o strukturze z naszego przewodnika po Prompt Cowboy skracają diff. Zacznij od naszego przeglądu Freebuff, a sposób traktowania linków polecających opisuje nasze oświadczenie o afiliacji.
Najczęstsze pytania
Czy pozwolić mu uruchamiać polecenia w terminalu?+
Dostęp do terminala czyni agenta kodującego użytecznym i ryzykownym, a dostawca decyduje, jak działają uprawnienia. Zacznij od jednorazowej kopii lub tymczasowej gałęzi, obserwuj pierwsze uruchomienia i trzymaj poświadczenia poza zasięgiem; polecenie, które tylko czyta pliki, to inne żądanie niż wdrożenie.
Czy darmowy agent kodujący wystarczy do prawdziwej pracy?+
Do pracy mechanicznej, którą potrafisz przejrzeć — tak. Darmowość to model biznesowy, nie gwarancja jakości: dostawca finansuje go reklamami i może zmieniać modele, limity lub funkcje. Decyduje to, czy umiesz przeczytać i przetestować wynik, a nie cena.
Czy muszę ujawnić, że kod napisał agent?+
Stosuj zasady zespołu, repozytorium i licencji oraz odpowiadaj szczerze, jeśli ktoś zapyta. Zawodowo liczy się to, że człowiek przejrzał zmianę i za nią odpowiada; ryzykiem jest wygenerowany patch, którego nikt nie przeczytał, a nie narzędzie, które go napisało.
Źródła i dalsza lektura
Oficjalna dokumentacja dostawcy, sprawdzona 2026-10-26. Warunki mogą się zmieniać; sprawdź wersję dla swojego kraju.