Att underhålla appar byggda med AI: vad ingen berättar om vecka två

Den första helgen med Proyecta levererar du något riktigt. Det fungerar. Dina användare (eller ditt team, eller ditt framtida jag) börjar använda det. Och så är det måndag och en kund mejlar: “Kan du lägga till en rullgardinsmeny för att filtrera på region?”

Välkommen till underhåll. Det här är den del av att bygga en AI-app som ingen pratar om, och den del där de flesta projekt antingen blir en långsiktig tillgång eller tyst faller utför ett stup. Den goda nyheten är att underhåll av en AI-byggd app är en annan upplevelse än underhåll av traditionell kod. Den ärliga nyheten är att “annorlunda” inte betyder “gratis”.

Vad underhåll faktiskt betyder

När professionella utvecklare säger “underhåll” menar de fyra saker, mer eller mindre:

Lägga till små funktioner folk ber om efter lansering.
Fixa saker som gick sönder eller var fel från början.
Hänga med i förändringar utanför din app — en betalleverantör uppdaterar sitt API, en ny webbläsare lanseras, din dataform ändras.
Städa upp så att kodbasen inte långsamt förvandlas till ett träsk.

För en AI-byggd app händer alla fyra fortfarande. Det som ändras är vem som gör dem och hur arbetet känns.

Den goda nyheten: du kan prata med den

Här är delen ingen berättade för dig när du kopierade-klistrade kod från gamla handledningar. Med en AI-appbyggare underhåller du appen på samma sätt som du byggde den: genom att beskriva vad du vill ha.

Ett verkligt exempel. En grundare vi känner byggde ett litet CRM för sin coachingverksamhet — klienter, sessioner, betalningsspårning, alltihop. Tre veckor efter lansering nämnde en klient att de skulle älska att se hur många sessioner de hade gjort det året. Hon öppnade appen och sa: “Lägg till en räknare för ‘sessioner i år’ på varje klientkort, som hämtar från sessionstabellen där datumet är 2026.” Tolv minuter senare var det live. Hon var tillbaka och coachade.

Den historien låter normal tills du kommer ihåg alternativet: pinga en frilansare, vänta två dagar, betala 300 dollar, granska en PR hon inte helt förstod och be att inget annat gick sönder. Underhållsloopen är inte snabbare för att AI:n är smartare än frilansaren. Den är snabbare för att loopen har färre människor i sig.

Den svårare nyheten: små saker ackumuleras

Här är delen som överraskar folk. AI-byggda appar ser lätta ut att ändra för att det är lätt att lägga till saker. Det som inte är lätt är att hålla hela grejen sammanhängande medan den växer.

Några mönster vi ser gå fel:

Den oavsiktliga trasslan. Du ber om “lägg till ett rabattfält i kassan.” Sex revisioner senare bor rabattlogiken på tre ställen, och bara en av dem är rätt. Inget gick sönder än, men nästa ändring kommer bli förvirrande.
Det bortglömda kravet. Du la till “fri frakt över 50 dollar” i mars. I maj ber du AI:n att “göra om kassan så att den stöder presentkort.” Den gör det. Regeln om fri frakt är borta. Ingen märkte det på två veckor.
Driften. Din app började som “ett verktyg för mig.” Den används nu av ditt team. Den mentala modell AI:n jobbar utifrån är fortfarande “för mig”, för det var vad du ursprungligen sa. Nya funktioner känns konstigt fel, och du kan inte sätta fingret på varför.

Inget av detta är misslyckanden hos AI-appbyggare. Det är misslyckanden av minne och delad kontext — samma problem som ett team av mänskliga utvecklare har, bara i en annan form.

Hur du rustar dig

Teamen som lyckas med underhåll delar några vanor. Det är mestadels inte tekniska vanor. Det är vanor kring hur du beskriver vad din app är och vad som ändrades.

Håll ett “vad den här appen är”-dokument. En sida. Målgruppen, målen, reglerna (“fri frakt över 50 dollar”, “vi mejlar aldrig användare på söndagar”, “telefon är primärnyckeln, inte mejl”). När du ber AI:n att ändra något, klistra in den relevanta regeln i prompten. Du kringgår inte AI:ns intelligens; du matar den med kontexten den omöjligt kan komma ihåg.

Beskriv ändringar i termer av beteende, inte kod. “Jag vill att användare ska se sitt regionfilter ihågkommet mellan sessioner” är en mycket bättre begäran än “lägg till localStorage i filtret.” Den första beskriver vad du vill ha; den andra föreskriver ett av femton sätt att göra det, och förmodligen inte det bästa.

Gör ändringar en i taget. Två ändringar i en prompt betyder att en kan misslyckas tyst och du vet inte vilken. Det snabbaste sättet att underhålla en AI-app är att hålla dina iterationer små nog att du, med en blick, kan se om resultatet är rätt.

Titta på vad som ändrades. De flesta AI-appbyggare visar dig en förhandsvisning. Använd den. De trettio sekunder du lägger på att klicka runt för att bekräfta att den nya funktionen fungerar och att de gamla funktionerna fortfarande fungerar är den billigaste försäkring du köper i år.

Vad du inte kan göra (och förmodligen inte borde)

Det finns en frestelse, när du väl har byggt en app med AI, att tro att den också kan driva appen åt dig. Det kan den inte, och glappet är verkligt:

Den berättar inte för dig när något gick sönder tyst. Loggar, övervakning, jourrotationer — de är fortfarande en separat angelägenhet. De flesta AI-appbyggare bevakar inte din produktionsapp så som en backend-ingenjör skulle.
Den vet inget om världen utanför din app. Om en betalleverantör fasar ut ett API vet AI:n inte det förrän du berättar för den. Prenumerera på dina leverantörers ändringsloggar. Läs din mejl.
Den kan inte fatta produktbeslut åt dig. Om en funktion ska läggas till, vilken avvägning som ska göras, vad dina användare egentligen vill ha — det är fortfarande du. AI:n är ett väldigt snabbt par händer; hjärnan är din.

Den realistiska bilden

Efter sex månader med en AI-byggd app landar de flesta vi pratar med någonstans här: de lägger kanske två till fyra timmar i månaden på ändringar, nästan allt konverserande. De stora ombyggena de brukade bäva inför — “jag vill lägga till en helt ny sektion” — känns som en bra eftermiddag. Det tråkiga — “datumformatet är fel på exporten” — känns som en bra prompt.

Det de inte har är det konstanta bakgrundsbruset från en traditionell kodbas: beroendeuppdateringar, ramverksmigreringar, säkerhetspatchar, byggkonfigurationer. Det bruset har absorberats in i plattformen. Du betalar för att plattformen ska hantera det, vilket är en mycket bättre affär än att betala en utvecklare för att hantera det.

Om du är på väg att bygga din första app är inlägget om vad din första AI-byggda app borde vara värt att läsa innan du börjar. Och om du redan är några veckor in och känner igen några av mönstren ovan, så är det normalt. Skriv ditt “vad den här appen är”-dokument den här helgen. Ditt framtida jag, om tre månader, som ber om en ny instrumentpanel, kommer vara väldigt glad att du gjorde det.