Kodowanie Vibe to jedno z tych wyrażeń, które wydaje się być znienawidzone, a potem powoli staje się przydatne.

Na początku brzmi to tak: nie sądzę, pytam AI, akceptuję to, co wychodzi, idę dalej. Wesoły sposób na zaciągnięcie długu technicznego w tle muzycznym.

Ale zbyt łatwo byłoby to tak odrzucić. Prawda jest taka, że ​​kodowanie wibracyjne przechwyciło rzeczywistość: programowanie za pomocą modelu zmienia relację między pomysłem a prototypem.

Najpierw przyszła Ci do głowy myśl, a potem długa wspinaczka. Teraz często przychodzi Ci do głowy jakaś myśl, a pół godziny później coś porusza się na ekranie. Trudno się nim nie dać uwieść.

Ciekawym pytaniem w roku 2026 nie jest to, czy kodowanie wibracji jest prawdziwe. To jest. Pytanie brzmi: co stanie się po miesiącu miodowym?

Prototyp stał się ekonomiczny

To jest najważniejsza część.

Narzędzia AI obniżyły emocjonalny koszt rozpoczęcia. Wcześniej, jeśli chciałeś wypróbować pomysł, musiałeś już włożyć w to dużo pracy: wybrać stos, stworzyć projekt, zapamiętać szablon, napisać układ, połączyć API, kłócić się z nudnymi szczegółami.

Teraz możesz powiedzieć: daj mi pierwszą wersję.

I pojawia się pierwsza wersja.

Nie zawsze piękne. Nie zawsze poprawne. Często kruche. Ale to przychodzi. A kiedy nadejdzie, zmienia rozmowę. Nie kłócisz się już w próżni. Dotykasz czegoś.

Jest to bardzo przydatne dla projektantów, założycieli, menedżerów produktów, starszych programistów zmęczonych przepisywaniem rusztowań i ciekawskich ludzi, którzy wcześniej nie otworzyliby edytora.

Kodowanie Vibe jest modne, ponieważ daje większej liczbie osób fizyczne wrażenie tworzonego oprogramowania.

Problem polega na tym, że oprogramowanie nadal działa

Część, o której mem mówi najmniej, dotyczy następnego dnia.

Prototyp trzeba przeczytać. Prawidłowy. Przetestowany. Wdrożony. Zabezpieczone. Dostałem to od kogoś innego. Połączony z prawdziwymi danymi. Udostępnione. Utrzymywany w przypadku zmiany zależności.

Tutaj kodowanie czystego wibracji uderza w ścianę.

Model może szybko wygenerować dużą ilość kodu, ale kod sam w sobie nie jest wartością. To obietnica zachowania. A obietnicę trzeba zweryfikować.

Ryzyko kodowania wibracyjnego nie polega na pisaniu brzydkiego kodu. Zawsze to robiliśmy, nawet bez sztucznej inteligencji. Ryzyko to utrata poczucia własności: „model to zrobił” staje się wymówką, aby nie zrozumieć wystarczająco dużo.

Ale środowisko wykonawcze nie akceptuje wymówek. Jeśli kod działa w środowisku produkcyjnym, jest Twój.

Od kodowania wibracji po inżynierię agentyczną

Dojrzała wersja kodowania wibracyjnego nie polega na zaprzestaniu używania agentów. Chodzi o to, żeby je stosować przy poważniejszym cyklu.

Nie: generuje wszystko i mamy nadzieję.

Ale:

1. opisać zamiar;
2. pozwól wygenerować projekt;
3. poproś agenta o wyjaśnienie planu;
4. robić małe różnice;
5. uruchomić testy;
6. robić recenzje;
7. poprawne;
8. dopiero wtedy dołącz.

Ta rzecz zasługuje na inną nazwę. Lubię inżynierię agentów, nawet jeśli brzmi to nieco uroczyście. Oznacza to wykorzystywanie agentów nie jako automatów do gry, ale jako współpracowników w procesie inżynieryjnym.

Nie chodzi o to, żeby zabierać energię kodowaniu wibracji. Daje jej ślady.

Gdzie działa świetnie

Kodowanie Vibe sprawdza się, gdy koszt błędu jest niski, a wartość eksploracji wysoka.

Przykłady:

• prototypy interfejsów;
• narzędzia osobiste;
• wewnętrzne dashboardy;
• małe gry;
• skrypt jednorazowy;
• Skany API;
• dowód koncepcji;
• refaktoryzatory mechaniczne z dobrymi testami;
• treści techniczne do przekształcenia w wersje demonstracyjne.

W takich przypadkach liczy się szybkość. Chcesz zobaczyć, czy pomysł ma nogi. Chcesz dowiedzieć się, czego nie zrozumiałeś. Chcesz przejść do konkretnej rozmowy.

Kodowanie Vibe jest idealne do tworzenia formy.

Tam, gdzie robi się niebezpiecznie

Niebezpieczne staje się, gdy system ma konsekwencje i nikt nie zwalnia.

Płatności, dane osobowe, uwierzytelnianie, uprawnienia, infrastruktura, migracje baz danych, wrażliwy starszy kod, zgodność, produkcja. Tutaj atmosfera nie wystarczy. Potrzebujemy dyscypliny.

Nie oznacza to, że sztuczna inteligencja nie może pomóc. Faktycznie może bardzo pomóc. Ale musi działać w wąskich granicach: gałąź, piaskownica, test, lint, recenzja, flaga funkcji, wycofywanie.

Zdanie do wytatuowania na monitorze jest proste: im szybszy agent, tym bardziej czytelny musi być proces.

Jeśli nie potrafisz wyjaśnić, co się zmieniło, oznacza to, że nie przyspieszyłeś. Po prostu przesunąłeś dług z czasu na zrozumienie.

Nowa rola programisty

Najciekawsze jest to, że praca programisty nie znika. Zmień gęstość.

Mniej czasu na szablonach. Więcej czasu na intencję, dekompozycję, przegląd, integrację, testowanie, granice.

Deweloper staje się swego rodzaju redaktorem technicznym. Nie w kiepskim znaczeniu „korekty”. W mocnym sensie: decyduje o tym, co ma istnieć, co należy wyciąć, co jest zgodne z systemem, co zasługuje na zaufanie.

Dobry redaktor nie bierze wszystkiego, co dostaje. Nawet nie przepisuje tego wszystkiego z dumy. Rozpoznaje dobry materiał, nadaje mu formę, chroni czytelnika.

W przypadku agentów czytelnik jest także przyszłym opiekunem. Często to właśnie Ty jesteś w ciągu trzech tygodni.

Widzę wyłaniający się wzór

Najzdrowszy wzór to:

• człowiek: intencja, ograniczenia, gust, odpowiedzialność;
• agent: warianty, rusztowania, poszukiwania, modyfikacje lokalne, testy powtarzalne;
• infrastruktura: sandbox, CI, śledzenie, uprawnienia, wdrożenie;
• zespół: przegląd, własność, standardy.

Kiedy brakuje jednego z tych elementów, coś ulega deformacji.

Tylko człowiek: powolny, często ugrzęznięty w powtarzalnej pracy.

Tylko agent: szybko, ale bez umiejscowionego osądu.

Tylko infrastruktura: elegancki proces wytwarzania bezużytecznych rzeczy.

Tylko zespół: bardzo uporządkowane spotkania wokół prototypu, który nigdy nie pojawia się.

Najlepiej dzieje się, gdy kawałki ze sobą rozmawiają.

Mała lista kontrolna

Zanim pozwoliłem na rozwój prototypu zakodowanego wibracjami, zadałbym sobie następujące pytania:

• czy rozumiem strukturę kodu?
• czy istnieją testy krytycznego zachowania?
• czy wiem, jakich plików dotknął agent?
• czy usunąłem wygenerowany, ale nieużywany kod?
• czy jakieś sekrety, tokeny lub fałszywe dane znalazły się w niewłaściwym miejscu?
• czy przestrzegana jest minimalna dostępność?
• czy wdrożenie umożliwia wycofanie zmian?
• czy ktoś poza mną może to zatrzymać?

Jeśli odpowiedź na zbyt wiele pytań brzmi „nie”, nie oznacza to porażki. To tylko prototyp, który musi jeszcze trochę pozostać prototypem.

Moja lektura

Kodowanie Vibe to głośne określenie delikatnej rzeczy: radości, gdy pomysł nabiera kształtu, zanim powstrzymuje go strach.

Nie chcę tego wyrzucać. To byłoby snobistyczne. Wiele dobrych rzeczy rodzi się w ten sposób, na wpół krzywych i żywych.

Ale pozostałe oprogramowanie wymaga więcej. Potrzebuje zrozumienia, testowania, własności, infrastruktury, granic. Potrzebuje kogoś, kto powie: super, teraz zróbmy to realnie.

Być może przyszłość nie polega na wyborze pomiędzy programowaniem „poważnie” a programowaniem w klimacie. Może to nauka zmiany biegu: eksploruj lekko, a potem konsoliduj z szacunkiem.

Część ludzka jest tam. Wiedz, kiedy biegać, a kiedy siedzieć i czytać różnicę.

Źródła

– Simon Willison: Nie każde programowanie wspomagane sztuczną inteligencją to kodowanie wibracyjne – OpenAI: Jak ludzie korzystają z ChatGPT

• Blog GitHub: Agent kodujący GitHub Copilot – Anthropic: budowanie skutecznych agentów
• Blog Stack Overflow: Dlaczego kodowanie wibracyjne jest przyszłością