DRY, KISS, YAGNI în era LLM: ce rămâne valid, ce se rupe

Principiile clasice ale ingineriei software — DRY, KISS, YAGNI — au fost scrise pentru oameni care citeau și scriau fiecare linie de cod. Constantele acelei lumi erau evidente: tastarea este lentă, cititul este și mai lent, iar costul reparării unei greșeli se compune cu fiecare dezvoltator care atinge abstracția greșită.

Dezvoltarea asistată de LLM schimbă acele constante. Generarea codului este rapidă. Repetarea ta însuți nu mai este o problemă de tastare. Unele principii încă se mențin; altele se inversează în liniște. Iată versiunea 2026 a fiecăruia.

DRY — Don't Repeat Yourself

Argumentul original era simplu: fiecare concept ar trebui să aibă o singură reprezentare autoritativă. Dacă duplici formula total = subtotal + tax, atunci când regulile de taxă se schimbă o vei actualiza în trei locuri, vei rata una și vei livra un bug.

Principiul este încă corect pentru concepte. Este aplicat greșit pe scară largă la forme de cod. Două funcții care arată la fel astăzi dar codifică reguli de business diferite — taxa de factură versus taxa de refund — nu sunt duplicate, sunt similare. Forțarea lor să împartă o implementare creează abstracția greșită, iar abstracția greșită este mai scumpă decât duplicarea a fost vreodată.

Ce s-a schimbat pentru LLM-uri. Un model care citește un codebase trebuie să urmărească fiecare strat de indirecție în cap. O funcție care apelează applyTaxRules(ctx, line) care dispatch-uiește pe ctx.kind la unul din trei helperi privați este mai greu de raționat pentru model decât trei funcții explicite, applyInvoiceTax, applyRefundTax, applyCreditNoteTax, una lângă alta.

Abstracțiile DRY grele — helperi generici cu cinci parametri care "funcționează pentru tot" — afectează măsurabil calitatea codului LLM. Modelul trebuie să încarce context din mai multe fișiere pentru a înțelege ce face helper-ul, iar cu cât trebuie să încarce mai mult, cu atât greșește mai mult.

Regulă actualizată pentru 2026:

• DRY pe concept, nu pe formă. Dacă două bucăți de cod se schimbă din motive diferite, nu sunt duplicate.
• Preferă trei funcții explicite, denumite, în detrimentul unei abstracții parametrizate, până când ai suficiente cazuri de utilizare (trei este pragul obișnuit) pentru a ști care este abstracția corectă.
• Inline-ează codul care este folosit într-un singur loc. Oprește crearea de helperi privați cu utilizare unică.

KISS — Keep It Simple, Stupid

KISS a rezistat cel mai bine din cele trei. Spune: preferă cea mai simplă soluție care rezolvă problema. Principiul este și mai corect în 2026, pentru că LLM-urile sunt excelente la cod simplu, idiomatic și progresiv mai slabe la cod inteligent.

Capcana este că "simplu" este contestat. Unele echipe cred că "simplu" înseamnă "cel mai scurt". Altele cred că înseamnă "cele mai puține dependențe". Altele cred că înseamnă "ce echipa știe deja".

Versiunea 2026: simplu înseamnă "ce inginerul mediu din această echipă poate citi și modifica încrezător după șase luni de absență." Nu cel mai inteligent. Nu cel mai elegant. Nu cel mai corect din punct de vedere teoretic. Cel mai plictisitor cod care își face treaba este aproape întotdeauna răspunsul corect.

Ce s-a schimbat pentru LLM-uri. Codul plictisitor este la ce sunt LLM-urile cele mai bune. Codul plictisitor este ce generează implicit. Codul plictisitor este ce citesc cel mai fiabil. De fiecare dată când ajungi la un pattern inteligent — un generic cu șapte parametri de tip, o metaclasă, un DSL evaluat la runtime — pariezi că valoarea inteligenței depășește costul pe care modelul (și echipa ta) îl va plăti în comprehensiune.

Acel pariu rar se plătește. KISS în 2026 este "lasă modelul să-ți dea răspunsul plictisitor și suprascrie-l doar dacă ai un motiv specific."

YAGNI — You Aren't Gonna Need It

YAGNI spune: nu construi pentru cerințe viitoare ipotetice. Construiește pentru cerințele pe care le ai acum. Când viitorul sosește, construiește pentru el atunci.

Acest principiu este mai important în 2026, dintr-un motiv non-intuitiv. Scrierea codului este ieftină. Adăugarea de funcționalități speculativ este mai ieftină ca niciodată. Ceea ce înseamnă că costul marginal de a construi ceva ce poate nu vei avea nevoie a scăzut — iar tentația de a face asta a crescut corespunzător.

Capcana: funcționalitățile speculative adaugă complexitate codebase-ului pe care fiecare modificare viitoare trebuie să o navigheze. Fiecare feature flag de "s-ar putea să vrem asta", fiecare punct de extensie de "în caz că vreodată", fiecare abstracție de "future-proofing" este un cost care se compune.

Regulă actualizată pentru 2026:

• Faptul că ceva este ușor de construit nu este un motiv să-l construiești.
• Feature flag-urile nu sunt gratuite. Fiecare este o ramură în codebase pe care fiecare modificare viitoare trebuie să o considere.
• "S-ar putea să internaționalizăm asta mai târziu" este cea mai scumpă propoziție din dezvoltarea web modernă. Fie internaționalizezi acum, fie nu — nu lăsa hook-uri i18n neutilizate.
• Punctele de extensie fără un consumator curent sunt cod mort. Șterge-le.

YAGNI este mai greu de urmat când costul marginal de adăugare a codului este scăzut. Disciplina contează mai mult decât înainte.

Două principii care merită adăugate

DRY/KISS/YAGNI au fost principiile unei ere mai mici. Două în plus aparțin pe listă acum.

LOL — Locality of Logic

Dacă o funcție modifică un lucru, modificarea ar trebui să fie vizibilă la locul apelului sau aproape de el. Side effects îngropate la trei niveluri adâncime — un logger care scrie pe disc, un "service" care în secret pune un job în coadă, un hook care mută starea globală — sunt bug-urile la care LLM-urile sunt cele mai slabe la găsit, pentru că cauza și efectul nu sunt în același context.

Un codebase din 2026 ar trebui să fie citibil de sus-în-jos în orice fișier dat. Dacă trebuie să urmărești un side effect prin graful de apeluri pentru a înțelege ce face o funcție, arhitectura eșuează modelul și omul.

POLA — Principle of Least Astonishment, dar pentru AI

Acesta este POLA din anii '70 cu o întorsătură modernă. Codul nu ar trebui să surprindă un cititor. În 2026, cititorul relevant este din ce în ce mai mult un LLM. Pattern-urile care surprind modelul — string-uri magice ca chei de dispatch, monkey-patching la runtime, excepție-ca-flux-de-control, globale implicite — produc output AI încrezător-dar-greșit.

Când modelul returnează cod care arată rezonabil dar face lucrul greșit, întreabă-te dacă există ceva surprinzător în codebase care l-a indus în eroare. De obicei există. Eliminarea acelei surprize — chiar dacă înseamnă cod ușor mai verbose — se plătește următoarele zece ori când un agent atinge acea zonă.

Când clasicele încă se aplică neschimbate

Merită să fim clari despre unde DRY/KISS/YAGNI sunt încă exact corecte:

• DRY pentru concepte cu adevărat partajate — tipul tău Money, modelul tău User, middleware-ul tău de autentificare. O singură sursă a adevărului, întotdeauna.
• KISS pentru tot ce nu vei rescrie — codul plictisitor la care nimeni nu trebuie să se gândească este codul cu cea mai mare pârghie din clădire.
• YAGNI pentru funcționalități premature — nu construi dashboard-ul de admin înainte să știi cine sunt adminii.

Principiile nu au devenit greșite. Aplicarea lor s-a îngustat, iar câteva noi își câștigă locul alături.

Cum arată asta în practică

Principiile se concretizează ca un set diferit de întrebări de code review:

• Această abstracție își câștigă locul, sau este aceeași formă fiind partajată de două concepte diferite? (DRY)
• Aceasta este versiunea plictisitoare, sau am devenit inteligenți? Inteligența se plătește? (KISS)
• Acest feature flag este efectiv activat în vreun mediu, sau este speculativ? (YAGNI)
• Pot vedea ce face această funcție fără să părăsesc fișierul? (LOL)
• Va surprinde asta un cititor proaspăt (uman sau model) peste șase luni? (POLA)

O echipă care internalizează aceste cinci întrebări scrie un codebase pe care tool-urile AI îl pot extinde rapid și pe care oamenii îl pot menține ani de zile. Cele două obiective se dovedesc a fi același obiectiv.

Principiile nu au fost niciodată despre viteza de tastare. Erau despre costul înțelegerii — iar în 2026, înțelegerea este singurul cost care contează.