Vad som faktiskt finns inuti en AI-byggd app: en rundtur för icke-utvecklare

Du skrev en beskrivning, tryckte på kör, och tjugo minuter senare hade du en fungerande app. Toppen. Men nu har du klickat på “visa filer” och stirrar på ett mappträd som ser ut att vara skrivet på ett annat språk. Vad är package.json? Varför finns det fyrtio saker i node_modules? Vad betyder “schema” och varför har du ett?

Det här inlägget är en guidad rundtur. Inte en handledning – en rundtur. Efter att ha läst det kommer du inte att veta hur man skriver någon av de här filerna själv, men nästa gång något ser konstigt ut vet du vilket hörn av appen du ska peka på.

Jag ska använda tre genomgående exempel hela vägen, så att de abstrakta delarna har något konkret att hänga upp sig på:

• Maya, en marknadschef, som byggde en värvningstoppista för sitt team.
• Jordan, en yogalärare, som byggde en sida för klassbokning.
• Sam, som driver ett bageri, som byggde en “förbeställ morgondagens croissanter”-sida.

Alla tre använde en AI-appbyggare. Alla tre apparna ser helt olika ut för en kund. Under huven är de förvånansvärt likartat formade.

Frontend: det din kund faktiskt ser

Frontend är allt som laddas i någons webbläsare. Knappar, layouter, typsnitt, animationer, sättet ett formulär rensar sig själv efter att du skickat in det. Om du kan se det är det frontend.

För Maya är frontend en topplista med rang, namn och antal värvningar. För Jordan är det en kalender med klasser och en “boka”-knapp. För Sam är det en lista med bakverk med små plus-och-minus-knappar bredvid var och en.

Inuti projektet bor frontend oftast i en mapp som heter något i stil med app/, pages/ eller src/. Du ser filer som slutar på .tsx eller .jsx. Var och en är ungefär “en skärm” eller “en del av en skärm”. Topplisteraden är en fil. Sidhuvudet är en annan fil. Sidan som binder ihop allt är en tredje.

När du ber AI-byggaren att “göra knapparna rundare” eller “flytta topplistan till höger” är det den här delen som ändras.

Backend: delen som tänker

Backend är delen ingen ser, men alla är beroende av. Det är koden som körs någon annanstans – på en server, inte i kundens webbläsare – när något behöver hända som kundens webbläsare inte ska litas på att göra ensam.

Varför kan inte webbläsaren göra allt? För att webbläsaren är kundens maskin, och du kan inte lita på den. Om Mayas topplista uppdaterade värvningsräkningar enbart i webbläsaren kunde vem som helst högerklicka och lägga till 9 000 värvningar till sig själv. Så backend är där reglerna bor: “den här personen får göra det här, men inte det där”, “spara faktiskt det här i databasen”, “skicka det här mejlet”.

Backend bor oftast i en mapp som heter api/, server/ eller app/api/. Filerna där är oftast korta. Var och en hanterar en specifik begäran: “skapa en bokning”, “lista dagens croissanter”, “lägg till en värvning”.

När något fungerar i din app men resultatet inte fastnar – du klickar skicka, du ser en bekräftelse, men imorgon är datan borta – är det nästan alltid i backend buggen finns.

Databasen: din apps minne

Föreställ dig din apps minne som en rad arkivskåp. Varje skåp har en etikett på framsidan. Ett säger “användare”. Ett säger “bokningar”. Ett säger “croissant_bestallningar”. Inuti varje skåp är varje låda en rad. Varje låda har samma uppsättning fack: ett namn, en e-post, ett skapat-datum, en status.

Den strukturen – “vilka skåp som finns, vilka fack varje rad har” – kallas ett schema. Det är den viktigaste filen i projektet, även om det också förmodligen är den tråkigast utseende. Hitta en fil som heter schema.ts, schema.prisma eller något inuti en mapp som heter db/ eller migrations/. Öppna den. Du ser en lista som speglar vad din app faktiskt minns om världen.

Jordans schema har en classes-tabell, en bookings-tabell och en users-tabell. Sams har products, orders och order_items. Mayas har members och referrals. Schemats form är produktens form, vilket är varför det är svårare att ändra det senare än att ändra hur knapparna ser ut.

Ett användbart trick: om du kan beskriva vad din app minns, med vanliga ord, kan du oftast beskriva schemat. “Jag minns varje kunds namn och e-post. För varje kund minns jag de beställningar de lade. För varje beställning minns jag vilka bakverk och hur många av varje.” Den meningen är, nästan ord för ord, schemat.

Auth: dörrvakten

“Auth” är två ord hopslagna: authentication (vem är du?) och authorization (vad får du göra?). Båda hanteras oftast av en liten uppsättning filer i en mapp som heter auth/, eller av en tjänst vars namn du kanske känner igen: Clerk, Auth0, Supabase Auth, NextAuth.

De två frågorna är olika. Authentication besvarar: “är det här verkligen Maya?” – oftast med ett lösenord, en Google-inloggning eller en magisk länk mejlad till henne. Authorization besvarar: “får Maya radera andras värvningar?” – och det ärliga svaret för de flesta AI-byggda appar deras första vecka är “vi glömde att kontrollera”.

Det här är den del som oftast är tyst trasig. Inloggningsskärmen fungerar, så det känns säkert. Men backend kontrollerar inte alltid att den inloggade personen är samma person vars data de försöker läsa. Om din app har något begrepp om “min data kontra din data”, fråga AI-byggaren uttryckligen: “Se till att användare bara kan se och redigera sin egen data.” Du kommer att bli förvånad över hur ofta den enda meningen avslöjar en saknad kontroll.

Integrationer: sakerna du inte byggde men ändå använder

Det här är där de flesta icke-utvecklare underskattar vad som faktiskt händer. Det som skickar Sams “dina croissanter är klara”-mejl är inte kod – det är ett konto hos SendGrid eller Resend. Det som behandlar Jordans klassbetalning är inte kod – det är Stripe. Det som hostar fotona på Mayas topplista är inte kod – det är en lagringstjänst som S3 eller Cloudinary.

Varje integration dyker upp på två ställen. Det finns en liten kodbit i backend som säger “hej Stripe, debitera det här kortet”. Och det finns en nyckel – en lång hemlig sträng – lagrad någonstans säkert (oftast en fil som heter .env som ingen någonsin ska checka in) som bevisar för Stripe att begäran kom från Sams bageri och inte en främling.

Om du någonsin undrar varför din app plötsligt slutar skicka mejl eller slutar acceptera betalningar är orsaken nästan alltid en av: en utgången nyckel, en träffad användningsgräns eller en ändring i integrationens policyer. Koden gick inte sönder. Handskakningen gjorde det.

Deployen: hur det når internet

Den sista biten är delen som förvandlar mappen på din disk till något din kund kan besöka på en URL. Det betyder oftast tre små saker som arbetar tillsammans:

• Hosten: en tjänst som Vercel, Netlify, Fly eller Render som kör din backend och serverar din frontend.
• Domänen: ett namn som mayas-leaderboard.com som pekar på din host.
• Bygget: receptet som tar dina röriga källfiler och förvandlar dem till den slankare, snabbare version som faktiskt körs.

När något fungerar lokalt men går sönder i produktion ligger problemet oftast här. En nyckel som är satt på din laptop men inte på hosten. Ett bibliotek som är installerat i utveckling men inte i produktion. En databas som finns i din webbläsare men inte på den live-sajten.

Femminutersvanan som betalar sig själv

Du behöver inte läsa varje fil i ditt projekt. Du behöver inte veta vad de flesta av dem gör. Men du borde, en gång i veckan, göra en femminuters genomgång där du öppnar var och en av mapparna ovan och frågar AI-byggaren, med vanliga ord, vad som ändrades.

Maya gör det här varje fredag eftermiddag. Hon skriver: “Vad ändrades i schemat den här veckan, och varför?” Och: “Finns det några nya integrationer i den här appen som jag inte bad om?” Svaren är nästan alltid lugnande. De få gånger de inte är det fångar hon problem medan de fortfarande är små.

Det är hela poängen med att förstå delarna. Inte att bli en utvecklare. Bara att kunna ställa bättre frågor.

Vart du går härnäst

Om den här rundturen hjälpte är två uppföljare värda din tid. “Ser bra ut”-buggen täcker vad du ska göra när en av de här delarna är tyst trasig, och demo-redo kontra produktionsredo täcker hur du avgör när din app gått från det första stadiet till det andra. Samma karta, olika användning av den.