Vibe Coding Dag 12, Kanske den sista tråden här. Jag tillbringade 100 timmar med att bygga en app av kommersiell kvalitet med vibekodning. Några iakttagelser från upplevelsen. Mina 13 bästa lärdomar som hjälper dig - vibekoda din egen. En tråd🧵

Notera: Jag var med och grundade en banbrytande SaaS som skalade till 200 miljoner dollar i ARR, så även om jag inte är ingenjör och inte riktigt har kodat sedan gymnasiet (och det räknas inte riktigt) - har jag sammanhang om vad kommersiell programvara kräver. Jag älskar dessa appar. Men om du verkligen går för det, känn till deras gränser. Åtminstone deras gränser idag. Saker och ting förändras så snabbt, jag är säker på att dessa lärdomar kommer att vara föråldrade även om 90 dagar.

1/13: Börja med ett slit-och-släng-hack. Tillbringa max 60 minuter med att berätta för en vibe-kodningsapp som dina vildaste produktdrömmar om utan någon planering. Se vad som dyker upp. Men bestäm dig i förväg för att slänga det – det här är inte din riktiga produkt, det är din utbildning. Den första timmen kommer att lära dig mer om plattformens funktioner och begränsningar än någon självstudie.

2/13: Innan du skriver någon kod, tillbringa en hel vecka med att studera 20 produktionsappar byggda på vibe-kodningsplattformar. Inte slentrianmässig surfning – använd faktiskt appar som är live, tar emot betalningar och betjänar riktiga kunder. Du letar efter vad som verkligen är möjligt i stor skala och där begränsningarna biter hårdast. Denna rekognoscering sparar veckor av frustration senare.

3/13: Definiera dina produktionskrav innan du börjar bygga. Fråga: 1⃣Hur säkert behöver detta vara? 2⃣Vem kommer att underhålla den efter lanseringen? 3⃣Behöver du den för att skala till 100 användare eller 100 000? 4⃣Hittade du en annan vibe-kodad app i produktion, med betalande kunder, på din komplexitetsnivå? Om du inte har solida svar, sluta bygga och börja forska.

13/4: Skriv den mest detaljerade specifikationen du kan hantera. Mappa varje sida, arbetsflöde, behörighetsnivå. Definiera e-postsystem, instrumentpaneler, användarhanteringsflöden explicit. Ja, detta verkar kontraintuitivt för uppmaningar på naturligt språk, men det tvingar dig att tänka igenom gränsfall och blir din polstjärna när AI föreslår oönskade funktioner.

13/5: Vissa funktioner ser enkla ut i demos men blir tekniska mardrömmar. Exempel idag i alla fall (och detta förändras ständigt): ▶️ Pålitlig e-postleverans ▶️OAuth/identitetshantering ▶️Generering av media ▶️Inbyggda mobilappar ▶️Anpassad design utöver mallar ▶️Säkerhet för företag. Dessa orsakar konsekvent smärta på olika plattformar. Planera extra tid eller fundera på om de faktiskt är nödvändiga för MVP. Hitta en erfaren ingenjör som har byggt vidare på din plattform och FRÅGA dem. FRÅGA dem.

13/5: Vissa funktioner ser enkla ut i demos men blir riktigt stora tekniska utmaningar. Exempel idag i alla fall (och detta förändras ständigt): ▶️ Pålitlig e-postleverans ▶️OAuth/identitetshantering ▶️Generering av media ▶️Inbyggda mobilappar ▶️Anpassad design utöver mallar ▶️Säkerhet för företag. Dessa orsakar konsekvent smärta på olika plattformar. Planera extra tid eller fundera på om de faktiskt är nödvändiga för MVP. Anta inte att din statiska demo som verkar göra dessa saker bra verkligen gör dem bra. Hitta en erfaren ingenjör som har byggt vidare på din plattform och FRÅGA dem. FRÅGA dem.

6/13: AI-system fabricerar data när de misslyckas. Alla som har arbetat på NÅGON vibe-kodningsplattform, inklusive Claude Code, vet detta. Det är en bugg men också en funktion. Utan detta kan de inte lösa problem. En AI på VILKEN plattform som helst när den stöter på hinder kommer att generera fiktiva data. Det här är inte en bugg – de är tränade för att ge utdata i stället för att erkänna fel. Efter flera misslyckade försök kommer de att skapa övertygande falska data istället för att säga "Jag kan inte göra det här". Du måste förstå detta, acceptera det och arbeta runt det. Detta kommer att ta tid.

13/7: Tillbringa din första hela dag med att lära dig alla plattformens funktioner, inte att bygga. Dessa plattformar har enorm funktionalitet i sina gränssnitt. Varje ikon, menyalternativ, funktion finns av en anledning. Du kan inte utnyttja funktioner som du inte vet finns. Det här är inte valfri forskning – det är viktig kunskap för appar av kommersiell kvalitet. Det finns inte en lösning på alla utmaningar. Men plattformarna har fler lösningar än du kommer att tänka först. Och de är lite nördiga. På ett bra sätt, men nördigt. Innerst inne är de byggda för utvecklare, oavsett vad marknadsföringen säger. Acceptera det och lär känna ALLA funktioner innan du börjar. Om du inte förstår en funktion, en ikon, en akronym, STOPPA. Gå och undersök det. Nu. Inte senare.

8/13: Bemästra rollback-system dag ett, innan du desperat behöver dem. De flesta plattformar erbjuder elegant versionskontroll ungefär som sparpunkter för videospel. Öva på att rulla tillbaka avsiktligt medan insatserna är låga. Förstå exakt hur det fungerar, vad som bevaras och vad som går förlorat. Detta blir ditt mest värdefulla felsökningsverktyg.

9/13: AI kommer att göra ändringar som du inte har begärt. Det bara kommer. Det kommer att modifiera etablerade funktioner, lägga till oönskad funktionalitet, bryta fungerande kod samtidigt som det "förbättrar" något annat. Försvar: Lägg till "INGA ÄNDRINGAR UTAN ATT FRÅGA" till varje uppmaning. När du diskuterar ändringar, ange "INGA ÄNDRINGAR. INGEN KOD. BARA DISKUSSION." Minskar oönskade ändringar ~80%. Men det stoppar dem inte. Detta gäller för alla plattformar. Till slut kör de alla på Claude – för det mesta. De har alla olika nivåer av samma problem från det. De kommer att >alla< göra ändringar som du inte har begärt. Det är bara mer prosumentappar som kommer att gå längre, eftersom de utvecklarfokuserade kodningsapparna är mer isolerade när det gäller de ändringar de gör.

10/13: Lär dig att förgrena ditt program när det når stabil komplexitet. I ett tidigt skede hanterar återställningar de flesta problem. Men när din app blir komplex kanske du inte vet vilken version du ska återställa till. Förgrena dig vid stabila tillstånd för att skapa säkra experimentgrenar samtidigt som du bevarar versioner som du vet fungerar. Tänk försäkringar.

11/13: Budgetera 150 timmar under en hel månad för att nå kommersiell kvalitet. Kanske mer. ▶️Den 20 minuter långa prototypen är 5 % av ditt faktiska arbete. ▶️Mer än hälften av din tid kommer att gå åt till testning, felsökning och förfining. Den första versionen är enkel – att göra den tillförlitlig, säker och användarvänlig kräver större delen av ansträngningen. Låt dig inte luras av demohastigheten.

12/13: Acceptera din nya roll som QA-ingenjör. När du väl är några dagar in i seriös utveckling, förvänta dig daglig rutin av: ▶️Ta skärmdumpar av buggar ▶️skriva detaljerade rapporter för AI ▶️Testa partiella korrigeringar ▶️Testa om gränsfall ▶️Dokumentera nya frågeställningar ▶️Köra enhetstester på din gaffel Det här är inte en begränsning av kodning av atmosfären – det är verkligheten för programvaruutveckling. Plattformar hanterar kodning; QA är fortfarande mänskligt arbete. Plattformarna gör ... några. Men bara vissa. Du kan inte lita på att de gör din QA ensam.

13/13: Planera din exitstrategi från dag ett. De flesta kommersiella appar växer så småningom ur plattformar för kodning av prosumentvibbar på grund av skalning, anpassning eller säkerhetsbehov. Alternativ: 1⃣Exportera plattformskod 2⃣Hybrid-metod 3⃣fullständig ombyggnad, eller ... 4⃣Stanna kvar och skala. Sanningen är att de flesta lämnar prosumentapparna idag. Inte alla. Men de flesta som bygger riktiga kommersiella appar. Tills vidare. Det betyder inte att du måste göra det. Men ha >alternativ< när du börjar. Ha... En exitplan om du behöver det. Dokumentera affärslogik, underhåll specifikationer, utvärdera regelbundet. Om din app blir komplex kan det i slutändan vara lättare att lämna än att kringgå ackumulerade begränsningar.

Vibe-kodningsplattformar är genuint magiska för vissa typer av applikationer – och genuint otillräckliga för andra. Ditt jobb är att ta reda på vilken kategori ditt projekt faller in i innan du är för djup för att ändra kurs. Dessa är kraftfulla verktyg med specifika begränsningar, inte ersättningar för att förstå vad kommersiell programvara kräver. De är verktyg. Inte utvecklingsteam. Påminn dig själv om det varje dag.

Plattformarna kommer att fortsätta att utvecklas snabbt. Det som är omöjligt idag kan vara enkelt om ett halvår. Men just nu, tänk på "prosumer"-vibekodning utan att röra kod som lika troligt en bro till traditionell utveckling för kommersiella appar ... än ett sluttillstånd. Använd den för att validera din marknad, förfina kraven, skapa initiala intäkter – och fatta sedan välgrundade beslut baserat på verkliga begränsningar, inte teoretiska möjligheter.

12 dagar av vibekodning känns som ... 12 veckor. De sena nätterna med felsökning, dopaminet slår till när något äntligen fungerar, frustrationen när det går sönder igen. Det har varit en av de mest intensiva lärorika upplevelserna jag har haft på flera år. För mig är det dags att ta ett steg tillbaka och göra mer planering, mer tänkande. Jag har hittat några av mina nya favoritappar. Men jag har också lärt mig att även jag behöver lära mig allt mycket bättre. Förhoppningsvis hjälper detta dig.

Kod: mycket glada vi har inspirerat @dharmesh att köpa och satsa stort här!!

Coda: Superglada över att vår resa har inspirerat @dharmesh att köpa och starta ett helt samhälle här!

@dharmesh Dag 11 här: