O inteligență artificială se implicită într-o medie generică a datelor pe care a fost antrenată, deci pentru a obține stilul tău trebuie să-l arăți și să-l enforțuezi — prin exemple, un fișier explicit de reguli, și o buclă de linter care prinde ceea ce scapă. Nu te baza pe faptul că va ghici standardele tale (WordPress Coding Standards, PSR-12, etc.).
.eslintrc, phpcs.xml, sau .editorconfig. Acestea sunt regulile în formă verificabilă de mașină, și AI-ul le poate citi.CLAUDE.md sau system prompt care enunță standardul explicit: "Acest proiect urmează PSR-12. Folosește indent de 4 spații, acolade pe linia următoare pentru funcții, snake_case pentru hook-uri." Instrucțiunile permanente sunt mai bune decât să te repeți la fiecare prompt.# 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.
Această buclă converge repede pentru că linterul furnizează feedback precis, la nivel de linie, pe care AI-ul poate acționa direct, în loc ca tu să descrii stilul în proză.
Codul care ignoră convențiile proiectului creează fricțiune în revizuire și inconsistență chiar și când este funcțional corect — reviewerii pierd timp cu formatarea, și codebase-ul se dezleagă. Un AI nu are conștientizare a stilului tău de casă decât dacă i-l furnizezi, deci munca este să faci regulile explicite și verificabile: un fișier de reguli pentru intenție, cod reprezentativ pentru idiomuri, și linterul ca enforcer în buclă. Aceeași disciplină (configurație + exemple + verificare automatizată) este cum integrezi un coechipier uman în convențiile tale, de asemenea.