Een AI gebruikt standaard een generiek gemiddelde van zijn trainingsgegevens, dus om jouw stijl te krijgen moet je deze tonen en afdwingen — via voorbeelden, een expliciet regelbestand en een linter-loop die uitvallers opvangt. Verlaat je niet op het feit dat het je standaarden raadt (WordPress Coding Standards, PSR-12, enz.).
.eslintrc, phpcs.xml of .editorconfig. Dit zijn de regels in machineleesbare vorm, en de AI kan ze lezen.CLAUDE.md of systeemherinnering die de standaard expliciet stelt: "Dit project volgt PSR-12. Gebruik 4-space inspringing, accolades op de volgende regel voor functies, snake_case voor hooks." Permanente instructies besparen je herhaling.# 1. AI generates the change, then you run the project linter on it:
phpcs --standard=phpcs.xml src/NewClass.php
# => src/NewClass.php 12 | ERROR | Expected 1 space after FUNCTION keyword; 0 found
# src/NewClass.php 14 | ERROR | Line indented incorrectly; expected 4 spaces, found 2
# 2. Paste those exact errors back to the AI: "Fix these phpcs errors."
# 3. Re-run until clean. The linter — not the AI's claim — is the source of truth.
Deze loop convergeert snel omdat de linter precieze, regel-niveau feedback geeft waarop de AI direct kan reageren, in plaats van dat je de stijl in proza beschrijft.
Code die projectconventies negeert creëert reviewfrictie en inconsistentie zelfs als het functioneel correct is — reviewers verspillen tijd aan opmaak, en de codebase drift uit elkaar. Een AI heeft geen bewustzijn van jouw huisstijl tenzij je die levert, dus het werk is om de regels expliciet en controleerbaar te maken: een regelbestand voor intentie, representatieve code voor idiomatische conventies en de linter als handhaver in de loop. Dezelfde discipline (configuratie + voorbeelden + geautomatiseerde controle) is hoe je een menselijk teamgenoot ook aan je conventies leert.