Dlaczego AI nie radzi sobie z infrastrukturą (i co z tym zrobić)

Wiele osób zachwyca się tym, jak AI pisze kod aplikacji. I faktycznie – w tym obszarze radzi sobie całkiem nieźle. Tworzenie endpointów, zapytań do bazy czy funkcji pomocniczych przychodzi mu z łatwością. Problem pojawia się dopiero wtedy, gdy sprawa dotyczy infrastruktury.

Gdy AI dostaje do ręki plik Terraform, nagle wszystko się sypie.

AI zna składnię, ale nie rozumie kontekstu

Modele językowe świetnie radzą sobie z poprawną składnią HCL. Potrafią wygenerować zasoby AWS, kolejki czy polityki IAM. Tylko że same wartości – timeouty, zakresy uprawnień, czasy przechowywania – wybierają na ślepo.

Wyobraź sobie prosty przypadek: prosisz AI o dodanie nowego eventu do systemu. Model stworzy temat SNS, kolejkę SQS z DLQ i odpowiednie polityki. Wygląda dobrze, dopóki nie zaczniesz zadawać pytań. Dlaczego visibility timeout wynosi 60 sekund? Czy polityka IAM powinna być ograniczona do konkretnego zasobu, czy używać wildcardów? Skąd model ma wiedzieć, że w zeszłym kwartale mieliście problem z za krótkim oknem na ponowne przetwarzanie wiadomości?

Nie wie. Po prostu wybiera wartości, które „wydawały się sensowne” w danych treningowych.

Review infrastruktury staje się koszmarem

Co gorsza, zamiast oszczędzać czas na przeglądaniu kodu, tracisz go jeszcze więcej. Sprawdzanie logiki biznesowej to jedno. Sprawdzanie wygenerowanej infrastruktury to zupełnie inna para kaloszy.

Trzeba zweryfikować nie tylko składnię, ale też semantykę IAM, zgodność z istniejącą architekturą pipeline'ów i nieudokumentowane konwencje zespołu. Reviewer staje się czymś w rodzaju ludzkiego kompilatora – musi nosić w głowie cały kontekst, którego AI nie ma dostępu.

A gdy coś pójdzie nie tak (zły timeout, za szerokie uprawnienia), to nie pipeline Cię obudzi o trzeciej nad ranem. Tylko Ty sam.

Problem leży w architekturze, nie w narzędziach

Możesz nakładać kolejne warstwy modułów, katalogów usług i walidatorów polityk. Nic z tego nie rozwiąże sedna sprawy. A sedno jest proste: kod aplikacji i kod infrastruktury żyją w osobnych repozytoriach i przechodzą przez osobne cykle review.

AI podejmuje decyzje infrastrukturalne w oderwaniu od kodu, który będzie z nich korzystał. Kontekst potrzebny do podjęcia właściwej decyzji po prostu tam nie istnieje.

Lepsze podejście: infrastruktura jako część kodu aplikacji

A co, gdyby infrastruktura nie była osobnym problemem?

Zamiast pisać kod, który tylko sugeruje, jakiej infrastruktury potrzebuje, możesz zadeklarować ją bezpośrednio w typowanym kodzie aplikacji. Framework sam zajmie się provisioningiem, politykami IAM i kolejkami na podstawie tego, co widzi w kodzie.

Wygląda to mniej więcej tak:

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

Nie ma osobnego pliku HCL. Nie ma ręcznie audytowanej polityki IAM. Nie ma zgadywania timeoutów. Framework wie dokładnie, czego potrzebuje ten temat, bo widzi kod, który go produkuje i konsumuje.

Twój pull request to teraz jeden diff w TypeScript, a nie diff plus pięćdziesiąt linii Terraform plus polityki do ręcznej weryfikacji.

To nie jest problem promptów

„Vibe coding” infrastruktury wymaga zupełnie innej architektury niż „vibe coding” aplikacji. Logikę biznesową można bezpiecznie oddać AI, gdy jest otoczona typami i testami. Decyzje infrastrukturalne wymagają kontekstu, który żyje gdzie indziej.

Rozwiązanie nie leży w lepszych promptach ani w bardziej wymyślnych narzędziach. Polega na usunięciu granicy między aplikacją a infrastrukturą. Gdy framework kompiluje infrastrukturę bezpośrednio z kodu aplikacji, niebezpieczne decyzje przestają być domeną AI – i przestają być problemem reviewerów odgrywających rolę ludzkiego kompilatora o północy.

Wtedy infrastrukturę naprawdę można „vibe code'ować” z większym spokojem.