AI Design Authority

Znajdujemy się w punkcie zwrotnym w rozwoju oprogramowania. Dyskusja często dotyczy które tego, czy AI pisze najlepszy kod (Claude vs. ChatGPT), czy gdzie gdzie AI powinno się znajdować (IDE czy CLI). Ale to zła dyskusja.

Prawdziwym problemem nie jest generacja kodu. Prawdziwym problemem jest walidacja jego.

Jeśli przyjmiemy sztuczną inteligencję jako „Vibe Coders” – gdzie wskazujemy intencję, a AI zajmuje się wykonaniem – stworzymy ogromny strumień nowego oprogramowania. Rój agentów AI może wygenerować więcej kodu w ciągu minuty, niż starszy programista jest w stanie przejrzeć w tydzień. Człowiek stał się wąskim gardłem.

Rozwiązaniem nie są więcej ludzie. Rozwiązaniem jest Autorytet Projektowania AI.

Od Rzemieślnika do Dyrektora Fabryki

Tradycyjnie „Władza Projektowa” (Design Authority) to mała grupa architektów, która spotyka się raz w tygodniu lub raz w miesiącu, aby zatwierdzić lub odrzucić projekt. W świecie szybki rozwój AI ten model jest beznadziejnie przestarzały. Jest zbyt wolny i zbyt reaktywny.

Kiedy przechodzimy na „Kod Jednorazowego Użytku” (Disposable Code) – oprogramowanie, którego nie refaktoryzujemy w nieskończoność, ale wyrzucamy i generujemy na nowo, gdy zmieniają się wymagania – nasza rola fundamentalnie się zmienia. Nie jesteśmy już murarzami układającymi kamień po kamieniu. Jesteśmy architektami fabryki, która drukuje ściany.

Ale kto sprawdzi, czy te mury są proste?

„Rękawica”: Zautomatyzowana próba ogniowa

AI Design Authority to nie osoba, ale potok. "Próba" (Gauntlet), przez którą musi przejść każdy wiersz wygenerowanego kodu, aby trafić do produkcji. Ten proces nie zastępuje ludzkiego przeglądu kodu niczym, ale czymś lepszym.

Działa to w trzech warstwach:

1. Władza Wykonawcza (Generacja)
Nie prosimy jednego AI o rozwiązanie, prosimy o trzy. Sprawiamy, że Gemini 3, GPT-5 i model open-source (taki jak Llama) pracują równolegle nad tym samym problemem. Zapobiega to myśleniu tunelowemu i przełamuje „lenistwo”, na które czasami cierpią LLM-y. To podejście jest również zbadane naukowo i pokazuje, że można zapobiegać halucynacjom AI i budować bardzo długie łańcuchy bez błędów

2. Twardy Filtr (Prawo)
Nie ma tu miejsca na dyskusję. Kod musi się kompilować. Lintery nie mogą narzekać. I co kluczowe: testy Testy czarnej skrzynki muszą przejść. Nie testujemy, czy funkcja działa wewnętrznie (to może zmanipulować AI), testujemy, czy system na zewnątrz robi to, co powinien. Test nieudany? Prosto do kosza.

3. Miękki Filtr (AI Jury)
To jest prawdziwa innowacja. Pozostałe rozwiązania są przedstawiane wyspecjalizowanej „AI Głosującej”. Ten agent nie pisze kodu, ale czyta kod. Jest przeszkolony w zakresie naszych zasad architektonicznych, wymagań bezpieczeństwa (OWASP, ISO) i przepisów dotyczących zgodności (UE AI Act).
Stwierdza: „Rozwiązanie A jest szybsze, ale Rozwiązanie B jest bezpieczniejsze i lepiej odpowiada naszej architekturze mikroserwisów.”

Zwycięzca przechodzi do produkcji.

Trias Politica Oprogramowania

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

• Władza Ustawodawcza (Architekt): Architekt pisze "Konstytucję". Prompty, dokumenty architektoniczne (project-description.md, rules.md en principles.md), twarde wymagania. Architekt decyduje co co budujemy i dlaczego.
• Władza Wykonawcza (Agenci Kodujący): Wykonują. Szybko, tanio i pod auspicjami ludzkich deweloperów.
• Władza Sądowa (Organ Uprawniony do Projektowania): Niezależna warstwa AI, która sprawdza zgodność z prawem.

Wniosek: Nowa rola Architekta

Zwalnia nas z tyranii błędów składniowych i pozwala skupić się na tym, w czym jesteśmy dobrzy: myśleniu systemowym. Odkrywaniu prawdy. Strukturze i podejmowaniu decyzji.

Pytanie nie brzmi, czy AI potrafi pisać nasz kod. To już przesądzone. Kod staje się w dużej mierze jednorazowy.
Pytanie brzmi: Czy odważysz się przejąć kontrolę nad wykonanie pozwalając na utratę kontroli nad jakość odzyskać?