Ich stimme absolut zu, und ich denke, dass LLM-Tools ein treibender Faktor für die Übernahme einiger Praktiken der besten Teams/Organisationen in kleineren Teams sein könnten, die diese zuvor möglicherweise nicht rechtfertigen konnten.

Ich denke, es wäre verrückt, mehrere hundert Ingenieure ohne einen Linter zu haben. Wenn Sie jedoch nur zwei oder vier haben, erreichen Sie vielleicht einfach nie die Aktivierungsenergie dafür und haben hauptsächlich unproduktive Kämpfe über den Codierungsstil. Aber fügen Sie Claude Code hinzu und a) Sie wollen diesen Linter.

b) Die Einrichtung dieses Linters erfordert jetzt fünf Minuten marginalen Aufwands im Vergleich zu "Eine Person begibt sich in eine klassische Tarpit-Aufgabe, um ihn mit allen IDEs usw. zu integrieren."

Für den Teil meines Publikums, der es nicht weiß: Ein Linter ist ein automatisiertes Tool, das Codierungsstandards durchsetzen kann, die strenger sind als die, die eine Sprache möglicherweise zulässt. Zum Beispiel können Sie eine Hausregel einführen, dass bestimmte rechtliche Konstruktionen nicht erlaubt sind.

Als Beispiel gibt es einen sehr knappen juristischen Ausdruck in vielen Sprachen, der als ternärer Operator bezeichnet wird. Ternäre Operatoren sind notorisch anfällig für Fehler, und ein Ingenieurteam könnte entscheiden, dass sie, obwohl sie knapp sind, auf einer risikoadjustierten Basis kein akzeptables Merkmal zur Verwendung sind.

Als Beispiel für etwas, das Sie sinnvoll über einen Linter regulieren können, über das Sie keine wiederholten Diskussionen mit Claude Code führen möchten: In Rails bedeutet something_id einen Fremdschlüssel für die something-Tabelle. Claude vergisst dies gelegentlich und nennt viele andere Dinge ids.

Du kannst, wenn du möchtest, eine Linter-Regel schreiben, die jedes Mal ausgeführt wird, wenn der Code geändert wird, und Claude und der restlichen Welt signalisiert: „Du hast eine Variable box_id genannt, aber _ids sollten nur verwendet werden, um auf Datenbankschlüssel zu verweisen. Überlege dir box_code oder einen anderen Namen.“

Eine schöne Sache an Linter-Regeln ist, dass sie beliebig projektspezifisches Wissen in sich tragen können. Ein wiederholtes Argument, das ein japanischer Angestellter vor langer Zeit mit (anderen) nicht-muttersprachlichen Sprechern, die eine Webanwendung für die Universität entwickelten, führen musste: Ihr dürft "subject" NICHT verwenden.

Warum nicht? Weil japanische Universitäten akademische Fächer in 教科 (kyouka; ein Fach wie „Mathematik“) und 科目 (kamoku; ein Fach wie „lineare Algebra“) unterteilen, und da Unterfächer in Code schrecklich zu lesen sind, wurden diese romanisiert bezeichnet, um immer eindeutig zu sein.