AI-nettsidebyggere lager sider raskt, men hva skjuler seg under panseret? Lær hvorfor arkitektur og databaser er avgjørende for bedriftens framtid.
en
no
frAI har endret måten vi lager nettsider og programvare på.
I dag kan du åpne en AI-basert nettsidebygger, beskrive hva du ønsker med vanlig språk, og se en applikasjon bli bygget foran øynene dine.
«Lag en nettside for bedriften min.»
«Legg til et kontaktskjema.»
«Legg til en blogg.»
«La brukere opprette konto.»
«Legg til betaling.»
«Gjør designet mer eksklusivt.»
Noen minutter senere har du noe som ser ut som et ekte produkt.
Og det er imponerende.
Men det er ett spørsmål mange bedriftseiere ikke stiller:
Hva har AI egentlig bygget bak skjermen?
For en nettside er mye mer enn det du ser i nettleseren.
Knappene, fargene, animasjonene, bildene og teksten er bare den synlige delen.
Bak alt dette finnes databaser, API-er, autentisering, forretningslogikk, serverkode, avhengigheter, infrastruktur, sikkerhetsregler, caching, bildelagring, integrasjoner og tusenvis av tekniske beslutninger som de fleste besøkende aldri vil se.
Og det er her forskjellen mellom AI-assistert utvikling og å lage nettsider med AI blir viktig.
La oss først avklare én ting.
Jeg er programvareutvikler, og jeg bruker AI.
Mye.
AI har blitt et av de mest nyttige verktøyene i utviklingsprosessen min.
Jeg bruker AI til å utforske ideer, undersøke problemer, skrive tester, analysere kode, refaktorere eksisterende kode, forstå systemer jeg ikke kjenner fra før og utvikle raskere.
AI gjør meg ikke til en dårligere utvikler.
Det gjør meg raskere.
Den viktige forskjellen er at jeg allerede forstår hva jeg ber AI om å bygge.
Jeg vet hva et databaseskjema er.
Jeg vet hvorfor to tabeller bør – eller ikke bør – være koblet sammen.
Jeg vet hva et API er.
Jeg vet hva som kan skje dersom autentisering implementeres feil.
Jeg vet hvorfor ett rammeverk kan være bedre egnet enn et annet for et bestemt prosjekt.
Jeg vet hva som kan skje når en avhengighet blir utdatert.
Og viktigst av alt:
Jeg kan se når koden AI har laget ikke er god nok.
Det siste punktet er mye viktigere enn mange tror.
Ordet «AI» kan få det til å høres ut som om alle disse verktøyene fungerer på samme måte.
Det gjør de ikke.
Det er nyttig å skille mellom minst tre nivåer.
Dette er intelligensen som ligger i kjernen av systemet.
Modeller som GPT, Claude og andre kan forstå instruksjoner, resonnere rundt kode og generere kode.
Men en AI-modell alene er ikke nettsiden din.
Du kan heller tenke på den som en ekstremt kraftig utvikler som sitter ved siden av deg og kan produsere kode når du ber om det.
Verktøy som brukes av utviklere fungerer på en annen måte.
De kan jobbe direkte i et eksisterende prosjekt.
De kan analysere filer, forstå prosjektstrukturen, endre komponenter, kjøre tester, finne feil og gjøre endringer samtidig som de beholder konteksten rundt den eksisterende koden.
Utvikleren har fortsatt ansvaret for arkitekturen.
AI hjelper utvikleren med å implementere den.
Så har vi plattformer som Lovable og lignende verktøy.
Disse er nærmere applikasjonsgeneratorer.
Du beskriver produktet.
Plattformen gjør beskrivelsen om til en applikasjon og genererer blant annet frontend, backend-integrasjoner, datastrukturer og andre deler som trengs.
Det er utrolig praktisk.
Men det skaper også en ny mulighet:
Du kan bygge programvare uten å egentlig forstå programvaren du bygger.
Og det er her det blir viktig for en bedrift.
Dette er sannsynligvis det sterkeste argumentet.
Og noen ganger er det helt riktig.
Nettsiden fungerer.
Forsiden laster.
Kontaktskjemaet sendes.
Bildene vises.
Innlogging fungerer.
Eieren kan publisere nettsiden.
Så hva er problemet?
Problemet er at at noe fungerer i dag og at det er et godt fundament for morgendagen, er to forskjellige ting.
Tenk på det som å kjøpe et hus bare fordi inngangsdøren åpner seg.
Det sier ingenting om kvaliteten på fundamentet.
For å vite det må du se under overflaten.
Programvare fungerer på samme måte.
La oss ta et helt vanlig eksempel.
Tenk deg at en personlig trener starter et lite treningsstudio.
I begynnelsen trenger han eller hun bare en nettside.
Behovene virker enkle:
Forside
Om oss
Tjenester
Kontaktskjema
Noen bilder
Kanskje en blogg
Treneren åpner en AI-basert nettsidebygger og lager nettsiden selv.
Resultatet ser veldig bra ut.
Så fortsetter utviklingen.
«Legg til et bookingsystem.»
AI legger til et bookingsystem.
«La kundene opprette en konto.»
Nå må systemet håndtere autentisering.
«La kundene se sine kommende timer.»
Nå må det opprettes relasjoner mellom kunder og bookinger.
«Lag et dashboard hvor jeg kan administrere timene.»
Nå må systemet håndtere forskjellige tilgangsnivåer.
«La kundene kjøpe et klippekort med ti treningstimer.»
Nå kommer betaling og transaksjoner inn i systemet.
«Trekk automatisk én time når kunden møter opp.»
Vi har nå forretningslogikk.
«Send en e-postpåminnelse 24 timer før hver time.»
Nå må systemet håndtere bakgrunnsprosesser og en e-posttjeneste.
«La kundene avbestille frem til 12 timer før timen.»
Nå må systemet håndheve forretningsregler.
«Legg til flere trenere og la kundene velge trener.»
Nye relasjoner må håndteres.
«La trenerne se sine egne timeplaner, men ikke andre treneres private kundeinformasjon.»
Autentisering og tilgangskontroll blir nå mer avansert.
«Legg til venteliste når timene er fulle.»
Enda mer forretningslogikk.
Og plutselig er ikke den opprinnelige nettsiden bare en nettside lenger.
Den har blitt en plattform for booking og kundehåndtering.
Og denne transformasjonen kan skje gradvis, én liten forespørsel om gangen.
Det er her ting blir interessante.
Når jeg jobber med en kunde, er noe av det første jeg ønsker å forstå ikke fargen på knappene.
Det er:
Hvordan fungerer virksomheten egentlig?
La oss ta et bookingsystem.
En kunde kan si:
«Jeg trenger at kundene mine kan bestille timer.»
Det høres enkelt ut.
Men hva betyr egentlig «bestille»?
Hvem kan bestille?
Må kunden opprette en konto?
Kan timen avbestilles?
Hvor lenge før timen kan den avbestilles?
Skal betalingen skje før eller etter timen?
Hva skjer hvis kunden ikke møter opp?
Kan to personer bestille samme tidspunkt?
Hva skjer hvis treneren ikke er tilgjengelig?
Kan en administrator endre en booking?
Kan en kunde ha flere klippekort?
Hvordan beregner systemet hvor mange timer kunden har igjen?
Hva skjer når et klippekort utløper?
Hvem kan se kundeinformasjonen?
Hva skjer dersom en betaling feiler?
Skal kunden få en e-post?
Skal treneren også få en e-post?
Hva skjer når timen er full?
Dette er ikke designspørsmål.
Dette er spørsmål om forretningslogikk.
Og denne forretningslogikken blir til slutt databastabeller, relasjoner, API-er, tilgangsregler, validering, bakgrunnsprosesser og applikasjonskode.
Det er den delen de fleste besøkende aldri ser.
Men det er den delen virksomheten faktisk er avhengig av.
Dette er viktig.
Programvare som er generert med AI blir ikke automatisk dårlig.
Det er fullt mulig å bygge en svært godt strukturert applikasjon ved hjelp av AI.
Problemet oppstår når arkitektur blir erstattet av en samtale.
Tenk deg at du hele tiden ber AI:
«Legg til dette.»
«Nå, endre dette.»
«Egentlig, gjør det på en annen måte.»
«Legg til et felt.»
«Flytt denne funksjonen.»
«Gjør denne brukeren til administrator.»
«Nå skal denne siden være offentlig.»
«Koble også til betaling.»
AI vil forsøke å tilfredsstille hver enkelt forespørsel.
Og det er akkurat det du ba den om å gjøre.
Men samtidig bygger systemet opp lag på lag med tekniske beslutninger.
Hvis ingen tar ansvar for arkitekturen underveis, kan du gradvis ende opp med:
duplisert kode
inkonsekvente datastrukturer
unødvendige avhengigheter
komponenter som er vanskelige å forstå
dårlig utformede databaserelasjoner
for mye logikk på klientsiden
mangelfull validering
inkonsekvent autentisering
API-er som er vanskelige å vedlikeholde
skjulte antakelser i koden
unødvendig mange tjenester
stadig mer komplisert deploy og drift
Og det verste?
Nettsiden kan fortsatt se perfekt ut.
Det er nettopp det som gjør problemet vanskelig å oppdage.
En annen ting mange bedriftseiere ikke er klar over, er at det ikke finnes én enkelt ting som heter «koden til nettsiden».
Det finnes forskjellige programmeringsspråk, rammeverk, runtime-miljøer, biblioteker og arkitekturer.
To nettsider kan se nesten identiske ut, samtidig som de er fullstendig forskjellige på innsiden.
Den ene kan bruke WordPress og PHP.
En annen kan bruke React og Next.js.
En tredje kan bruke et annet JavaScript-rammeverk.
En fjerde kan bruke en plattformbasert løsning.
En femte kan bruke en spesialtilpasset backend med en relasjonell database.
Alle kan vise en forside.
Men de har ikke nødvendigvis de samme:
ytelsesegenskapene
sikkerhetsmodellene
skaleringsmulighetene
vedlikeholdskostnadene
deploy-prosessene
databasearkitekturene
SEO-mulighetene
fleksibiliteten
hostingbehovene
utviklingskostnadene
fremtidige utviklingskostnadene
Programmeringsspråket alene avgjør heller ikke om én løsning er bedre enn en annen.
Arkitekturen og hvordan teknologien brukes, er avgjørende.
En dårlig utformet applikasjon i et moderne språk kan være langt dårligere enn en godt utformet applikasjon i et eldre språk.
Det riktige spørsmålet er derfor ikke:
«Hvilket språk er mest moderne?»
Men:
«Hvilken teknologi og arkitektur passer denne virksomheten?»
Dette er kanskje det bedrifter burde tenke mer på.
Ikke spør bare:
«Kan jeg lansere denne nettsiden?»
Spør:
«Hva skjer hvis virksomheten min lykkes?»
Hva skjer hvis du plutselig får ti ganger så mange besøkende?
Hvis du ønsker å lage en app?
Hvis du trenger kundekontoer?
Hvis du vil lage en mobilapplikasjon?
Hvis du vil bygge en markedsplass?
Hvis du ønsker å nå kunder internasjonalt?
Hvis du trenger flere språk?
Hvis du vil koble til et CRM-system?
Hvis du trenger ditt eget dashboard?
Hvis du trenger et API?
Hvis andre selskaper skal integrere med systemet ditt?
Hvis du vil bytte CMS?
Hvis hostingleverandøren blir for dyr?
Hvis databasen må migreres?
Hvis du ansetter et annet utviklingsteam om fem år?
Dette kan høres ut som fremtidige problemer.
Det er de ikke.
Dette er arkitekturspørsmål som det er verdt å tenke på allerede i dag.
Du trenger ikke bygge alle disse funksjonene i dag.
Men du bør unngå å ta beslutninger i dag som gjør morgendagens utvikling unødvendig vanskelig.
Jeg forklarer ofte dette til kunder med en analogi fra arkitektur.
Frontend er det de besøkende ser.
Det er veggene, vinduene, dørene, belysningen og interiøret.
Backend er mer som fundamentet, rørene, det elektriske anlegget og selve konstruksjonen.
Du kan relativt enkelt male en vegg på nytt.
Det er noe helt annet å endre fundamentet.
Det samme gjelder programvare.
Det er enkelt å endre en knapp.
Det er noe helt annet å endre hele databasearkitekturen etter at tusenvis av brukere og datapunkter er avhengige av den.
Det er enkelt å endre en farge.
Det er mye vanskeligere å endre autentisering og tilgangskontroll i en hel applikasjon.
Det er enkelt å endre en overskrift.
Det er mye vanskeligere å endre innholdsarkitekturen på en stor, flerspråklig nettside.
Derfor ønsker jeg vanligvis å forstå backend før jeg bruker for mye tid på å perfeksjonere frontend.
Vi må vite hva vi bygger før vi bestemmer hvordan det skal se ut.
Noen ganger, absolutt.
Jeg mener ikke at bedrifter bør slutte å bruke AI-baserte nettsidebyggere.
Tvert imot.
Jeg synes de er svært nyttige.
Hvis du er gründer og ikke er teknisk, kan en AI-basert nettsidebygger være en fantastisk måte å gjøre en idé konkret på.
Du kan lage prototyper.
Du kan teste en idé.
Du kan vise den til investorer.
Du kan kommunisere visjonen din til en utvikler.
Du kan oppdage hva du faktisk trenger.
Du kan til og med bygge et ekte produkt med slike verktøy.
Spørsmålet bør derfor ikke være:
«Er dette AI-verktøyet dårlig?»
Det bedre spørsmålet er:
«Er måten jeg bruker det på riktig for virksomheten min?»
For en enkel landingsside?
Sannsynligvis helt fint.
For en midlertidig MVP?
Potensielt utmerket.
For å validere en idé?
Absolutt.
For et lite internt verktøy?
Det kan være svært nyttig.
For en forretningskritisk plattform som skal utvikles og leve i ti år?
Da bør du tenke mye grundigere.
Ikke fordi AI ikke kan bygge den.
Men fordi noen fortsatt må designe arkitekturen.
Det endrer rollen deres.
Det er en viktig forskjell.
Fremtiden er ikke nødvendigvis:
Mennesker skriver hver eneste linje kode manuelt.
Den ser mer ut som:
Mennesker designer systemet, og AI hjelper med å bygge det.
En utvikler kan bruke mindre tid på å skrive repetitiv kode manuelt og mer tid på å tenke på arkitektur, data, sikkerhet, forretningslogikk, testing, ytelse og produktbeslutninger.
Og det er bra.
Jeg vil ikke bruke tre timer på å skrive repetitiv kode hvis AI kan gjøre det på tre minutter.
Jeg vil heller bruke de tre timene på å forstå virksomheten.
Det er der den virkelige verdien ligger.
Det er slik jeg personlig ser på AI-assistert programvareutvikling.
Utvikleren bidrar med:
Forretningsforståelse
Hvilket problem prøver vi egentlig å løse?
Arkitektur
Hvordan bør systemet bygges opp?
Datamodellering
Hvilke data finnes, og hvordan henger de sammen?
Teknologivalg
Hvilke verktøy og rammeverk passer faktisk til prosjektet?
Sikkerhet
Hvem skal ha tilgang til hva?
Kvalitet
Fungerer systemet faktisk som forventet?
Langsiktig tenkning
Hvordan skal systemet kunne utvikles videre?
AI kan hjelpe med:
Implementasjon
Skrive koden.
Utforskning
Teste forskjellige løsninger.
Testing
Generere og forbedre tester.
Feilsøking
Finne problemer.
Refaktorering
Forbedre eksisterende kode.
Dokumentasjon
Forklare systemer og tekniske beslutninger.
Hastighet
Komme mye raskere fra idé til fungerende programvare.
Denne kombinasjonen er langt kraftigere enn noen av delene alene.
En av de største feilene jeg ser, er at bedrifter velger teknologi kun basert på dagens pris.
En bedrift kan spare penger ved å velge den raskeste og billigste måten å lansere nettsiden på.
Og noen ganger er det helt riktig valg.
Men noen ganger er den billigste nettsiden bare den billigste første versjonen.
Hvis du senere må bygge alt på nytt, migrere innholdet, redesigne databasen, bytte autentiseringssystem, bytte hosting, bygge integrasjoner på nytt og skrive om forretningslogikken, kan den opprinnelige besparelsen til slutt bli svært dyr.
Det betyr ikke at alle små bedrifter trenger en kompleks, skreddersydd plattform.
Langt ifra.
Noen ganger er WordPress akkurat riktig løsning.
Noen ganger er en AI-basert nettsidebygger akkurat riktig løsning.
Noen ganger er en statisk nettside alt du trenger.
Og noen ganger er en spesialutviklet applikasjon den riktige investeringen.
Målet er ikke å bruke den dyreste teknologien.
Målet er å bruke riktig arkitektur for virksomheten din og fremtiden din.
Svaret mitt er:
Ja.
Men ikke forveksle det å bruke AI med å la AI ta alle tekniske beslutninger for deg.
Bruk AI til å utforske.
Bruk AI til å lage prototyper.
Bruk AI til å jobbe raskere.
Bruk AI til å skrive kode.
Bruk AI til å teste ideer.
Bruk AI til å forbedre utviklingsprosessen.
Men hvis nettsiden blir en viktig del av virksomheten din, bør du forstå hva som finnes under overflaten.
Vit hvor dataene dine ligger.
Vit hvem som eier koden.
Vit hvilken database du bruker.
Vit hvilke tjenester applikasjonen din er avhengig av.
Vit hvordan autentiseringen fungerer.
Vit hva som skjer hvis du forlater plattformen.
Vit hvordan nettsiden kan utvikles videre.
Vit om arkitekturen faktisk kan støtte virksomheten du ønsker å bygge.
For den farligste setningen innen programvareutvikling er ikke:
«Jeg vet ikke hvordan dette fungerer.»
Den er:
«Det fungerer, så det må være riktig.»
Kundene dine bryr seg ikke om nettsiden ble laget av en utvikler, AI, WordPress, Next.js eller en AI-basert nettsidebygger.
De vil bare at den skal fungere.
Virksomheten din bør derimot spørre hva som skjer etter at den fungerer.
Det er der den virkelige programvaren begynner.
Hos Natasun ser vi ikke på AI som fienden til programvareutvikling.
Vi ser på det som enda et verktøy i verktøykassen.
Vår tilnærming er å kombinere moderne utviklingsmetoder med AI-assistert utvikling for å bygge programvare som ikke bare ser bra ut på overflaten, men som også er solid bygget under.
Målet er ikke bare å lansere noe.
Målet er å bygge noe som kan fortsette å utvikle seg.
For den første nettsiden din trenger kanskje bare en forside.
Men virksomheten din kan en dag trenge en komplett plattform.
Og ideelt sett bør ikke de første tekniske beslutningene dine hindre deg i å komme dit.
