Zgadzam się w pełni i myślę, że narzędzia LLM mogą być czynnikiem wymuszającym przyjęcie niektórych praktyk najlepszych zespołów/organizacji w mniejszych zespołach, które wcześniej mogły nie być w stanie ich uzasadnić.

Myślę, że byłoby szaleństwem mieć kilkuset inżynierów bez lintera. Jeśli masz tylko dwóch lub czterech, to być może nigdy nie osiągniesz energii aktywacji do tego, a zamiast tego będziesz miał głównie nieproduktywne kłótnie o styl kodowania. Ale dodaj Claude Code i a) chcesz mieć ten linter.

b) skonfigurowanie tego lintera zajmuje teraz pięć minut marginalnego wysiłku w porównaniu do "Jedna osoba schodzi w klasyczne zadanie tarpit, aby zintegrować to ze wszystkimi IDE/itd."

Dla części mojej publiczności, która nie wie: linter to zautomatyzowane narzędzie, które może egzekwować standardy konwencji kodowania, które są surowsze niż te, które może dopuszczać dany język. Na przykład, możesz przyjąć zasadę, że określone konstrukcje prawne nie są dozwolone.

Na przykład istnieje bardzo zwięzłe wyrażenie prawne w wielu językach zwane operatorem trójargumentowym. Operatory trójargumentowe są notorycznie skłonne do powodowania błędów, a zespół inżynieryjny może zdecydować, że, chociaż zwięzłe, na podstawie analizy ryzyka nie są akceptowalną funkcją do użycia.

Jako przykład rzeczy, którą można sensownie regulować za pomocą lintera, o którą nie chcesz mieć powtarzających się kłótni z Claude Code: w Rails, something_id oznacza klucz obcy dla tabeli something. Claude czasami o tym zapomina, nazywając wiele innych rzeczy id.

Możesz, jeśli chcesz, napisać regułę lintera, która będzie wykonywana za każdym razem, gdy kod zostanie zmodyfikowany i powiadomi Claude'a oraz resztę świata: „Nazwalesz zmienną box_id, ale _ids są używane tylko do odniesienia się do kluczy bazy danych. Rozważ box_code lub inną nazwę.”

Fajną rzeczą w zasadach lintera jest to, że mogą mieć wbudowaną dowolną wiedzę specyficzną dla projektu. Jednym z powtarzających się argumentów, które japoński salaryman musiał prowadzić dawno temu, z (współ) nie-native speakerami tworzącymi aplikację internetową na uniwersytecie: NIE MOŻESZ używać „subject.”

Dlaczego nie? Ponieważ japońskie uniwersytety dzielą przedmioty akademickie na 教科 (kyouka; przedmiot taki jak „matematyka”) i 科目 (kamoku; przedmiot taki jak „algebra liniowa”), a ponieważ podprzedmiot jest okropny do odczytania w kodzie, te były określane za pomocą romanizowanego japońskiego, aby zawsze były jednoznaczne.