Vibe Research: En arbeidsflytveiledning for KI-samarbeidende forskning
Yuan Ren
april 2026
De siste årene har store språkmodeller, kodeagenter og automatiseringsverktøy gradvis funnet veien inn i forskningspraksis. De kan hjelpe forskere med å organisere litteratur, implementere kode, orkestrere eksperimenter, samle resultater og til og med skrive utkast. Dette betyr likevel ikke at forskningsprosessen automatisk blir mer stringent. Tvert imot: når klare grenser, evaluering og prosesskontroll mangler, forsterker KI ofte den eksisterende uorden. Kodestrukturer vokser raskt, eksperimentelle resultater blir vanskelige å spore, utdatafiler hoper seg opp, og forskerens oversikt over prosjektets samlede tilstand svekkes stadig. Relevante oversiktsartikler har allerede påpekt at forutsetningen for at store språkmodeller skal kunne tjene forskningen effektivt, ikke er at de «gjennomfører forskning autonomt», men at de plasseres innenfor en prosess som er avstemt med menneskelige forskningsmål og utstyrt med klare evalueringsmekanismer (Zhang et al., 2025).
Det denne artikkelen kaller Vibe Research, er ikke et strengt formalisert akademisk begrep, men snarere et praktisk arbeidsrammeverk. Grunnprinsippet er at forskeren har ansvar for problemdefinisjon, retningsvalg, evalueringsdesign og gjennomgang av konklusjoner, mens KI står for høyfrekvent iterasjon, implementering av standardkode, lokal utforskning og repetitivt arbeid. Artikkelen forsøker å organisere dette rammeverket som en kortfattet og gjennomførbar veiledning.
I. Prosjektoppstart: etabler først kjøremiljøet og samarbeidsgrensene
I kaldstartfasen av et prosjekt er den første oppgaven ikke å generere kode umiddelbart, men å etablere det mest grunnleggende kjøremiljøet og de nødvendige samarbeidsrammene. Erfaringsmessig omfatter dette trinnet vanligvis å konfigurere agents.md, relevante skills og plugins i prosjektmappen på forhånd; dersom man bruker en kommandolinjebasert arbeidsflyt, bør man i tillegg klargjøre verktøy for bakgrunnsøkter som tmux eller screen, slik at langvarige oppgaver kan kjøre uavbrutt.
Betydningen av denne fasen ligger først og fremst ikke i verktøyene selv, men i at den etablerer et stabilt ytre rammeverk for den videre forskningen. I KI-samarbeidende forskning er stabile miljøer, gjenopprettbare oppgaver og tydelig fordelte ansvarsområder ofte viktigere enn å jakte på en «elegant kodestruktur» helt fra starten. Sett fra forskningsnormenes perspektiv samsvarer dette også med den vekten maskinlæringsfeltet de senere årene har lagt på reproduserbarhet og åpenhet: forskningsprosessen må oppfylle grunnleggende krav om at den kan gjentas, spores og verifiseres (NeurIPS, 2026).
II. Idéfasen: forskningsretningen bør styres av mennesker, med KI som støtte for forståelsen
I fasen der ideer formes, bør KIs rolle begrenses til støtte snarere enn erstatning. En relativt pålitelig fremgangsmåte er at forskeren først selv leser kjerneartiklene, velger ut de virkelig relevante referansene og tekniske sporene, og deretter gir dette materialet til agenten, som genererer en mer helhetlig forståelse av feltet. Samtidig beholder forskeren selv et foreløpig veikart som klargjør hvordan prosjektet skal gå videre.
Denne arbeidsdelingen er i hovedsak i tråd med vurderingene i eksisterende oversiktsartikler. Relevante studier påpeker at LLM-er kan delta i flere faser av forskningsarbeidsflyten, men at rollen deres bygger på avstemming med menneskelige forskningsmål, ikke på å erstatte forskeren i problemdefinisjonen (Zhang et al., 2025). I denne fasen egner KI seg derfor bedre som en «forståelsesakselerator» enn som en «retningsgiver».
III. Kodebasefasen: koderammeverket er fundamentet for forskningsarbeidet
Når KI deltar i kodegenerering, er kodebasens struktur ikke et sekundært spørsmål, men selve infrastrukturen for forskningsarbeidet. I praksis er et vanlig problem at agenter har en tendens til å overabstrahere tidlig i prosjektet, for eksempel ved å dele opp en i utgangspunktet enkel datainnlastingsprosess i flere lag med dataclasses, konfigurasjonsobjekter og mellomliggende innpakningsstrukturer. Dette får systemets kompleksitet til å øke betydelig før den egentlige eksperimenteringen i det hele tatt har begynt.
I kodebasens designfase bør forskeren derfor så langt som mulig aktivt begrense abstraksjonsnivået i den første versjonen av rammeverket, gjennom plan mode eller andre midler. Det viktigste i denne fasen er ikke å bygge et generelt system for alle fremtidige scenarier, men å etablere den korteste, tydeligste og mest verifiserbare hovedveien gjennom forskningen. Hvilke strukturer som må abstraheres, hvilke deler som foreløpig bør forbli direkte, hvilke konfigurasjoner som må eksponeres, og hvilken logikk som bør styres sentralt: alle disse spørsmålene bør avgjøres av mennesker fra begynnelsen. Er det første laget av rammeverket dårlig utformet, vil hver påfølgende funksjonsiterasjon akkumulere ekstra kompleksitet. Er hovedveien derimot tydelig nok, blir senere endringer, sammenligninger og feilsøking langt mer kontrollerbare.
IV. Evalueringsfasen: evaluering bør komme før gjennomføringen av eksperimenter
I denne arbeidsflyten bør evaluering ikke forstås som «resultatstatistikk» etter at eksperimentet er avsluttet, men som «problemdefinisjon» før eksperimentet begynner. Mer presist er evalueringen det kjørbare uttrykket for hypotesen. Hvis evalueringslogikken ikke er tydelig utformet før eksperimentene starter, vil de store beregningsressursene som senere investeres, sannsynligvis utgjøre et retningsløst forbruk.
En mer pålitelig rekkefølge er derfor å utforme evalueringen først og deretter gå over til eksperimentering. Evalueringslogikken bør ikke hektes midlertidig på slutten av eksperimentene, men bør settes av som en del av kodebasen allerede i den tidligste fasen. Den konkrete formen kan avhenge av prosjektets kompleksitet: det kan være et relativt enkelt prosedyrisk skript eller et godt oppdelt modulært system. Ett prinsipp bør imidlertid ikke overses: funksjoner med ulike avhengighetsforhold bør så langt som mulig håndteres hver for seg, i stedet for at lagring av resultater, beregning av metrikker og visualisering presses inn i én altfor lang funksjon.
V. Funksjonsfasen: bruk Red–Green–Refactor for å etablere en lukket utviklingssløyfe
Når prosjektet går inn i fasen med funksjonsiterasjon, er en relativt pålitelig praksis å ta i bruk Red–Green–Refactor. Ifølge Martin Fowlers klassiske sammenfatning av TDD består denne syklusen av tre trinn: først skrives en test som feiler (Red), deretter fullføres implementeringen slik at testen passerer (Green), og til slutt omorganiseres strukturen, duplisering fjernes og teknisk gjeld reduseres (Refactor) (Fowler, 2023).
Metoden er særlig effektiv i scenarier med kodeagenter. Simon Willison (2026) anbefaler uttrykkelig å bruke red/green TDD i arbeid med kodeagenter: la først testen feile, og la deretter tilbakemeldingen fra feilen drive implementeringen. Slik reduseres tvetydighet og kvaliteten på iterasjonene øker.
Grunnen til at Refactor fortjener særskilt vekt, er at agenter ofte er flinke til å fullføre funksjonalitet raskt, men ikke av natur flinke til å omorganisere systemstrukturen proaktivt etter at funksjonaliteten fungerer. Finnes bare Red og Green, men ingen Refactor, vil prosjektets kompleksitet fortsatt hope seg opp over flere iterasjonsrunder. I funksjonsfasen bør vekten derfor ikke bare ligge på å «få KI til å skrive funksjonen», men også på å bruke tester til å etablere en lukket utviklingssløyfe som er verifiserbar, korrigerbar og bærekraftig å vedlikeholde.
VI. Eksperimentfasen: prosesstyring avgjør om prosjektet forblir kontrollerbart
Når eksperimentfasen for alvor kommer i gang, flytter prosjektets kjerneutfordring seg fra «hvordan skrive koden» til «hvordan opprettholde orden». To praktiske tiltak er særlig verdt å ta vare på.
Det første er å håndheve vedlikehold av CHANGELOG.md. Særlig når flere agenter kjører samtidig, bør enhver endring i kjernelogikken registreres kort i endringsloggen, med minst en forklaring av hva som er endret og hvilket omfang endringen har. Det andre er å skille mellom dokumenter laget av mennesker og dokumenter generert av agenter gjennom navnekonvensjoner. For eksempel kan alle markdown-filer laget av mennesker konsekvent skrives med små bokstaver, mens filer som er opprettet eller kraftig omarbeidet av agenter, konsekvent skrives med store bokstaver. Slik kan opphav og ansvarsgrenser identifiseres raskt.
Disse praksisene tilhører ikke nødvendigvis strenge, etablerte normer, men de tjener samme mål: å holde eksperimentprosessen sporbar, gjenopprettbar og tolkbar. Dette er også i tråd med maskinlæringsmiljøets nåværende krav til sporbarhet av resultater: forskning bør ikke bare rapportere resultater, men også bevare tilstrekkelig prosessinformasjon for senere kontroll og reproduksjon (NeurIPS, 2026).
VII. Autoresearch-fasen: automatisert utforskning må bygge på klare grenser
Når funksjonaliteten har nådd et relativt stabilt stadium og optimaliseringsmålene er tilstrekkelig klare, kan man forsøke å gå inn i autoresearch-fasen. Kjernen i denne fasen er ikke å «la KI optimalisere fritt», men at forskeren først definerer det akseptable optimaliseringsrommet, inkludert hvilke kodeområder som kan endres, parameterrommet og de strukturelle grensene, og først deretter lar KI utforske under kontrollerte betingelser.
Denne vurderingen er svært viktig, fordi automatisering i seg selv ikke automatisk garanterer mer pålitelige resultater. Relevante oversiktsartikler påpeker likeledes at forutsetningen for at LLM-er skal spille en rolle i forskning, er klare evalueringsmetrikker og avstemming med menneskelige mål. KI kan med andre ord hjelpe til med å søke etter kandidatløsninger, men den kan ikke erstatte forskeren i å avgjøre hva som faktisk utgjør en forbedring (Zhang et al., 2025). Autoresearch egner seg derfor bedre som en avgrenset mekanisme for delvis delegering enn som en overføring av forskningsmessig dømmekraft.
VIII. Resultatinnsamling og utkastfase: i forskningens sene fase er nøkkelen konvergens snarere enn ekspansjon
Når eksperimentene kjører stabilt og formen på evalueringsresultatene også er avklart, går prosjektet inn i sin sene fase. Erfaringsmessig er den viktigste oppgaven i denne fasen å holde orden på utdatamappen, arkivere mislykkede eksperimenter eller ugyldige resultater fortløpende og samtidig føre kjerneresultatene inn i endringsloggen.
Betydningen av dette trinnet ligger i å bevare tydeligheten i forskningskjeden. Etter hvert som antallet eksperimenter øker, er det som virkelig truer prosjektets kvalitet, ofte ikke lenger «om det fortsatt finnes nye ideer», men «om man fortsatt tydelig kan vite hvor hvert resultat kommer fra, hvilken endring det svarer til og hvilken konklusjon det støtter».
Å gå inn i utkastfasen betyr vanligvis at storskala eksperimenter, som ablasjonsstudier eller hyperparametersøk, i hovedsak er fullført, og at prosjektet nærmer seg avslutning. På dette tidspunktet bør man vende tilbake til det opprinnelige veikartet, kontrollere om noen sentrale eksperimenter er utelatt, bekrefte at argumentasjonskjeden er lukket, og først da begynne å skrive.
Det bør også bemerkes at denne veiledningen er mer direkte anvendelig i fagfelt som informatikk og økonometri, der forskningsarbeidsflytene ofte er mer formaliserte, datadrevne og lettere å evaluere reproduserbart. Den er derimot generelt mindre egnet for mange områder innen humaniora og bredere samfunnsvitenskap, der tolkning og kontekstuell analyse spiller en mer sentral rolle.
Konklusjon
Samlet sett tar Vibe Research ikke til orde for å «overlate forskningen til KI», men for å gjenopprette et strengere sett med prosessrammer etter at KI har økt iterasjonshastigheten betydelig. Rammeverket er verdifullt nettopp fordi det konsekvent holder fast ved tre ting: for det første må rammeverket etableres først; for det andre må evalueringen være gjennomtenkt først; for det tredje må utviklingen etablere en lukket tilbakemeldingssløyfe. Kjernekonklusjonen i Vibe Research kan derfor oppsummeres i én setning: KI kan øke forskningens tempo, men ansvaret for forskningsmessige vurderinger, evaluering og konklusjoner må fortsatt bæres av mennesker.
References
Fowler, M. (2023, December 11). *bliki: TestDrivenDevelopment*. Martinfowler.com. https://martinfowler.com/bliki/TestDrivenDevelopment.html
NeurIPS. (2026). *PaperInformation / PaperChecklist*. Neurips.cc. https://neurips.cc/public/guides/PaperChecklist
Willison, S. (2026). *Red/green TDD - Agentic Engineering Patterns*. Simon Willison’s Weblog. https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/
Zhang, Y., Khan, S. A., Mahmud, A., Yang, H., Lavin, A., Levin, M., Frey, J., Dunnmon, J., Evans, J., Bundy, A., Dzeroski, S., Tegner, J., & Zenil, H. (2025). Exploring the role of large language models in the scientific method: from hypothesis to discovery. *NPJ Artificial Intelligence*, *1*(1), 14. https://doi.org/10.1038/s44387-025-00019-5
Kommentarer