Autorytet Projektowania AI
Znajdujemy się w punkcie zwrotnym w rozwoju oprogramowania. Dyskusja często dotyczy które tego, czy AI pisze najlepszy kod (Claude kontra ChatGPT), czy też gdzie gdzie AI powinno się znajdować (IDE czy CLI). Ale to nie jest właściwe pytanie.
Problemem nie jest generować kodu. Problem polega na walidacja tego.
Jeśli przyjmiemy sztuczną inteligencję jako “Vibe Coders” – gdzie my wskazujemy intencję, a SI wykonuje zadanie – stworzymy ogromny strumień nowego oprogramowania. Rój agentów SI może wygenerować więcej kodu w ciągu minuty, niż starszy programista 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 SI.
Od Rzemieślnika do Dyrektora Fabryki
Tradycyjnie „Władza Projektowa” (Design Authority) to mała grupa architektów, która spotyka się raz w tygodniu lub raz w miesiącu, aby zatwierdzić lub odrzucić projekt. W świecie szybki rozwój sztucznej inteligencji ten model jest beznadziejnie przestarzały. Jest zbyt wolny i zbyt reaktywny.
Jeśli przejdziemy na „Kod Jednorazowego Użytku” (Disposable Code) – oprogramowanie, którego nie będziemy bez końca refaktoryzować, ale wyrzucać i generować na nowo, gdy zmienią się wymagania – nasza rola fundamentalnie się zmienia. Nie jesteśmy już murarzami układającymi kamień po kamieniu. Jesteśmy architektami fabryki, która drukuje ściany.
Ale kto sprawdzi, czy te mury są proste?
„Rękawica”: Zautomatyzowana próba ognia
AI Design Authority to nie osoba, ale potok. "Rękawica", przez którą każdy wiersz wygenerowanego kodu musi się przedrzeć, aby trafić do produkcji. Ten proces nie zastępuje ludzkiego przeglądu kodu niczym, ale czymś lepszym.
Działa to w trzech warstwach:
1. Władza Wykonawcza (Generacja)
Nie prosimy jednego AI o rozwiązanie, prosimy o trzy. Sprawiamy, że Gemini 3, GPT-5 i model open-source (taki jak Llama) pracują równolegle nad tym samym problemem. Zapobiega to myśleniu tunelowemu i przełamuje „lenistwo”, na które czasami cierpią LLM-y. To podejście jest również zbadane naukowo i pokazuje, że można zapobiegać halucynacjom AI i budować bardzo długie łańcuchy bez błędów
2. Twardy Filtr (Prawo)
Nie ma tu miejsca na dyskusję. Kod musi się kompilować. Lintery nie mogą narzekać. I co kluczowe: testy Testy Czarnej Skrzynki muszą przejść. Nie testujemy, czy funkcja działa wewnętrznie (to może zmanipulować AI), testujemy, czy system na zewnątrz robi to, co powinien. Test nieudany? Prosto do kosza.
3. Miękki Filtr (AI Jury)
To jest prawdziwa innowacja. Pozostałe rozwiązania są przedstawiane wyspecjalizowanej „AI Głosującej”. Ten agent nie pisze kodu, ale czyta kod. Jest przeszkolony w zakresie naszych zasad architektonicznych, wymagań bezpieczeństwa (OWASP, ISO) i przepisów dotyczących zgodności (UE Akt o Sztucznej Inteligencji).
Stwierdza: „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 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 decyduje co budujemy, kto buduje, jak i dlaczego. - Władza Wykonawcza (Agenci Kodujący): Oni wykonują. Szybko, tanio i pod auspicjami ludzkich deweloperów.
- Władza Sądownicza (Organ Zatwierdzający Projekt): Niezależna warstwa AI, która sprawdza zgodność z prawem.
Wniosek: Nowa rola Architekta
Zwalnia nas z tyranii błędów składniowych i pozwala skupić się na tym, w czym jesteśmy dobrzy: myśleniu systemowym. Odkrywaniu prawdy. Strukturze i podejmowaniu decyzji.
Pytanie nie brzmi, czy AI potrafi pisać 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ę przejąć kontrolę nad kodem pozwalając jej, aby odzyskać kontrolę nad jakości z powrotem?
daj mi znać
