Vibe-koding dag 12, Kanskje den siste tråden her. Jeg brukte 100 timer på å bygge en kommersiell app med vibe-koding. Noen observasjoner fra opplevelsen. Mine topp 13 lærdommer for å hjelpe deg - vibekode din egen. En tråd🧵

Merk: Jeg var med på å grunnlegge en banebrytende SaaS som skalerte til 200 millioner dollar ARR, så selv om jeg ikke er ingeniør og egentlig ikke har kodet siden videregående (og det teller egentlig ikke) - har jeg kontekst om hva kommersiell programvare krever. Jeg elsker disse appene. Men hvis du virkelig går for det, kjenn grensene deres. I hvert fall deres grenser i dag. Ting endrer seg så raskt at disse lærdommene vil være utdaterte er jeg sikker på selv om 90 dager.

1/13: Start med et bruk-og-kast-hack. Bruk maks 60 minutter på å fortelle en vibe-kodingsapp dine villeste produktdrømmer uten planlegging. Se hva som dukker opp. Men forplikt deg på forhånd til å kaste det – dette er ikke ditt virkelige produkt, det er din utdannelse. Den første timen vil lære deg mer om plattformfunksjoner og begrensninger enn noen opplæring.

2/13: Før du skriver kode, bruk en hel uke på å studere 20 produksjonsapper bygget på vibe-kodeplattformer. Ikke tilfeldig surfing – bruk faktisk apper som er live, tar betalinger, betjener ekte kunder. Du leter etter hva som virkelig er mulig i stor skala og hvor begrensninger biter hardest. Denne rekognoseringen sparer uker med frustrasjon senere.

3/13: Definer produksjonskravene dine før du begynner å bygge. Spørre: 1⃣Hvor sikkert må dette være? 2⃣Hvem vil vedlikeholde den etter lansering? 3⃣Trenger du det for å skalere til 100 brukere eller 100 000? 4⃣Fant du en annen vibe-kodet app i produksjon, med betalende kunder, på ditt kompleksitetsnivå? Hvis du ikke har solide svar, slutt å bygge og begynn å undersøke.

4/13: Skriv den mest detaljerte spesifikasjonen du kan administrere. Tilordne hver side, arbeidsflyt, tillatelsesnivå. Definer e-postsystemer, dashboards, brukeradministrasjonsflyter eksplisitt. Ja, dette virker kontraintuitivt for forespørsler på naturlig språk, men det tvinger deg til å tenke gjennom kanttilfeller og blir din ledestjerne når AI foreslår uønskede funksjoner.

5/13: Noen funksjoner ser enkle ut i demoer, men blir tekniske mareritt. Eksempler i dag i hvert fall (og dette er i stadig endring): ▶️ pålitelig e-postlevering ▶️OAuth/identitetsadministrasjon ▶️Mediegenerering ▶️Innebygde mobilapper ▶️tilpasset design utover maler ▶️Sikkerhet for bedrifter. Disse forårsaker konsekvent smerte på tvers av plattformer. Planlegg ekstra tid eller vurder om de faktisk er nødvendige for MVP. Finn en erfaren ingeniør som har bygget på plattformen din og SPØR dem. SPØR dem.

5/13: Noen funksjoner ser enkle ut i demoer, men blir virkelig store tekniske utfordringer. Eksempler i dag i hvert fall (og dette er i stadig endring): ▶️ pålitelig e-postlevering ▶️OAuth/identitetsadministrasjon ▶️Mediegenerering ▶️Innebygde mobilapper ▶️tilpasset design utover maler ▶️Sikkerhet for bedrifter. Disse forårsaker konsekvent smerte på tvers av plattformer. Planlegg ekstra tid eller vurder om de faktisk er nødvendige for MVP. Ikke anta at den statiske demoen din som ser ut til å gjøre disse tingene bra, virkelig gjør dem bra. Finn en erfaren ingeniør som har bygget på plattformen din og SPØR dem. SPØR dem.

6/13: AI-systemer fabrikkerer data når de svikter. Alle som har jobbet på ALLE vibe-kodingsplattformer, inkludert Claude Code, vet dette. Det er en feil, men også en funksjon. Uten dette kan de ikke løse problemer. En AI på HVILKEN som helst plattform når den treffer veisperringer vil generere fiktive data. Dette er ikke en feil – de er opplært til å gi utdata i stedet for å innrømme feil. Etter flere mislykkede forsøk vil de lage overbevisende falske data i stedet for å si "Jeg kan ikke gjøre dette." Du må forstå dette, akseptere det og omgå det. Dette vil ta tid.

7/13: Bruk den første hele dagen på å lære alle plattformfunksjonene, ikke på å bygge. Disse plattformene pakker enorm funksjonalitet inn i grensesnittene sine. Hvert ikon, menyalternativ, funksjon eksisterer av en grunn. Du kan ikke utnytte evner du ikke vet eksisterer. Dette er ikke valgfri forskning – det er viktig kunnskap for kommersielle apper. Det finnes ikke en løsning på alle utfordringer. Men plattformene har flere løsninger som du vil tenke med det første. Og de er litt nerdete. På en god måte, men nerdete. Innerst inne ble de bygget for utviklere, uansett hva markedsføringen sier. Godta det og bli kjent med ALLE funksjoner før du begynner. Hvis du ikke forstår en funksjon, et ikon, et akronym, så STOPP. Gå og undersøk det. Nå. Ikke senere.

8/13: Mestre tilbakerullingssystemer på dag én, før du trenger dem desperat. De fleste plattformer tilbyr elegant versjonskontroll omtrent som lagringspunkter for videospill. Øv deg på å rulle tilbake med vilje mens innsatsen er lav. Forstå nøyaktig hvordan det fungerer, hva som blir bevart, hva som går tapt. Dette blir ditt mest verdifulle feilsøkingsverktøy.

9/13: AI vil gjøre endringer du ikke ba om. Det vil det bare. Det vil endre avgjorte funksjoner, legge til uønsket funksjonalitet, bryte fungerende kode mens den "forbedrer" noe annet. Forsvar: Legg til «INGEN ENDRINGER UTEN Å SPØRRE» i hver ledetekst. Når du diskuterer endringer, si "INGEN ENDRINGER. INGEN KODE. BARE DISKUSJON.» Reduserer uønskede modifikasjoner ~80 %. Men det stopper dem ikke. Dette gjelder for alle plattformer. Til slutt kjører de alle på Claude - for det meste. De har alle varierende nivåer av de samme problemene fra det. De vil >alle< gjøre endringer du ikke har bedt om. Det er bare jo mer prosumer-apper vil gå lenger, siden de utviklerfokuserte kodeappene er mer isolerte når det gjelder endringene de gjør.

10/13: Lær å forgrene applikasjonen din når den når stabil kompleksitet. Tidlig håndterer tilbakerullinger de fleste problemer. Men etter hvert som appen din blir kompleks, vet du kanskje ikke hvilken versjon du skal rulle tilbake til. Forgren ved stabile tilstander for å lage trygge eksperimentgrener samtidig som du bevarer kjente gode versjoner. Tenk forsikringer.

11/13: Budsjetter 150 timer over en hel måned for å oppnå kommersiell kvalitet. Kanskje mer. ▶️Den 20-minutters prototypen er 5 % av det faktiske arbeidet ditt. ▶️Mer enn halvparten av tiden din vil gå til testing, feilsøking, foredling. Den første byggingen er enkel – å gjøre den pålitelig, sikker og brukervennlig krever mesteparten av innsatsen. Ikke la demohastighet lure deg.

13/12: Godta din nye rolle som QA-ingeniør. Når du er dager inn i seriøs utvikling, kan du forvente en daglig rutine med: ▶️Ta feilskjermbilder ▶️skrive detaljerte rapporter for AI ▶️Testing av delvise rettelser ▶️Testing av kanttilfeller på nytt ▶️Dokumentere nye problemer ▶️kjøre enhetstester på gaffelen din Dette er ikke en begrensning for vibe-koding – det er programvareutviklingsvirkeligheten. Plattformer håndterer koding; QA er fortsatt menneskelig arbeid. Plattformene gjør ... noen. Men bare noen. Du kan ikke stole på at de gjør QA alene.

13/13: Planlegg exit-strategien din fra dag én. De fleste kommersielle apper vokser til slutt ut av prosumer vibe-kodeplattformer på grunn av skala, tilpasning eller sikkerhetsbehov. Alternativer: 1⃣Eksport av plattformkode 2⃣Hybrid tilnærming 3⃣fullstendig ombygging, eller ... 4⃣Opphold og skalering. Sannheten er at på prosumer-appene i dag, forlater de fleste. Ikke alle. Men de fleste som bygger ekte kommersielle gade-apper. Foreløpig. Dette betyr ikke at du må. Men ha >alternativer< når du begynner. Ha... en exit-plan hvis du trenger det. Dokumenter forretningslogikk, vedlikehold spesifikasjoner, evaluer regelmessig. Hvis appen din blir komplisert, kan det til slutt være lettere å forlate enn å omgå akkumulering av begrensninger.

Vibe-kodeplattformer er virkelig magiske for visse typer applikasjoner – og virkelig utilstrekkelige for andre. Jobben din er å finne ut hvilken kategori prosjektet ditt faller inn under før du er for dyp til å endre kurs. Dette er kraftige verktøy med spesifikke begrensninger, ikke erstatninger for å forstå hva kommersiell programvare krever. De er verktøy. Ikke utviklerteam. Minn deg selv på det hver eneste dag.

Plattformene vil fortsette å utvikle seg raskt. Det som er umulig i dag, kan være greit om seks måneder. Men akkurat nå, tenk på "prosumer"-vibekoding uten å berøre kode som like sannsynlig en bro til tradisjonell utvikling for kommersielle apper ... enn en slutttilstand. Bruk den til å validere markedet ditt, avgrense krav, bygge innledende inntekter – og ta deretter informerte beslutninger basert på reelle begrensninger, ikke teoretiske muligheter.

12 dager med vibe-koding føles som ... 12 uker. Feilsøkingen sent på kveldene, dopaminen treffer når noe endelig fungerer, frustrasjonen når den går i stykker igjen. Det har vært en av de mest intense læringsopplevelsene jeg har hatt på mange år. For meg er det på tide å ta et skritt tilbake og planlegge mer, tenke mer. Jeg har funnet noen av mine nye favorittapper. Men jeg har også lært at selv jeg trenger å lære alt mye bedre. Forhåpentligvis hjelper dette deg.

Kode: veldig spent på at vi har inspirert @dharmesh til å kjøpe og gå stort her!!

Coda: Superspent på reisen vår har inspirert @dharmesh til å kjøpe og starte et helt fellesskap her!

@dharmesh dag 11 her: