Du beskriver appen. AI skriver koden. Vem lagar den?
Ett bokningssystem visar skillnaden mellan en snygg prototyp och en tjänst som går att äga.
Med Lovable eller Cursor kan vägen från idé till klickbar app bli kort. Men när två kunder bokar samma tid, någon försöker läsa grannens uppgifter eller verksamheten ändrar reglerna börjar det verkliga arbetet. Här är en praktisk bygg- och granskningsplan för dig som inte är utvecklare.
Av Johan LindqvistSkribent · Verktyg och praktikEn kund väljer tisdag klockan tio, skriver sitt namn och trycker på Boka. En bekräftelse visas. För verksamhetsägaren ser saken avgjord ut: bokningssystemet fungerar.
Sedan öppnar en annan kund samma tid i en annan webbläsare. Båda försöker boka. Vem får platsen? Och kan den ena kunden läsa den andras bokning genom att ändra adressen till sidan?
Det är här AI-driven programmering behöver granskas. Inte bara i hur snabbt den ritar kalendern, utan i vad som händer när verkligheten slutar följa demonstrationen.
Vi följer ett litet bokningssystem för en verkstad: en bokningsbar resurs, halvtimmespass, kundinloggning och en administratör. Genomgången är ett reproducerbart bygg- och testupplägg, inte ett redovisat produkttest. Inga verktyg har körts för artikeln, och inga uppmätta resultat tillskrivs dem. Produktfunktioner och säkerhetsråd stöds av dokumentationen i källistan.
1. Beställ reglerna, inte bara skärmen
Lovable representerar ett arbetssätt där du beskriver en webbapp i en konversation och låter verktyget skapa och ändra den. Cursor är en AI-kodredigerare som arbetar med projektets filer och, med agentfunktioner, kan utföra utvecklingsuppgifter. Båda kan hjälpa till att skriva kod, men deras utgångspunkter skiljer sig.
Lovable: En naturlig start för den som vill formulera produkten och snabbt arbeta med ett gränssnitt. Dokumentationen beskriver bland annat integration med Supabase för databas och autentisering samt synkronisering med GitHub.
Cursor: Närmare den traditionella utvecklingsmiljön. Det kan passa när ett kodprojekt redan finns eller när en utvecklare ska ta över. För en nybörjare blir filer, terminalkommandon och felmeddelanden samtidigt fler saker att förstå.
Jämförelsen är inte ett uppmätt hastighetstest. Den handlar om var ansvaret blir synligt: i produktbeskrivningen eller inne i kodprojektet.
Börja inte med ”bygg ett snyggt bokningssystem”. Skriv ett litet kontrakt:
Bygg en prototyp för en verkstad med en bokningsbar resurs. Varje pass är 30 minuter. Kunden måste logga in och får bara läsa och avboka sina egna bokningar. Administratören får hantera samtliga. Två aktiva bokningar får aldrig finnas för samma resurs och starttid. Använd bara syntetiska personuppgifter. Föreslå datamodell och åtkomstregler innan du skriver kod.
Be sedan modellen lista det som fortfarande är oklart. Vilken tidszon gäller? Hur nära start får kunden avboka? Kan administratören boka åt någon annan? Är e-postbekräftelsen obligatorisk?
Det låter långsammare än att börja med färger och knappar. Men varje obesvarad fråga blir annars ett beslut som modellen riskerar att fatta åt dig.
Spara reglerna i projektet, inte bara i chatten. Lägg till konkreta exempel: ”Anna får inte läsa Bos bokning” och ”ett avbokat pass ska kunna bokas igen”. Då får både AI:n och en framtida utvecklare något tydligt att kontrollera mot.
2. Bygg den minsta kedjan som faktiskt fungerar
Första etappen är en enda sammanhängande resa: logga in, visa lediga tider, boka, se bokningen och avboka. Vänta med betalningar, SMS, rabattkoder och återkommande tider. Varje integration tillför egna felmöjligheter och kostnader.
Be AI:n skilja på gränssnitt, serverlogik och datalagring. Gränssnittet visar tiderna. Serverlogiken eller databasen måste avgöra om bokningen är tillåten. Databasen bevarar resultatet. En grön bock i webbläsaren är inte bevis för att informationen faktiskt sparats.
Om bygget använder Supabase behöver du förstå två skilda funktioner. Autentisering fastställer vem användaren är. Behörighetsregler avgör vad den användaren får göra. Inloggning innebär inte automatiskt att varje kunds data är skyddade från andra kunder.
För prototypen räcker tabeller för resurser, bokningar och de användaruppgifter som verkligen behövs. Undvik att samla telefonnummer, adress och fritext ”för framtiden”. Testa med påhittade kunder, inte en exporterad kundlista.
Kontrollera därefter hela kedjan:
- Boka en tid, ladda om sidan och kontrollera att bokningen finns kvar.
- Logga ut och in igen. Samma bokning ska visas.
- Öppna ett separat kundkonto. Det ska inte se den första kundens uppgifter.
- Avboka och kontrollera att tiden blir tillgänglig igen.
Dokumentera förväntat och faktiskt resultat. En skärmbild visar utseendet; ett testprotokoll visar beteendet.
Koppla också projektet till versionshantering, exempelvis GitHub där verktyget stöder det. Spara en känd fungerande version före större ändringar. Det ger möjlighet att jämföra kod och backa förändringar, men är inte samma sak som säkerhetskopiering av databasen. Kundernas bokningar finns inte nödvändigtvis i kodarkivet.
Be slutligen AI:n skriva en kort startguide: hur projektet körs, vilka externa tjänster som krävs och var inställningarna finns. Kan instruktionen inte användas av någon annan är överlämningen ännu inte klar.
3. Försök komma åt det du inte får se
Demonstrationen visar vanligen vad en användare får göra. Säkerhetsgranskningen börjar med motsatsen.
Skapa tre testidentiteter: kund Anna, kund Bo och administratören. Använd separata webbläsarprofiler så att inloggningarna inte blandas ihop. Testa dessutom helt utloggat läge.
Anna ska kunna läsa och avboka sin bokning. Bo ska inte kunna göra något av detta med Annas bokning, även om han känner till dess identifierare. En utloggad besökare ska inte kunna hämta kundlistan. En vanlig kund ska inte kunna tilldela sig administratörsrollen.
Det räcker inte att administrationsknappen är dold. Webbläsaren skickar anrop till bakomliggande tjänster, och en angripare kan försöka skicka motsvarande anrop utan att använda knappen. OWASP beskriver bristande kontroll av åtkomst till enskilda objekt som en central API-risk.
Be därför AI:n:
Visa var behörigheten kontrolleras för varje läsning och ändring av bokningar. Skriv tester som försöker läsa, avboka och ändra en annan användares bokning. Ett dolt gränssnittselement räknas inte som åtkomstkontroll.
Med Supabase kan Row Level Security, RLS, användas för regler på databasrader. Men reglerna måste vara korrekt konfigurerade. En ny tabell eller en alltför bred regel kan skapa luckor. Supabases privilegierade service role-nyckel kan kringgå RLS och får inte exponeras i klientkoden.
Be om en förteckning över projektets nycklar: vilka som är avsedda för klienten, vilka som är hemliga och var de lagras. Låt en kunnig person kontrollera svaret. Modellens förklaring är inte ett oberoende säkerhetsbevis.
Nästa prov är dubbelbokningen. Öppna samma lediga pass i två sessioner och försök boka nästan samtidigt. Upprepa, gärna med ett automatiserat test. Att först kontrollera ledighet och sedan skriva bokningen kan ge en kapplöpning: båda anropen hinner se tiden som ledig.
För vår förenklade modell behöver databasen upprätthålla att endast en aktiv bokning kan finnas per resurs och starttid, exempelvis genom ett lämpligt unikt index. Den förlorande kunden ska få ett begripligt besked, inte en falsk bekräftelse. Ett manuellt försök som lyckas bevisar dock inte att konstruktionen är säker under samtidighet.
4. Personuppgifter och drift följer med på köpet
När riktiga kunder börjar boka är appen inte längre bara ett kodexperiment. Namn, e-postadresser och bokningshistorik är personuppgifter när de kan knytas till en person.
GDPR kräver bland annat uppgiftsminimering, lagringsbegränsning och lämplig säkerhet. För verkstaden betyder det praktiska beslut: vilka uppgifter behövs, varför behandlas de och när ska de raderas? Rättslig grund måste bedömas för den faktiska behandlingen; samtycke är inte ett universalsvar.
Kartlägg hela flödet. Uppgifter kan hamna i databasen, e-posttjänsten, felloggar, säkerhetskopior och supportärenden. Skicka inte riktiga kunduppgifter till en kodassistent för att förklara ett fel. Skapa ett syntetiskt exempel med samma tekniska struktur.
Kontrollera leverantörernas personuppgiftsbiträdesavtal där sådana behövs, underbiträden och eventuella överföringar utanför EU/EES. En vald europeisk databasregion besvarar inte ensam alla frågor om behandling och åtkomst.
Gör sedan driftkostnaden begriplig utan att lita på en prislapp från en demonstration. Prisplaner och användningsgränser förändras, och utvecklingsverktyget är bara en del av kalkylen.
Byggkostnad: Abonnemang eller användningskrediter för AI-verktyget samt tid för instruktioner, felsökning och granskning.
Driftkostnad: Webbhosting, databas, autentisering, lagring, trafik, domän och e-post. Vilka poster som debiteras separat beror på tjänster och plan.
Förvaltningskostnad: Övervakning, säkerhetsuppdateringar, support, återställningsövningar och hjälp när något slutar fungera.
Räkna på tre scenarier, exempelvis 100, 1 000 och 10 000 bokningar per månad. Det är kalkylexempel, inte kapacitetslöften. En bokning kan ge flera databasoperationer och meddelanden; översätt användningen till leverantörernas faktiska prismått. Sätt budgetvarningar där det går och kontrollera om de bara meddelar eller faktiskt stoppar förbrukning.
Simulera också att e-posttjänsten inte svarar. Ska bokningen ändå gälla? Vanligen behöver bokning och bekräftelse behandlas som skilda tillstånd, så att kunden inte skapar en dubblett genom att försöka igen.
Utse en mottagare för driftlarm. En logg som ingen läser är ingen beredskap.
5. Ändra kravet som prototypen byggdes på
Nu kommer verkstadsägarens till synes lilla önskemål: ”Vissa jobb tar en timme. Och nästa månad får vi en andra arbetsplats.”
Det är ett bättre underhållsprov än att byta knappfärg. Grundmodellen med fasta halvtimmespass påverkas. En bokning 10.00–11.00 får inte krocka med 10.30–11.00 på samma resurs, men kan vara tillåten på en annan.
Den tidigare spärren mot identisk starttid räcker inte för att hindra överlappande intervall. Systemet behöver antingen hantera intervallkonflikter korrekt eller dela upp bokningen i låsbara tidsblock med sammanhållen bokning. Här bör en utvecklare bedöma konstruktionen.
Ge inte bara instruktionen ”lägg till olika längder”. Be först om en förändringsplan:
- Vilka databasfält, regler och tester påverkas?
- Hur ska befintliga bokningar tolkas och flyttas?
- Vilka delar kan ändras utan driftstopp?
- Hur återställs tjänsten om uppdateringen misslyckas?
Flytten av befintliga data kallas migrering. Den ska provas med testdata som representerar gamla bokningar, inte improviseras i den skarpa databasen. Att återställa gammal programkod återställer inte automatiskt en ändrad databas.
Kör därefter om tidigare tester. Anna får fortfarande inte läsa Bos bokningar. Avbokningar måste fortfarande frigöra rätt kapacitet. Två samtidiga bokningsförsök får inte smita igenom. Det är regressionstestning: att kontrollera att en förbättring inte förstör något som redan fungerade.
AI:n kan hjälpa till att skriva testerna, men låt inte samma genererade antagande bli både implementation och enda facit. Kravexemplen från början behövs fortfarande som oberoende måttstock.
6. Bestäm vem som äger nästa fel
Den rimliga frågan är inte om en icke-utvecklare kan skapa appen. Det går att komma långt med instruktioner, återkoppling och avgränsade krav. Frågan är vilket ansvar personen kan bära efter publiceringen.
Fortsätt själv med prototypen när den använder syntetiska data, saknar kritiska integrationer och kan kastas bort utan att någon drabbas. Använd den för att pröva arbetsflödet med personalen.
Ta in en utvecklare före skarp drift när riktiga personuppgifter, flera behörighetsnivåer eller verksamhetskritiska bokningar tillkommer. Uppdraget bör omfatta datamodell, åtkomstregler, samtidighet, hemligheter, driftsättning och återställning — inte bara en snabb blick på gränssnittet.
Sök specialistkompetens vid exempelvis känsliga personuppgifter eller särskilda regelkrav. En allmän kodgranskning ersätter inte säkerhets- eller dataskyddskompetens.
Kräv ett litet överlämningspaket: kodarkiv, systemöversikt, testinstruktioner, versionshistorik, leverantörslista, kostnadsöversikt och en provad återställningsrutin. Verksamheten ska kontrollera domänen och relevanta tjänstekonton. Hemligheter ska överlämnas säkert, inte skrivas in i dokumentationen.
Avsluta med en enkel övning: en annan person ska kunna starta projektet, hitta ett rapporterat fel och beskriva hur en rättning når produktion. Om allt kräver tillgång till grundarens chattminne äger verksamheten ännu inte ett underhållbart system.
AI flyttar tröskeln för att bygga. Den avskaffar inte ansvaret för det byggda. Den fungerande bokningsknappen är början — först när någon kan förklara, kontrollera och laga det bakom knappen har prototypen blivit en tjänst.
Källor
- Lovable, Lovable documentation (Löpande dokumentation)
- Cursor, Cursor Docs (Löpande dokumentation)
- Supabase, Row Level Security (Löpande dokumentation)
- OWASP, API1:2023 Broken Object Level Authorization (2023)
- Europaparlamentet och Europeiska unionens råd, Europaparlamentets och rådets förordning (EU) 2016/679 (2016)
- PostgreSQL Global Development Group, Constraints (Löpande dokumentation)
Ställ frågor om "Du beskriver appen. AI skriver koden. Vem lagar den?". Svaren bygger på tidningens egna artiklar.
