Az AI Tervezési Hatóság

Szoftverfejlesztés fordulóponthoz érkezett. A vita gyakran arról szól, melyik az AI írja-e a legjobb kódot (Claude vs. ChatGPT) vagy hol hogy hol kell az AI-nak laknia (IDE vagy CLI). De ez nem a helyes kérdésfeltevés.

A probléma nem a generálás kóddal. Hanem a ellenőrzés miatta.

Ha elfogadjuk az AI-t „Vibe Coders” szerepként – ahol megadjuk a szándékot, és az AI végrehajtja – hatalmas mennyiségű új szoftvert hozunk létre. Egy AI-ügynökraj percenként több kódot generálhat, mint egy senior fejlesztő egy hét alatt átnéz. Az ember vált a szűk keresztmetszetté.

A megoldás nem több emberek. A megoldás egy AI-tervezési hatóság.

A mestertől a gyárigazgatóig

Hagyományosan a „Design Authority” egy kis csapat építészt jelent, akik hetente vagy havonta összegyűlnek, hogy jóváhagyjanak vagy elutasítsanak egy tervet. Egy világban magas sebességű MI fejlesztés ez a modell reménytelenül elavult. Túl lassú és túl reaktív.

Ha áttérünk a „eldobható kódra” – olyan szoftverre, amelyet nem végtelenül refaktorálunk, hanem kidobunk és újragenerálunk, ha a követelmények változnak – akkor a szerepünk alapvetően megváltozik. Már nem ácsok vagyunk, akik követ raknak egymásra. Mi vagyunk a gyár tervezői, amely a falakat nyomtatja.

De ki ellenőrzi, hogy azok a falak egyenesek-e?

A „Kesztyűpróba”: Egy automatizált tűzpróba

Egy MI Design Authority nem egy személy, hanem egy csővezeték. Egy „Gauntlet”, amelyen minden generált kódsor végig kell menjen, hogy bekerüljön a produkcióba. Ez a folyamat nem helyettesíti az emberi kódátvizsgálatot semmivel, hanem valami mással jobbbal.

Három rétegben működik:

1. A Végrehajtó Hatalom (A Generálás)
Nem egy MI-t kérünk fel megoldásra, hanem hármat. Ugyanarra a problémára párhuzamosan kérjük meg a Gemini 3-at, a GPT-5-öt és egy nyílt forráskódú modellt (például Llama-t). Ez megakadályozza az alagútlátást és megtöri azt a „lustaságot”, amivel az LLM-ek néha küzdenek. Ez a megközelítés továbbá tudományosan kutatott és bizonyítja, hogy az MI-hallucináció megelőzhető, és nagyon hosszú láncokat lehet hiba nélkül építeni

2. A kemény szűrő (A törvény)
Erről nincs vita. A kódnak le kell fordulnia. A lintereknek nem szabad panaszkodniuk. És ami kulcsfontosságú: a Fekete doboz tesztek meg kell felelniük. Nem azt teszteljük, hogy a függvény belsőleg hogyan működik (ezet az AI manipulálhatja), hanem azt, hogy a rendszer kívülről azt teszi-e, amit kell. Sikertelen teszt? Azonnal a kukába.

3. A lágy szűrő (Az AI esküdtszék)
Ez az igazi innováció. A megmaradt megoldásokat egy speciális „Voting AI”-nak vetjük alá. Ez az ügynök nem ír kódot, hanem olvassa kódot értékel. Arra képezték a mi architektúra-elveinkre, biztonsági követelményeinkre (OWASP, ISO) és megfelelőségi szabályainkra (EU AI Act).
Ő szavaz: „A Megoldás A gyorsabb, de a Megoldás B biztonságosabb és jobban követi a microservices-architektúránkat.”

A győztes megy élesbe.

A szoftverhármas elve

Ez a modell kikényszerít egy hatalmi ágak szétválasztását, amely sok csapatnál hiányzik.

• A Törvényhozó Hatalom (A Tervező): Az építész írja meg az „Alkotmányt”. A promptok, az architekturális dokumentumok (project-description.md, rules.md, skills.md en principles.md), a kemény követelmények. Az építész határozza meg mi mit építünk, ki építi, hogyan és miért.
• A Végrehajtó Hatalom (A Kódoló Ügynökök): Ők hajtják végre. Gyorsan, olcsón és emberi fejlesztők felügyelete alatt.
• Az Igazságszolgáltató Hatalom (A Dizájn Hatóság): Egy független mesterséges intelligencia réteg, amely a jogszabályoknak megfelelően ellenőriz.

Következtetés: Az építész új szerepe

Megszabadít minket a szintaktikai hibák uralmától, és lehetővé teszi, hogy arra koncentráljunk, amiben jók vagyunk: rendszerszemlélet. Igazságfeltárás. Struktúra és döntéshozatal.

A kérdés nem az, hogy az AI képes-e megírni a kódunkat. Ez a téma már eldőlt. A kód nagyrészt eldobható terméggé válik.
A kérdés az: Mered-e átadni az irányítást a kód elengedni, hogy ezzel visszanyerjük az irányítást a minőség visszaszerezni?

tudasd velem