Skapa en isolerad kopia, bekräfta att den matchar originalets baslinje och beställ sedan en avgränsad synlig ändring. Godkänt betyder att det nya beteendet fungerar i två bestämda steg, att designen följer två synliga regler och att originalets publika adress fortfarande ser ut och fungerar som före provet.
Vad Fable-resultatet säger – och inte säger
I Lovables officiella presentation av Fable 5.1 jämförs modellen med Fable 5 i tre interna kategorier: nybyggen, iterativ rättning av befintlig kod och visuell design. Jämförelsen gjordes på låg, medel och hög resonemangsnivå, och varje uppgift kördes fem gånger. På hög nivå fick Fable 5.1 en 17,2 procent högre viktad poäng för iterativ kodrättning och en 31,4 procent lägre kostnad per uppgift än Fable 5.
Siffrorna behöver sin motvikt. I samma interna test på hög nivå var poängen för nybyggen 2,7 procent lägre och kostnaden per sådan uppgift 7,1 procent högre. Visuell design låg 3,5 procent högre i poäng, men kostade 7,8 procent mer per uppgift. Det här är alltså inte bevis för att modellen är bättre och billigare på allt. Det är Lovables mätning av avgränsade arbetskategorier mot en viss föregångare – inte ett prisbesked, en prognos för din app eller ett löfte om färre fel.
Lovable uppger att Fable 5.1 öppnar den körande appen i webbläsaren innan den kallar arbetet klart. Det är en modellkontroll. Den vet fortfarande bara vad du beställde och vad den själv valde att prova. Om din beställning saknar ett viktigt beteende kan ett väl genomfört självtest ändå godkänna fel sak.
Lovable beskriver också Fable 5.1 som modellen tjänsten använder vid komplicerat arbete ovanpå appar som redan är live. Under fortsatta A/B-test kan fastnade, längre och mer komplicerade sessioner routas dit. Formuleringen betyder inte att du får eller ser samma modell vid varje ändring. Utgå därför från resultatet du kan observera i appen, inte från vilket modellnamn du tror arbetade bakom kulisserna.
Frys baslinjen innan kopian skapas
Välj en liten förbättring i en vy som redan fungerar. Exemplet här är en lista över tre ärenden där knappen Alla visar samtliga poster. Du vill lägga till filtret Väntar. Byt orden så att de passar din app, men behåll upplägget: ett krav på vad som händer och ett krav på hur det ser ut.
Använd påhittade testposter och ett testkonto. En projektkopia behöver inte innebära att datan är isolerad; den kan fortfarande peka mot samma databas, utskick eller betalflöde. Kontrollera vad kopian ansluter till innan du klickar, sparar eller skickar något. Om du behöver återställa data är det ett annat prov: artikeln Prova att återställa appen från en backup skiljer en datakopia från en vanlig projektkopia.
Kopian ska ha en egen identitet
Använd den kopierings-, remix- eller förgreningsväg som faktiskt finns i din aktuella arbetsyta. Artikeln utgår inte från att en viss knapp ingår i varje konto. Ge kopian ett namn som inte kan förväxlas med originalet, till exempel Ärenden – Fable 5.1-prov – 2026-09-02. Koppla inte originalets publika adress till den.
En kopia som öppnas är inte automatiskt en korrekt baslinje. Om den saknar en testpost eller redan ser annorlunda ut vet du inte senare om avvikelsen kom från kopieringen eller modellens ändring. Börja inte prompten förrän samma baslinje är synlig på båda ställena.
Beställ exakt de två krav som ska poängsättas
Prompten nedan ändrar bara filtret. Den beställer samma handlingar, texter och skärmstorlekar som kontrollen ska mäta. Det minskar tolkningsutrymmet utan att tala om hur koden måste skrivas.
Arbeta endast i projektet ”Ärenden – Fable 5.1-prov – 2026-09-02”. Ändra inte originalprojektet och publicera ingenting. På sidan Ärenden: lägg till filtret ”Väntar” bredvid det befintliga filtret ”Alla”. När jag väljer Väntar ska endast testärendena BETA och GAMMA visas. När jag väljer Alla igen ska ALFA, BETA och GAMMA visas i ursprunglig ordning. Designkrav: Väntar ska använda samma höjd, textstil och hörnform som Alla. Det aktiva filtret ska kunna skiljas från det inaktiva utan att texten flyttar sig. Vid 390 och 1280 pixlars bredd ska båda filtren ligga på samma rad utan att överlappa den första ärenderaden. Ändra inte sidhuvudet, formuläret för nytt ärende eller ärendekortens innehåll. Kör först kontrollerna ovan i förhandsvisningen. Rapportera varje kontroll som godkänd eller underkänd och ange vad du faktiskt såg. Rätta inget mer i samma körning om en kontroll misslyckas.
Metod och poängkriterium matchar nu varandra. Beteendekravet mäter två filterlägen med namngivna poster. Designkravet mäter samma visuella egenskaper som prompten beställer, vid samma två bredder. “Snyggare filter” hade inte gått att poängsätta på det sättet.
Jämför previewn mot baslinjen rad för rad
Låt gärna Lovable köra sin kontroll, men gör samma prov själv efteråt. Ladda om förhandsvisningen helt innan första klicket. Anteckna förväntat och faktiskt resultat innan du börjar rätta. En enkel matris gör ett nästan-rätt resultat synligt:
Ta en ny skärmbild av kopian vid varje bredd och lägg den bredvid baslinjen. Designkontrollen handlar inte om att bilderna ska vara identiska – den nya knappen ska ju finnas – utan om att alla andra synliga delar ligger kvar. Om flera saker har ändrats, gå tillbaka och beställ en avgränsad rättning. Artikeln En sak i taget visar varför staplade fixar gör det omöjligt att se vilken ändring som löste problemet.
Godkänd kopia är underlag för beslut, inte liveändring
Markera varje rad med godkänd, underkänd eller inte körbar. Fyra godkända rader och två obesvarade är inte ett godkänt prov. “Inte körbar” är viktig information: kanske saknar kopian testdata, kanske fungerar inte smal bredd i den inbyggda previewn, eller kanske kan du inte bevisa att originalet är orört.
- kopian och originalet delar ett skarpt sidoeffektflöde som du inte kan stänga av,
- Lovables rapport säger godkänt men ditt eget klickprov visar fel poster,
- filtret fungerar men sidhuvudet, formuläret eller mobilvyn har ändrats,
- originalets publika adress har fått den nya knappen under kopieprovet, eller
- du inte längre kan återskapa baslinjen som jämförelsen började med.
När alla sex rader är godkända har du ett granskat exempel på hur ändringen ska fungera och se ut. Först då kan du besluta om motsvarande ändring ska beställas för liveappen. Beslutet bör behålla samma två krav och samma provmatris. Kopiera inte bara en vag slutsats som “gör som i testet”; då tappar nästa körning de synliga kriterier som gjorde provet användbart.
Originalets namn, adress, tre testposter och två skärmbilder finns sparade som baslinje. Kopian har ett eget tydligt namn och en bekräftad isolering från skarpa utskick, betalningar och data. Bara filtret Väntar har beställts. B1, B2, D1, D2, A1 och O1 är godkända med faktiskt resultat noterat, och ingen publicering har gjorts. Du har nu ett beslutsunderlag för en eventuell liveändring – inte ett löfte från modellnamnet.