Brug AI-agenter sikkert til kodegennemgang, test og deploy

Start med opgaver, der er gentagne, lette at kontrollere og har lav risiko

De bedste første opgaver for en agent er dem, dit team allerede løser på samme måde hver uge og hurtigt kan kontrollere. Hvis en udvikler ikke inden for et minut kan se, om resultatet er rigtigt, skaber agenten mere gennemgangsarbejde i stedet for at spare det.

Vent med ændringer i produktionsdata, ændringer i infrastrukturen og alt, der ikke kan gøres om, til agenten har bevist sit værd på mere sikre opgaver.

• Første gennemgang af pull requests: manglende tests, risikable mønstre, uklar navngivning, stilproblemer
• Tests til eksisterende funktioner, især kanttilfælde og regressionstests for rettede fejl
• Pull requests med opdaterede afhængigheder og et resumé af hver changelog
• Udkast til release notes ud fra de pull requests, der er merget
• Sortering af fejlede CI-kørsler, hvor fejlene grupperes, og det sandsynlige commit udpeges

Vælg det rigtige lag: model-API, agentframework eller workflowværktøj

Direkte kald til OpenAI- eller Anthropic Claude-API'erne med værktøjsbrug er nok til en enkelt, veldefineret opgave. LangChain tilføjer integrationer og gængse byggeklodser, og LangGraph modellerer en agent som en eksplicit graf af trin med fælles tilstand, hvilket gør forgreninger, nye forsøg og punkter for menneskelig godkendelse lettere at overskue.

n8n passer til alt det, der binder agenten sammen med omgivelserne: at starte på et webhook fra GitHub eller GitLab, kalde modellen, skrive en review-kommentar og give besked i en kanal. En almindelig opdeling er n8n til orkestreringen og selve ræsonnementet i kode, hvor det kan versionsstyres og testes som resten af din software.

Hos NorthStar Network byggede vores udviklere AI-drevne interne værktøjer, der automatiserede tilbagevendende udviklingsopgaver for platformens værktøjsteam.

Giv agenten de færrest mulige værktøjer

En agent kan kun gøre skade gennem sine værktøjer, så værktøjslisten er din vigtigste sikkerhedskontrol. Definér hvert værktøj med et snævert formål og validerede input i stedet for at give agenten en generel shell eller et API-token med brede rettigheder.

Behandl alt, hvad agenten læser, også teksten i issues, kodekommentarer og websider, som input, du ikke kan stole på. Instruktioner gemt i en fil kan forsøge at lede agenten i en anden retning, en risiko kendt som prompt injection, og det er stramme grænser for værktøjerne, der forhindrer et sådant forsøg i at gøre skade.

• Kun læseadgang som standard: læsning af filer, diffs og CI-logs
• Skriveadgang begrænset til en arbejdsgren, aldrig til hovedgrenen eller produktion
• Separate, kortlivede adgangsoplysninger for hver agent med de mindst mulige rettigheder
• Ingen direkte udrulning: agenten opretter en pull request, og din normale pipeline udruller efter godkendelse
• En liste over tilladte kommandoer til at køre tests, afviklet i en isoleret container

Først planen, så handlingen, og log hvert værktøjskald

Bed agenten om at lave en plan, før den ændrer noget: hvilke filer den vil læse, hvad den har tænkt sig at ændre, og hvordan den vil kontrollere resultatet. Planer med lav risiko kan køre automatisk. Alt, der rører delt kode, venter på, at et menneske godkender planen.

Log hvert værktøjskald med input, output, tidsstempel og den opgave, det hører til. Med den log kan du fejlsøge et dårligt resultat, besvare et spørgsmål fra en revision og opdage en agent, der bevæger sig uden for sin opgave. Beskyt den som andre udviklingslogs, da den kan indeholde kildekode.

Sæt faste grænser for hver kørsel: et maksimalt antal trin, tokens og minutter og et stop efter gentagne fejl i stedet for en endeløs løkke af nye forsøg.

Lever hver ændring som et diff, som et menneske gennemgår

Agentens output skal lande der, hvor udviklerne allerede gennemgår arbejde: en pull request, en review-kommentar, et udkast til release notes. Diffet viser præcis, hvad der er ændret, CI kører mod det, og dine normale regler for godkendelse gælder.

Hold agentens diffs små og med ét formål. En pull request, der tilføjer tests til ét modul, er let at gennemgå, mens en, der rører ti filer for at forbedre lidt af hvert, enten bliver godkendt ukritisk eller afvist. Markér ændringer skrevet af en agent, så reviewerne kontrollerer antagelserne og ikke kun syntaksen.

Genererede tests kræver særlig omhu. Tjek, at de afprøver den tilsigtede adfærd og ville fejle, hvis koden var forkert, i stedet for blot at registrere det, den nuværende kode returnerer.

Evaluer på din egen historik, før du udvider rammerne

Byg et lille evalueringssæt ud fra dine egne repositories: tidligere pull requests med kendte problemer, funktioner med kendte fejl, fejlede CI-kørsler med kendte årsager. Kør agenten mod det, hver gang du ændrer prompten, modellen eller værktøjerne, og sammenlign resultaterne med den forrige kørsel.

I den daglige brug skal du følge, hvor ofte reviewere accepterer agentens forslag, hvor mange af agentens pull requests der merges uden rettelser, og hvor ofte planer afvises. Giv først agenten en ny opgave eller mere adgang, når de signaler er stabile.

Skriv datapolitikken før den første kørsel

Beslut, hvilken kode og hvilke data der må sendes til hvilken modeludbyder og på hvilke kontraktvilkår, og skriv det ned. Tjek hver udbyders indstillinger for opbevaring og træning ved brug via API, og hold hemmeligheder, adgangsoplysninger og persondata ude af prompts og logs.

Hvis en agent betjener flere teams eller kunder, så isolér hver enkelts data, adgangsoplysninger og logs. SDK Pilot, vores AI-agent til softwareudvikling, som nu er gratis i tidlig adgang, følger disse regler: den viser sin plan, før den udfører den, logger hvert værktøjskald, leverer diffs, der kan gennemgås, og isolerer hver organisations data.

FAQ