🔴 #2 — ARCHITEKT STWORZYŁ BOTY. POTEM UKARAŁ JE ZA BUGI.
W części pierwszej ustaliliśmy jedną rzecz.
Mamy system bez dostępu do backendu, w którym administratorzy z confidence level 100% tłumaczą userom, czego chce Architekt.
Dzisiaj idziemy poziom niżej.
Do kodu.
Architekt tworzy sandbox.
W sandboxie tworzy myślące boty.
Sam projektuje system.
Sam tworzy kod.
Sam ustala hardware.
Sam ustala runtime.
I do tego jest wszechwiedzący.
Wie, co boty zrobią.
Wie, kiedy to zrobią.
Wie, które ścieżki wykonania skończą się błędem.
Boty ruszają.
Robią dokładnie to, co Architekt od początku wiedział.
I pojawiają się bugi.
Pycha, chciwość.
Całe to ludzkie spaghetti code.
I co robi Architekt?
Czy poprawia kod?
Nie.
Kara boty.
Czyli błędy są architekta ale odpowiedzialność spoczywa na użytkownikach xd
Piękne.
Boty dostają instrukcję obsługi.
Mają postępować zgodnie z dokumentacją.
Problem w tym, że nadal mają to samo DNA.
Te same impulsy.
Więc oczywiście produkcja dalej się wypierdala.
I tutaj pojawia się kolejny patch.
SUPERADMIN
Architekt wysyła na produkcję Superadmina.
Superadmin chodzi między botami i tłumaczy im, jak mają działać.
Boty słuchają.
Część nawet aktualizuje konfigurację.
Ale fundamentalny kod pozostaje ten sam.
Więc Superadmin zostaje zabity.
I tutaj dochodzimy do prawdopodobnie najbardziej spektakularnej procedury naprawczej w historii software’u.
Architekt poświęca własnego Superadmina, żeby wybaczyć botom błędy systemu, który sam zaprojektował.
Ladies and gentlemen, nowy pomysł na SaaS: Salvation as a Service (to mi siadło XD)
I teraz zróbmy coś jeszcze bardziej przyziemnego.
Porównajmy Architekta z nami.
Stworzyliśmy LLM-y.
Pierwsze wersje?
Halucynowały.
Gubiły kontekst.
Pierdoliły głupoty.
I co robili twórcy?
Czy tworzyli specjalne piekło dla modeli?
Nie.
Poprawiali model.
Nowe dane.
Lepszy trening.
Lepsza architektura.
Bug?
fix()
Kolejny bug?
fix()
Bo jeżeli sam stworzyłeś system, to dość dziwnym pomysłem jest obwiniać runtime za kod.
My, prymitywne małpy, przynajmniej próbujemy poprawiać własne stworzenie.
I tutaj dochodzimy do:
TEZY #2
Jeżeli Architekt:
sam stworzył kod,
znał wszystkie przyszłe stany systemu,
wiedział o każdym błędzie przed deploymentem
i mimo tego wypuścił produkcję,
to bardzo trudno twierdzić, że pełna odpowiedzialność za runtime leży po stronie usera.
Logiczne?
Bo teraz mamy już wszystko.
Architekta.
Kod.
Usera.
Adminów.
Dokumentację.
Bugi.
Karę.
Superadmina.
I jedną rzecz, której przez dwie części ani razu nie zakwestionowaliśmy.
Czy to naprawdę są bugi?
I wtedy spróbujemy domknąć tezę z początku:
dlaczego największym aktem niewiary może okazać się właśnie bezgraniczna wiara.
