Samouczek Kimi Vibe Coding: Tworzenie produktu bez pisania kodu jest łatwiejsze, ale jego wdrożenie już nie

Kimi przekształciło niegdyś techniczny proces w konwersacyjny, ale ta zmiana tworzy nowy konflikt między szybkim tworzeniem a odpowiedzialnym wdrażaniem. Ten samouczek Kimi vibe coding analizuje ten konflikt poprzez pełną drogę produktu — od początkowej specyfikacji po publiczne wdrożenie.

Ważna zmiana nie polega na tym, że model AI potrafi wygenerować stronę docelową. Agenci kodujący mogą teraz sprawdzać pliki projektu, edytować kilka komponentów, wykonywać polecenia, uruchamiać testy i dostosowywać swoje plany po niepowodzeniach. Kimi Code, Qwen Code i usługi programistyczne oparte na GLM umieszczają ten przepływ pracy w terminalach i środowiskach programistycznych.

Stawia to osoby tworzące swoje pierwsze projekty w nietypowej sytuacji. Mogą stworzyć więcej oprogramowania, zanim zrozumieją systemy, które się pod nim kryją. Jednak hosting, uwierzytelnianie, bazy danych, bezpieczeństwo, konfiguracja domeny i obowiązki regulacyjne nadal pozostają problemami inżynieryjnymi.

Andrej Karpathy nadał tej praktyce zapadającą w pamięć nazwę w lutym 2025 roku. Jego opis podkreślał akceptowanie wygenerowanych zmian i tymczasowe zapominanie, że kod w ogóle istnieje. Takie podejście sprawdzało się w eksperymentalnych projektach weekendowych, ale publiczny produkt wymaga innego standardu.

Użyteczne pytanie nie brzmi już, czy osoba bez doświadczenia w programowaniu może stworzyć aplikację. Może. Trudniejsze pytanie brzmi, czy potrafi zrozumieć, przetestować, obsługiwać i odzyskać działanie aplikacji po tym, jak agent ją stworzy.

Agenci kodujący Kimi obsługują teraz więcej niż generowanie kodu

Przejście od asystenta czatu do agenta kodującego zmienia to, kto może rozpocząć projekt programistyczny, ale nie zwalnia twórcy z odpowiedzialności.

Model czatowy zwykle zwraca tekst lub odizolowane próbki kodu. Agent kodujący może pracować w projekcie, sprawdzać jego strukturę, modyfikować pliki, uruchamiać polecenia i obserwować wynikowe dane wyjściowe. Ta pętla informacji zwrotnej pozwala systemowi kontynuować pracę po pierwszej odpowiedzi.

To rozróżnienie ma znaczenie dla nietechnicznego twórcy. Kopiowanie kodu między przeglądarką a edytorem wymaga wiedzy, gdzie należy umieścić każdy fragment. Agent może zlokalizować odpowiednie pliki i koordynować zmiany w interfejsie, serwerze, bazie danych i konfiguracji.

Kimi opisuje swojego klienta wiersza poleceń jako agenta, który może odczytywać i modyfikować kod, przeszukiwać pliki, wykonywać polecenia powłoki i aktualizować swój plan na podstawie informacji zwrotnych. Jego aktualny przewodnik Kimi Code wyjaśnia również, jak klient może wygenerować plik AGENTS.md po przeskanowaniu projektu.

Ten plik pełni rolę kontekstu operacyjnego dla agenta. Może rejestrować strukturę projektu, polecenia budowania, konwencje i inne instrukcje, które powinny zachować się między zadaniami. Agent otrzymuje mapę zamiast traktować każdy prompt jako odizolowane żądanie.

Qwen Code stosuje podobny model. Jego przegląd agenta opisuje narzędzie terminalowe, które przekształca instrukcje dotyczące produktu w kod i obsługuje skryptowe, nieinteraktywne użycie. Może również łączyć się za pośrednictwem kilku opcji uwierzytelniania i dostawców modeli.

Produkty te reprezentują większą zmianę w interfejsie tworzenia oprogramowania. Użytkownik opisuje zachowanie, ograniczenia i kryteria akceptacji. Agent tłumaczy tę intencję na pliki, polecenia i testy.

Jednak język naturalny nie jest kompletną specyfikacją. Prośba taka jak „zbuduj portal klienta” pozostawia kluczowe pytania bez odpowiedzi. Nie mówi nic o odzyskiwaniu konta, uprawnieniach dostępu, retencji danych, nieudanych płatnościach, dziennikach audytu ani zapobieganiu nadużyciom.

Doświadczony inżynier zauważa te luki, ponieważ przypominają wcześniejsze awarie. Początkujący często widzi widoczny interfejs i zakłada, że system jest niemal gotowy. Agenci kodujący skracają czas implementacji, ale mogą też ukrywać niedokończone decyzje za dopracowanym ekranem.

Chiński przewodnik pochodzący z AIHOT dobrze oddaje ten nowy przepływ pracy. Przedstawia krajowe modele, w tym Kimi, GLM i Qwen, jako dostępne drogi od pomysłu do produktu online. Jego najważniejsza rada pojawia się pod koniec: twórca może uniknąć pisania kodu, ale nie może uniknąć zrozumienia architektury.

To rozróżnienie powinno definiować każdy poważny samouczek Kimi vibe coding. Agent może wykonywać zadania, podczas gdy człowiek nadal odpowiada za zdefiniowanie systemu i ocenę, czy działa.

Specyfikacja produktu musi powstać przed pierwszym promptem

Nieprecyzyjny pomysł daje przekonujące demo, natomiast ograniczona specyfikacja daje agentowi szansę na stworzenie produktu, który można obsługiwać.

Pierwszym rezultatem nie powinien być kod. Powinna nim być krótka specyfikacja produktu obejmująca użytkowników, zadania, dane, uprawnienia, stany błędów i kryteria sukcesu. Dokument ten staje się punktem odniesienia, gdy agent zaczyna przyjmować założenia.

Zacznij od jednego użytkownika i jednego zadania. „Freelancerzy muszą przekształcać notatki ze spotkań w wiadomości follow-up dla klientów” jest bardziej praktyczne niż „zbuduj platformę produktywności AI”. Węższe stwierdzenie określa dane wejściowe, transformację i dane wyjściowe.

Następnie zdefiniuj najmniejszą kompletną ścieżkę. Użytkownik tworzy konto, importuje notatkę, przegląda wygenerowaną wiadomość follow-up, edytuje ją i eksportuje wynik. Każdy krok powinien obejmować to, co widzi użytkownik, oraz to, co dzieje się, gdy działanie się nie powiedzie.

Dane zasługują na własną sekcję. Wymień każdy rodzaj informacji przechowywanych przez aplikację, ich źródło, kto może je odczytać i kiedy powinny zostać usunięte. Wrażliwe dokumenty wymagają innych zabezpieczeń niż publiczne dane katalogowe.

Uprawnienia również wymagają jednoznacznego opisu. Administrator, zwykły użytkownik i anonimowy odwiedzający nie powinni mieć tych samych możliwości. Jeśli produkt obsługuje zespoły, określ, czy członkowie mogą przeglądać nawzajem swoje rekordy i kto może odebrać dostęp.

Następnie zdefiniuj system jako kilka komponentów:

• Interfejs wyświetla ekrany, formularze, nawigację i informacje zwrotne.

• Usługa aplikacyjna egzekwuje reguły biznesowe i koordynuje żądania.

• Baza danych przechowuje użytkowników, rekordy, uprawnienia i stan.

• Uwierzytelnianie weryfikuje tożsamość i kontroluje sesje.

• Usługi zewnętrzne zapewniają e-mail, płatności, wnioskowanie AI lub przechowywanie plików.

• Hosting udostępnia aplikację oraz zapewnia logi, sieć i kopie zapasowe.

Początkujący nie musi znać każdego szczegółu implementacyjnego przed rozpoczęciem. Musi rozpoznać te komponenty i zapytać, gdzie znajduje się każda odpowiedzialność. W przeciwnym razie agent może po cichu połączyć niepowiązane kwestie w kruchym kodzie.

Tryb planowania jest przydatny na tym etapie. Zamiast prosić agenta o natychmiastowe budowanie, poproś go o sprawdzenie specyfikacji, wskazanie brakujących decyzji, zaproponowanie architektury i podzielenie pracy na kamienie milowe.

Plan agenta powinien nazwać główne encje danych, trasy, zależności i strategię testowania. Powinien również określać założenia. Ukryte założenia stają się kosztowne, gdy zależy od nich kilka funkcji.

Poproś agenta o opisanie architektury bez kodu. Jeśli wyjaśnienie nadal jest niezrozumiałe, produkt nie jest gotowy do autonomicznej implementacji. Przerób plan, aż będziesz w stanie wyjaśnić przepływ żądań prostym językiem.

Przydatne prompty definiują dowody, a nie entuzjazm. „Dodaj logowanie” jest niekompletne. „Dodaj logowanie przez e-mail, odrzucaj wygasłe sesje, uniemożliw użytkownikom dostęp do rekordów innego konta i napisz testy dla tych przypadków” tworzy obserwowalne wymagania.

Ta sama dyscyplina dotyczy pracy nad interfejsem. Opisz stany puste, stany ładowania, błędy walidacji, małe ekrany, nawigację klawiaturą i działania destrukcyjne. Wygenerowany panel, który obsługuje wyłącznie idealne dane, nadal jest makietą.

Twórcy mogą przechowywać wymagania, notatki źródłowe, decyzje dotyczące modeli i obserwacje z testów w przeszukiwalnym przepływie pracy AI. Ten kontekst staje się cenny, gdy agent pyta, dlaczego podjęto wcześniejszą decyzję architektoniczną.

Specyfikacja zmieni się w trakcie rozwoju. To normalne. Ważną zasadą jest aktualizowanie dokumentu źródłowego przed poproszeniem agenta o wdrożenie nowego kierunku.

Samouczek Kimi Vibe Coding: od planu do działającej wersji

Najbezpieczniejszy przepływ pracy z agentami wykorzystuje małe, weryfikowalne kamienie milowe zamiast jednego polecenia, które prosi o całą aplikację.

Utwórz projekt w repozytorium z kontrolą wersji przed rozpoczęciem głównej implementacji. Kontrola wersji rejestruje zmiany jako commity, umożliwiając twórcy porównywanie rewizji i odzyskanie wcześniejszego stanu. Początkowy commit powinien zawierać specyfikację i minimalny szkielet projektu.

Poproś agenta o zaproponowanie stosu technologicznego opartego na prostocie operacyjnej. Odpowiedź powinna wyjaśniać, dlaczego istnieje każdy komponent, jak zostanie wdrożony i jakie alternatywy odrzucono. Unikaj wyboru frameworka tylko dlatego, że model wygenerował go jako pierwszy.

Pierwszy kamień milowy powinien ustanowić szkielet aplikacji. Obejmuje on polecenie programistyczne, konfigurację środowiska, podstawową nawigację, kontrolę stanu i polecenie testowe. Żadna funkcja biznesowa nie powinna być rozwijana, dopóki inne czyste środowisko nie będzie mogło uruchomić tego szkieletu.

Drugi kamień milowy powinien zaimplementować podstawowy model danych. Poproś agenta, aby przed wygenerowaniem migracji pokazał encje, ich relacje i zasady własności. Migracja to kontrolowana zmiana w bazie danych, którą można konsekwentnie zastosować w różnych środowiskach.

Przejrzyj schemat, używając prostego języka. Który rekord należy do którego użytkownika? Co się dzieje po usunięciu konta? Czy dwa rekordy mogą przypadkowo odwoływać się do brakujących danych? Odpowiedzi pokazują, czy podstawowy model odpowiada produktowi.

Trzeci kamień milowy dodaje uwierzytelnianie i autoryzację. Uwierzytelnianie odpowiada na pytanie, kim jest użytkownik. Autoryzacja odpowiada na pytanie, co ten użytkownik może robić. Wiele wygenerowanych aplikacji implementuje pierwsze, traktując drugie jako kwestię interfejsu.

Autoryzacja musi być egzekwowana przez serwer dla każdej chronionej operacji. Ukrycie przycisku nie jest kontrolą dostępu. Złośliwy lub ciekawski użytkownik może wysyłać żądania bez korzystania z zamierzonego interfejsu.

Czwarty kamień milowy wdraża jedną kompletną ścieżkę produktu. Oprzyj się dodawaniu stron ustawień, paneli analitycznych lub dopracowań wizualnych, zanim podstawowa ścieżka zacznie działać. Wąski pionowy wycinek wcześniej ujawnia problemy z integracją.

Po każdym zadaniu wymagaj od agenta podsumowania:

• Plików, które zmienił

• Zachowania, które dodał

• Założeń, które przyjął

• Testów, które uruchomił

• Testów, które nadal wymagają ludzkiej oceny

• Wszelkich konsekwencji dla bezpieczeństwa lub wdrożenia

Uruchamiaj aplikację po każdym kamieniu milowym. Najpierw sprawdź oczekiwane zachowanie, a potem użyj jej niewłaściwie. Przesyłaj puste formularze, zbyt duże dane wejściowe, zduplikowane żądania, wygasłe sesje, nieprawidłowe adresy URL oraz identyfikator rekordu innego użytkownika.

Gdy coś zawiedzie, zgłoś zaobserwowane zachowanie zamiast prosić agenta o „naprawienie wszystkiego”. Uwzględnij polecenie, oczekiwany wynik, rzeczywisty wynik i odpowiednie dane z logów. Precyzyjna informacja zwrotna pomaga modelowi odróżnić defekt od źle zrozumianego wymagania.

Nie akceptuj szeroko zakrojonych przeróbek jako domyślnej odpowiedzi na lokalny błąd. Poproś o wyjaśnienie przyczyny źródłowej i minimalną poprawkę. Duże wygenerowane zmiany są trudniejsze do przejrzenia i mogą usunąć działające zachowanie.

Twórz commit po każdym zweryfikowanym kamieniu milowym. Używaj opisów określających zmianę produktu, a nie historię rozmowy. Czysta historia pozwala wrócić do znanego stanu, gdy agent wprowadzi kilka powiązanych błędów.

Rozpocznij nową sesję agenta, gdy kontekst stanie się chaotyczny. Przekaż nowej sesji specyfikację, architekturę, bieżący kamień milowy i zweryfikowany stan repozytorium. Długie rozmowy mogą utrwalać nieaktualne założenia po zmianie produktu.

To etapowe podejście wydaje się wolniejsze niż generowanie za jednym razem. W praktyce ogranicza kosztowny cykl, w którym dopracowana aplikacja rozpada się podczas wdrożenia. Celem nie jest maksymalna ilość kodu wygenerowanego na polecenie, lecz maksymalny zweryfikowany postęp na zmianę.

Wdrożenie zamienia demonstrację w działający system

Uruchomienie produkcyjne dodaje obowiązki dotyczące infrastruktury, tożsamości, regulacji i odzyskiwania, których agent programujący nie może osobiście przejąć.

Lokalna aplikacja działa na jednej maszynie w sprzyjających warunkach. Publiczne wdrożenie otrzymuje nieprzewidywalny ruch, nieprawidłowo sformułowane żądania, automatyczne skany i prawdziwe dane użytkowników. To środowisko zmienia znaczenie słowa „działa”.

Oddziel środowiska programistyczne i produkcyjne. Środowisko programistyczne służy eksperymentowaniu. Produkcja to system, od którego zależą prawdziwi użytkownicy. Nie powinny współdzielić tej samej bazy danych, poświadczeń ani nieograniczonego dostępu administracyjnego.

Przechowuj konfigurację za pomocą zmiennych środowiskowych lub zarządzanej usługi sekretów. Nigdy nie umieszczaj haseł do bazy danych, kluczy API ani sekretów podpisywania w plikach źródłowych. Poproś agenta o przeskanowanie historii repozytorium pod kątem przypadkowo zapisanych poświadczeń przed uruchomieniem.

Wybierz hosting na podstawie komponentów aplikacji. Statyczny interfejs, długo działający serwer, zaplanowane zadanie i relacyjna baza danych mają różne wymagania. Plan wdrożenia powinien określać, jak każdy komponent jest uruchamiany, komunikuje się, rejestruje błędy i jest ponownie uruchamiany.

Domena dodaje kolejną warstwę. Jej rekordy DNS kierują użytkowników do usługi hostingowej, a TLS szyfruje połączenia. Produkt potrzebuje także strategii przekierowywania alternatywnych form domeny i odnawiania certyfikatów.

Produkty hostowane w Chinach kontynentalnych mogą podlegać dodatkowym obowiązkom związanym z rejestracją. Zmienione chińskie zasady rejestracji ICP stanowią, że niekomercyjne usługi internetowe udostępniane na terenie kraju muszą przejść procedury rejestracyjne.

Zasady stanowią również, że kompletne wnioski powinny otrzymać decyzję dotyczącą rejestracji w ciągu 20 dni roboczych. To maksymalny termin regulacyjny, a nie obietnica, że każde uruchomienie zakończy się według stałego harmonogramu. Twórcy powinni traktować rejestrację jako wczesny strumień prac.

Dokładny obowiązek zależy od usługi, ustaleń hostingowych, modelu biznesowego i jurysdykcji. Agent programujący może uporządkować wymagania, ale nie może zapewnić autorytatywnej zgody prawnej. Gdy zakres jest niepewny, skonsultuj się z odpowiednim dostawcą i wykwalifikowanym doradcą prawnym.

Wdrożenie wymaga także kontroli migracji bazy danych. Utwórz kopię zapasową danych produkcyjnych przed zastosowaniem destrukcyjnej zmiany. Przetestuj migrację na reprezentatywnych danych i udokumentuj sposób jej cofnięcia.

Utwórz listę kontrolną wydania obejmującą pomyślne zbudowanie, automatyczne testy, kontrole bezpieczeństwa, migracje, konfigurację, monitorowanie i wycofanie zmian. Każdy element powinien dostarczać dowodów, a nie ustnego zapewnienia agenta.

Logi powinny odpowiadać na pytanie, co zawiodło, kiedy zawiodło i której operacji dotyczyło. Nie powinny ujawniać haseł, tokenów, prywatnych dokumentów ani niepotrzebnych danych osobowych. Rejestrowanie większej ilości danych nie jest automatycznie bezpieczniejsze.

Monitorowanie powinno obejmować podstawową dostępność, błędy serwera, opóźnienia, nieudane zadania w tle i limity przestrzeni dyskowej. Alert potrzebuje ludzkiego właściciela i ścieżki reakcji. Powiadomienie, którego nikt nie rozumie, jest tylko dodatkowym szumem.

Kopie zapasowe wymagają testów odtwarzania. Pomyślne zadanie tworzenia kopii zapasowej dowodzi, że dane zostały gdzieś skopiowane. Nie dowodzi, że produkt może odzyskać sprawność w akceptowalnym czasie.

Przed zaproszeniem użytkowników utwórz jedną ścieżkę wycofania zmian. Może to oznaczać przywrócenie poprzedniego wydania, wyłączenie nowej funkcji lub cofnięcie migracji. Zespół powinien wiedzieć, które działanie dotyczy każdej prawdopodobnej awarii.

To właśnie tutaj opis „no-code” staje się mylący. Twórca może nie wpisywać implementacji, ale nadal obsługuje system z obowiązkami technicznymi i organizacyjnymi.

Kod wygenerowany przez AI wymaga ochrony gałęzi i testów adversarialnych

Pewność agenta nie jest dowodem na to, że produkt jest bezpieczny, poprawny lub gotowy do produkcji.

Badanie Stack Overflow Developer Survey 2025 wykazało wyraźną lukę zaufania wobec wyników AI. Chociaż 84 procent respondentów używało lub planowało używać narzędzi AI, 46 procent nie ufało ich dokładności. Zaufanie wyraziło tylko 33 procent.

To samo badanie deweloperów wykazało, że 66 procent było sfrustrowanych rozwiązaniami AI, które były niemal poprawne. Kolejne 45 procent wskazało czasochłonne debugowanie wygenerowanego kodu jako główną frustrację.

Te dane nie pokazują, że agenci kodujący nie mają wartości. Pokazują, dlaczego weryfikacja musi skalować się wraz z wdrażaniem. Szybsze generowanie może tworzyć większe obciążenie związane z przeglądem, gdy zmiany rozprzestrzeniają się po nieznanych częściach systemu.

Chroń główną gałąź po początkowej konfiguracji projektu. Funkcja GitHub ochrona gałęzi może wymagać pull requestów, pomyślnych kontroli statusu, rozwiązanych dyskusji lub zatwierdzających przeglądów, zanim zmiana zostanie scalona.

Samodzielny twórca również może skorzystać z tej struktury. Agent pracuje na osobnej gałęzi, uruchamiane są zautomatyzowane kontrole, a twórca przegląda podsumowanie przed scaleniem. Ta przerwa tworzy granicę między generowaniem a wydaniem.

Co najmniej zautomatyzowany pipeline powinien instalować zależności z zablokowanego pliku, budować aplikację, uruchamiać testy i wykonywać kontrole ukierunkowane na bezpieczeństwo. Błąd powinien blokować scalenie, zamiast stawać się ostrzeżeniem ukrytym w logach.

Testowanie powinno działać na kilku poziomach:

• Testy jednostkowe sprawdzają odizolowane reguły biznesowe.

• Testy integracyjne sprawdzają komunikację z bazami danych i usługami zewnętrznymi.

• Testy end-to-end obejmują kompletne ścieżki użytkownika.

• Testy autoryzacji potwierdzają, że jedno konto nie może uzyskać dostępu do danych innego konta.

• Testy migracji sprawdzają, czy zmiany schematu zachowują istniejące rekordy.

• Testy manualne badają użyteczność, niejednoznaczne wyniki i nieoczekiwane zachowania.

Poproś agenta, aby napisał testy przed naprawieniem potwierdzonego defektu. Nieudany test utrwala problem i zmniejsza prawdopodobieństwo jego powrotu. Następnie wymagaj, aby ten sam test przeszedł po zastosowaniu poprawki.

Bezpieczeństwo wymaga osobnego etapu modelowania zagrożeń. Model zagrożeń identyfikuje cenne zasoby, możliwych atakujących, ujawnione punkty wejścia i prawdopodobne nadużycia. Zamienia „zadbaj o bezpieczeństwo” w zestaw konkretnych pytań.

Co się stanie, jeśli użytkownik zmodyfikuje identyfikator w żądaniu? Czy przesłana treść może wykonać kod? Czy serwer pobiera zewnętrzne adresy URL? Czy powtarzające się próby podania hasła mogą trwać bez ograniczeń? Czy trasy administracyjne sprawdzają role na serwerze?

OWASP ostrzega, że systemy wygenerowane przez AI lub tworzone przez użytkowników nietechnicznych mogą ponownie wykorzystywać podatne komponenty, a nawet odwoływać się do nieistniejących pakietów. Jego wytyczne dotyczące niezaufanych komponentów zalecają traktowanie wygenerowanych zależności jako elementów wymagających weryfikacji.

Sprawdź każdą nową zależność. Potwierdź, że pakiet istnieje, pochodzi od oczekiwanego wydawcy, jest utrzymywany i służy niezbędnemu celowi. Wiarygodnie brzmiąca nazwa pakietu nie jest dowodem jego legalności.

Używaj pliku blokady zależności i unikaj niepotrzebnych pakietów. Mniejsza liczba zależności zmniejsza liczbę zewnętrznych komponentów, które mogą zawieść, zmienić właściciela lub wprowadzić podatności.

Wygenerowany kod uwierzytelniania zasługuje na szczególnie dokładną kontrolę. Przechowywanie haseł, obsługa sesji, procesy resetowania, ustawienia plików cookie i kontrole autoryzacji zawierają szczegóły wrażliwe dla bezpieczeństwa. Preferuj ugruntowane, udokumentowane implementacje zamiast własnej logiki.

Nigdy nie używaj rzeczywistych danych klientów podczas wczesnych testów. Generuj syntetyczne rekordy, które przypominają wymaganą strukturę, nie ujawniając danych osobowych. Ogranicz dostęp do środowiska produkcyjnego, nawet jeśli tylko jedna osoba obsługuje projekt.

Funkcje AI tworzą dodatkowe ryzyka. Jeśli treść użytkownika trafia do promptu modelu, traktuj ją jako niezaufaną. Może próbować nadpisać instrukcje, ujawnić ukryty kontekst lub uruchomić niezamierzone narzędzia.

Agent z dostępem do plików i poleceń ma również istotne uprawnienia lokalne. Przeglądaj żądane działania, ograniczaj poświadczenia i unikaj przyznawania dostępu do środowiska produkcyjnego podczas zwykłego rozwoju. Wygoda nie powinna usuwać granic operacyjnych.

Nietechniczny założyciel powinien zorganizować niezależny przegląd przed uruchomieniem produktu obsługującego pieniądze, informacje zdrowotne, poufne dokumenty lub wrażliwe dane tożsamości. Agent, który wygenerował kod, nie powinien być jedynym recenzentem własnej pracy.

Na co twórcy powinni zwracać uwagę po uruchomieniu

Decydującym testem vibe codingu nie jest to, czy agent potrafi opublikować wersję pierwszą, lecz to, czy człowiek potrafi obsługiwać wersję drugą.

Pierwszym sygnałem jest niezawodność zmian. Śledź, jak często żądana funkcja przechodzi testy, trafia na produkcję i pozostaje aktywna bez wycofania. Częste cofnięcia sugerują, że architektura lub proces weryfikacji nie mogą wspierać szybkości agenta.

Drugim sygnałem jest odpowiedzialność za incydenty. Gdy pojawia się alert, twórca powinien zidentyfikować dotknięty komponent, sprawdzić odpowiednie logi i wyjaśnić ścieżkę awarii. Całkowita zależność od odpowiedzi innego agenta pozostawia produkt bez odpowiedzialnej diagnozy.

Trzecim sygnałem jest przenośność między modelami. Kimi, Qwen, GLM i inne systemy do kodowania będą nadal zmieniać swoich klientów, modele, metody uwierzytelniania i limity. Repozytorium z jasną dokumentacją i standardowymi narzędziami może łatwiej przechodzić między agentami.

Przenośność między modelami nie oznacza, że każdy agent tworzy identyczny kod. Oznacza, że wymagania projektu, architektura, polecenia i testy są wystarczająco jawne, aby inne narzędzie lub inżynier mógł kontynuować pracę.

Twórcy powinni również obserwować różnicę między widocznym rezultatem a jakością operacyjną. Nowe ekrany interfejsu łatwo zademonstrować. Niższe wskaźniki błędów, bezpieczniejsze migracje, szybsze odzyskiwanie sprawności i jaśniejsze uprawnienia są mniej widoczne, ale ważniejsze.

Ten samouczek Kimi dotyczący vibe codingu kończy się zatem inną definicją sukcesu. Sukcesem nie jest osiągnięcie działającego adresu URL bez dotknięcia języka programowania. Jest nim osiągnięcie działającego systemu, którego zachowanie, dane, ryzyka i ścieżkę odzyskiwania możesz wyjaśnić.

Zacznij od jednej ścieżki użytkownika i spisz jej wymagania przed otwarciem agenta kodującego. Niech agent zaplanuje pracę, wdroży jeden kamień milowy i dostarczy dowody z testów. Zatwierdzaj tylko zweryfikowane zmiany, a następnie zbuduj mechanizmy wdrażania i odzyskiwania przed zaproszeniem prawdziwych użytkowników.

Jeśli nie potrafisz wyjaśnić, gdzie sprawdzana jest tożsamość, gdzie znajdują się dane lub jak odwracane jest nieudane wydanie, wstrzymaj uruchomienie. Poproś agenta o zmapowanie tych systemów, aż odpowiedzi staną się jasne. Vibe coding może obniżyć koszt implementacji, ale nie może przenieść odpowiedzialności za produkt na model.