Fra kode til forskning: Dette vil jeg kontrollere
Fire påstander jeg kan kontrollere
Jeg begynner med det sikre. OpenAI beskriver samarbeid med laboratorier, universiteter og forskere om AI-støttet vitenskap. OpenAI understreker også at forskere må definere spørsmål og validere resultater. Det er to avgrensede påstander om samarbeid og menneskelig validering.
Anthropic beskriver Claude Code som et agentisk kodeverktøy og deler arbeidsmåter fra utviklingen. Google beskriver lokale modeller og utviklerverktøy i en offisiell AI-oppdatering. Ingen av disse setningene dokumenterer et bestemt resultat hos en bruker. Det skillet styrer resten av vurderingen min.
Forskere må fortsatt definere og validere
OpenAIs formulering gjør meg mer interessert i arbeidsdelingen enn i løftet om AI-støttet vitenskap. Hvis forskere skal definere spørsmålene, må prosjektet kunne vise hvem som formulerte dem, og hvilket grunnlag de bygget på. Hvis forskere skal validere resultater, må de også kunne forklare hva som ble kontrollert.
Kilden i dette grunnlaget beskriver ikke én felles metode for slik validering. Derfor vil jeg ikke late som den finnes. I stedet spør jeg: Hvilke resultater krever kontroll? Hvilket materiale skal forskeren sammenligne med? Når er et svar bare et forslag, og når kan det brukes videre? Dette er praktiske spørsmål som følger av den menneskelige rollen kilden faktisk nevner.
Et agentisk kodeverktøy må vurderes gjennom arbeidet
Anthropic beskriver Claude Code som et agentisk kodeverktøy og deler arbeidsmåter fra utviklingen. Det forteller hvordan selskapet omtaler verktøyet, og at det har erfaringer å dele. Det forteller ikke i dette kildegrunnlaget hvordan verktøyet oppfører seg i et bestemt prosjekt, eller hvilket resultat et bestemt team får.
Jeg vil derfor se på arbeidsflyten i praksis. Hvilken oppgave får verktøyet? Hvilket kodegrunnlag får det tilgang til? Hvem leser endringene? Hvilke kontroller skjer før noe tas i bruk? Dette er ikke påstander om verktøyets virkning. Det er spørsmål et team kan bruke for å dokumentere sin egen bruk uten å gjøre leverandørens beskrivelse om til et målt resultat.
Lokale modeller og utviklerverktøy er et eget spor
Google beskriver lokale modeller og utviklerverktøy i sin offisielle AI-oppdatering. Det er et teknologisignal, men ikke en ferdig vurdering av en virksomhets oppsett. Jeg vet ikke fra denne kildesetningen hvilken modell en bestemt utvikler velger, hvilke data som brukes, eller hvordan arbeidet kontrolleres.
Det gjør spørsmålene konkrete. Hvilken del av kode- eller forskningsarbeidet skal skje lokalt? Hvilke resultater må kunne gjenskapes? Hvem har ansvar for å stoppe eller endre arbeidsflyten dersom kontrollen ikke gir et klart svar? Jeg vil heller la disse spørsmålene stå åpne enn å fylle dem med generelle antakelser om lokale modeller.
Min kontroll før jeg tror på et resultat
Mitt råd er å skrive ned fem ting for hver arbeidsflyt: spørsmålet som skal løses, materialet verktøyet får, handlingene det utfører, kontrollen et menneske gjør, og beslutningen som tas etterpå. Listen beviser ingen gevinst, men den gjør det mulig å diskutere hva som faktisk skjedde.
For forskning vil jeg særlig følge hvordan forskere beskriver definisjon og validering. For kode vil jeg se etter konkrete arbeidsmåter og tydelig menneskelig kontroll. For lokale verktøy vil jeg undersøke hva den offisielle oppdateringen faktisk dokumenterer. Inntil kildene gir mer, er min konklusjon enkel: AI-verktøy kan omtales som arbeidsverktøy, men hvert resultat må vurderes i den arbeidsflyten der det ble til.
Kilder
- Skriv Bjørgs personlige analyse av hvordan AI-verktøy flyttes fra svarmaskiner til arbeidsverktøy for kode og
