Władza Projektowa AI

Stoimy na przełomowym etapie rozwoju oprogramowania. Dyskusja często dotyczy które AI, która pisze najlepszy kod (Claude vs. ChatGPT) lub gdzie która AI powinna być używana (IDE lub CLI). Ale to nie jest właściwe pytanie.

Jeśli przyjmiemy AI jako „Vibe Coders” – wskazując intencję, a AI wykonuje zadanie – stworzymy ogromny strumień nowego oprogramowania. Swarm AI‑agentów może w jednej minucie wygenerować więcej kodu niż senior developer jest w stanie przejrzeć w ciągu tygodnia. Człowiek stał się wąskim gardłem.

Rozwiązanie nie jest więcej ludzie. Rozwiązaniem jest Autorytet 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 szybkiego rozwoju AI ten model jest beznadziejnie przestarzały. Jest zbyt wolny i zbyt reaktywny.

Jeśli przejdziemy na „Disposable Code” – oprogramowanie, którego nie refaktoryzujemy w nieskończoność, lecz wyrzucamy i generujemy ponownie, gdy zmieniają się wymagania – nasza rola zmieni się fundamentalnie. Nie jesteśmy już murarzami kładącymi cegłę po cegle. Jesteśmy architektami fabryki, które drukują ściany.

Ale kto kontroluje, czy te ściany stoją prosto?

„Gauntlet”: Zautomatyzowana próba ognia

AI Design Authority nie jest osobą, lecz pipeline'em. „Gauntlet”, przez który każda linia wygenerowanego kodu musi przejść, aby trafić do produkcji. Ten proces nie zastępuje ludzkiego przeglądu kodu nic, ale z czymś lepsze.

Działa w trzech warstwach:

1. Władza wykonawcza (Generacja)
Nie prosimy jednej AI o rozwiązanie, prosimy trzy. Pozwalamy Gemini 3, GPT-5 i modelowi open‑source (takim jak Llama) równolegle pracować nad tym samym problemem. To zapobiega tunelowemu widzeniu i przełamuje „leniwość”, z którą LLM‑y czasami mają problem. To podejście jest również naukowo zbadane i wykazuje, że można zapobiec 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ą narzekać. I co najważniejsze: Testy czarnej skrzynki muszą przejść. Nie testujemy, czy funkcja działa wewnętrznie (to może manipulować AI), testujemy, czy system na zewnątrz robi to, co powinien. Czy test nie powiedzie się? Od razu do kosza.

3. Miękki filtr (Jury AI)
To jest prawdziwa innowacja. Pozostałe rozwiązania są przedstawiane wyspecjalizowanej „Voting AI”. Ten agent nie pisze kodu, ale czyta kod. Jest wytrenowany na naszych zasadach architektury, wymaganiach bezpieczeństwa (OWASP, ISO) oraz regułach zgodności (EU AI Act).
On głosuje: „Rozwiązanie A jest szybsze, ale rozwiązanie B jest bezpieczniejsze i lepiej odpowiada naszej architekturze mikroserwisów.”

Zwycięzca przechodzi do produkcji.

Trójpodział władzy w oprogramowaniu

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

• Władza ustawodawcza (Architekt): Architekt tworzy „Konstytucję”. Prompty, dokumenty architektoniczne (project-description.md, rules.md, skills.md en principles.md), twarde wymagania. Architekt określa co co budujemy, kto to buduje, jak i dlaczego.
• Władza wykonawcza (Agenci kodowania): Wykonują to. Szybko, tanio i pod auspicjami ludzkich deweloperów.
• Władza sądownicza (Design Authority): Niezależna warstwa AI, która sprawdza 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 dobrzy: myśleniu systemowym. Poszukiwaniu prawdy. Struktury i podejmowaniu decyzji.

Pytanie nie brzmi, czy AI może napisać nasz kod. Ten temat jest już zamknięty. Kod staje się w dużej mierze produktem jednorazowego użytku.
Pytanie brzmi: Czy odważysz się oddać kontrolę nad kod uwolnić, aby w ten sposób odzyskać kontrolę nad jakość odzyskać?

daj mi znać