Autorytet ds. projektowania AI

Znajdujemy się w punkcie zwrotnym rozwoju oprogramowania. Dyskusja często dotyczy tego, które czy AI pisze najlepszy kod (Claude kontra ChatGPT), czy też gdzie gdzie to AI powinno działać (IDE czy CLI). Ale to nie jest właściwe postawienie pytania.

Jeśli zaakceptujemy AI jako „Vibe Coders” – gdzie określamy intencję, a sztuczna inteligencja zajmuje się wykonaniem – tworzymy ogromny strumień nowego oprogramowania. Rój agentów AI może w ciągu minuty wygenerować więcej kodu, niż starszy programista (senior developer) jest w stanie zrecenzować w ciągu tygodnia. Człowiek stał się wąskim gardłem.

Rozwiązaniem nie jest więcej ludzi. Rozwiązaniem jest Autorytet 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ć lub odrzucić projekt. W świecie szybko rozwijającego się AI (high-velocity AI development) ten model jest beznadziejnie przestarzały. Jest zbyt wolny i zbyt reaktywny.

Jeśli przejdziemy na „Disposable Code” – oprogramowanie, którego nie refaktoryzujemy bez końca, lecz wyrzucamy i generujemy na nowo, gdy zmieniają się wymagania – nasza rola ulega fundamentalnej zmianie. Nie jesteśmy już murarzami układającymi cegła po cegle. Jesteśmy architektami fabryki, która drukuje ściany.

Ale kto sprawdza, czy te ściany są proste?

„Gauntlet”: Zautomatyzowana próba ognia

AI Design Authority to nie osoba, lecz potok (pipeline). „Gauntlet”, przez który każdy wygenerowany fragment kodu musi się przepracować, aby trafić na produkcję. Ten proces nie zastępuje ludzkiego przeglądu kodu przez nic, lecz przez coś lepszego.

Działa to w trzech warstwach:

1. Władza Wykonawcza (Generowanie)
Nie prosimy jednego AI o rozwiązanie, prosimy trzy. Pozwalamy Gemini 3, GPT-5 oraz modelowi open-source (takiemu jak Llama) pracować równolegle nad tym samym problemem. Zapobiega to tunelowemu widzeniu i przełamuje „leniwośc”, na którą LLM czasem cierpią. Podejście to jest również 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ć błędów. I co kluczowe: Testy czarnoskrzynkowe muszą zakończyć się sukcesem. Nie testujemy, czy funkcja działa wewnętrznie (AI może tym manipulować), testujemy, czy system na zewnątrz robi to, co powinien. Test się nie powiódł? Natychmiast do kosza.

3. Miękki filtr (Jury AI)
To jest prawdziwa innowacja. Ocalałe rozwiązania są przedkładane wyspecjalizowanemu „Voting AI”. Ten agent nie pisze kodu, lecz odczytuje kod. Został przeszkolony pod kątem naszych zasad architektury, wymagań bezpieczeństwa (OWASP, ISO) i reguł zgodności (EU AI Act).
On decyduje: „Rozwiązanie A jest szybsze, ale Rozwiązanie B jest bezpieczniejsze i lepiej wpisuje się w naszą architekturę mikroserwisów”.

Zwycięzca trafia na produkcję.

Trójpodział władzy w oprogramowaniu

Ten model wymusza podział władzy, którego brakuje w wielu zespołach.

• Władza ustawodawcza (Architekt): Architekt pisze „konstytucję”. Prompt, dokumenty architektoniczne (project-description.md, rules.md, skills.md en principles.md), surowe wymagania. Architekt decyduje co budujemy, kto to buduje, jak i dlaczego.
• Władza wykonawcza (Agenci kodujący): Oni wykonują. Szybko, tanio i pod nadzorem ludzkich deweloperów.
• Władza sądownicza (Organ ds. projektowania): Niezależna warstwa AI, która weryfikuje zgodność z prawem.

Wniosek: Nowa rola architekta

Uwalnia nas od tyranii błędów składniowych i pozwala skupić się na tym, w czym jesteśmy najlepsi: na myśleniu systemowym. Poszukiwaniu prawdy. Strukturze i podejmowaniu decyzji.

Pytanie nie brzmi, czy sztuczna inteligencja potrafi pisać nasz kod. Ten temat jest już zamknięty. Kod w dużej mierze staje się produktem jednorazowym.
Pytanie brzmi: Czy odważysz się porzucić kontrolę nad kodem aby odzyskać kontrolę nad jakością ?

daj mi znać