Sådan itererer du på en AI-bygget app uden at ødelægge den

For at iterere på en AI-bygget app uden at ødelægge den, skal du ændre én ting pr. prompt, tjekke den i preview'et og gemme et checkpoint, før du går videre. Beskriv hvad du ser, i stedet for hvad du tror koden gør, planlæg store ændringer, før du bygger dem, og når en ændring går galt, så rul tilbage til den sidste gode version i stedet for at bede AI'en rette sin egen rettelse.

Første version af en app er ofte klar på få minutter. Det svære er den halvtredsindstyvende ændring, hvor hver ny prompt risikerer at ødelægge noget, der allerede virkede. Denne guide er løkken, der forhindrer det.

Iterationsløkken

1. Vælg én ændring. Én funktion, én fejl, én side.
2. Beskriv den ud fra hvad brugeren ser og gør.
3. Ved store ændringer: planlæg først. Bed om en plan, læs den, og byg derefter.
4. Tjek resultatet i preview'et — ændringen og de flows, der ligger tæt på den.
5. Gem et checkpoint eller en commit.
6. Gentag.

Hvert trin findes for at holde ændringerne små og reversible.

Trin 1: Hold en kort liste

Før du prompter, skal du skrive ned, hvad du vil ændre, i rækkefølge efter vigtighed. Det forhindrer dig i at sende et afsnit med ti ønsker i én besked, og det giver dig en måde at sige "ikke nu" til idéer, der dukker op midt i arbejdet.

Hvis en ændring er stor, så del den op. "Tilføj teamkonti" bliver til: opret teams, inviter et medlem, skift mellem teams, begræns data til det aktuelle team. Hver er sin egen prompt. At skrive brugerhistorier er en god måde at gøre det på.

Trin 2: Beskriv hvad du ser

AI'en kan ikke se din skærm, medmindre du fortæller den det. Peg på bestemte ting, og sig hvad der skal ske:

På prissiden på en telefon er knappen på Pro-kortet skåret af i højre kant. Behold desktoplayoutet, som det er; under 640 px skal kortene stables, og knapperne skal fylde hele bredden.

Sammenlign det med "prissiden ser dårlig ud på mobil". Den første kan laves og tjekkes på én gang; den anden inviterer til en redesign, du ikke bad om.

Skærmbilleder hjælper. Hvis din builder accepterer billeder, så vedhæft et og markér problemet.

Trin 3: Planlæg før store ændringer

Til alt, der rører flere dele af appen — en ny datamodel, betalinger, brugerroller — så bed om en plan, før nogen kode ændres:

Ændr endnu ikke koden. Jeg vil have, at brugere tilhører teams og kun ser deres teams projekter. Planlæg ændringen: hvilke tabeller, sider og API-ruter ændres, hvad der sker med eksisterende brugeres data, og i hvilken rækkefølge du ville bygge det.

Læs planen. Hvis den er forkert, er det meget billigere at rette en plan, end at fortryde et byg.

Trin 4: Sig hvad der ikke må ændres

AI-værktøjer "rydder op" nogle gange i ting, du ikke bad om. Beskyt det, der virker:

Tilføj et datofilter til ordretabellen. Ændr ikke tabellens kolonner, styling eller eksportknappen.

Til regler, der gælder overalt — brandfarver, tone, "slet aldrig data uden bekræftelse" — så læg dem i en projektnotefil eller vidensindstilling, som AI'en læser hver gang, i stedet for at gentage dem.

Trin 5: Tjek mere end selve ændringen

Efter hver prompt skal du teste:

• Selve ændringen. Gør den det, du bad om, på desktop og telefon?
• Naboerne. Ting på samme side, og flows der bruger de samme data.
• Den kritiske sti. Tilmelding, login, hovedhandlingen, betaling. Et halvt minuts gennemgang efter hver stor ændring fanger det meste brud tidligt.

Hvis noget er galt, så beskriv det præcist — se sådan skriver du en god fejlrapport.

Trin 6: Rul tilbage i stedet for at stable

Når en ændring ødelægger noget, og den første rettelse ikke virker, så stop. Hver ekstra "rettelse" bygger på en ødelagt tilstand, og problemerne forstærker hinanden.

I stedet:

1. Rul tilbage til den sidste version, der virkede (et checkpoint eller en Git-commit).
2. Find ud af, hvad der var uklart i prompten.
3. Prøv igen med en mindre eller tydeligere anmodning.

Den ændring ødelagde gemning af kladder. Jeg har rullet tilbage. Denne gang: tilføj kun indikatoren for automatisk gemning, som tekst i headeren. Ændr ikke måden kladder gemmes på.

Trin 7: Vid hvornår en ny build er det rigtige

At bygge forfra smider meget fungerende detalje væk. Det er kun umagen værd, når:

• Produktideen er ændret fuldstændigt.
• Den underliggende struktur ikke kan bære det, du nu har brug for — for eksempel blev den bygget som en statisk side, og nu skal den have konti og en database.
• Projektet stadig er tæt på tomt.

Når du bygger forfra, så lav en liste over hvad der skal beholdes: navn, farver, tekst, de dele brugerne kunne lide.

Eksempler på prompts

Før vi fortsætter, så opsummer hvordan appen fungerer nu: sider, data den gemmer, og alt du mener er skrøbeligt.

Jeg vil tilføje gentagne bookinger. Hvad er den mindste version, der ville være nyttig? Foreslå den som tre separate ændringer, vi kan lave én ad gangen.

Gennemgå de sidste tre ændringer for noget, der kan have ødelagt betalingsflowet. Ret ikke endnu.

Almindelige fejl

• Ti anmodninger i én prompt. Nogle bliver udført, nogle halvt, og du kan ikke se hvilke.
• Vag feedback. "Det er i stykker" eller "gør det bedre" giver gætterier.
• Aldrig at tjekke naboerne. En ændring i en fælles komponent ødelægger tre andre sider.
• At rette rettelser. Fire prompts inde i en fejl — rul tilbage.
• At gentage konteksten hver gang i stedet for at holde faste regler i projektnoter.
• At bygge forfra, når du sidder fast. De fleste "start forfra"-øjeblikke er egentlig "rul to trin tilbage".

Tjekliste

• Ét mål pr. prompt.
• Jeg beskriver hvad jeg ser, og hvad der skal ske.
• Store ændringer får en plan, før der skrives kode.
• Jeg siger hvad der ikke må ændres.
• Efter hver ændring tester jeg den, dens naboer og den kritiske sti.
• Jeg gemmer et checkpoint eller en commit efter hver ændring, der virker.
• Når en rettelse fejler, ruller jeg tilbage i stedet for at stable rettelser.
• Faste regler ligger i projektnoter, som AI'en læser hver gang.

Iteration på Mythex

Mythex er bygget op omkring denne løkke:

• Plan-, Build- og Ask-tilstande. Plan drøfter fremgangsmåden, før der redigeres; Ask besvarer spørgsmål uden at ændre kode; Build laver ændringen. Se Chat.
• Checkpoints. Efter hver vellykket tur gemmer Mythex et git-checkpoint; Revert to this point ruller tilbage. Du kan også redigere en tidligere besked og vælge Discard & resend for at prøve en anden prompt fra det punkt. Se Iterér uden at bygge forfra.
• Viden. Projektindstillinger → Knowledge indeholder faste noter, som agenten følger ved hver besked.
• /test får agenten til at klikke sig igennem preview'et som en bruger efter en stor ændring.

Mindre forespørgsler koster også færre kreditter. For at skrive selve prompts, se sådan skriver du prompts til AI-appbyggere; når noget går i stykker, se sådan fejlretter du en AI-bygget app.

Spørgsmål