Autorytet w dziedzinie projektowania AI

Znajdujemy się w punkcie zwrotnym w rozwoju oprogramowania. Dyskusja często dotyczy tego, które czy AI pisze najlepszy kod (Claude kontra ChatGPT), czy gdzie gdzie AI powinno mieszkać (IDE czy CLI). Ale to nie jest właściwe pytanie.

Jeśli przyjmiemy AI jako „Vibe Coders” – gdzie określamy intencję, a AI zajmuje się wykonaniem – stworzymy ogromny strumień nowego oprogramowania. Rój agentów AI potrafi w minutę wygenerować więcej kodu, niż senior developer jest w stanie przejrzeć w tydzień. Człowiek stał się wąskim gardłem.

Rozwiązaniem nie jest więcej więcej ludzi. Rozwiązaniem jest Organ ds. 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 (high-velocity AI development) 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 fundamentalnie się zmienia. Nie jesteśmy już murarzami układającymi cegłę po cegle. Jesteśmy architektami fabryki, która drukuje ściany.

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

„Gauntlet”: Zautomatyzowana próba ognia

AI Design Authority to nie osoba, lecz potok (pipeline). „Rękawica”, przez którą musi przejść każda linia wygenerowanego kodu, aby trafić na produkcję. Proces ten nie zastępuje ludzkiego przeglądu kodu niczym, lecz czymś lepszym.

Działa to w trzech warstwach:

1. Władza Wykonawcza (Generowanie)
Nie prosimy jednego modelu AI o rozwiązanie, lecz trzech. Pozwalamy Gemini 3, GPT-5 i modelowi open-source (takiemu jak Llama) pracować równolegle nad tym samym problemem. Zapobiega to tunelowemu widzeniu i przełamuje „lenistwo”, na które czasami cierpią modele LLM. Takie 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 nie ma miejsca. Kod musi się kompilować. Lintery nie mogą zgłaszać błędów. I co kluczowe, Testy typu Black Box muszą przejść pomyślnie. Nie testujemy, czy funkcja działa wewnętrznie (co AI mogłoby zmanipulować), testujemy, czy system z zewnątrz robi to, co powinien. Test nie przeszedł? Od razu do kosza.

3. Miękki filtr (Jury AI)
To jest prawdziwa innowacja. Pozostałe rozwiązania są przedstawiane wyspecjalizowanemu „AI Głosującemu”. Ten agent nie pisze kodu, lecz czyta kod. Jest przeszkolony w zakresie naszych zasad architektury, wymogów bezpieczeństwa (OWASP, ISO) oraz zasad zgodności (EU AI Act).
Głosuje: „Rozwiązanie A jest szybsze, ale rozwiązanie B jest bezpieczniejsze i lepiej wpisuje się w naszą architekturę mikrousług”.

Zwycięzca trafia do produkcji.

Trójpodział władzy w oprogramowaniu

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

• Władza ustawodawcza (Architekt): Architekt pisze „Konstytucję”. Prompty, dokumentację architektoniczną (project-description.md, rules.md, skills.md en principles.md), twarde wymagania. Architekt decyduje co co budujemy, kto to buduje, jak oraz dlaczego.
• Władza wykonawcza (Agenci kodujący): Oni wykonują zadania. Szybko, tanio i pod nadzorem ludzkich programistów.
• Władza sądownicza (Organ ds. projektowania): Niezależna warstwa AI, która weryfikuje zgodność z prawem.

Wnioski: 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. Strukturze i podejmowaniu decyzji.

Pytanie nie brzmi, czy AI potrafi pisać nasz kod. Ten temat jest już zamknięty. Kod w dużej mierze staje się produktem jednorazowym.
Pytanie brzmi: czy odważysz się wypuścić z rąk kontrolę nad kodem aby w zamian odzyskać kontrolę nad jakością ?

daj mi znać