Gevinster:
- Evne til å forklare hvordan en kodeassistent fungerer som språkmodell og begrepene token, kontekstvindu, hallusinasjon
- Evne til å skille programvareoppgaver der AI er sterk og svak med et mentalt kart
- Evne til å bruke den grunnleggende arbeidssyklusen for å foreslå-produsere-verifisere på sine egne oppgaver
En programvareutviklers dag blir sjelden brukt på å "skrive kode fra bunnen av." Sanntid; Lese koden skrevet av noen andre, prøve å reprodusere en feil, skanning av loggen (logglinjer produsert av applikasjonen mens den kjører), skrive tester, skrive en PR (pull request - en sammenslåingsforespørsel hvor en kodeendring sendes inn for teamgjennomgang) forklaring og oppdatering av dokumentasjonen. Kunstig intelligens (AI) er en hastighetsmultiplikator som kan berøre nesten alle disse usynlige jobbene. Men den første betingelsen for å bruke det trygt er å forstå hva det er og hva det ikke er.
I denne enheten forklarer vi først den underliggende teknologien til en kodeassistent på klart språk; så lager vi et mentalt kart over modellens styrker og svakheter; Til slutt etablerer vi den grunnleggende arbeidsdisiplinen som vi skal bruke gjennom hele modulen: foreslå, produsere, verifisere. Disse tre trinnene er ryggraden i de neste elleve enhetene.
Merk: Denne modulen er en generell opplæring. I sikkerhetskritisk programvare (betalingsbehandling, helsetjenester, autentisering, kritisk infrastruktur) er AI-utdata ikke en erstatning for gjennomgang og godkjenning av en kvalifisert ingeniør. AI er en assistent; Underskriveren er ingeniøren.
Hva gjør egentlig en kodingsassistent?
De fleste kodeassistenter er bygget på en stor språkmodell (LLM – en AI trent på enorme mengder tekst og kode som forutsier den neste mest sannsynlige "biten"). Modellen «forstår» ikke koden som et menneske; Den genererer den mest sannsynlige fortsettelsen av konteksten du gir den, basert på mønstrene den lærer fra et stort utvalg eksempler. Denne tilsynelatende enkle mekanismen gir overraskende dyktige resultater i praksis - fordi det meste av programvare består av repeterende mønstre: en HTTP-forespørsel, en loop, en nullsjekk, et testmønster.
Tre termer er kritiske her. Token er den minste enheten som modellen behandler ved å dele teksten; Det er omtrent noen få bokstaver eller deler av et ord. Kontekstvinduet er mengden tokens modellen kan "se" på en gang; Din kode, feilmelding og instruksjon må passe inn i dette vinduet. En ledetekst er alle instruksjonene og konteksten du gir modellen. Kvaliteten på resultatet du får avhenger direkte av disse to: jo bedre kontekst og klarere instruksjoner du gir modellen, jo bedre resultat får du. Dårlig input produserer dårlig utgang, selv om det er en smart modell - den klassiske "søppel inn, søppel ut"-regelen for programvare gjelder også for AI.
Kart over styrker og svakheter
For å lede AI til de riktige jobbene, er det nødvendig å vite hvor den skinner og hvor den snubler. Å memorere dette kartet vil få deg til å lure på ved hvert neste oppdrag: "Skal jeg outsource denne jobben til AI eller gjøre det selv?" Den lar deg svare på spørsmålet på sekunder.
Dens styrker er: Generering av standardkode, oversetting fra ett språk til et annet, skriving av et regulært uttrykk (regex), beskrive en funksjon, lage et testskjelett, tolke en feilmelding, utarbeide dokumentasjon, foreslå variabel-/funksjonsnavn og mindre refaktoriseringer (forbedre strukturen til koden uten å endre oppførselen).
Svakheter: Kjenne til bedriftsspesifikke forretningsregler, huske hele kodebasen, faktisk kjøre og verifisere koden, vite de nyeste bibliotekversjonene med sikkerhet, oppdage sikkerhetssårbarheter med hundre prosent garanti. Det farligste er hallusinasjoner: modellen finner opp en ikke-eksisterende funksjon, bibliotek eller API (grensesnitt som muliggjør datautveksling mellom applikasjoner) på et svært overbevisende språk. Denne risikoen kan faktisk snus til din fordel, siden koden, i motsetning til ren tekst, kan testes for å se om den "fungerer" - bare ikke hopp over bekreftelsestrinnet.
Oppdragstype
Rollen til AI
manns rolle
Produsere kjele/skjelett
produserer utkast
Tilpasser, anmeldelser
Kodebeskrivelse
Gir en rask oppsummering
Verifiserer den kritiske delen i koden
skrive prøver
Case antyder
Bekrefter dekning og nøyaktighet
Sikkerhetskritisk logikk
nyttig idé
Beslutning og ansvar ligger utelukkende hos mennesker.
API/bibliotekbruk
Genererer prøve
Verifiserer eksistens og versjon
arkitektonisk beslutning
Slags alternativer
Velger og forsvarer å kjenne konteksten
Trinn for trinn: Grunnleggende arbeidssyklus
- Avklar oppgaven. Hvis du ikke kan skrive det du vil i én setning, kan heller ikke modellen. Jo tidligere usikkerhet siver inn i input, jo større vokser det i output.
- Gi kontekst. Legg til relevant kode, fullstendig feilmelding, språk-/rammeversjon og begrensninger i ledeteksten. Ikke si "fiks dette", si "Python 3.11, FastAPI 0.110; denne funksjonen gir en 500-feil, den eksploderer når forespørselsteksten er tom".
- Påleggsrolle og format. Et rammeverk som "Du er en senior Go-utvikler; bare gi koden og en begrunnelse med to setninger" fokuserer resultatet.
- Be om liten. Del det ned i trinn i stedet for én gigantisk forespørsel; Bekreft hvert trinn separat. Store endringer er risikable fordi de er vanskelige å verifisere og tilbøyelige til å skjule feil.
- Verifisere. Kjør den, test den, les den visuelt. Uverifisert AI-kode er en "skisse", ikke en "løsning". Dette er det mest ikke-omsettelige trinnet i syklusen.
Tre minivesker
Tilfelle 1 — Tidsbesparelsen er reell, men beskjeden. Når et team skjelettet nye CRUD-endepunkter (Create-Read-Update-Delete) med AI, sank tiden for første utkast fra omtrent 40 minutter til 8 minutter. Men med gjennomgang og testing var den totale tiden 25 minutter; så den reelle gevinsten er fra 40 til 25, omtrent 38 %. Denne raten, målt i stedet for forventningen om «vi har akselerert 10 ganger», er en bærekraftig gevinst.
Tilfelle 2 — Hallusinasjon er kostbart. En utvikler brukte AI-suggested requests.get_json()-kallet uten validering; Det fantes ingen slik metode (nøyaktig response.json()). 20 minutter gikk tapt da koden ikke kompilerte. En enkel "eksisterer denne metoden virkelig?" verifisering vil tilbakestille tapet.
Tilfelle 3 — God kontekst dobler produksjonen. For den samme feilen skrev en utvikler ganske enkelt "Jeg får en feil", og den andre la til hele stabelsporingen, versjonen og inndataeksemplet. Sistnevnte fikk riktig løsning på første forsøk; Den første brukte tre svinger. Forskjellen lå ikke i modellen, men i input.
Fire kopierbare maler
En generell, kraftig oppstartsmelding:
Rolle: Du er en erfaren {{language}}-utvikler. Oppgave: {{what_want}}Kontekst:- Rammeverk/versjon: {{framework_and_version}}- Begrensninger: {{ytelse, stil, avhengighetsregler}}Regler:- Ikke bruk ikke-eksisterende bibliotek/funksjon; Hvis du ikke er sikker, merk den som "bekreft". - Først, gi en kort plan, deretter koden, deretter 2 setninger med begrunnelse. - Produser testbar, fungerende kode.
Slik filtrerer du usikkerheten tilbake i modellen:
Før du løser oppgaven nedenfor, skriv MINST 3 punkter som du synes mangler eller er uklare som spørsmål. IKKE skriv kode før jeg svarer. Oppgave: {{oppgave}}
For å få utgangen selvsjekket:
Du har laget følgende kode. Endre nå rollen din og kritiser denne koden:- List opp 3 tilfeller (kanttilfeller) som kanskje ikke fungerer.- Er det noen APIer/funksjoner du kunne ha laget? Merk.- Gi korrigert versjon.Kode:{{code}}
For å dele opp en beslutning i alternativer:
Foreslå 2-3 løsningsmetoder for {{problem}}. For hver: kort beskrivelse, pluss/minus, når du skal velge. Gi i tabellform. IKKE velg for meg; bare avklar alternativet.
Svak forespørsel / Sterk forespørsel
Svak: "Fiks feilen i denne koden." (Hvilken feil? Hvilket språk? Hva er forventet oppførsel?)
Sterkt: "Python 3.11 / FastAPI 0.110. Følgende endepunkt returnerer 500 med KeyError når forespørselsteksten blir tom; Jeg vil at den skal returnere 400 og meningsfull melding på tom kropp. Forklar først årsaken, gi deretter den korrigerte funksjonen, og skriv deretter en test for dette scenariet. [kode]"
Kraftig versjon; Den gir språk, versjon, faktisk feil, forventet oppførsel og utdataformat. Modellen trenger ikke lenger å forutsi.
Vanlige feil
- Stoler på uten bekreftelse. Den vanligste og dyreste feilen. Ikke si "løst" før koden er kompilert og testet.
- Stille spørsmål uten kontekst. Svaret uten versjon, feiltekst og begrensninger er generisk og ofte feil.
- En stor forespørsel. Å ikke kunne be om og gjennomgå en produksjon på 300 linjer samtidig gjør feil usynlige.
- Å ta feil av modellens selvtillit som bevis. AI kan trygt si noe galt; Tone er ikke en indikator på nøyaktighet.
- Limer inn firmahemmeligheten tilfeldig. Private nøkler, kundedata eller privat kildekode skal ikke legges inn i ikke-godkjente verktøy (vi vil fordype oss i dette emnet i enhet 10).
Tips: Behandle hver AI-utgang som "dette er et utkast." Denne enkle mentale vanen eliminerer de fleste risikoene du vil se gjennom hele modulen.
Oppsummert
En kodeassistent er en språkmodell som forutsier det neste mest sannsynlige fragmentet; Den forstår ikke koden, den produserer mønstre. Det er derfor han er sterk i repeterende, formele jobber; Den bør brukes med forsiktighet for arbeid som krever verifisering som er spesifikk for din kontekst. Den største risikoen er hallusinasjoner, og den eneste motgiften er verifisering. Disiplinen vi skal følge gjennom hele modulen er tydelig: klargjør oppgaven, gi kontekst, be om små, valider hver leveranse.
Søknadsoppgave
Skriv ned tre programvareoppgaver du gjorde den siste uken (f.eks. en feilretting, en test, en README-oppdatering). Se på "styrker og svakheter-kartet" for hver og beskriv i én setning hva din og AI-ens rolle ville vært hvis du fikk AI-en til å gjøre dette. Gi deretter en av disse oppgavene til AI med "start-prompt"-malen ovenfor og kjør og verifiser utdataene; Legg merke til hvor mange minutter du sparte og hvor mange feil du måtte fikse.
sjekkliste
- [ ] Jeg innså at LLM produserer mønstre, ikke "forstår" kode.
- [ ] Jeg kan forklare begrepene token, kontekstvindu og ledetekst i én setning.
- [ ] Jeg kan skille mellom typer oppgaver der AI er sterk og svak.
- [ ] Jeg vet hva en hallusinasjon er, og den eneste motgiften er bekreftelse.
- [ ] Jeg tilpasset "foreslå, produsere, verifisere"-syklusen til min egen oppgave.
- [ ] Jeg kan vise forskjellen mellom en sterk forespørsel og en svak forespørsel i et konkret eksempel.