Абсолютно согласен, и я думаю, что инструменты LLM могут стать движущей силой для принятия некоторых практик лучших команд/организаций в меньших командах, которые ранее не могли их оправдать.

Я думаю, что вы были бы безумны, если бы у вас было несколько сотен инженеров без линтера. Однако, если у вас всего два или четыре, возможно, вы просто никогда не достигнете активационной энергии для этого и будете в основном вести непродуктивные споры о стиле кода. Но добавьте Claude Code, и а) вы захотите этот линтер.

b) настройка этого линтера теперь занимает пять минут незначительных усилий по сравнению с "Одному человеку предстоит погрузиться в классическую задачу, связанную с интеграцией его со всеми IDE и т.д."

Для части моей аудитории, которая не знает: линтер — это автоматизированный инструмент, который может обеспечивать соблюдение стандартов кодирования, которые строже, чем те, которые может позволить язык. Например, вы можете принять внутреннее правило, что определенные юридические конструкции не допускаются.

В качестве примера существует очень краткое юридическое выражение во многих языках, называемое тернарным оператором. Тернарные операторы известны своей склонностью вызывать ошибки, и инженерная команда может решить, что, хотя они и кратки, с учетом рисков они не являются приемлемой функцией для использования.

В качестве примера того, что вы можете разумно регулировать с помощью линтера, о чем не хотите постоянно спорить с Claude Code: в Rails, something_id означает внешний ключ для таблицы something. Claude иногда забывает об этом, называя многие другие вещи id.

Вы можете, если хотите, написать правило линтера, которое будет выполняться каждый раз, когда код изменяется, и сообщать Клоду и остальному миру: "Вы назвали переменную box_id, но _ids используются только для обозначения ключей базы данных. Рассмотрите возможность использования box_code или другого имени."

Хорошая вещь в правилах линтера заключается в том, что в них можно встроить произвольные знания, специфичные для проекта. Один из повторяющихся аргументов, который японский salaryman был вынужден обсуждать много лет назад с (коллегами) носителями языка, не являющимися носителями языка: вы НЕ ДОЛЖНЫ использовать "subject."

Почему бы и нет? Потому что японские университеты делят академические предметы на 教科 (kyouka; предмет, такой как "математика") и 科目 (kamoku; предмет, такой как "линейная алгебра"), и поскольку подпредмет ужасно читать в коде, их называли романизированным японским, чтобы всегда быть однозначными.