Władza Projektowa AI

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

Problem nie leży w generowanie kodzie. To jest walidacja jego

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ż starszy programista może 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 szybki rozwój 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 sprawdza, czy te ściany stoją prosto?

„Gauntlet”: Zautomatyzowany test ogniowy

AI Design Authority nie jest osobą, lecz potokiem. „Gauntlet”, przez który każda linia wygenerowanego kodu musi przejść, aby trafić do produkcji. Ten proces nie zastępuje przeglądu kodu przez człowieka, lecz nic, ale 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 się borykają. To podejście jest również badane naukowo 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ą się powieść. Nie testujemy, czy funkcja działa wewnętrznie (to może manipulować AI), testujemy, czy system z 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).
Głosuje: „Rozwiązanie A jest szybsze, ale rozwiązanie B jest bezpieczniejsze i lepiej spełnia naszą architekturę mikroserwisów.”

Zwycięzca przechodzi do produkcji.

Triada polityczna 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, 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 (Władza Projektowa): 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 przejąć kontrolę nad jakość odzyskać?

daj mi znać