Oppgaven

Problemet er konkret: distribusjonen av små varepakker i Norge gjøres ineffektivt i dag. For mye som sendes i for store bokser, for mange omveier gjennom lagre, for mye CO₂ som kunne ha vært sparing. Løsningen er å distribuere automatiserte knutepunkter geografisk, men en slik infrastruktur krever software som ikke hviler på statisk kode og forhåndsbeslutninger. 

Teamet

Identigo er en norsk logistikk-startup. Løsningen er utviklet av Novanet, der teknologirådgiver Einar Ingebrigtsen er leid inn som CTO, og i tett samarbeid med gründer og CEO Jan Gusland, som uten utviklerbakgrunn, selv tok eierskap til domenemodelleringen og begynte å definere hendelsene i systemet. 

Innsikt

Den grunnleggende innsikten var at denne løsningen fra første dag må lære og tilpasse seg. Statisk kode holder ikke. Arkitekturen måtte derfor bygges som event sourcing fra starten, ikke som en ettertanke, fordi hendelsesdata er det beste grunnlaget for å trene maskinlæringsmodeller. Hver gang systemet gjør noe, lagres det som en hendelse. Over tid oppstår en komplett tidslinje av beslutninger og utfall, nøyaktig det som kreves for å bygge prediktive modeller som kontinuerlig blir bedre. 

Løsningen

Med event sourcing og event modeling på plass var det også mulig å skrive koden selv gjennom AI. Når domenemodellen var tydelig, hver hendelse navngitt etter hva den representerer i virkeligheten, og arkitekturen var konsekvent, ble kodebasen så strukturert at AI-modeller kunne generere produksjonskode, ikke prototyper. 

Tre byggeklosser: command, event, state 

Hele løsningen hviler på event sourcing, og på tre grunnleggende byggeklosser. En command uttrykker et ønske om å endre noe. Den produserer et event, som sier at en hendelse har skjedd og lagres fortløpende. Hendelsene kan da brukes til å projiseres til en tilstand (state), lesemodellene som systemet faktisk presenterer og fatter beslutninger på grunnlag av. Denne indre løkken, dvs. command som blir event som blir state, dét er motoren i alt. 

Det elegante er at dette ikke bare er en teknisk modell, men et tankesett en domeneekspert kan ta eierskap til. Det er formalisert som en modellerings-teknikk som heter Event Modeling. En av kundens egne, uten utviklerbakgrunn, tok modellen i bruk og begynte selv å definere hendelsene i systemet. Arbeidet starter i en brainstorming-fase der man fanger alt som kan skje, strukturerer hendelsene i vertikale «slices», og lar hver slice bære sitt eget lille univers av kommando, event, lesemodell og test. 

Skrevet av AI, klar for produksjon 

Her ligger kanskje det mest oppsiktsvekkende: koden er i praksis fullstendig skrevet av AI, og det er ikke en prototype. Det er produksjonskvalitet, med automatiserte tester, satt i drift som en reell MVP. Forklaringen ligger ikke i at vi slapp AI løs på et tomt lerret, men i strukturen rundt. Når arkitekturen er konsekvent, hver slice er liten, isolert og selvforklarende, og frontend og backend ligger side om side i samme mappe, blir kodebasen ekstremt enkel å utvide, og ekstremt godt egnet for AI. Det er fokuset og begrensningene, ikke friheten, som gjør det mulig. 

Agnostisk til skyen, av prinsipp 

På applikasjonsnivå er løsningen bygget på actor-modellen med bruk av Microsoft Orleans, en distribuert, turn-based programmeringsmodell som lar systemet skaleres ut uten at utvikleren må tenke på samtidighet. Valget er strategisk: serverless-funksjoner og leverandørspesifikke byggeklosser er bevisst utelatt, fordi de låser deg til én sky. Løsningen er multitenant fra bunnen, med fullstendig data skille per kunde, og kan flyttes fritt mellom Azure, alternative skyleverandører og norske datasenteraktører. Lokalt kan utviklerne kjøre opp hele løsningen med bruk av .NET Aspire, og også bare starte opp akkurat de tjenestene de trenger der og da, for ingenting dreper flyt som å vente. 

Broen mellom backend og frontend 

Et gjennomgående designprinsipp er at frontend ikke skal måtte tenke på protokoller. I stedet for å hente rå JSON via fetch og miste all typeinformasjon på veien, genereres typesikre objekter automatisk fra backend til en TypeScript- og React-frontend. Utvikleren forholder seg til domenemodellen; kommandoer, spørringer og datasett, ikke til REST eller transport. Det betyr at vi kan bytte protokoll, for eksempel til gRPC-web, uten å endre en eneste linje applikasjonskode. 

Spørringene er like gjennomtenkte. En abstraksjon lytter på endringer på databasenivå, og sender automatisk oppdateringer ut til frontend, enten som hele resultatet eller bare som de faktiske endringene som skjedde. I et distribuert system der data ikke nødvendigvis er konsistent i samme øyeblikk, er det å vise riktig tilstand til riktig tid ikke en luksus, men en forutsetning. 

Etterlevelse innebygd 

Compliance er ikke et lag som legges på til slutt. Felter som inneholder personopplysninger merkes, og krypteres deretter automatisk. GDPR-hensyn er bygget inn i rammeverket fra grunnen, en arv fra at fundamentet ble lagt mens utvikleren jobbet i forsikringsbransjen, der kontroll på personopplysninger ikke er forhandlingsbart. 

Historikken som aldri forsvinner 

Den virkelige gevinsten ved event sourcing viser seg i innsikten. Fordi hvert event lagres uforanderlig, finnes det en komplett tidslinje for hvert objekt i systemet. Vi kan spole tilbake gjennom et lagerobjekts liv, se nøyaktig hvilket event som endret hvilken tilstand, gruppere hendelser på navn, tid eller korrelasjon, og følge en forespørsel på tvers av tjenester. Den typen historikk får man ikke tradisjonelt, med mindre man bygger den manuelt. Her er logikken snudd 180 grader: man bygger hendelsene først, og lesemodellene og visningene på toppen. 

For logistikkdomenet betyr det at all data ligger klar til å trene modeller på. Et live dashboard måler de fire datapunktene som betyr noe: CO₂, kostnad, leveringstid og avstand, og gjør innsikten handlingsrettet: en forsinket forsendelse kan omdirigeres, og systemet foreslår selv konsolideringer som sparer både penger og utslipp. En egen simulator lar teamet teste hypotetiske nettverk, vekte scenarier etter hva som er viktigst, og til og med injisere «kaos» som trafikkulykker for å se hvor robust et oppsett er. 

Kunden

Identigo er en norsk logistikk-startup med ambisjon om å effektivisere distribusjonen av varepakker gjennom et nettverk av automatiserte, geografisk distribuerte knutepunkter. Selskapet er grunnlagt og ledes av Jan Gusland. 

Teknologi