AI Design Authority

Stoimy u progu przełomu w tworzeniu oprogramowania. Dyskusja często dotyczy które czy AI pisze najlepszy kod (Claude kontra ChatGPT) lub gdzie czy AI powinna mieszkać w IDE czy CLI. Jednak to nie jest właściwe pytanie.

Problem nie leży w samym generowanie kodzie. Chodzi o walidacja jego użycie.

Gdy przyjmiemy AI jako „Vibe Coders” – gdzie określamy zamiar, a AI wykonuje – tworzymy ogromny napływ nowego oprogramowania. Rój agentów AI może wygenerować w minutę więcej kodu, niż senior developer 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 „Design Authority” to grupa architektów, która spotyka się raz w tygodniu lub miesiącu, by zatwierdzić projekt. W świecie szybkiego rozwoju AI ten model jest zupełnie 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 na nowo, gdy wymagania się zmieniają — nasza rola ulega zasadniczej zmianie. Nie jesteśmy już murarzami układającymi cegłę po cegle. Jesteśmy projektantami fabryki, która drukuje ściany.

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

„Gauntlet": Zautomatyzowana próba ogniowa

AI Design Authority to nie osoba, lecz pipeline. „Gauntlet”, przez który każda linia wygenerowanego kodu musi przejść, by trafić do produkcji. Ten proces nie zastępuje ludzkiego przeglądu kodu niczym, lecz czymś lepszym.

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 (np. Llama) pracować równolegle nad tym samym problemem. Zapobiega to wąskości spojrzenia i przełamuje „lenistwo”, na które modele LLM czasem cierpią. To podejście jest również naukowo zbadane i pokazuje, że można zapobiegać halucynacjom AI oraz konstruować bardzo długie łańcuchy bez błędów

2. Twardy filtr (Prawo)
Tu nie ma dyskusji. Kod musi się kompilować. Lintery nie mogą zgłaszać błędów. I co najważniejsze: Testy czarnej skrzynki musi przejść testy. Nie sprawdzamy, czy funkcja działa wewnętrznie (to mogłoby zostać zmanipulowane przez AI), sprawdzamy, czy system z zewnątrz robi to, co powinien. Test nie przeszedł? Prosto do kosza.

3. Miękki filtr (Ława przysięgłych AI)
To jest prawdziwa innowacja. Pozostałe rozwiązania są przekazywane wyspecjalizowanej „Voting AI”. Ten agent nie pisze kodu, lecz czyta kod. Został wytrenowany zgodnie z naszymi zasadami architektonicznymi, wymaganiami bezpieczeństwa (OWASP, ISO) i regułami 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 trafia 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, 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ą zadania. Szybko, tanio i pod nadzorem ludzkich deweloperów.
• Władza Sądownicza (Organ ds. Projektowania): Niezależna warstwa AI, która działa zgodnie z prawem.

Wniosek: Nowa rola architekta

Uwolni nas od tyranii błędów składni i pozwoli skupić się na tym, w czym jesteśmy dobrzy: myśleniu systemowym. Ustalaniu prawdy. Strukturze i podejmowaniu decyzji.

Pytanie nie brzmi, czy AI potrafi pisać nasz kod. Ten temat jest już zamknięty. Kod w dużej mierze stanie się produktem jednorazowym.
Pytanie brzmi: Czy odważysz się oddać kontrolę nad kod puścić wolno, aby w ten sposób odzyskać kontrolę nad jakość odzyskać kontrolę?

daj mi znać