A szoftverfejlesztés fordulópontjához érkeztünk. A vita gyakran arról szól, hogy melyik melyik AI írja a legjobb kódot (Claude vs. ChatGPT), vagy hol hol kell az AI-nak élnie (IDE vagy CLI). De nem ez a helyes kérdésfeltevés.
Ha az AI-t „Vibe Coders”-ként öleljük magunkhoz – ahol mi adjuk meg a szándékot, az AI pedig elvégzi a kivitelezést –, akkor új szoftverek hatalmas áradatát hozzuk létre. Egy AI-ágensekből álló raj egy perc alatt több kódot generálhat, mint amennyit egy senior fejlesztő egy hét alatt át tud nézni. Az ember vált a szűk keresztmetszetté.
A megoldás nem több több ember. A megoldás egy AI Tervezési Hatóság.
Hagyományosan a „Design Authority” egy építészekből álló csoport, amely hetente vagy havonta összegyűlik, hogy jóváhagyjon vagy elutasítson egy tervet. A nagy sebességű AI-fejlesztés világában ez a modell reménytelenül elavult. Túl lassú és túl reaktív.
Ha áttérünk a „Disposable Code”-ra – olyan szoftverre, amelyet nem refaktorálunk végtelenül, hanem eldobunk és újra generálunk, ha a követelmények változnak –, akkor a szerepünk alapjaiban változik meg. Már nem kőművesek vagyunk, akik tégláról téglára építenek. Mi vagyunk annak a gyárnak az építészei, amely kinyomtatja a falakat.
De ki ellenőrzi, hogy azok a falak egyenesek-e?
Az AI Design Authority nem egy személy, hanem egy folyamat. Egy „kesztyűs kéz”, amelyen keresztül minden generált kódsornak át kell küzdenie magát, hogy eljusson a gyártásig. Ez a folyamat nem az emberi kódellenőrzést váltja ki semmivel, hanem valami jobbal.
Három szinten működik:
1. A végrehajtó hatalom (A generálás)
Nem egyetlen AI-tól kérünk megoldást, hanem háromtól. Párhuzamosan dolgoztatjuk a Gemini 3-at, a GPT-5-öt és egy nyílt forráskódú modellt (például a Llama-t) ugyanazon a problémán. Ez megakadályozza az alagútlátást és megtöri azt a „lustaságot”, amelytől az LLM-ek néha szenvednek. Ez a megközelítés szintén tudományosan alátámasztott és bizonyítja, hogy az AI-hallucinációk megelőzhetők, és nagyon hosszú láncok építhetők hibák nélkül
2. A szigorú szűrő (A törvény)
Itt nincs helye vitának. A kódnak le kell fordulnia. A linterek nem panaszkodhatnak. És ami döntő: Black Box tesztek sikeresnek kell lenniük. Nem azt teszteljük, hogy a függvény belsőleg működik-e (ezt az AI manipulálhatja), hanem azt, hogy a rendszer kívülről azt teszi-e, amit tennie kell. Ha a teszt megbukik, azonnal a kukába kerül.
3. A puha szűrő (Az AI zsűri)
Ez az igazi innováció. A megmaradt megoldásokat egy speciális „szavazó AI”-nak mutatjuk be. Ez az ágens nem ír kódot, hanem olvasás kódot. Úgy van kiképezve, hogy ismerje az architektúra-elveinket, a biztonsági követelményeket (OWASP, ISO) és a megfelelőségi szabályokat (EU AI Act).
Így szavaz: „Az A megoldás gyorsabb, de a B megoldás biztonságosabb, és jobban illeszkedik a mikroszolgáltatás-architektúránkhoz.”
A győztes kerül gyártásba.
Ez a modell olyan hatalmi ágak szétválasztását kényszeríti ki, amely sok csapatból hiányzik.
project-description.md, rules.md, skills.md en principles.md), a szigorú követelményeket. Az építész határozza meg, mit mit építünk, ki építi, hogyan és miért.Felszabadít minket a szintaktikai hibák zsarnoksága alól, és lehetővé teszi, hogy arra összpontosítsunk, amiben jók vagyunk: a rendszerszintű gondolkodásra. Az igazságkeresésre. A struktúrára és a döntéshozatalra.
A kérdés nem az, hogy az AI meg tudja-e írni a kódunkat. Ez a téma már lezártnak tekinthető. A kód nagyrészt eldobható termékké válik.
A kérdés az: mersz-e lemondani a kód feletti kontrollról, hogy ezzel visszanyerd az irányítást a minőség felett?
tudasd velem