Organ ds. 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 ta sztuczna inteligencja powinna 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 od nowa, gdy zmieniają się wymagania – nasza rola zmienia się fundamentalnie. 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 linijka wygenerowanego kodu, aby trafić na produkcję. Ten proces nie zastępuje ludzkiego przeglądu kodu niczego, lecz coś lepszego.

Działa to w trzech warstwach:

1. Władza Wykonawcza (Generowanie)
Nie prosimy jednego modelu AI o rozwiązanie, prosimy o nie trzy. 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ż potwierdzone 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 sensu. Kod musi się kompilować. Lintery nie mogą zgłaszać zastrzeżeń. I co kluczowe, muszą przejść Testy typu Black Box testy. Nie sprawdzamy, czy funkcja działa wewnętrznie (AI może tym manipulować), sprawdzamy, czy system z zewnątrz robi to, co powinien. Test nie przeszedł? Od razu do kosza.

3. Miękki filtr (Jury AI)
To prawdziwa innowacja. Pozostałe rozwiązania są przedstawiane wyspecjalizowanej „AI Głosującej”. Ten agent nie pisze kodu, lecz czyta kod. Jest przeszkolony w zakresie naszych zasad architektury, wymogów bezpieczeństwa (OWASP, ISO) oraz przepisów dotyczących 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 programujący): Oni wykonują pracę. 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 jednorazowego użytku.
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ć