AI gjør oss raskere. Det er ikke problemet.

Vi bygger dataplattformer og pipelines med AI som fast del av arbeidshverdagen. Her er hva vi gjør i praksis, hva som fungerer — og hva som kan gå galt.

AI har blitt en fast del av arbeidshverdagen vår i Glitni. Det gjør oss raskere på mye av det vi uansett måtte gjøre. Og det gjør det tydeligere hva som krever faglig skjønn.

Problemet med AI i dataarbeid - som data engineering og dataplattformutvikling - er ikke farten. Det er at farten gjør det billigere å overse hva som er galt.

En kort begrepsavklaring: “AI” dekker i denne artikkelen to ganske forskjellige ting. Det ene er klassisk maskinlæring — egenutviklede modeller som predikerer, klassifiserer eller segmenterer basert på data. Det har vi jobbet med lenge, og det er en etablert del av dataplattformarbeidet. Det andre er generativ AI — språkmodeller som skriver kode, genererer tekst og resonnerer rundt problemer. De siste par årene har “AI” i praksis blitt synonymt med det siste. Det er forståelig, men upresis. Vi bruker begge, og de fyller ganske ulike roller.

Det er lett å gjøre dette til en verktøydiskusjon: “hvilken modell”, “hvilken plugin”, “hvilken chat”. Men for oss er det mer interessant å snakke om hva AI gjør med selve faget. Når en maskin kan skrive mer av koden, flytter verdien seg bort fra det å kunne en bestemt konfigurasjon utenat — og over mot å forstå hva data betyr, hvilke avveiinger som er riktige, og hvordan man verifiserer at det som ser riktig ut er riktig.

Sikkerhet er alltid startpunktet

Det mest praktiske (og kjedeligste) er også det viktigste: vi bruker kun AI-verktøy som er godkjent i kundens regime. Har kunden ikke policy eller egnede verktøy på plass, tar vi det som et eget spor tidlig og får det avklart. Det er ofte ett av de første temaene vi tar opp i oppstart.

Måten vi jobber på gjør at dette sjelden er et praktisk problem i selve kodearbeidet: AI-assistenten kjører direkte mot kodebasen i Git, integrert i VS Code eller tilsvarende utviklingsmiljø — i den konfigurasjonen kunden har godkjent. Det betyr at AI-assistenten jobber mot koden lokalt i kundens miljø. Data forlater ikke miljøet. Det er en annen og tryggere arkitektur enn å lime inn utdrag i en ekstern chat-app.

Men her er en nyanse som er verdt å løfte: “kundens regime styrer” er ikke alltid like enkelt i praksis. En konsulent som kobler seg på et kundeoppdrag har gjerne sine egne organisasjonsinnstillinger for AI-verktøy — satt sentralt hos konsulentens arbeidsgiver, på tvers av alle oppdrag. Disse trenger ikke å være i takt med kundens policy. Et konkret eksempel: kunden har ikke tatt stilling til MCP, men konsulenten har det aktivert via egne organisasjonsinnstillinger. Her hjelper det ikke å ha god intern policy — det er et sprik som må håndteres eksplisitt.

Vår tilnærming er enkel: kan vi noe som ikke er avklart, gjør vi det ikke. At noe er teknisk mulig, er ikke det samme som at det er innenfor. Der vi opplever at kundens policy ikke holder tritt med den tekniske utviklingen, løfter vi det som et tema noen må eie og avklare — heller enn å navigere kreativt rundt det.

Der vi er ekstra varsomme er i resonnering og problemløsing utenfor kodebasen — for eksempel når vi diskuterer et dataavvik eller analyserer et feilmønster i et dialogverktøy. Her bruker vi syntetiske eksempler eller anonymiserte utdrag fremfor produksjonsdata. Og uansett kontekst gjelder det samme: AI-output behandles som utkast. Alt går gjennom PR-review, tester og validering før noe lever sitt eget liv i produksjon.

Eksempel: Prompts vi bruker i kodearbeid er skrevet som om de kan ligge i en PR: hva er konteksten, hva prøver vi å løse, hva er antakelsene, og hva er definisjonen på “riktig”. Det gir bedre treff og gjør det lettere å forklare valget til neste person som leser koden.

Tre måter AI lyver for deg i data engineering

Før vi går inn på hva AI er god på, er det nyttig å kjenne til hva den konsekvent gjør feil. Datafaget er særlig utsatt for noen gjengangere — og å kjenne dem gjør praksiseksemplene under mer meningsfulle.

Feil grain er den vanligste: AI foreslår en modell på feil detaljeringsnivå — for høy aggregering eller for detaljert — fordi den ikke kjenner beslutningskonteksten. Det ser riktig ut til du sjekker det mot noe du vet svaret på.

Feil join-nøkkel er den farligste: modellen ser plausibel ut, tallene er i riktig størrelsesorden, men de er gale fordi en join dupliserer rader eller dropper noen. Tester for unikhet og sum-kontroller fanger dette, men bare hvis du husker å sette dem opp.

For optimistiske antakelser om datakvalitet er den mest systematiske: AI antar at data er fullstendige, konsistente og unike med mindre du eksplisitt forteller den noe annet. I produksjonsdata er dette sjelden sant.

Disse tre er grunnen til at verifisering og tester ikke er “ekstraarbeid” — det er det som gjør at tempoet ikke blir dyrt i etterkant.

Hvorfor AI treffer data engineering annerledes enn andre fag

Det som tok en halv dag å skrive for to år siden, tar nå minutter. En dbt-modell med testpakke, en pipeline-konfig, en SQL-spørring med edge cases — AI leverer et godt nok førsteutkast raskt. Det er en reell endring i arbeidsdagen.

Men det skjer i et fag som allerede har blitt mer standardisert og verktøydrevet de siste årene. Vi har bygget mønstre, rammeverk og plattformer som gjør det enklere å levere. Det betyr at en stadig større del av arbeidet ligner “beskriv det du vil ha, og få en fungerende implementasjon” — og det er nettopp den typen arbeid AI er god nok på.

Det er den typen arbeid AI nå er god nok på. Den kan skrive SQL, sette opp pipeline-konfig, foreslå dbt-struktur og generere tester. Ikke perfekt, men godt nok til at du kommer 80% av veien raskt. Og når den gjør det, endrer det arbeidsdelingen i team: mindre tid på å skrive først, mer tid på å sjekke, diskutere og ta beslutninger.

Eksempel: “Lag en dbt-modell som beregner aktiv kunde per måned, med tydelig definisjon og tester for unike nøkler og nullverdier.” Du får et forslag raskt. Men du må fortsatt avklare hva “aktiv” betyr, og hvilke unntak som gjelder.

Det påvirker også verktøymarkedet. Når en agent kan se en flyt fra A til B som en helhet, blir grensene mellom “ingest”, “transform” og “orkestrering” mindre viktige. Spørsmålet blir i større grad om du har kontroll på flyten end-to-end, og mindre om du har valgt riktig verktøy i hvert enkelt lag. Plattformene som holder data, står stødigere. Lagene rundt blir mer utskiftbare.

Slik bruker vi det i hverdagen — konkret

Vi bruker primært en AI-assistent integrert direkte i VS Code eller tilsvarende utviklingsmiljø — mot kodebasen i Git, i den konfigurasjonen kunden har godkjent. I tillegg bruker vi dialogverktøy til resonnering, problemanalyse og dokumentasjon, der vi jobber med syntetiske eller anonymiserte eksempler. Det er sjelden “skriv hele løsningen”, og oftere “gi meg et førsteutkast, så tar jeg resten”.

Et skille vi finner nyttig å holde på er mellom utforskningsmodus og produksjonsmodus. I utforskning — notebooks, ad hoc-analyse, prototyping — kan AI brukes direkte og uten særlige krav til struktur. Når noe flyttes til produksjonspipeline, skjerpes kravene: samme forventning til PR-review, tester og sporbarhet som all annen kode. Uten det skillet er det lett å la “fungerer på laptopen” bli “fungerer i prod”.

I dbt bruker vi AI mye til å etablere en baseline raskt: et forslag til modellstruktur, koding av et par første modeller, YAML-dokumentasjon og en startpakke med tester. Det gir tempo i oppstarten, og det gjør det lettere å få standarder til å sitte. Men effekten kommer først når vi følger opp med det AI ikke kan gjøre for oss: avklare begreper, sikre eierskap og sjekke at modellene svarer på beslutninger noen bryr seg om.

Eksempel: Vi ber ofte om et førsteutkast til testpakke i dbt: not null på nøkler, unique der det skal være unikhet, accepted values på statusfelt, og freshness-sjekk på kilder. Det tar minutter å få et utkast. Det tar fortsatt erfaring å vite hva som bør testes først.

I modernisering og migrering er AI særlig nyttig på avstemming. Ikke fordi den “forstår dataene”, men fordi den er god på å foreslå kontrollpunkter og spørringer som raskt synliggjør avvik: summer over tid, tellerader, distinkte nøkler, null- og duplikatkontroller. Det gjør oss raskere til et systematisk opplegg. Men det flytter ikke ansvaret: mennesker må fortsatt forklare avvik, og forretningen må fortsatt godkjenne hva som er riktig.

Eksempel: Når to rapporter ikke matcher, bruker vi AI til å foreslå en “trakt” for avstemming: start på totalsum, deretter per dag, så per produktgruppe, så per region eller kundegruppe. Da finner vi ofte avviket i én eller to iterasjoner i stedet for ti.

Vi bruker også AI mye på det som ofte blir skjøvet ned på prioriteringslisten: dokumentasjon og PR-tekst. Førsteutkast til ADR-er, “how-to”, endringslogg og PR-beskrivelser basert på diff gjør det enklere å holde sporbarhet og felles forståelse. Det høres lite ut, men det er ofte det som avgjør om en løsning kan forvaltes av flere enn de som bygde den.

Eksempel: Når vi endrer en modell som påvirker en KPI, ber vi AI hjelpe oss å skrive PR-beskrivelse med: hva endrer seg, hvorfor, hvilke tabeller og modeller påvirkes, og hvordan vi kan validere at tallene fortsatt stemmer.

En praksis vi har funnet nyttig er å behandle gode prompts som teamressurser — versjonert i Git på linje med kode. En velfungerende prompt for å generere dbt-tester eller skrive PR-beskrivelser er like mye en gjenbrukbar ressurs som en SQL-mal. Det gjør det enklere å dele praksis på tvers av konsulenter, og det gir ny kontekst til neste person som tar over et prosjekt.

Når AI er selve pipelinen — ikke bare verktøyet som bygger den

Det er lett å tenke på AI i data engineering som “assistenten i IDE-en”. Men vi bruker det også som en integrert komponent i selve pipelinen — og her er skillet mellom klassisk maskinlæring og generativ AI særlig tydelig.

Klassisk maskinlæring bruker vi til predikering og strukturert klassifisering: for eksempel egenutviklede modeller som predikerer bemanningsbehov basert på historiske mønstre. Her er inndataene definerte, modellen er trent og versjonert, og outputen er en verdi eller en kategori som downstream-systemer konsumerer på vanlig måte.

Generativ AI bruker vi der inputen er ustrukturert og vi trenger språklig tolkning: for eksempel segmentering av kundeservicesaker med språkmodeller, der fritekst skal kategoriseres og rutes videre. Her er utfordringene litt andre — output er mindre deterministisk, og det stiller høyere krav til testing og monitorering av reell atferd over tid.

Felles for begge: prinsippet er det samme som for resten av plattformarbeidet. AI-komponenten skal være sporbar, testbar og kontrollert. Vi vet hvilke datafelt som sendes inn, vi tester outputen, og vi behandler det som en hvilken som helst annen del av pipelinen. Det vi aktivt unngår er black-box-avhengigheter — situasjoner der ingen lenger vet hvilke datafelt som driver en beslutning, eller der AI-laget er koblet løst fra resten av plattformkontrollen.

En del av dette er å bygge feedback-loops fra produksjon tilbake til modell eller prompt. Hva ble output i produksjon? Stemte det med forventet resultat? Og hvis ikke — oppdaterer det modellen, prompten eller treningsdataene? For klassisk ML er dette etablert MLOps-praksis. For generativ AI i pipeline er det nyere, men like nødvendig. Uten det er det ingen systematisk måte å vite om AI-komponenten forverres over tid etter hvert som data og kontekst endrer seg.

Farten øker — men det er ikke der verdien flyttes

Vi blir mer produktive på oppgaver med tydelig form. Det gjelder koding, testskjelett, dokumentasjon og oppsummeringer. I praksis betyr det at vi kommer raskere til “et fungerende forslag”.

Men den store flaskehalsen i dataarbeid er ofte ikke å produsere mer kode. Det er å bli enige om hva data betyr, hvem som eier det, og hvordan vi vet at det vi leverer er riktig. AI fjerner ikke disse diskusjonene. Den kan gjøre dem tydeligere, fordi den gjør det billigere å lage ting — og dermed mer synlig når vi lager ting som ingen egentlig bruker til å ta beslutninger.

Vi ser også at erfarne folk ofte får mer ut av AI enn mindre erfarne. Ikke fordi de er flinkere til å bruke verktøy, men fordi de er flinkere til å vurdere svarene. De stopper tidligere, utfordrer mer og vet hva som må verifiseres før noe er sant i produksjon. En viktig nyanse: seniorer bruker mer tid på å avkrefte egne antakelser enn å bekrefte dem. Det handler om aktivt å lete etter hva som kan være feil — ikke bare om å lese svarene kritisk.

Alle løfter seg, men vi tror gapet kan øke hvis man ikke jobber bevisst med review, validering og læring i team.

Tre ting som holder kontroll

Vi har landet på tre minimumspraksiser vi anbefaler uansett hvor mye eller lite AI et team bruker.

1. Verifisering før merge. AI kan skrive mye, men det er PR-review, CI-gates og tester som avgjør om det blir en del av løsningen. “AI foreslo dette” er ikke en begrunnelse — “dette er riktig fordi, og dette er hva som kan gå galt” er det.

2. Avstemming som del av endringer og migrering. Ikke som en aktivitet på slutten, men som en plan med kontrollpunkter, differanser og forklaring av avvik.

3. Begreper og definisjoner med navngitt eier. Det er vanskelig å automatisere seg ut av uenighet. Den uenigheten må håndteres med enkle, tydelige definisjoner som brukes.

Oppsummert

AI gjør oss raskere på mye av det vi gjør hver dag. Men det viktigste den gjør er å flytte oppmerksomheten: fra å produsere til å verifisere, fra verktøy til beslutningsverdi, og fra individuell leveranse til felles praksis.

Bruker du det uten de rette kontrollpunktene, blir AI bare en effektiv måte å produsere mer feil med høyere tempo. Og det siste er også en type effektivitet — bare ikke den du vil ha.

Spørsmål vi ofte får om AI i leveranser

Øker AI gapet mellom junior og senior? Det kan det gjøre — og vi ser det i praksis. En junior som får et plausibelt svar fra AI, stopper sjeldnere opp for å avkrefte antakelsen enn en senior ville gjort. Det handler ikke om verktøybruk, men om å vite hva som kan være feil. Derfor jobber vi bevisst med to-og-to på de viktigste avklaringene, og vi setter gjerne en senior på review av AI-generert kode som berører kritiske modeller — ikke fordi koden er dårlig, men fordi det er der risikoen sitter.

Hva regner dere som “kundedata”? Alt som kan avsløre forretningslogikk, personer, transaksjoner, kundelister, avtaler, priser eller interne forhold. I kodearbeidet er dette sjelden et praktisk problem — AI-assistenten jobber mot kodebasen lokalt i kundens miljø, ikke mot data i en ekstern tjeneste. Der vi er varsomme er i resonnering og dialog utenfor kodebasen: der bruker vi syntetiske eksempler eller anonymiserte utdrag.

Hva gjør dere hvis kunden ikke har policy eller godkjente verktøy? Da tar vi det opp tidlig og får på plass et minimum: hva som er tillatt, hvilke verktøy som er godkjent, og i hvilken konfigurasjon. I mellomtiden er utgangspunktet konservativt: vi bruker ikke AI-verktøy mot kode eller data som ikke er avklart. Vi er også oppmerksomme på at konsulenter kan ha egne organisasjonsinnstillinger som avviker fra kundens policy — dette er noe vi avklarer eksplisitt, ikke noe vi forutsetter er i takt.

Hvordan ser en “god prompt” ut hos dere? Vi skriver prompts som om de kan ligge i en PR: kontekst, hva vi prøver å løse, antakelser, hva som definerer “riktig”, og hvordan det skal verifiseres. Det gir bedre treff og mindre opprydding.

Hvordan kvalitetssikrer dere AI-generert kode? AI-output behandles som utkast. Vi har fortsatt de samme kravene: PR-review, tester, CI-gates og eksplisitt validering der risikoen er høy — særlig ved migrering. Hvis vi ikke kan forklare endringen, kan vi heller ikke merge den.

Hvilke AI-verktøy bruker dere? Vi har standardisert på én primær AI-assistent internt — i IDE og i dialog. Hvilke tjenester vi bruker i et konkret prosjekt avhenger av hva kunden har godkjent. Vi er mer opptatt av praksis og kontrollpunkter enn av én bestemt modell.