Autorytet Projektowania AI

Znajdujemy się w punkcie zwrotnym w rozwoju oprogramowania. Dyskusja często dotyczy tego, jakie czy AI pisze najlepszy kod (Claude kontra ChatGPT), czy gdzie gdzie AI powinno rezydować (IDE czy CLI). Ale to jest zła dyskusja.

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

Jeśli przyjmiemy AI jako „Vibe Coders” – gdzie my wskazujemy intencję, a AI zajmuje się wykonaniem – stworzymy ogromny strumień nowego oprogramowania. Rój agentów AI może wygenerować w minutę więcej kodu, niż starszy deweloper 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.

Jeśli przejdziemy na „Kod Jednorazowego Użytku” (Disposable Code) – oprogramowanie, którego nie będziemy bez końca refaktoryzować, ale które wyrzucimy i wygenerujemy na nowo, gdy zmienią się wymagania – nasza rola fundamentalnie się zmienia. Nie jesteśmy już murarzami układającymi kamień po kamieniu. Jesteśmy architektami fabryki drukującej ściany.

Ale kto sprawdzi, czy te mury są proste?

Test "Gauntlet": Zautomatyzowana próba ognia

AI Design Authority to nie osoba, lecz potok. „Rękawica” (Gauntlet), przez którą musi przejść każdy fragment wygenerowanego kodu, aby trafić do produkcji. Ten proces nie zastępuje ręcznego przeglądu kodu niczym, lecz 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 oraz budować bardzo długie łańcuchy bez błędów

2. Twardy Filtr (Prawo)
Tutaj dyskusja jest niemożliwa. Kod musi się kompilować. Lintery nie mogą narzekać. I co kluczowe: testy Testy typu Black Box muszą się powieść. Nie testujemy, czy funkcja działa wewnętrznie (AI może to zmanipulować), testujemy, czy system na zewnątrz robi to, co powinien. Test się nie powiódł? Bezpośrednio 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 on szkolony na naszych zasadach architektonicznych, wymogach bezpieczeństwa (OWASP, ISO) i przepisach zgodności (UE AI Act).
Głosuje on: „Rozwiązanie A jest szybsze, ale Rozwiązanie B jest bezpieczniejsze i lepiej pasuje do naszej architektury mikroserwisowej.”

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 jak budujemy i dlaczego.
• Władza Wykonawcza (Agenci Kodujący): Wykonują zadania. Szybko, tanio i pod nadzorem ludzkich deweloperów.
• Władza Sądowa (Organ Wdrażający Projekt): Niezależna warstwa AI, która weryfikuje 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ę oddać kontrolę nad realizacja aby odzyskać kontrolę nad jakość z powrotem?