Fra «vibe coding» til produksjonsklar: Hva skjer etter prototypen?

AI-verktøy kan få en idé til å fungere raskt. Sandkassen skal hjelpe dere å finne ut om løsningen har verdi, tåler motstand og fortjener en vei inn i driften.

En fungerende prototype er ikke en produksjonsløsning.

Med «vibe coding» brukes AI-verktøy til å beskrive hva som skal bygges, og få fram en fungerende løsning uten å starte med et langt utviklingsløp. Det kan være en god måte å utforske en idé på. Men en fungerende prototype viser først og fremst at noe kan bygges. Den avgjør ikke om løsningen bør settes i drift, og er som regel heller ikke ment å være en løsning som kan tas i bruk direkte.

Prototypen har kanskje svart på ett spørsmål: Kan vi få dette til å fungere?

Før løsningen får ekte brukere, data eller tilgang til andre systemer, må dere svare på flere:

• Løser den et problem som er viktig nok til å prioritere?
• Hvordan ser et godt resultat ut, og hvem vurderer det?
• Hvilke data trenger løsningen, og hvilke data skal den aldri få se?
• Hvilke handlinger kan den utføre på egen hånd?
• Hva koster en oppgave når den gjentas mange ganger?
• Hvem eier løsningen når den feiler eller må endres?

Det er her sandkassen kommer inn.

Sandkassen er et beslutningsrom

En sandkasse er en bevisst grense rundt en løsning som fortsatt er under utforsking. Den skal være avgrenset nok til å redusere konsekvensen av feil, men realistisk nok til at dere kan teste om løsningen gir verdi.

En sandkasse som skal redusere konsekvensen av feil, bør minst ha disse fem egenskapene:

1. Avgrenset tilgang. Gi brukeren og løsningen bare tilgangene som trengs for testen. Lesetilgang bør være utgangspunktet. Handlinger som endrer data, sender meldinger eller påvirker økonomi, bør kreve en egen godkjenning.
2. Kontroll på data. Start med syntetiske, anonymiserte eller på andre måter minimerte data når det er mulig. Dersom ekte data må brukes, bør dere vite hva de inneholder, hvem som kan se dem og hvor lenge de lagres. Test også at dokumenter, e-poster og eksterne kilder ikke kan endre oppgaven utenfor det dere har godkjent.
3. Budsjett for tid og tokens. Sett en grense for hvor mange steg, forsøk, tokens og kroner en oppgave kan bruke. En løsning som fungerer i én demonstrasjon, kan oppføre seg annerledes når den møter lange dokumenter, uklare forespørsler eller gjentatte feil.
4. Logging som kan brukes. Logg hvilke kilder som ble brukt, hvilke verktøy som ble kalt, hva som feilet og når et menneske godkjente en handling. Ikke legg passord, API-nøkler eller unødvendige personopplysninger i loggene. Målet er å kunne forstå hva som skjedde uten å lage en ny datarisiko.
5. Stopp og reversering. En test bør kunne stoppes. Sett tidsavbrudd og stoppkriterier. Bruk rollback der det faktisk er mulig. For irreversible handlinger bør løsningen ligge i dry-run eller en kø, eller kreve eksplisitt menneskelig godkjenning med en definert prosedyre for å kompensere eller rette opp en feil.

Disse kontrollene gjør ikke en prototype sikker i enhver situasjon. De gjør det mulig å oppdage svakheter mens løsningens handlingsrom fortsatt er lite.

Test både verdi og feil

Det er lett å teste den gode historien: En bruker gir riktig instruksjon, løsningen finner riktig informasjon og resultatet ser nyttig ut. Det er nødvendig, men ikke tilstrekkelig.

Start med én konkret arbeidsflyt. Tenk deg for eksempel en prototype som leser en innkommende forespørsel, finner relevant informasjon og lager et forslag til neste steg. Før testen bør dere beskrive hvordan oppgaven løses i dag, hva som teller som et godt forslag og hvor mye menneskelig kontroll som er akseptabelt.

Mål det som skal bli bedre. Det kan være behandlingstid, antall korrigeringer, kvaliteten på kildegrunnlaget eller hvor raskt selgeren kommer videre. Testen kan vise at en forbedring er mulig. Først når arbeidsmåten endres og noen faktisk tar i bruk den frigjorte kapasiteten, vet dere om forbedringen har fått verdi i driften.

Test deretter når løsningen møter motstand:

• Hva skjer når data mangler eller motsier hverandre?
• Hva skjer når et dokument inneholder en instruksjon som prøver å endre oppgaven?
• Hva skjer når en bruker ber om noe utenfor det løsningen skal håndtere?
• Hva skjer når en tjeneste er utilgjengelig, eller modellen prøver på nytt mange ganger?
• Hva skjer når en bruker har mer tilgang enn arbeidsflyten trenger?

Dette beviser ikke at løsningen aldri kan misbrukes. Det viser hvor den kan feile, og hvilke grenser som må bygges rundt den.

Når prototypen begynner å bruke verktøy eller utføre handlinger, blir identitet og tilgang særlig viktig. NIST peker på at langlivede bearer tokens og statiske API-nøkler ikke beviser identitet og kan gi for bred tilgang. OWASP fremhever på sin side minste privilegium, tillatelser per verktøy, eksplisitt godkjenning for høyrisiko-handlinger, logging og grenser for tokens, kostnad, forsøk og verktøykjeder.

Rådene handler ikke om vibe coding spesifikt. De er relevante fordi en prototype raskt kan gå fra å foreslå noe til å lese, endre eller sende noe på vegne av virksomheten.

Gjør prototypen mulig å vurdere

Etter testen må dere kunne ta en beslutning: Skal dere stoppe, forbedre eller gå videre med en kontrollert pilot?

En praktisk overgang kan se slik ut:

1. Bestem om problemet fortjener mer arbeid. Definer hvilken verdi dere undersøker, og hva som må være sant for at arbeidet skal prioriteres videre. En prototype kan være morsom å bygge uten å løse et problem som betyr noe for virksomheten.
2. Dokumenter arbeidsflyten. Beskriv hvilke data som kommer inn, hvilke steg løsningen utfører, hvor den kan ta feil og når et menneske skal overta. En prototype som bare én person forstår, er ikke klar for en organisasjon.
3. Gjør minimumskontrollene på plass før piloten. Før dere gir grønt lys, skal sandkassens kontrollpunkter være bestått: data- og tilgangsoppsettet er godkjent, kvalitetsnivået er definert, kostnadsgrensen er satt, høyrisiko-feil er håndtert, og irreversible handlinger krever menneskelig godkjenning. En navngitt eier godkjenner at piloten kan starte.
4. Kjør en kontrollert pilot. Bruk en begrenset gruppe, en avtalt periode og tydelige pass-/fail-kriterier. I tilbudsarbeidsflyten kan en eksempelterskel være at alle priser skal kunne spores til en godkjent kilde, at ingen tilbud sendes uten menneskelig godkjenning, og at piloten stoppes ved en avtalt feilrate. Dette er eksempelverdier teamet selv må fastsette. En navngitt person tar go/no-go-beslutningen når piloten er ferdig.
5. Bygg ut driftsgrunnlaget etter behov. Når piloten viser stabil kvalitet, kan dere utvide med tester, utrulling, overvåkning, backup og mulighet for rollback. Hvor mye som kreves, avhenger av hvilke data og handlinger løsningen har tilgang til.

En produksjonsløsning trenger også en navngitt eier eller et team som følger opp feil, endringer, tilgang og videre utvikling. Det ansvaret forsvinner ikke fordi koden ble laget med et AI-verktøy. Kravene bør stå i forhold til konsekvensen. En intern prototype som lager tekstutkast, trenger ikke samme kontroll som en løsning som endrer priser, behandler personopplysninger eller sender informasjon til kunder. Men begge trenger en tydelig grense for hva de kan gjøre, og en person som vet hva som skjer når grensen nås.

Bygg videre først når dere vet hvorfor

Vibe coding kan redusere det innledende utviklingsarbeidet og gjøre det mulig å utforske flere muligheter. Det betyr ikke nødvendigvis lavere totalkostnad; den må vurderes etter testing, integrasjon og drift.

Sandkassen er stedet der dere kan teste om løsningen fortjener å gå videre. Den gjør det mulig å stoppe tidlig, forbedre informasjon eller gå videre med et mer realistisk bilde av kostnad og risiko.

Start med én prototype. Skriv ned hvilke data den kan bruke, hvilke handlinger den kan utføre, hvor mye den får koste og når den skal stoppe. Test både den gode historien og de ubehagelige variantene.

En fungerende prototype viser at dere kan bygge noe. En produksjonsløsning krever at dere vet hvem som eier løsningen, hvordan den kontrolleres, og hva som skjer når den feiler eller må endres.