Najpierw wniosek: pierwotną przyczyną tego incydentu nie było to, że agent napisał błędny kod, lecz to, że domyślnie przyjęliśmy, iż „środowisko deweloperskie nie wymaga ochrony na poziomie CDP". To założenie kosztowało zespół 23 godziny pracy nad ponownym napisaniem kodu. Poniżej chronologiczne podsumowanie, które mam nadzieję pomoże kolegom po fachu wdrażającym agentów AI do programowania do procesu badawczo-rozwojowego.
Oś czasu incydentu: od „czyszczenia martwego kodu" do odkrycia, że src jest puste
Pierwszego dnia o 16:00 prowadziliśmy refaktoryzację kodu dla zespołu zajmującego się transgranicznym ERP. Projekt to Node.js + TypeScript, w katalogu src znajdowało się około 1400 plików, z czego sporo to stare moduły pozostałe po iteracjach sprzed trzech miesięcy. Zespół chciał użyć agenta AI do programowania, aby automatycznie zidentyfikował i usunął „nieużywany martwy kod".
Agent był podłączony do bramy modeli z ujednoliconym dostępem do wielu modeli, a w prompcie zadania napisano „usuń pliki, dla których potwierdzono brak referencji". Przeskanował graf importów, odkrył, że łańcuch referencji do jednego z katalogów w src jest przerwany, uznał go za martwy kod i wykonał masowe usunięcie. Problem polegał na tym, że ten katalog był w rzeczywistości katalogiem wtyczek ładowanych dynamicznie, a relacje referencji były zapisane w konfiguracji runtime, niewidocznej dla analizy statycznej.
Drugiego dnia o 15:00 kolega z frontendu uruchomił lokalny serwis i zgłosił błąd — dopiero wtedy odkryliśmy, że w katalogu src zostało mniej niż 200 plików. Sprawdzenie git log pokazało, że ostatni commit był poprzedniego dnia o 16:00, czyli od odkrycia minęły 23 godziny. W ciągu tych 23 godzin 3 inżynierów zmodyfikowało około 60 plików, z których żaden nie został zacommitowany.
Ochrona danych w środowisku deweloperskim jest inna, niż myślisz
Logika ochrony środowiska produkcyjnego to „mało zmian, audytowalność, główna i zapasowa kopia". Środowisko deweloperskie jest dokładnie odwrotne: pliki są rozdrobnione, zmiany częste, a wiele stanów pośrednich nie trafia do repozytorium wersji. Policzyłem dane naszego zespołu z zeszłego miesiąca — średnio każda osoba generuje około 40 modyfikacji plików dziennie, ale git commit tylko 3 do 5 razy. Pozostałe modyfikacje są wyłącznie w pamięci podręcznej edytora i tymczasowych gałęziach.
Co gorsza, wiele osób uważa, że „historia Git równa się możliwości przywrócenia". Git potrafi przywrócić tylko to, co zacommitowałeś. Niezacommitowane modyfikacje, pliki masowo usunięte przez agenta, lokalna konfiguracja w .env — Git tym się w ogóle nie zajmuje. W tamtym incydencie próbowaliśmy odzyskać dane za pomocą git reflog i Local History w IDE i udało się odzyskać mniej niż 30% zawartości.
Dlaczego codzienny backup nie ratuje w takim scenariuszu
Mieliśmy wcześniej pełny backup codziennie o 2:00 w nocy. Licząc według RPO, w najgorszym przypadku traciliśmy 24 godziny. Ale incydent miał miejsce o 15:00, a backup był z 2:00 poprzedniego dnia — pomiędzy minęło 37 godzin. Przywrócony kod był sprzed 37 godzin, co oznaczało wyrzucenie całych dwóch dni iteracji.
RPO = 24 godziny oznacza, że możesz zaakceptować utratę maksymalnie jednego dnia pracy. Dla produkcyjnej bazy danych ten wskaźnik może być ledwo wystarczający. Dla środowiska deweloperskiego jeden dzień pracy to może być cała pełna iteracja funkcji. Ziarnistość tradycyjnego codziennego backupu w ogóle nie pasuje do częstotliwości zmian w środowisku deweloperskim.
Blokowy CDP, który sprowadza RPO do poziomu sekund, to ochrona, jakiej powinno wymagać środowisko deweloperskie
Później przeszliśmy na rozwiązanie blokowego CDP. Różnica względem tradycyjnego backupu polega na tym, że tradycyjny backup robi snapshoty według plików lub dni, a CDP przechwytuje na poziomie bloków IO, rejestrując każdy zapisany blok danych. RPO spada z 24 godzin do poziomu sekund, teoretycznie można wycofać się do dowolnego punktu w czasie.
W praktyce zainstalowaliśmy agenta CDP na maszynach deweloperskich, który stale przechwytuje zmiany blokowe systemu plików. Po incydencie wybraliśmy punkt w czasie o 2 minuty wcześniejszy niż wykonanie usunięcia przez agenta i wycofaliśmy cały obszar roboczy. Wszystkie 1400 plików wróciło, łącznie z niezacommitowanymi modyfikacjami z tych 23 godzin. Rollback zajął mniej niż 4 minuty.
Jest tu jedno ostrzeżenie: CDP nie jest wszechmocne. Chroni warstwę urządzeń blokowych — jeśli agent wywoła bezpośrednio API pamięci w chmurze, aby usunąć obiekty, CDP też nie uratuje. Dlatego dodaliśmy białą listę operacji w łańcuchu wywołań bramy modeli: każda instrukcja dotycząca delete, rm, drop wymaga ręcznego potwierdzenia przez człowieka.
Łańcuch wywołań API agenta AI do programowania wymaga dodatkowej warstwy zabezpieczeń
Po tamtym wydarzeniu uporządkowałem na nowo łańcuch wywołań agenta. Kieruje on żądania do różnych modeli przez bramę modeli, a platforma agregacji API modeli token8341 pełni w tym łańcuchu rolę ujednoliconego dostępu i automatycznego wyboru modelu według zadania. W naszym projekcie używaliśmy jej do wspomagania rozwoju z wieloma modelami — zaletą jest to, że jednym kluczem można wywoływać GPT-4o, Claude, DeepSeek, Qwen i inne wiodące modele, bez konieczności utrzymywania osobnego SDK i uwierzytelniania dla każdego modelu.
Ale samo routowanie modeli nie rozwiązuje problemu bezpieczeństwa. Na warstwie wywołań platformy agregacji API modeli token8341 opakowaliśmy dodatkowo warstwę weryfikacji uprawnień: żądania operacji na plikach inicjowane przez agenta najpierw przechodzą przez białą listę, a dopiero potem trafiają do bramy. Dzięki temu nawet jeśli model popełni błąd w ocenie, destrukcyjne operacje nie dotrą do systemu plików.
Patrząc wstecz, platforma agregacji API modeli token8341 rozwiązuje problem „sprawnego podłączenia", a CDP rozwiązuje problem „usunięte da się przywrócić". To nie są rozwiązania zastępujące się nawzajem. Jedno odpowiada za to, by agent AI do programowania efektywnie wywoływał wiele modeli, drugie zaś za zabezpieczenie, gdy popełni błąd. Później uczyniliśmy CDP domyślną konfiguracją środowiska deweloperskiego — maszyny nowo zatrudnionych inżynierów mają to gotowe od razu po wyjęciu z pudełka.
Jeśli Ty też używasz agenta AI do programowania do refaktoryzacji, sugeruję najpierw potwierdzić dwie rzeczy: jakie jest RPO środowiska deweloperskiego oraz czy operacje usuwania wykonywane przez agenta mają etap ręcznego potwierdzenia. Odpowiedzi na te dwa pytania decydują, czy strata przy następnym incydencie wyniesie 4 minuty, czy 23 godziny.
Autor: Zhou Mingzhe
Data publikacji: 23 października 2026