Læringsløp 01Leksjon 4 / 6

Velg en nyttig første AI-oppgave

Velg en liten oppgave med tydelige inndata, synlige resultater og begrensede konsekvenser.

Grunnleggende8 minGjennomgått

Publisert av Slik skriver vi

Dette lærer du

  • Vurder hvor tydelig, verifiserbar og reverserbar en oppgave er.
  • Definer suksess før du starter.
  • Hold sensitive data og produksjonshandlinger utenfor en første øvelse.

Velg en oppgave du kan verifisere

Den første nyttige oppgaven bør lære deg hvordan verktøyet fungerer i miljøet ditt. Den bør også gi et resultat du kan undersøke. En liten rettelse av en kjent feil oppfyller ofte begge betingelsene.

Ikke velg oppgaven bare fordi demonstrasjonen vil se imponerende ut. Et omfattende redesign kan gi mange synlige endringer og samtidig skjule feil antakelser. En liten oppgave kan vise om agenten leser instruksjoner, respekterer omfanget og rapporterer mislykkede kontroller korrekt.

Du trenger ikke velge den enklest mulige oppgaven. Velg en der teamet kan gjenkjenne et riktig resultat og forklare hvorfor det er riktig.

Sammenlign mulige oppgaver

Se for deg tre fiktive forespørsler i en rapporteringsapplikasjon.

Mulig oppgaveVerifiseringKonsekvenser
Forklar en datoparserSammenlign forklaringen med kode og eksemplerIngen repositoryendring
Legg til en regresjonstest for en kjent datofeilTesten feiler på feilen og består etter rettingEn liten branchendring
Skriv om rapporteringsarkitekturenMange krav og integrasjoner må gjennomgåsEn omfattende endring med usikre virkninger

Forklaringsoppgaven hjelper deg med å undersøke resonnement og dokumentasjon. Regresjonstesten legger til en kontrollert handling. Arkitekturoppgaven kan være verdifull senere, men krever en langt sterkere oppgavebeskrivelse og gjennomgangsprosess.

Velg regresjonstesten som første øvelse. Bruk oppdiktede datoer og en lokal branch. Angi at produksjonstilgang, oppgradering av avhengigheter og uvedkommende refaktorering ligger utenfor omfanget.

Skriv betingelsen for fullføring

«Forbedre datohåndtering» gir for stort tolkningsrom. Bruk en konkret betingelse: «Når inndata inneholder en ugyldig kalenderdato, returner en valideringsfeil. Bevar dokumentert utdata for gyldige datoer.»

Legg til eksempler på gyldige og ugyldige inndata. Identifiser den eksisterende testkommandoen. Be agenten undersøke gjeldende atferd før den endrer filer. Krev en kort forklaring av feilen og dokumentasjonen etter endringen.

Skill oppgavens resultat fra en aktivitet. «Agenten skrev en test» beskriver aktivitet. «Testen avviser den kjente feilen» beskriver dokumentasjon. En test som består med både riktig og feil kode, dokumenterer ikke den tilsiktede beskyttelsen.

Observer arbeidsprosessen

Registrer under øvelsen hvor agenten trenger mer kontekst. Kontroller om den leser relevante repositoryinstruksjoner. Legg merke til om den endrer filer utenfor omfanget eller gjentar en mislykket tilnærming uten ny dokumentasjon.

Ikke korriger hvert lite valg med en gang. La agenten fullføre autorisert, reverserbart arbeid slik at du kan vurdere resultatet. Grip inn når neste handling krysser en grense, eller når videre arbeid avhenger av et uavklart krav.

Gjennomgå diffen og kjør relevante kontroller når arbeidet er ferdig. Registrer både agentens tid og din tid til forberedelse og gjennomgang. Observasjonene hjelper deg med å velge neste oppgave og forbedre arbeidsinstruksjonene.

Utvid én grense om gangen

Hvis øvelsen lykkes, øk én dimensjon av kompleksitet. Du kan gå fra én funksjon til to relaterte moduler. Du kan legge til en dokumentert integrasjon. Hold tillatelser og verifiseringskrav tydelige.

Hvis øvelsen mislykkes, identifiser årsaken før omfanget utvides. Manglende kontekst, uklare krav, utilgjengelig testmiljø og modellbegrensninger krever ulike rettelser. Mer autonomi løser ikke alle fire problemer.

Utpek en vedlikeholdsansvarlig hvis en prototype forblir i bruk. Ny sårbarhetsinformasjon kan kreve handling uten en kodeendring. Se kontinuerlig sårbarhetshåndtering.

Gjør øvelsen

Skriv tre mulige oppgaver. Angi resultat, verifiseringsmetode, tillatte data og gjenopprettingshandling for hver oppgave. Velg oppgaven med den tydeligste dokumentasjonen. Hvis ingen har en pålitelig kontroll, forbedre oppgavebeskrivelsen før du bruker en agent.

Last ned arbeidsark (Markdown)

Kontroller forståelsen din

Hvilken oppgave er den beste første øvelsen for et team som ikke har brukt kodeagenter før?

Kilder og videre lesning

Relatert lesning fra Taiga