Organ ds. architektury AI

Stoimy w punkcie zwrotnym w rozwoju oprogramowania. Dyskusja często dotyczy tego, które czy AI pisze najlepszy kod (Claude czy ChatGPT), czy też gdzie gdzie AI powinno być dostępne (IDE czy CLI). Ale to nie jest właściwie postawione pytanie.

Jeśli zaakceptujemy AI jako „Vibe Coders” — wskazując intencję, a AI pozostawiając realizację — stworzymy ogromny strumień nowego oprogramowania. Rój agentów AI może w ciągu jednej minuty wygenerować więcej kodu, niż starszy programista jest w stanie przejrzeć w ciągu tygodnia. Człowiek stał się wąskim gardłem.

Rozwiązaniem nie są więcej ludzie. Rozwiązaniem jest organ ds. projektowania AI.

Od rzemieślnika do dyrektora fabryki

Tradycyjnie „Design Authority” to grupa architektów, która spotyka się raz w tygodniu lub miesiącu, aby zatwierdzić projekt albo go odrzucić. W świecie szybkiego rozwoju AI ten model jest beznadziejnie przestarzały. Jest zbyt powolny i zbyt reaktywny.

Jeśli przejdziemy na „Disposable Code” — oprogramowanie, którego nie refaktoryzujemy bez końca, lecz wyrzucamy i generujemy ponownie, gdy zmieniają się wymagania — nasza rola zmienia się zasadniczo. Nie jesteśmy już murarzami, którzy układają cegłę po cegle. Jesteśmy architektami fabryki, która drukuje mury.

Ale kto sprawdza, czy te mury stoją prosto?

„Gauntlet”: zautomatyzowana próba ognia

AI Design Authority nie jest osobą, lecz potokiem. „Gauntletem”, przez który każda linijka wygenerowanego kodu musi przejść, aby trafić na produkcję. Ten proces nie zastępuje ludzkiego przeglądu kodu niczym, lecz czymś lepszym.

Działa on w trzech warstwach:

1. Władza wykonawcza (generowanie)
Nie prosimy jednej AI o rozwiązanie — prosimy o nie trzy. Gemini 3, GPT-5 i model open source, taki jak Llama, pracują równolegle nad tym samym problemem. Zapobiega to zawężeniu perspektywy i przełamuje „lenistwo”, na które czasami cierpią modele LLM. To podejście jest również zostało zbadane naukowo i pokazuje, że można zapobiegać halucynacjom AI oraz budować bardzo długie łańcuchy bez błędów

2. Twardy filtr (prawo)
Tutaj nie ma miejsca na dyskusję. Kod musi się kompilować. Lintery nie mogą zgłaszać żadnych uwag. Co kluczowe, Testy czarnoskrzynkowe muszą przejść pomyślnie. Nie sprawdzamy, czy funkcja działa wewnętrznie — AI może to zmanipulować — lecz czy system z zewnątrz robi to, co powinien. Test zakończony niepowodzeniem? Natychmiast do kosza.

3. Miękki filtr (jury AI)
To właśnie prawdziwa innowacja. Pozostałe rozwiązania są przedstawiane wyspecjalizowanej „AI głosującej”. Ten agent nie pisze kodu, lecz czyta kod. Został przeszkolony w zakresie naszych zasad architektonicznych, wymagań bezpieczeństwa (OWASP, ISO) oraz przepisów dotyczących zgodności (unijny akt o sztucznej inteligencji).
Rozstrzyga: „Rozwiązanie A jest szybsze, ale rozwiązanie B jest bezpieczniejsze i lepiej odpowiada naszej architekturze mikrousługowej.”

Zwycięzca trafia na produkcję.

Trójpodział władzy w oprogramowaniu

Ten model wymusza rozdział kompetencji, którego brakuje w wielu zespołach.

• Władza ustawodawcza (Architekt): Architekt spisuje „Konstytucję”. Prompty, dokumenty architektoniczne (project-description.md, rules.md, skills.md en principles.md), twarde wymagania. Architekt decyduje co co budujemy, kto to buduje, jak i dlaczego.
• Władza wykonawcza (agenci kodujący): Wykonują zadania. Szybko, tanio i pod nadzorem ludzkich deweloperów.
• Władza sądownicza (Design Authority): Niezależna warstwa AI, która weryfikuje zgodność z prawem.

Podsumowanie: nowa rola architekta

Uwalnia nas od tyranii błędów składni i pozwala skupić się na tym, w czym jesteśmy dobrzy: myśleniu systemowym, poszukiwaniu prawdy, strukturze i podejmowaniu decyzji.

Pytanie nie brzmi, czy AI potrafi pisać nasz kod. Ta kwestia jest już zamknięta. Kod w dużej mierze stanie się produktem jednorazowego użytku.
Pytanie brzmi: Czy odważysz się zrezygnować z kontroli nad kodem aby odzyskać w ten sposób kontrolę nad jakością ?

daj mi znać