Forki vibrów: AI skopiuje twój projekt, ale straci jego duszę

Forki vibrów: AI skopiuje twój projekt, ale straci jego duszę

Lip 09, 2026 vibe coding ai development software engineering llm developer tools

Vibe forks i teraźniejszość, która wyprzedza wyobraźnię

Kilka dni temu oglądałem demo, które trzy lata temu wyglądałoby jak science fiction. System AI wygenerował działający kompilator zdolny do targetowania wielu architektur procesorów. Nie zabawka. Nie prototyp. Prawdziwy, działający kompilator, który przeszedł 99% branżowych testów.

Tak wygląda nasza rzeczywistość.

Trajektoria generowania kodu przez AI przyprawia o zawrót głowy. Zaczęliśmy od przewidywania następnego słowa w linii, potem funkcji, następnie całych plików, a teraz – coraz częściej – całych projektów. Wraz z tym eksplozją możliwości pojawił się fascynujący efekt uboczny: tak zwane w społeczności "vibe forks."

Vibe fork to w uproszczeniu to, co dzieje się, gdy ktoś używa vibe coding do stworzenia clean-room implementacji istniejącego oprogramowania. Nikt nie kopiuje kodu. Ludzie odtwarzają funkcjonalność od zera, wymuszając ją do istnienia przez coraz zdolniejsze systemy AI. Kod źródłowy nie jest już fosą – prawdę mówiąc, nigdy nią nie był. Wiedza o tym, jak rzeczy działają, została wchłonięta do danych treningowych i zakodowana w wagach modelu.

Eksperyment z kompilatorem

Najbardziej uderzający przykład pochodzi z niedawnych badań nad AI. Szesnaście agentów AI dostało dostęp do wspólnej bazy kodu, żeby zbudować kompilator C od zera. Po prawie 2000 sesjach i 20 000 dolarach kosztów API wyprodukowali 100 000 linii kodu kompilatora zdolnego zbudować Linux 6.9 na architekturach x86, ARM i RISC-V. Kompiluje nawet DOOM-a.

Dajcie temu chwilę.

Sto tysięcy linii kodu kompilatora klasy produkcyjnej. Trzy różne architektury procesorów. Kernel, który faktycznie się uruchamia. To nie projekt na weekend – to oprogramowanie, nad którym badacze pracowali latami, odtworzone przez autonomiczne agenty w czasie odpowiadającym kilku tygodniom mocy obliczeniowej.

Natychmiastowa reakcja to albo euforia, albo egzystencjalny lęk, zależnie od perspektywy. Ale moim zdaniem rzeczywistość jest bardziej nuansowana i szczerze mówiąc – ciekawsza.

Dlaczego nie tracę snu przez vibe forki

Kontrowersyjna opinia: vibe forki są imponujące, ale nie stanowią egzystencjalnego zagrożenia dla twórców oprogramowania.

Pomyślcie o ekonomii obfitości. Kiedy każdy może "wymusić" kompilator C do istnienia, artefakt przestaje być rzadki. Co staje się rzadkie? Osąd – konkretnie osąd o tym, który z wielu wygenerowanych wariantów jest poprawny, utrzymywany, bezpieczny i wart zaufania w systemach produkcyjnych.

Ten wzorzec już się pojawiał. Spójrzcie na sklepy z aplikacjami. Koszt klonowania jest tam już bliski zeru. Próg wejścia niski. Rezultat? Sto aplikacji do nawyków, tysiąc latarek, ocean niemal identycznych narzędzi productivity. Klony istnieją. Po prostu nie zdobywają popularności na dłuższą metę.

To nie funkcje wyróżniają zwycięzców od stosu. To selekcja, discoverability, zaufanie i reputacja. Artykuły polecające, recenzje użytkowników, oceny gwiazdkowe, rozpoznawalność marki budowana latami. Listę funkcji skopiujecie w jedną noc. Zaufania nie.

Ukryta przewaga incumbents

Oto coś counterintuitive: ta sama właściwość, która umożliwia vibe forking, w praktyce bardziej pomaga incumbents niż nowicjuszom.

Szeroko wdrożone oprogramowanie było w danych treningowych niezliczoną ilość razy. Uderzały w nie przypadki brzegowe i warunki skrajne, które deweloperzy spędzili lata odkrywając i naprawiając. Model jest dobry w utrzymywaniu tego oprogramowania właśnie dlatego, że świat już wykonał ciężką pracę znajdowania tego, co jest zepsute.

Świeżo utworzony vibe fork nie ma tej historii. Może pięknie działać na happy path. Ale ten tajemniczy crash, który pojawia się tylko podczas przetwarzania pliku z znakami Unicode w środku wtorkowego popołudnia w novembro? Tego ktoś szukał trzy miesiące. To nie jest w waszym prompcie. To wiedza instytucjonalna zakodowana w oryginalnym kodzie.

Modele są naprawdę lepsze w utrzymywaniu tego, czego świat już się nauczył utrzymywać. To nie fair, ale to prawda.

Element ludzki, którego nie da się skalować

A potem jest support. To tutaj vibe forki naprawdę odstają i myślę, że to najbardziej niedoceniana fosa w tym wszystkim.

AI agentyczne świetnie sobie radzą z projektami greenfield. Budowanie czegoś nowego od zera? Modele są niezwykle zdolne. Ale prawdziwe oprogramowanie to nie greenfield. Prawdziwe oprogramowanie to brownfield. Ma nagromadzone zależności, legacy integracje, dziwne konfiguracje i nagromadzony bagaż lat "naprawimy to później."

Każdy dojrzały projekt niesie essential complexity – inherentną trudność problemu, który rozwiązuje. Ale niesie też accidental complexity, tę która wpełza z czasem przez zmieniające się wymagania, rotację kadry i tysiąc małych decyzji, które wtedy wydawały się rozsądne.

Redukcja tej accidental complexity? To głęboko ludzkie zadanie. Wymaga zrozumienia kontekstu, który mógł nigdy nie zostać spisany. Wymaga rozmów z użytkownikami o tym, czego naprawdę potrzebują. Wymaga osądów o tradeoffs, które mają sens tylko w kontekście historii organizacji.

Agenci AI mogą pomóc w tym wszystkim. Ale nie zrobią tego sami, a na pewno nie zrobią tego dla świeżego forka, który nie ma tych relacji ani tego kontekstu.

Prawdziwa szansa

Oto co moim zdaniem naprawdę dzieje się z vibe forks: nie eliminują wartości świetnego oprogramowania. Demokratyzują możliwość budowania nowego oprogramowania.

Ludzie, którzy byli zablokowani od tworzenia bo nie znali C lub nie mieli lat doświadczenia z kompilatorami? Teraz są odblokowani. Startupy, które nie mogły sobie pozwolić na budowanie infrastruktury od zera? Mogą prototypować i walidować pomysły szybciej niż kiedykolwiek.

Tego, czego vibe forki nie mogą łatwo odtworzyć, to nagromadzone zaufanie, społeczność i wiedza instytucjonalna, która sprawia, że oprogramowanie zyskuje wartość z czasem. To nadal budowane po staremu: przez lata wysyłania, słuchania, naprawiania i iterowania.

Więc tak, bariera odtwarzania oprogramowania dramatycznie spadła. Ale bariera tworzenia oprogramowania, które ma znaczenie – tego, któremu ludzie ufają ze swoimi firmami i życiami – nadal wymaga elementu ludzkiego. Zawsze będzie wymagać.

Pytanie nie brzmi, czy AI może zbudować wasze marzenia. Może. Pytanie brzmi, czy możecie zbudować coś wartego utrzymywania.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT NB NL HU IT FR ES DE DA ZH-HANS EN