Miért bukik el az AI az infrastruktúra-döntéseknél?
Miért nem bízhatod az AI-ra az infrastruktúra tervezését?
Az utóbbi időben sokan azt hangoztatják, hogy „hadd írja az AI a kódot”. Alkalmazási logikában ez valóban jól működik. Útvonal-kezelők, adatbázis-lekérdezések, segédfüggvények – ezeken a területeken a nagy nyelvi modellek tényleg otthon vannak. Az igazi probléma ott kezdődik, amikor az infrastruktúráról van szó.
Az infrastruktúra kontextusproblémája
Az AI modellek kiválóan kezelik a szintaxist. Érvényes Terraform-kódot bárki tud tőlük kérni. A nehézség nem a kód írásában van, hanem abban, hogy az AI nem érti, miért pont azokat az értékeket kell beállítani.
Vegyünk egy egyszerű példát: egy új eseményt szeretnél hozzáadni az üzenetküldő rendszerhez. Az AI legenerálja az SNS témát, az SQS sort holtlevél-sorral, a feliratkozást és a megfelelő IAM-szabályokat. A probléma az, hogy a láthatósági időkorlátot, az IAM-hatóköröket vagy a megőrzési időt teljesen véletlenszerűen választja ki. Nincs tudomása arról, hogy a csapatod milyen terhelésre számít, vagy hogy az előző negyedévben milyen incidens történt egy rosszul beállított visszajátszási ablak miatt.
A kódellenőrzés rejtett költsége
A helyzetet tovább rontja, hogy a review-teher nem csökken, hanem nő. Alkalmazási kódnál viszonylag egyszerű átlátni a logikát és a biztonsági kockázatokat. Infrastruktúra esetén viszont a review-zónak egyszerre kell ellenőriznie a HCL szintaxist, az IAM-szemantikát, a meglévő pipeline architektúrát és azokat a belső konvenciókat, amelyeket soha nem írtak le.
Ha valami rosszul kerül élesbe – rossz időkorlát, túl tág IAM-hatókör –, akkor nem a CI pipeline, hanem a supportos kapja az éjszakai hívást.
Az igazi ok: elkülönített rétegek
A gyökérprobléma nem az, hogy hiányzik egy eszköz. Akárhány egyedi modult vagy policy-validátort tehetsz az AI köré, az nem oldja meg az alapvető architekturális hibát: az alkalmazási és az infrastruktúra-kód külön repóban, külön review-ciklusban él. Az AI így olyan döntéseket hoz, amelyekhez nincs meg a szükséges kontextus.
Jobb megközelítés: az infrastruktúra fordítási időben
Képzeld el, ha az infrastruktúrát nem külön kellene leírni, hanem az alkalmazási kód részeként, típusosan deklarálnád. A keretrendszer maga állítja elő a szükséges erőforrásokat, IAM-szabályokat és holtlevél-sorokat – mindezt abból, amit a kód ténylegesen használ.
Egy pub/sub téma így nézne ki:
export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
deliveryGuarantee: "at-least-once",
});
Nincs külön Terraform-fájl, nincs kézzel auditált IAM-policy, nincs találgatás az értékek körül. A keretrendszer pontosan tudja, mire van szüksége a témának, mert látja, ki állítja elő és ki fogyasztja az eseményeket.
Miért számít ez a „vibe coding” szempontjából?
Az alkalmazási logikát nyugodtan rábízhatod az AI-ra, ha a kód típusos és tesztelt. Az infrastruktúra viszont olyan kontextust igényel, ami a különálló repókban rejtőzik. A megoldás nem jobb prompt vagy újabb eszköz, hanem az, hogy megszünteted a szakadékot a két réteg között. Ha a keretrendszer az alkalmazási kódból fordítja le az infrastruktúrát, a veszélyes döntések kikerülnek az AI és az éjszakai review-zók kezéből.