Ik ben het er absoluut mee eens, en ik denk dat LLM-tools een drijvende kracht kunnen zijn voor het aannemen van enkele van de praktijken van de beste teams/organisaties bij kleinere teams die deze misschien eerder niet konden rechtvaardigen.

Ik denk dat je gek zou zijn om meerdere honderden ingenieurs te hebben zonder een linter. Als je er echter maar twee of vier hebt, is het misschien gewoon nooit mogelijk om de activatie-energie daarvoor te bereiken, en heb je vooral onproductieve ruzies over de codestijl. Maar voeg Claude Code toe en a) je wilt die linter.

b) het opzetten van die linter kost nu vijf minuten van marginale inspanning in vergelijking met "Een persoon daalt af in een klassieke tarpit-taak om het geïntegreerd te krijgen met alle IDE's/etc."

Voor het deel van mijn publiek dat het niet weet: een linter is een geautomatiseerd hulpmiddel dat coderingconventiestandaarden kan afdwingen die strenger zijn dan wat een taal zou toestaan. Je kunt bijvoorbeeld een huisregel aannemen dat bepaalde juridische constructies niet zijn toegestaan.

Als voorbeeld is er een zeer beknopte juridische uitdrukking in veel talen die een ternary operator wordt genoemd. Ternary operators staan erom bekend dat ze vaak bugs veroorzaken, en een engineeringteam kan besluiten dat, hoewel beknopt, ze op basis van risico-analyse geen aanvaardbare functie zijn om te gebruiken.

Als voorbeeld van iets dat je verstandig kunt reguleren via een linter waar je geen herhaalde discussies met Claude Code over wilt hebben: in Rails betekent something_id een vreemde sleutel voor de something-tabel. Claude vergeet dit af en toe, en noemt veel andere dingen ids.

Je kunt, als je wilt, een linterregel schrijven die elke keer wordt uitgevoerd wanneer de code wordt gewijzigd en Claude en de rest van de wereld waarschuwt: “Je hebt een variabele box_id genoemd, maar _ids mogen alleen worden gebruikt om naar database-sleutels te verwijzen. Overweeg box_code of een andere naam.”

Een mooi aspect van linterregels is dat ze willekeurige project-specifieke kennis kunnen bevatten. Een herhaald argument dat een Japanse salariman lang geleden moest voeren, met (medewerkers) niet-native sprekers die een universitaire webapplicatie maakten: je MAG "subject" NIET gebruiken.

Waarom niet? Omdat Japanse universiteiten academische vakken onderverdelen in 教科 (kyouka; een vak zoals "wiskunde") en 科目 (kamoku; een vak zoals "lineaire algebra"), en aangezien subvak vreselijk is om in code te lezen, werden deze aangeduid met geromaniseerde Japanse termen om altijd ondubbelzinnig te zijn.