Wątpliwości wokół bezpieczeństwa dystrybucji Omarchy
Tworzenie oprogramowania przy użyciu sztucznej inteligencji wchodzi w fazę, w której zachwyt nad tempem pisania kodu zderza się z brutalną weryfikacją jakości. Najlepszym tego przykładem jest Omarchy – nowa dystrybucja Linuksa, za którą stoi David Heinemeier Hansson (DHH). Projekt ten, promujący ideę systemu niewymagającego konfiguracji i rozwijany z intensywnym wykorzystaniem agentów AI, spotkał się z poważnymi zarzutami. Kwestia zaufania do kodu tworzonego w dużej mierze automatycznie przez jednoosobowego twórcę wywołuje dziś pytania o to, na jakim poziomie niezawodności realnie się znajdujemy.
"Security review po prostu wylało szambo"
Krytyka dystrybucji Omarchy skupia się na fundamentalnym braku weryfikacji. Jak trafnie podsumowano to w podcaście Patoarchitekci (odcinek "Slop factories vs dark AI factories"), audyt bezpieczeństwa – czyli security review – w przypadku projektu DHH "po prostu wylało szambo". Główną osią problemu jest jednoosobowy model pracy wspierany masowo generatorami AI, w którym brakuje odpowiednich testów i tradycyjnych procedur weryfikacyjnych, absolutnie niezbędnych dla bezpieczeństwa systemu operacyjnego.
Twórcy podcastu uderzają w sedno problemu pracy z masowo dostarczanym kodem: "Realnie nie robisz review kodu. Przy tej ilości nie masz opcji, żeby to zrobić". Skupienie się na błyskawicznym tworzeniu nowych funkcji sprawia, że brakuje rygorystycznego, ludzkiego nadzoru nad stabilnością powstającego oprogramowania.
Slop factories i rynek juniorów IT
Wokół podobnych projektów wyrasta szersze zjawisko, które Łukasz z Patoarchitektów wprost nazywa "slop factories". Określenie to odnosi się do swoistych fabryk kodu, w których gigantyczna "ilość szumu w planach, testach i goalach robi wrażenie", ale jednocześnie maskuje liczne wady. Zjawisko to ma bezpośrednie przełożenie na całą branżę IT. Z rynku znikają pozycje dla początkujących programistów, co nie wynika wprost ze standardowych zwolnień, lecz z zastępowania ich jawnymi budżetami rzędu 300-500 dolarów na developera, przeznaczanymi celowo na opłacenie narzędzi AI.
Skuteczność takich asystentów mocno zależy od doświadczenia operatora. Powoływane w podcaście benchmarki mówią o tym wprost: "juniorzy z AI-em - zwalnia, seniorzy z AI-em - przyspiesza". Dawny tokenmaxxing spełnił już w dużej mierze swoją rolę marketingową, a realny rynek bardzo twardo weryfikuje prawdziwą przydatność inteligentnych agentów na produkcji.
Ograniczenia sprzętowe i wyścig gigantów
Chociaż idea autonomicznych systemów piszących niezawodne oprogramowanie mocno rozbudza wyobraźnię, ogranicza ją brutalna matematyka. Lokalne uruchamianie dużych modeli napotyka na sprzętowe wąskie gardło – nawet najmocniejszy procesor M5 Max wyciąga zaledwie 20-30 tokenów na sekundę, co oznacza "tyle co nic przy chmarze równoległych agentów". Z drugiej strony, na rynku otwartych wag (open weight) pojawiają się silne, alternatywne modele, od rozwiązań takich jak Qwen po tworzone przez Metę Muse, ale ich wdrożenie wymaga potężnej, skalowalnej infrastruktury.
Dlatego branżowy rozwój wciąż opiera się na usługach chmurowych i potężnych przejęciach kapitałowych, czego wymownym dowodem jest zakup startupu OpenRouter przez firmę Stripe za oszałamiającą kwotę 7-8 miliardów. Zmienia się układ sił, popularny edytor Cursor zagościł na sprzęcie u Elona Muska, choć nie brakuje problemów na tle konsumenckim, w tym pozwów o mylące limity 5x i 20x narzucane przez dostawców. O tym, jak głęboko sięgają zmiany świadczy fakt, że wsparcie AI pojawia się jako temat głosowań w ugruntowanej społeczności Debian, a sam Linus debugował kernel używając sztucznej inteligencji poprzez kolejne 18 rebootów.
Przypadek Omarchy pozostaje jednak bardzo wyraźnym sygnałem ostrzegawczym. Pokazuje on, że w przypadku rozwiązań systemowych poleganie na kodzie generowanym automatycznie, bez odpowiednich narzędzi badających szczelność i bez drobiazgowego weryfikowania wprowadzanych zmian, to wciąż szalenie ryzykowny eksperyment.
