Så itererar du på en AI-byggd app utan att förstöra den

För att iterera på en AI-byggd app utan att förstöra den, ändra en sak per prompt, kontrollera den i förhandsvisningen och spara en checkpoint innan du går vidare. Beskriv vad du ser i stället för vad du tror att koden gör, planera stora ändringar innan du bygger dem, och när en ändring går fel, återställ till den senaste fungerande versionen i stället för att be AI:n laga sin egen lagning.

Den första versionen av en app blir ofta klar på några minuter. Det svåra är den femtionde ändringen, när varje ny prompt riskerar att bryta något som redan fungerade. Den här guiden är loopen som förhindrar det.

Iterationsloopen

1. Välj en ändring. En funktion, en bugg, en sida.
2. Beskriv den utifrån vad användaren ser och gör.
3. Planera stora ändringar först. Be om en plan, läs den och bygg sedan.
4. Kontrollera resultatet i förhandsvisningen: ändringen och flödena runt den.
5. Spara en checkpoint eller commit.
6. Upprepa.

Varje steg finns för att hålla ändringarna små och reversibla.

Steg 1: Håll en kort lista

Innan du skriver prompten, skriv ner vad du vill ändra, i ordning efter vikt. Det hindrar dig från att skicka ett stycke med tio önskemål i ett meddelande, och ger dig ett sätt att säga ”inte nu” till idéer som dyker upp mitt i arbetet.

Om en ändring är stor, dela upp den. ”Lägg till teamkonton” blir: skapa team, bjud in en medlem, byt mellan team, begränsa data till det aktuella teamet. Varje sak är en egen prompt. Att skriva användarhistorier är ett bra sätt att göra det.

Steg 2: Beskriv vad du ser

AI:n kan inte se din skärm om du inte berättar. Peka på specifika saker och säg vad som ska hända:

På prissidan i mobilen är Pro-kortets knapp avklippt vid högerkanten. Behåll skrivbordslayouten som den är; under 640 px, stapla korten och gör knapparna fullbredd.

Jämför det med ”prissidan ser dålig ut på mobilen”. Den första kan göras och kontrolleras på en gång; den andra bjuder in till en omdesign som du inte bad om.

Skärmbilder hjälper. Om din byggare tar emot bilder, bifoga en och rita en ring runt problemet.

Steg 3: Planera innan stora ändringar

För allt som berör flera delar av appen, en ny datamodell, betalningar, användarroller, be om en plan innan någon kod ändras:

Ändra inte koden än. Jag vill att användare ska tillhöra team och bara se sitt teams projekt. Planera ändringen: vilka tabeller, sidor och API-routes som ändras, vad som händer med befintliga användares data och i vilken ordning du skulle bygga det.

Läs planen. Om den är fel är det mycket billigare att rätta en plan än att ångra en build.

Steg 4: Säg vad som inte får ändras

AI-verktyg ”städar” ibland saker du inte bad om. Skydda det som fungerar:

Lägg till ett datumfilter i ordertabellen. Ändra inte tabellens kolumner, stilar eller exportknappen.

För regler som gäller överallt, varumärkesfärger, tonalitet, ”radera aldrig data utan bekräftelse”, lägg dem i en projektanteckningsfil eller kunskapsinställning som AI:n läser varje gång, i stället för att upprepa dem.

Steg 5: Kontrollera mer än ändringen

Efter varje prompt, testa:

• Själva ändringen. Gör den det du bad om, på dator och telefon?
• Grannarna. Saker på samma sida, och flöden som använder samma data.
• Den kritiska vägen. Registrera dig, logga in, huvudåtgärden, betalning. En trettiosekunders genomgång efter varje stor ändring fångar det mesta av trasigheten tidigt.

Om något är fel, rapportera det exakt. Se hur du skriver en bra buggrapport.

Steg 6: Gå tillbaka i stället för att stapla på

När en ändring förstör något och den första lagningen inte fungerar, stanna. Varje extra ”lagning” bygger på ett trasigt läge, och problemen förstärker varandra.

Gör så här i stället:

1. Återställ till den senaste versionen som fungerade (en checkpoint eller Git-commit).
2. Fundera över vad som var oklart i prompten.
3. Försök igen med en mindre eller tydligare förfrågan.

Den ändringen förstörde sparandet av utkast. Jag har återställt. Den här gången: lägg bara till en autosave-indikator, som text i sidhuvudet. Ändra inte hur utkast sparas.

Steg 7: Vet när en ombyggnad är rätt

Att bygga om från början kastar bort mycket fungerande detalj. Det är värt det bara när:

• Produktidén har förändrats helt.
• Den underliggande strukturen inte klarar det du nu behöver, till exempel om den byggdes som en statisk sajt och nu behöver konton och en databas.
• Projektet fortfarande ligger nära tomt.

När du bygger om, lista vad som ska behållas: namn, färger, text, delarna som användarna gillade.

Exempelprompter

Innan vi fortsätter, sammanfatta hur appen fungerar just nu: sidor, data den lagrar och allt du tror är bräckligt.

Jag vill lägga till återkommande bokningar. Vad är den minsta version som skulle vara användbar? Föreslå den som tre separata ändringar som vi kan göra en i taget.

Granska de tre senaste ändringarna för allt som kan ha brutit utcheckningsflödet. Ändra inte något än.

Vanliga misstag

• Tio önskemål i en prompt. Vissa blir klara, andra halvklara, och du kan inte se vilka.
• Vag återkoppling. ”Det är trasigt” eller ”gör det bättre” ger gissningar.
• Att aldrig kontrollera grannarna. En ändring i en delad komponent bryter tre andra sidor.
• Att laga lagningar. Fyra prompter in i en bugg, gå tillbaka.
• Att upprepa sammanhanget varje gång i stället för att hålla stående regler i projektanteckningar.
• Att bygga om när du kör fast. De flesta ”börja om”-ögonblick betyder egentligen ”gå tillbaka två steg”.

Checklista

• Ett mål per prompt.
• Jag beskriver vad jag ser och vad som ska hända.
• Stora ändringar får en plan innan någon kod.
• Jag säger vad som inte får ändras.
• Efter varje ändring testar jag den, dess grannar och den kritiska vägen.
• Jag sparar en checkpoint eller commit efter varje ändring som fungerar.
• När en lagning inte fungerar går jag tillbaka i stället för att stapla.
• Stående regler finns i projektanteckningar som AI:n läser varje gång.

Iterera på Mythex

Mythex är byggt kring den här loopen:

• Lägena Plan, Build och Ask. Plan diskuterar tillvägagångssättet innan något redigeras; Ask svarar utan att ändra kod; Build gör ändringen. Se Chatt.
• Checkpoints. Efter varje lyckad tur sparar Mythex en git-checkpoint; Återställ till den här punkten går tillbaka. Du kan också redigera ett tidigare meddelande och Kassera och skicka igen för att prova en annan prompt från den punkten. Se Iterera utan att bygga om.
• Kunskap. Projektinställningar → Kunskap håller stående anteckningar som agenten följer i varje meddelande.
• /test låter agenten klicka igenom förhandsvisningen som en användare efter en stor ändring.

Mindre förfrågningar kostar också färre krediter. För att skriva själva prompterna, se hur du skriver prompter för AI-appbyggare; när något väl går sönder, se hur du felsöker en AI-byggd app.

Frågor