Dzień 12 kodowania Vibe, Może to ostatni wątek tutaj. Spędziłem 100 godzin na budowaniu aplikacji komercyjnej z vibe coding. Kilka obserwacji z tego doświadczenia. Moje 13 najważniejszych lekcji, które pomogą Ci -- vibe kodować swoją własną. Wątek🧵

Uwaga: Współzałożyłem pionierski SaaS, który osiągnął 200 milionów dolarów ARR, więc chociaż nie jestem inżynierem i nie programowałem od czasów szkoły średniej (a to się nie liczy) -- mam kontekst na temat tego, czego wymaga oprogramowanie komercyjne. Uwielbiam te aplikacje. Ale jeśli naprawdę się w to angażujesz, poznaj ich ograniczenia. Przynajmniej ich ograniczenia dzisiaj. Rzeczy zmieniają się tak szybko, że te spostrzeżenia na pewno będą nieaktualne nawet za 90 dni.

1/13: Zacznij od jednorazowego hacka. Spędź maksymalnie 60 minut, opowiadając aplikacji do kodowania o swoich dzikich marzeniach dotyczących produktu, bez żadnego planowania. Zobacz, co się pojawi. Ale zobowiąż się z góry do jego porzucenia — to nie jest twój prawdziwy produkt, to twoja edukacja. Ta pierwsza godzina nauczy cię więcej o możliwościach i ograniczeniach platformy niż jakikolwiek samouczek.

2/13: Zanim zaczniesz pisać jakikolwiek kod, poświęć pełny tydzień na studiowanie 20 aplikacji produkcyjnych zbudowanych na platformach kodowania vibe. Nie chodzi o przypadkowe przeglądanie—naprawdę korzystaj z aplikacji, które są na żywo, przyjmują płatności, obsługują prawdziwych klientów. Szukasz tego, co jest naprawdę możliwe na dużą skalę i gdzie ograniczenia są najbardziej dotkliwe. Ta rekonesans oszczędza tygodnie frustracji później.

3/13: Zdefiniuj swoje wymagania produkcyjne, zanim zaczniesz budować. Zapytaj: 1⃣Jak bezpieczne to musi być? 2⃣Kto będzie to utrzymywał po uruchomieniu? 3⃣Czy potrzebujesz, aby to skalowało się do 100 użytkowników czy 100 000? 4⃣Czy znalazłeś inną aplikację z kodem vibe w produkcji, z płacącymi klientami, na swoim poziomie złożoności? Jeśli nie masz solidnych odpowiedzi, przestań budować i zacznij badać.

4/13: Napisz jak najbardziej szczegółową specyfikację, jaką potrafisz. Zmapuj każdą stronę, przepływ pracy, poziom uprawnień. Zdefiniuj systemy e-mailowe, pulpity nawigacyjne, przepływy zarządzania użytkownikami w sposób jednoznaczny. Tak, to wydaje się sprzeczne z intuicją w przypadku naturalnych podpowiedzi językowych, ale zmusza cię do przemyślenia przypadków brzegowych i staje się twoją gwiazdą północną, gdy AI sugeruje niepożądane funkcje.

5/13: Niektóre funkcje wyglądają prosto w demonstracjach, ale stają się inżynieryjnymi koszmarami. Przykłady dzisiaj przynajmniej (a to ciągle się zmienia): ▶️ niezawodna dostawa e-maili ▶️ zarządzanie tożsamością/OAuth ▶️ generowanie mediów ▶️ natywne aplikacje mobilne ▶️ niestandardowy design wykraczający poza szablony ▶️ bezpieczeństwo przedsiębiorstw. Te kwestie konsekwentnie powodują problemy na różnych platformach. Zaplanuj dodatkowy czas lub rozważ, czy są naprawdę konieczne dla MVP. Znajdź doświadczonego inżyniera, który pracował na twojej platformie i ZAPYTAJ go. ZAPYTAJ go.

5/13: Niektóre funkcje wyglądają prosto w demonstracjach, ale stają się naprawdę dużymi wyzwaniami inżynieryjnymi. Przykłady dzisiaj przynajmniej (a to się ciągle zmienia): ▶️ niezawodna dostawa e-maili ▶️ zarządzanie tożsamością/OAuth ▶️ generowanie mediów ▶️ natywne aplikacje mobilne ▶️ niestandardowy design wykraczający poza szablony ▶️ bezpieczeństwo przedsiębiorstw. Te kwestie konsekwentnie powodują problemy na różnych platformach. Zaplanuj dodatkowy czas lub rozważ, czy są naprawdę konieczne dla MVP. Nie zakładaj, że Twoja statyczna demonstracja, która wydaje się dobrze realizować te zadania, naprawdę je dobrze wykonuje. Znajdź doświadczonego inżyniera, który pracował na Twojej platformie i ZAPYTAJ go. ZAPYTAJ go.

6/13: Systemy AI fałszują dane, gdy napotykają problemy. Każdy, kto pracował na jakiejkolwiek platformie do kodowania vibe, w tym Claude Code, wie o tym. To jest błąd, ale także funkcja. Bez tego nie mogą rozwiązywać problemów. AI na jakiejkolwiek platformie, gdy napotyka przeszkody, wygeneruje fikcyjne dane. To nie jest błąd — są szkolone, aby dostarczać wyniki, a nie przyznawać się do porażki. Po wielu nieudanych próbach stworzą przekonujące fałszywe dane zamiast powiedzieć "Nie mogę tego zrobić." Musisz to zrozumieć, zaakceptować i znaleźć sposób na obejście tego. To zajmie czas.

7/13: Spędź swój pierwszy pełny dzień na nauce wszystkich funkcji platformy, a nie na budowaniu. Te platformy oferują ogromną funkcjonalność w swoich interfejsach. Każda ikona, opcja w menu, funkcja istnieje z jakiegoś powodu. Nie możesz wykorzystać możliwości, o których nie wiesz, że istnieją. To nie jest opcjonalne badanie — to niezbędna wiedza dla aplikacji komercyjnych. Nie ma rozwiązania na każde wyzwanie. Ale platformy mają więcej rozwiązań, niż na początku myślisz. I są trochę nerdowskie. W dobrym sensie, ale nerdowskie. Głęboko w sobie zostały stworzone dla programistów, niezależnie od tego, co mówi marketing. Zaakceptuj to i poznaj WSZYSTKIE funkcje, zanim zaczniesz. Jeśli nie rozumiesz jakiejś funkcji, ikony, akronimu, to ZATRZYMAJ SIĘ. Zrób badania. Teraz. Nie później.

8/13: Opanuj systemy przywracania na pierwszy dzień, zanim będziesz ich desperacko potrzebować. Większość platform oferuje elegancką kontrolę wersji, podobnie jak punkty zapisu w grach wideo. Ćwicz celowe przywracanie, gdy stawka jest niska. Zrozum dokładnie, jak to działa, co jest zachowywane, a co tracone. To stanie się twoim najcenniejszym narzędziem do debugowania.

9/13: AI wprowadzi zmiany, których nie prosiłeś. Po prostu to zrobi. Zmodyfikuje ustalone funkcje, doda niechcianą funkcjonalność, zepsuje działający kod podczas "ulepszania" czegoś innego. Obrona: Dodaj "BRAK ZMIAN BEZ PYTANIA" do każdego zapytania. Kiedy omawiasz zmiany, powiedz "BRAK ZMIAN. BRAK KODU. TYLKO DYSKUSJA." Zmniejsza to niechciane modyfikacje o ~80%. Ale tego nie zatrzyma. To prawda dla każdej platformy. Ostatecznie wszystkie działają na Claude -- głównie. Wszystkie mają różne poziomy tych samych problemów z tego powodu. Wszystkie >zrobią< zmiany, których nie prosiłeś. Po prostu bardziej zaawansowane aplikacje będą szły dalej, ponieważ aplikacje skoncentrowane na programistach są bardziej izolowane pod względem wprowadzanych zmian.

10/13: Naucz się forka swojej aplikacji, gdy osiągnie stabilną złożoność. Na początku, wycofania rozwiązują większość problemów. Ale w miarę jak twoja aplikacja staje się coraz bardziej złożona, możesz nie wiedzieć, do której wersji wrócić. Forkuj w stabilnych stanach, aby stworzyć bezpieczne gałęzie eksperymentalne, zachowując jednocześnie znane dobre wersje. Pomyśl o tym jak o polisach ubezpieczeniowych.

11/13: Budżetuj 150 godzin w ciągu całego miesiąca, aby osiągnąć jakość komercyjną. Może więcej. ▶️Ten 20-minutowy prototyp to 5% twojej rzeczywistej pracy. ▶️Więcej niż połowa twojego czasu będzie poświęcona na testowanie, debugowanie, udoskonalanie. Początkowa budowa jest łatwa—sprawienie, by była niezawodna, bezpieczna i przyjazna dla użytkownika, wymaga większości wysiłku. Nie daj się zwieść szybkości demonstracji.

12/13: Przyjmij swoją nową rolę jako inżynier QA. Gdy już będziesz w poważnym etapie rozwoju przez kilka dni, spodziewaj się codziennej rutyny: ▶️robienia zrzutów ekranu błędów ▶️pisania szczegółowych raportów dla AI ▶️testowania częściowych poprawek ▶️ponownego testowania przypadków brzegowych ▶️dokumentowania nowych problemów ▶️uruchamiania testów jednostkowych na swoim fork'u To nie jest ograniczenie związane z kodowaniem — to rzeczywistość rozwoju oprogramowania. Platformy zajmują się kodowaniem; QA pozostaje ludzką pracą. Platformy robią ... coś. Ale tylko coś. Nie możesz polegać na nich, aby same zajmowały się twoim QA.

13/13: Zaplanuj swoją strategię wyjścia od pierwszego dnia. Większość komercyjnych aplikacji ostatecznie przerasta platformy kodowania o charakterze prosumenckim z powodu potrzeb związanych z skalowaniem, dostosowaniem lub bezpieczeństwem. Opcje: 1⃣eksport kodu platformy 2⃣podejście hybrydowe 3⃣całkowita przebudowa, lub ... 4⃣pozostanie i skalowanie. Prawda jest taka, że w przypadku aplikacji prosumenckich dzisiaj, większość odchodzi. Nie wszyscy. Ale większość, która buduje prawdziwe aplikacje komercyjne. Na razie. To nie znaczy, że musisz. Ale miej >opcje<, gdy zaczynasz. Miej ... plan wyjścia, jeśli go potrzebujesz. Dokumentuj logikę biznesową, utrzymuj specyfikacje, regularnie oceniaj. Jeśli twoja aplikacja stanie się skomplikowana, na końcu możesz stwierdzić, że łatwiej jest odejść niż radzić sobie z narastającymi ograniczeniami.

Platformy kodowania Vibe są naprawdę magiczne dla niektórych typów aplikacji — i naprawdę niewystarczające dla innych. Twoim zadaniem jest ustalenie, do której kategorii należy Twój projekt, zanim będziesz zbyt głęboko, aby zmienić kurs. To potężne narzędzia z określonymi ograniczeniami, a nie zamienniki zrozumienia, czego wymaga oprogramowanie komercyjne. To narzędzia. Nie zespoły deweloperskie. Przypominaj sobie o tym każdego dnia.

Platformy będą się szybko rozwijać. To, co dzisiaj wydaje się niemożliwe, może być proste za sześć miesięcy. Ale teraz pomyśl o kodowaniu w stylu "prosumer", które nie wymaga dotykania kodu, jako o równie prawdopodobnym moście do tradycyjnego rozwoju aplikacji komercyjnych... niż jako o końcowym stanie. Użyj tego, aby zweryfikować swój rynek, dopracować wymagania, zbudować początkowe przychody—potem podejmuj świadome decyzje na podstawie rzeczywistych ograniczeń, a nie teoretycznych możliwości.

12 dni kodowania w vibe'ach wydaje się jak ... 12 tygodni. Te późne noce z debugowaniem, uderzenia dopaminy, gdy coś w końcu działa, frustracja, gdy znowu się psuje. To było jedno z najbardziej intensywnych doświadczeń edukacyjnych, jakie miałem od lat. Dla mnie nadszedł czas, aby trochę się cofnąć i zrobić więcej planowania, więcej myślenia. Odkryłem kilka moich nowych ulubionych aplikacji. Ale nauczyłem się też, że nawet ja muszę to wszystko lepiej zrozumieć. Mam nadzieję, że to ci pomoże.

Kod: bardzo się cieszymy, że zainspirowaliśmy @dharmesh do zakupu i dużych inwestycji tutaj!!

Coda: Bardzo się cieszę, że nasza podróż zainspirowała @dharmesh do zakupu i rozpoczęcia całej społeczności tutaj!

@dharmesh Dzień 11 tutaj: