DeepSeek har offentliggjort en prototype på en kodeagent, der kan følge opgaver i et GitHub-projekt og arbejde videre i egne sessioner. Projektet hedder dsh-superagent-prototype og giver et indblik i, hvordan et udviklingsteam kan organisere mere vedvarende arbejde med AI.

Den vigtigste begrænsning står allerede øverst i DeepSeeks projektbeskrivelse: Koden er til forskning og reference, ikke et officielt DeepSeek-produkt. Den offentliggjorte udgave er tilpasset og er hverken identisk med holdets interne løsning eller med alle de ideer, der beskrives i det tilhørende designarbejde.

Prototypen er udgivet under MIT-licensen. Den retter sig mod ét GitHub-kodelager og kan også kobles til samarbejdstjenesten Feishu. Når en person med den nødvendige adgang beder om arbejde, opretter systemet en opgave, arbejder i en særskilt session og mappe og svarer tilbage i den oprindelige samtale, for eksempel med et pull request: et forslag til ændringer, som kan gennemgås, før det indarbejdes.

Et system omkring modellen

Nyheden er dermed ikke alene en model, som kan skrive et stykke kode. Den handler om den struktur, der tager imod en besked, afgør om arbejdet må begynde, holder styr på opgaven og leverer et resultat tilbage.

Det er en praktisk forskel for et team. Et forslag i en chat skal normalt flyttes ind i udviklingsarbejdet, før andre kan vurdere det. Et ændringsforslag i projektets normale arbejdsgang kan i stedet møde de samme gennemgange og kontroller som andre ændringer.

Men placeringen i en velkendt arbejdsgang siger ikke i sig selv noget om kvaliteten. En automatisk oprettet ændring kan stadig være forkert, utilstrækkeligt testet eller misforstå opgaven. Elektronika har gennemgået dokumentationen, men har ikke installeret eller afprøvet prototypen.

Hvem må sætte agenten i gang?

I dokumentationen om autorisation beskriver DeepSeek en opdeling mellem beskeder, der indeholder en udtrykkelig opgave, og beskeder, der højst er mulige kandidater til arbejde.

Tilladte personer, regler og opgavernes mandat håndhæves af værtsprogrammet. Kommentarer, beskeder og citerede dokumenter beskrives som input til en beslutning; de kan ikke selv ændre tilladelserne. Det er relevant i et miljø, hvor en agent kan læse både menneskers anvisninger og automatisk genererede beskeder.

Systemet har tre tilstande for arbejde, der ikke er en udtrykkelig bestilling: Slået fra, observation og automatisk accept. Observation er standarden. Her kan en kandidat vurderes, og systemet registrerer, hvad det ville have accepteret, uden faktisk at starte opgaven. Dokumentationen anbefaler først at skifte til automatisk accept efter gennemgang af de registrerede beslutninger.

Botbeskeder kan indgå i dette flow, men er ikke udtrykkelige bestillinger fra en person. En besked om et testresultat og en menneskelig ordre har altså forskellige roller i den beskrevne model.

Egne arbejdsmapper er ikke en sikkerhedsgrænse

Beskrivelsen af selve udførelsen indeholder en vigtig teknisk detalje: Arbejdssessionerne kører kommandoer som operatørens bruger på computeren og uden særskilt godkendelse af hver kommando.

Dokumentationen understreger, at de valgte mapper og kommandoindpakninger fastlægger standarder, men ikke udgør en sikkerhedsgrænse. En agent kan fortsat kalde et program via dets fulde sti. En separat mappe bør derfor ikke forveksles med fuld isolation fra resten af maskinen.

Det gør opsætningen til en del af vurderingen af prototypen. Spørgsmålet er ikke kun, om agenten kan skrive en rettelse, men også hvilke filer, værktøjer og konti den kan nå, mens den forsøger.

For et tænkt team kan det betyde, at en afprøvning begynder med et afgrænset projekt og en konto med begrænset adgang. Det er et eksempel på en driftsbeslutning, ikke en funktion, som artiklen har testet i DeepSeeks kode.

Levering og indarbejdelse er to trin

Dokumentationen skelner mellem en opgave, som arbejder, venter eller har brug for et menneske. Et færdigt forslag kan vises som klar til gennemgang. Det giver en struktur for, hvornår en person skal tage stilling, frem for at alle beskeder behandles som lige vigtige.

Automatisk indarbejdelse af kode har også sin egen afgrænsning. Ifølge udførelsesdokumentet styres kravene af leveringsinstruktioner; værtsprogrammet har ikke en særskilt beslutningslogik for sammenlægning. Standardadfærden er ikke at aktivere automatisk sammenlægning som agentens egen konto, og uden den beskrevne alternative opsætning indarbejder mennesker ændringen.

Den sondring er væsentlig: At en agent leverer et pull request, er ikke det samme som, at dens kode automatisk sættes i drift. Det endelige resultat afhænger af projektets regler og den konkrete opsætning.

Åben kode giver mulighed for at undersøge påstandene

For udviklere er udgivelsen interessant, fordi systemets arbejdsgange kan læses og vurderes direkte. Det er muligt at undersøge, hvilke beslutninger der er lagt i programkode, og hvilke der afhænger af instruktioner til en model.

Åben adgang gør dog ikke projektet færdigt. DeepSeek skriver selv, at kode og arbejdspraksis kan være uensartede, og at der fortsat kan være fejl. Nogle designideer er retninger for fremtidigt arbejde og er ikke implementeret i prototypen.

Der følger heller ikke i den korte projektbeskrivelse et dokumenteret grundlag for at erklære løsningen bedre end bestemte kommercielle kodeagenter. En sådan sammenligning ville kræve ens opgaver, kendte betingelser og kontrol af de leverede resultater. Denne artikel fremsætter derfor ikke en rangliste eller en påstand om målte produktivitetsgevinster.

Den konkrete nyhed er en offentlig forskningsprototype med både et arbejdsflow og tydelige forbehold. Den peger på en udvikling, hvor kodeagenter får flere opgaver over længere tid, mens spørgsmålene om mandat, adgang og menneskelig gennemgang bliver en central del af selve produktdesignet.