Műszaki irányelvek hiánya okozza az AI által generált kódok architekturális eltérését

Egy staff engineer, Priya, egy 340 soros pull requestet nyit, amely egy új végpontot ad hozzá — ez a végpont közvetlenül ír a customer táblába, megkerülve a belső customer service API-t. A kód tiszta, a tesztek futnak, és az az AI kódolóügynök, amely a változtatást előállította, már hat hónapja a csapat legeredményesebb hozzájárlója. A változtatást három hónapja a csapatban lévő reviewer jóváhagyja, és a PR még aznap bekerül a masterbe.

Két héttel később egy integrációs hibakeresés során kiderül, hogy a végpont által létrehozott customer rekordokból hiányoznak audit-log bejegyzések. Az audit hookok a customer service API-ban vannak. Két évvel korábban a csapat tiltott minden közvetlen adatbázis-hozzáférést pontosan ezért, és erről egy Architectural Decision Recordot (ADR) írtak: egy verziózott markdown dokumentumot, amely rögzíti a döntést, az indoklást és azt, hogy mit váltott ki. Az ADR szerzője azóta elment a csapattól, a jelenlegi fejlesztők pedig nem emlékeztek a döntésre; a dokumentum egy olyan könyvtárban volt, amelyet a napi munkafolyamat nem érintett.

A végpontot átírják, az audit-járulékokat pótolják, és a csapat egy sprint nagy részét a takarításra fordítja. Senki sem nevezte ezt az AI-asszisztált fejlesztés „hibájának”: az AI funkcionális, helyes kódot írt; egyszerűen olyan kódot, amely megsértette a korábbi, a csapat által meghozott architekturális döntést — egy dokumentumot, amelyhez az AI és a reviewer sem fértek hozzá.

Miért nem egyszerű modellminőség vagy hallucináció?

Ez a hibatípus nem hallucináció: a kimenet földelt, szintaktikailag helyes és idiomatikus volt. Nem is a modell „minőségének” hiánya, mivel jobb modell ugyanarra a promptra sem feltétlenül segített volna, ha a döntés hiányzik a kontextusból. Ez egy memória-probléma — nem a modell belső kontextusablakára vonatkozó értelemben, hanem szervezeti értelemben: az ADR létezett a repo-ban, de soha nem került az ügynök látóterébe, és a reviewer sem olvasta.

A Faros AI-jelentés: mennyiségi jelzés a visszafordításra

A Priya-eset egy szélesebb újraírási problémára mutat rá. A Faros AI, egy mérnök-analitika platform, 2026-ban közzétett egy jelentést, amely több mint 22 000 fejlesztő telemetriáján alapult, több mint 4 000 csapatból. A jelentés szerint az AI-kód elfogadási arányai 20%-ról 60%-ra nőttek az alacsony és magas AI-elfogadási periódusok között, miközben a kódcserélődés (azaz azok a sorok, amelyeket napokkal azután töröltek, hogy hozzáadták) ugyanazon időszak alatt 861%-kal nőtt.

A Faros óvatos a szám értelmezésével: a növekedés tartalmazhat termékeny refaktorálást, korábban megfizethetetlen takarítást vagy gyorsabb iteratív javulást is. Mégis, a szám kiemeli a távolságot a repo-ba kerülő kód és az ott megmaradó kód között — egy, az AI-elfogadással párhuzamosan táguló szakadékot. Anedotikusan a fejlesztők arról számoltak be, hogy visszatérnek és javítják az általuk már jóváhagyott kódot olyan problémák miatt, amelyek a review pillanatában nem voltak nyilvánvalóak. Az egyik lehetséges ok az architekturális drift: olyan kód, amely egyenként rendben van, de összességében eltéríti a codebase-t a korábban elfogadott iránytól.

Miért siklanak mellé a meglévő eszközök?

A csapatok több, meglévő mechanizmust próbálnak bevetni a rés bezárására — a legtöbb azonban nem a problémának megfelelő rétegben működik.

• A legközelebbi kísérletek gyakran rövid, szabad szöveges markdown fájlok (pl. Cursor Rules vagy CLAUDE.md), amelyeket a projekt gyökérkönyvtárába helyeznek, hogy az ügynökök „állandó utasításként” olvashassák őket. Ez jó ösztön, de rossz felbontás: a szabad szövegnek nincs precedensrendszere, nincs verzió-életciklusa, és nincs eldöntő mechanizmusa, ha két szabály ellentmond.
• A linterek és kódformázók alacsonyabb rétegen működnek: a típusok, névadási konvenciók ellenőrzése szintaktikai szinten. Nem tudják kikényszeríteni, hogy az ügyféladat-írások a customer service API-n keresztül történjenek, mert ez nem szintaktikai, hanem szemantikai és architekturális döntés.
• A dependency scanner-ek, SCA eszközök és lockfile auditok a függőségek sebezhetőségeit, licenc- és verzióproblémáit fogják fel; Priya PR-jében semmit sem jeleztek volna, mert minden dependency naprakész, jóváhagyott és sérülékenység-mentes volt. A megsértés a csapat saját routing-döntése volt, nem külső könyvtár-probléma.
• Az LLM-alapú kódreview divatos válasz: egy második AI olvassa a PR-t és kommentel. Ez felszínibb problémákat észlelhet (elnyelt exception, off-by-one), de nem karanténozza az architekturális driftet, mert ugyanehhez a problémához ugyanaz a vakfolt tartozik: a második modell se látja a csapat rögzített döntéseit.
• Az emberi review végső védvonal lehet, ha a reviewer ismeri a történetet és van elég ideje. Az agentikus fejlesztés azonban mindkét feltételt megváltoztatja: az ügynökök sok implementációt, PR-t és revíziót képesek előállítani abban az időben, amíg egy ember egy változtatást megvizsgál. A kód skálázódik; a review figyelem nem. Arra kérni az embereket, hogy többet és alaposabban ellenőrizzék, csupán a korlátot tolná lejjebb a folyamatban.

Ezek az eszközök nem rosszak — egyszerűen nem a megfelelő rétegen célznak.

Mire lenne szükség: az "engineering governance" réteg

A hiányzó réteg összeköti a rögzített mérnöki döntéseket azokkal az eszközökkel, amelyek kódot generálnak, review-znak és merge-elnek. Feladata, hogy a csapat összegyűlt architekturális döntéseit gépileg olvashatóvá, befecskendezhetővé és kikényszeríthetővé tegye. Ezt a réteget engineering governance-nek nevezem, a data governance és security governance fogalmak mintájára: strukturált mód arra, hogy egy szervezet kifejezhetővé és érvényesíthetővé tegye a már implicit szabályait.

Formailag négy alapfunkcióra van szükség:

1. Döntések tárolása strukturált korpuszként, precedencia- és életciklus-metadataival, hogy egy eszköz eldönthesse, melyik ADR érvényes, ha kettő ütközik, és mely döntések aktívak még.
2. Megbízható lekérés ebből a korpuszból, hogy ugyanaz a kód ugyanazokat a releváns döntéseket kapja minden lekéréskor.
3. A döntések befecskendezése az AI kontextusába még a kódírás előtt, hogy a generált kimenet alapból figyelembe vegye őket.
4. Kikényszerzés a CI-ben: blokkolás vagy jelzés olyan kódra, amely megsérti a döntéseket, és a döntés legyen nyomon követhető egy konkrét ADR-hez, egy konkrét szabályszöveghez és a megfelelő egyezéshez.

A négy pontot összekötő kritikus tulajdonság az, hogy világos fegyelem legyen arról, hol engedélyezett a probabilisztikus érvelés. A probabilisztikus rendszerek ajánlhatnak vagy kereshetnek, de nem hozhatnak önálló, végleges kikényszerítési ítéletet. Minden blokk vagy figyelmeztetés rekonstruálható legyen a lemezen lévő artefaktumokból: a kódból, az ADR-ből, a lekérési naplóból és a szabály szövegéből. Ha egy fejlesztő rákérdez, hogy „miért bukott el?”, vagy egy auditor megkérdezi, „mi alapján?”, a válasz ne az legyen, hogy „az AI mondta”. Ez a determinisztikus, reprodukálható út adja meg a réteg védhetőségét szabályozott környezetekben, megfelelőségi vizsgálatoknál, incidens retrospektívákon és a napi vitákban.

Az AI segíthet releváns döntések felhozatalaiban, de nem lehet a végső hatóság. A kikényszerítési láncnak determinisztikusnak és reprodukálhatónak kell maradnia.

Mi nem tartozik ide — a határok tisztázása

Jól definiálni a kategóriát azt is jelenti, hogy megmondjuk, mi nem része:

• Nem egy agent: semmi autonómia, semmi iteratív cselekvés. A réteg meghívásra fut, ítéletet ad és leáll.
• Nem pusztán RAG-memória: a lekérési módszerek lehetnek probabilisztikusak, de az érvényesítés ítélete nem lehet az.
• Nem AI-által review-zott kód: egy második modell általi review nem orvosolja a fő probléma gyökerét.
• Nem vendor-locking: a csapatok gyakran párhuzamosan futtatnak Cursor-t, Claude Code-ot, GitHub Copilotot, Codex-et és ön-hostolt, nyílt súlyú modelleket. Az engineering governance független kell legyen mind a kódolóeszköztől, mind az alatta futó modelltől, hogy ugyanazok az architekturális döntések és determinisztikus kikényszerítések alkalmazhatók legyenek minden eszközre.

Az alakuló mérnöki stack és miért számít ez minden csapatnak

Az AI-kódoló stack nyíltan épül össze, anélkül, hogy bárki teljes architektúrát határozna meg. A különböző asszisztensek specializálódnak a loop más-más részére: szerkesztésre, autonóm végrehajtásra, review-ra, tervezésre. Amit a stack még nem tartalmaz, az az engineering governance.

Ez az igény nem csak a szabályozott iparágakra korlátozódik. Bárhol, ahol fontos a megbízható mérnöki munka, a hosszú távú termékminőség és az ügyfelek bizalma, szükség van arra biztosítékra, hogy a generált kód tiszteletben tartja a rendszer függőségeit és döntéseit. Magasabb kockázatú környezetekben ez formális, auditálható követelménnyé válik; máshol ez a felelős szoftverépítés része. Mindkét esetben a kikényszerítési út legyen determinisztikus és nyomon követhető.

Mit tegyenek a mérnöki vezetők az elkövetkező negyedévben?

Priya PR-je mintázat, nem egy elszigetelt incidens. Három gyakorlati lépés, amelyet érdemes megtenni, függetlenül a választott eszközöktől:

1. Auditálják az Architectural Decision Recordokat (ADR). Frissek-e? Egyértelműen nevesítik-e, mit váltottak ki? Ha a csapat nem ír ADR-eket, most van itt az ideje elkezdeni.
2. Döntsék el szándékosan az érvényesítési pozíciót: a rendszer csak figyelmeztessen, vagy blokkolja a változtatást, amíg a probléma meg nem oldódik? Mindkét megközelítés működhet, de a csapat egyezzen meg benne.
3. Ne bízzanak abban, hogy egy erősebb modell majd megoldja a problémát. A jobb modellek javíthatnak a generált kódon, de nem követik azokat az architekturális döntéseket, amelyeket nem kaptak meg.

A produktivitásnyereségek az AI-asszisztált fejlesztésből valósak és értékesek — akárcsak az a szerkezeti koherencia, amelyet a csapatok évek alatt építettek ki. Az engineering governance az a réteg, amely lehetővé teszi, hogy mindkettőt egyszerre megtartsuk.