GPT-6 Astra: Fra idé til spill og nyttige verktøy

En liten havn. Et fyrtårn. En måne som har meldt seg syk. Og en spiller som må finne ut hva som har skjedd.

Et eventyrspill og et internt arbeidsverktøy kan virke som to forskjellige verdener. Begge trenger likevel et forståelig grensesnitt, regler for hva som kan skje, og et system som husker hvor brukeren er i prosessen. Med GPT-6 Astra blir det mer tilgjengelig å utvikle slike løsninger ved å beskrive det vi vil oppnå, prøve resultatet og forbedre det underveis.

For oss i Skjld Labs ligger en særlig interessant mulighet i arbeidsdelingen: Bruk en stor modell til å hjelpe med å bygge løsningen. La vanlig kode og små, lokale spesialmodeller håndtere oppgavene de egner seg for når løsningen tas i bruk.

GPT-6 Astra gjør det enklere å komme i gang

OpenAI beskriver GPT-6 Astra som en modell for blant annet kompleks resonnering, koding og bruk av digitale verktøy. Veiledningen fremhever arbeid gjennom flere steg, på tvers av kode, nettlesere og programvare. Det gir et bredere utgangspunkt for utvikling enn å be om en isolert kodebit. OpenAIs modellbeskrivelse, veiledning for Astra.

En konkret bestilling kan derfor begynne med opplevelsen: «Lag et lite eventyr der spilleren utforsker en havn, samler spor og får hjelp uten at gåten avsløres.» For et arbeidsverktøy kan bestillingen være: «Gi oss en oversikt over innkommende forespørsler, hva som mangler, og hvem som skal følge opp.»

Så begynner det nyttige samarbeidet. Gjør navigasjonen tydeligere. Vis neste steg. La brukeren fortsette der hun slapp. Fang opp feil før de ødelegger fremdriften. En kjørbar versjon gir noe konkret å reagere på.

OpenAIs utviklerblogg viser denne arbeidsformen i Void Explorer, et romspill bygget med Astra i Codex. Utvikleren gikk fra ønsket spillopplevelse og konseptbilder til kode, spilltesting og videre forbedringer. Eksemplet viser verdien av iterasjon og tydelig retning. Building games with Astra, 4. september 2026.

Enkelheten ligger i at flere kan delta i denne prosessen. God smak, domenekunnskap og testing avgjør fortsatt om resultatet blir verdt å bruke.

Underholdning er en konkret test på om helheten fungerer

Skjermbildene fra Wobblequay: The Moon That Called in Sick viser en liten verden med havn, strand og fyrtårn. Her finnes figurer å snakke med, gjenstander å undersøke, en oppdragsoversikt og lommer med ting spilleren har samlet.

Det er et godt eksempel på hva programvare må få til: gjøre neste handling forståelig, bevare tilstand og gi tilbakemelding som betyr noe. Spilleren må forstå hvor hun kan gå, hva hun kan gjøre, og om en handling faktisk endret noe.

Denne typen små verdener kan også inspirere til læringsspill, interaktive fortellinger og opplæring. Vi kan gi brukeren en situasjon å utforske og la valgene få synlige konsekvenser. Når det blir lettere å lage og endre prototyper, kan vi undersøke flere ideer før vi bestemmer oss for hva som fortjener videre utvikling.

Den samme strukturen kan gjøre arbeidsdagen enklere

Bytt ut en ledetråd med et dokument, og et oppdrag med en kundehenvendelse. Mange av de samme designspørsmålene dukker opp: Hva vet systemet? Hva mangler? Hvilke handlinger er tilgjengelige nå? Hva skal brukeren se?

• I et eventyrspill: Spilleren undersøker en gjenstand → I et arbeidsverktøy: En medarbeider åpner en forespørsel
• I et eventyrspill: Et nytt spor oppdaterer oppdraget → I et arbeidsverktøy: Et nytt dokument oppdaterer saken
• I et eventyrspill: En handling låses opp når vilkårene er oppfylt → I et arbeidsverktøy: Neste steg blir tilgjengelig når informasjonen er komplett
• I et eventyrspill: Et hint hjelper spilleren videre → I et arbeidsverktøy: Systemet foreslår en konkret oppfølging

Tenk på en liten bedrift som mottar mange serviceforespørsler. En løsning kan samle dem, foreslå kategori, trekke ut produktnavn og vise hvilke opplysninger som mangler. Medarbeideren får et ryddig utgangspunkt for å følge opp.

Astra kan brukes i utviklingen av grensesnittet, datamodellen og arbeidsflyten. Verdien må deretter vurderes i faktisk bruk: Blir det færre manuelle steg? Oppdages mangler tidligere? Forstår medarbeideren hvorfor saken havnet her?

Vi har tidligere skrevet om hvordan grafstenkning gjør oppgaver og avhengigheter tydelige. Det er en nyttig måte å beskrive både oppdrag i et spill og arbeid i en virksomhet.

Bygg med en stor modell. Kjør avgrensede oppgaver lokalt.

Modellen som hjelper oss å lage programmet, trenger ikke være modellen programmet bruker til daglig.

En sterk generalist er nyttig når mange hensyn må ses i sammenheng: struktur, kode, brukeropplevelse og vanskelige feil. Når systemet er bygget, er mange av oppgavene langt smalere. Å plassere en forespørsel i én av seks kategorier stiller andre krav enn å designe hele produktet.

Her kommer små, integrerte, vertikale modeller inn. Med «vertikal» mener vi en modell tilpasset et avgrenset fagområde eller en bestemt oppgave. Den kan være valgt og konfigurert for oppgaven, eventuelt finjustert der det gir dokumentert verdi.

Inferens er kjøringen av modellen på nye inndata. Slik inferens kan foregå lokalt på brukerens enhet, eller på virksomhetens egen server, dersom modellen og maskinvaren passer sammen. ONNX Runtime dokumenterer kjøring på lokale og innebygde enheter, med modellstørrelse og ressursbehov som sentrale hensyn. ONNX Runtime: Deploy on IoT and edge.

Apple viser konkrete oppgaver for modeller på enheten: blant annet ekstraksjon, klassifisering, oppsummering og spilldialog. De fremhever også betydningen av avgrensede oppgaver og modellens begrensninger. Apples introduksjon til Foundation Models.

Dette gir grunnlag for en praktisk arkitektur: Astra hjelper med å bygge. Små modeller tolker og formulerer innenfor definerte rammer i det ferdige produktet. Valg, tilpasning og testing av disse modellene er en egen del av utviklingsarbeidet.

Grafen holder orden. Modellene bidrar der de trengs.

En arbeidsflytgraf beskriver hvilke steg som finnes, hvordan de henger sammen, og hvilke vilkår som leder videre. Programkode kan kjøre grafen, lagre tilstanden og håndheve reglene. Enkelte noder kan kalle en lokal modell når de trenger å forstå språk eller lage et tekstforslag.

I serviceeksemplet kan flyten være:

1. Kode tar imot forespørselen og lagrer den.
2. En lokal modell foreslår kategori og henter ut relevante opplysninger.
3. Kode kontrollerer format, påkrevde felt og tillatte verdier.
4. En medarbeider håndterer tvetydige saker og godkjenner oppfølgingen der det trengs.

En formatkontroll kan bekrefte at et produktfelt finnes. Den kan ikke alene bekrefte at modellen fant riktig produkt. Derfor må løsningen også testes mot representative eksempler med kjente svar, og ha en tydelig vei videre når resultatet er uklart eller feil.

I et spill kan samme arbeidsdeling la en liten modell formulere et hint ut fra oppdragsstatusen. Koden bestemmer hvilke ledetråder som kan avsløres og hvilke handlinger som er lovlige.

Lokal kjøring kan redusere behovet for eksterne modellkall og gjøre enkelte funksjoner tilgjengelige uten nett. Gevinsten må måles på aktuell maskinvare: kvalitet, svartid, minnebruk og strømforbruk. Integrasjoner og andre tjenester kan fortsatt kreve nettverk. Vanskelige saker kan gå til et menneske eller en større modell, med en eksplisitt beslutning om hvilke data som eventuelt kan sendes videre.

Produksjon krever fortsatt infrastruktur og fagfolk

Når prototypen fungerer, begynner arbeidet med å gjøre den klar for andre brukere. Programvaren skal pakkes, publiseres, sikres, overvåkes og oppdateres. Den skal tåle feil, og det må finnes en vei tilbake hvis en ny versjon skaper problemer.

Skjld Labs har både infrastrukturen og den praktiske kompetansen til å klargjøre, publisere og drifte slike løsninger. Vi kan ta arbeidet videre fra en kjørbar prototype til programvare som er herdet for produksjon. Det innebærer blant annet å kontrollere tilganger og avhengigheter, beskytte hemmeligheter, teste belastning og feilsituasjoner, og etablere logging, sikkerhetskopiering og gjenoppretting.

AI kan hjelpe med byggeskript, konfigurasjon og feilsøking. Denne hjelpen får først verdi i produksjon når noen kan vurdere om oppsettet er riktig, forstå konsekvensene av en endring og ta ansvar for driften. Infrastrukturen og denne kompetansen følger ikke automatisk med en AI-modell ut av boksen.

Det må fortsatt finnes folk som kan sette sammen programvarepakker, få avhengighetene til å fungere og vite hva som faktisk kjører på serverne. Noen må kunne slå en server av og på, forstå hvorfor den stoppet og få tjenesten trygt opp igjen. Når maskinvare eller nettverk svikter, kan det også være nødvendig med noen som møter opp og håndterer det fysisk.

Mye av dette arbeidet kan automatiseres. Fagfolk må fortsatt bygge, kontrollere og vedlikeholde automatiseringen. Det er denne kombinasjonen av AI, infrastruktur og praktisk erfaring vi bringer inn: evnen til å lage løsningen, sette den i produksjon og holde den i gang.

Fra en liten idé til noe folk bruker

Det spennende med GPT-6 Astra er muligheten til å gjøre flere ideer konkrete. Et lite eventyr kan bli en opplevelse vi kan spille og forbedre. En irritasjon i arbeidsdagen kan bli et verktøy vi kan prøve med dem som faktisk skal bruke det.

Vår vurdering er at sterk utviklingshjelp og lokal inferens for avgrensede oppgaver åpner et stort praktisk handlingsrom. Med tydelig systemarkitektur, riktig infrastruktur og folk som kan publisere og drifte programvaren, kan ideene bli til tjenester som fungerer over tid. Begynn med én opplevelse eller én arbeidsflyt. Bygg den, prøv den og mål hva som fungerer.

Har dere en idé til et spill, et opplæringsverktøy eller en arbeidsflyt? Ta en prat med Skjld Labs om veien fra idé til produksjon og drift.

Hovedillustrasjon: AI-generert for Skjld Labs.