AI pisze kod, który się kompiluje, ale potrafi wysypać stronę. Ustawiłem zasady

Gdy daję agentom AI wolną rękę przy kodzie frontendu, pojawia się problem, który nazywam "AI slop", czyli kod, który na pierwszy rzut oka wygląda dobrze, a w środku ma pułapki.

Co znalazłem: kompilator nie był oszukiwany, tylko zbywany

Kompilator to program, który sprawdza kod przed uruchomieniem. Agent potrafił uciszyć go zamiast naprawić problem. Trochę jak mechanik, który zamiast sprawdzić stukanie w silniku, zakleja lampkę kontrolną taśmą.

Najczęstsze sztuczki to trzy:

• Wymuszanie typów. Zapis w stylu as unknown as T mówi kompilatorowi: "uwierz mi, to na pewno jest profil użytkownika". Nikt tego nie sprawdza.
• Wyłączanie sprawdzania. Typ any wyłącza kontrolę całego fragmentu kodu.
• Ufanie serwerowi. Kod zakłada, że odpowiedź zawsze ma oczekiwany kształt.

Efekt był taki, że aplikacja się budowała bez ostrzeżeń, a po błędzie serwera strona pokazywała pusty ekran.

Dlaczego to ważne

Panel w Agent Operations Center pokazuje dane, na których opiera się praca. Biały ekran w takim miejscu oznacza, że nikt nie zobaczy stanu agentów akurat wtedy, gdy jest on potrzebny. Dodatkowo kod, który trzeba potem ręcznie poprawiać, kosztuje więcej niż kod napisany dobrze od początku.

Jak to naprawiłem

1. Brak skrótów przy typach. Agent nie może używać as unknown as T. Gdy naprawdę potrzebuje asercji, dopisuje komentarz z uzasadnieniem. Kod bez uzasadnienia odpada na etapie przeglądu.
2. Sprawdzanie danych na wejściu. Dane z sieci przechodzą przez schemat, czyli zestaw reguł opisujący, jak mają wyglądać. Biblioteka Zod sprawdza każde pole, a gdy coś się nie zgadza, pokazuje czytelny komunikat, na przykład "brakujące pole: email".
3. Jasne stany zamiast wielu flag. Zamiast pięciu osobnych znaczników typu isLoading i isError, które mogą być jednocześnie prawdziwe, komponent ma jeden stan: ładowanie, błąd albo gotowe dane.

Czego się nauczyłem

• Agentom AI trzeba stawiać granice. Moją rolą jest projektowanie zasad, a nie tylko pisanie promptów.
• Błąd kompilatora zwykle oznacza brak obsługi jakiegoś przypadku. Nie należy go wyciszać.
• Dane z zewnątrz trzeba sprawdzać na granicy systemu, niezależnie od tego, kto napisał kod.