Slik itererer du på en AI-bygget app uten å ødelegge den

For å iterere på en AI-bygget app uten å ødelegge den, endrer du én ting per prompt, sjekker den i forhåndsvisningen, og lagrer et sjekkpunkt før du går videre. Beskriv det du ser, ikke det du tror koden gjør, planlegg store endringer før du bygger dem, og når en endring går galt, rull tilbake til siste fungerende versjon i stedet for å be AI-en reparere sin egen reparasjon.

Den første versjonen av en app blir ofte til på minutter. Den vanskelige delen er den femtiende endringen, når hver ny prompt risikerer å ødelegge noe som allerede fungerte. Denne guiden er løkken som hindrer det.

Iterasjonsløkken

1. Velg én endring. Én funksjon, én feil, én side.
2. Beskriv den ut fra det brukeren ser og gjør.
3. For store endringer, planlegg først. Be om en plan, les den, og bygg deretter.
4. Sjekk resultatet i forhåndsvisningen — endringen og flytene rundt den.
5. Lagre et sjekkpunkt eller en commit.
6. Gjenta.

Hvert steg finnes for å holde endringene små og reversible.

Steg 1: Hold en kort liste

Før du skriver prompter, skriv ned hva du vil endre, i prioritert rekkefølge. Da slipper du å sende et avsnitt med ti ønsker i én melding, og du har en måte å si «ikke nå» til ideer som dukker opp midt i arbeidet.

Hvis en endring er stor, del den opp. «Legg til teamkontoer» blir: opprett team, inviter et medlem, bytt mellom team, begrens data til det gjeldende teamet. Hver av dem er en egen prompt. Å skrive brukerhistorier er en god måte å gjøre dette på.

Steg 2: Beskriv det du ser

AI-en kan ikke se skjermen din med mindre du forteller den. Pek på spesifikke ting, og si hva som skal skje:

På prissiden på en telefon er knappen på Pro-kortet kuttet av i høyre kant. Behold desktop-layouten som den er; på skjermer under 640 px skal kortene stables og knappene fylle hele bredden.

Sammenlign det med «prissiden ser dårlig ut på mobil». Den første kan gjøres og sjekkes i én omgang; den andre inviterer til en redesign du ikke ba om.

Skjermbilder hjelper. Hvis appbyggeren tar imot bilder, legg ved ett og sirkle problemet.

Steg 3: Planlegg før store endringer

For alt som berører flere deler av appen — en ny datamodell, betalinger, brukerroller — be om en plan før noen kode endres:

Ikke endre kode ennå. Jeg vil at brukere skal tilhøre team og bare se prosjektene til sitt team. Planlegg endringen: hvilke tabeller, sider og API-ruter som endres, hva som skjer med eksisterende brukeres data, og i hvilken rekkefølge du ville bygget det.

Les planen. Hvis den er feil, er det mye billigere å korrigere en plan enn å angre en bygging.

Steg 4: Si hva som ikke må endres

AI-verktøy «rydder» noen ganger i ting du ikke spurte om. Beskytt det som fungerer:

Legg til et datofilter i ordretabellen. Ikke endre tabellens kolonner, stil eller eksportknappen.

For regler som gjelder overalt — merkefarger, tone i språket, «slett aldri data uten bekreftelse» — legg dem i en notatfil eller kunnskapsinnstilling for prosjektet som AI-en leser hver gang, i stedet for å gjenta dem.

Steg 5: Sjekk mer enn endringen

Etter hver prompt, test:

• Selve endringen. Gjør den det du ba om, på desktop og telefon?
• Naboene. Ting på samme side, og flyter som bruker de samme dataene.
• Den kritiske veien. Registrering, innlogging, hovedhandlingen, betaling. Et halvt minutts gjennomgang etter hver store endring fanger opp mesteparten av ødeleggelsene tidlig.

Hvis noe er feil, rapporter det presist — se slik skriver du en god feilrapport.

Steg 6: Rull tilbake i stedet for å stable lapper

Når en endring ødelegger noe og den første reparasjonen ikke virker, stopp. Hver ekstra «reparasjon» bygger på en ødelagt tilstand, og problemene forsterker hverandre.

Gjør i stedet dette:

1. Rull tilbake til siste versjon som fungerte (et sjekkpunkt eller en Git-commit).
2. Finn ut hva som var uklart i prompten.
3. Prøv igjen med en mindre eller tydeligere forespørsel.

Den endringen ødela lagring av utkast. Jeg har rullet tilbake. Denne gangen: legg bare til autolagringsindikatoren, som tekst i toppteksten. Ikke endre hvordan utkast lagres.

Steg 7: Vit når en ny bygging er riktig

Å bygge på nytt fra bunnen av kaster bort mye fungerende detaljer. Det er verdt det bare når:

• Produktideen har endret seg helt.
• Den underliggende strukturen ikke kan støtte det du nå trenger — for eksempel om den ble bygget som en statisk side og nå trenger kontoer og en database.
• Prosjektet fortsatt er nær tomt.

Når du bygger på nytt, lag en liste over det som skal beholdes: navn, farger, tekst, delene brukerne likte.

Eksempelprompter

Før vi fortsetter, oppsummer hvordan appen fungerer nå: sider, data den lagrer, og alt du tror er skjørt.

Jeg vil legge til gjentakende bestillinger. Hva er den minste versjonen som ville vært nyttig? Foreslå den som tre separate endringer vi kan gjøre én om gangen.

Gå gjennom de tre siste endringene for alt som kan ha ødelagt kassaflyten. Ikke endre noe ennå.

Vanlige feil

• Ti forespørsler i én prompt. Noen blir gjort, noen halvveis, og du kan ikke se hvilke.
• Vag tilbakemelding. «Det er ødelagt» eller «gjør det bedre» gir gjetninger.
• Aldri å sjekke naboene. En endring i en delt komponent ødelegger tre andre sider.
• Å reparere reparasjoner. Er du fire prompter inn i en feil, rull tilbake.
• Å gjenta kontekst hver gang i stedet for å holde faste regler i prosjektnotater.
• Å bygge på nytt når du står fast. De fleste «start på nytt»-øyeblikk er egentlig «rull tilbake to steg».

Sjekkliste

• Ett mål per prompt.
• Jeg beskriver det jeg ser og hva som skal skje.
• Store endringer får en plan før noen kode.
• Jeg sier hva som ikke må endres.
• Etter hver endring tester jeg den, naboene og den kritiske veien.
• Jeg lagrer et sjekkpunkt eller en commit etter hver endring som fungerer.
• Når en reparasjon mislykkes, ruller jeg tilbake i stedet for å stable reparasjoner.
• Faste regler ligger i prosjektnotater som AI-en leser hver gang.

Iterere på Mythex

Mythex er bygget rundt denne løkken:

• Plan-, Build- og Ask-moduser. Plan diskuterer tilnærmingen før redigering; Ask svarer uten å endre kode; Build gjør endringen. Se Chat.
• Sjekkpunkter. Etter hver vellykket tur lagrer Mythex et git-sjekkpunkt; Revert to this point ruller tilbake. Du kan også redigere en tidligere melding og bruke Discard & resend for å prøve en annen prompt fra det punktet. Se Iterer uten å bygge på nytt.
• Kunnskap. Prosjektinnstillinger → Knowledge holder faste notater som agenten følger i hver melding.
• /test får agenten til å klikke seg gjennom forhåndsvisningen som en bruker etter en stor endring.

Mindre forespørsler koster også færre kreditter. For å skrive selve promptene, se slik skriver du prompter til AI-appbyggere; når noe går i stykker, se slik feilsøker du en AI-bygget app.

Spørsmål