Agent psuje wam przyciski, bo błąd nie mówi mu, co zrobić

Agent dostaje zadanie i pisze <Button className="p-4">Zapisz</Button>. Z jego perspektywy sprawa jest zamknięta, bo komponent się renderuje, nic się nie wysypało, można lecieć dalej. Tyle że w waszym systemie projektowym Button sam pilnuje swoich odstępów, a od wielkości jest osobny prop, więc właśnie wjechał wam do kodu przycisk inny niż wszystkie pozostałe. Jeśli zabezpieczyliście to typami, TypeScript owszem krzyknie, że padding nie występuje w typie propsa. Na tym jednak informacja się kończy: agent wie już, czego nie wolno, ale nie wie, co wstawić zamiast tego, więc zgaduje. Raz opakuje przycisk dodatkowym divem, raz dorzuci margines w przypadkowym miejscu.

Dokładnie w ten moment celuje @shadcn/lint, wtyczka od ekipy shadcn/ui do ESLinta i do napisanego w Ruście Oxlinta, który robi to samo szybciej. Wystarczy projekt na Tailwindzie v4, samo shadcn/ui nie jest do niczego potrzebne, a cała stawka leży nie w tym, co reguły wyłapują, tylko w tym, co mówią. Ten sam p-4 na Buttonie zwraca teraz komunikat, który tłumaczy, że Button sam zarządza swoimi odstępami, i podpowiada, żeby sięgnąć po jeden z jego rozmiarów, wymieniając z nazwy te dostępne w waszym repozytorium. Na odstęp wokół proponuje margines obok albo gap na rodzicu.

Przez 20 lat komunikaty lintera pisało się dla człowieka, który w razie czego wstanie i zapyta kogoś z zespołu. Teraz czyta je model, który ma jedno podejście, nikogo nie dopyta i nie pamięta waszych ustaleń sprzed pół roku, więc wszystko, czego ma się przy okazji nauczyć, musi zmieścić się w treści samego błędu. Błąd przestaje być powiadomieniem, a staje się kanałem, którym dowozicie zasady systemu projektowego w sekundzie, w której są potrzebne. To jest moim zdaniem prawdziwa zmiana, bo plik AGENTS.md, w którym spisujecie agentowi zasady pracy z waszym repozytorium, agent czyta raz, na początku sesji, a po 40 turach zostaje z nich mgliste wspomnienie.