Gevinster:
- Evne til at forklare, hvordan en kodningsassistent fungerer som sprogmodel og begreberne token, kontekstvindue, hallucination
- Evne til at skelne mellem softwareopgaver, hvor AI er stærk og svag, med et mentalt kort
- Evne til at anvende den grundlæggende arbejdscyklus af foreslå-producer-bekræfte til deres egne opgaver
En softwareudviklers dag bruges sjældent på at "skrive kode fra bunden". Realtid; Læsning af koden skrevet af en anden, forsøg på at reproducere en fejl, scanning af loggen (log linjer produceret af applikationen, mens applikationen kører), skrivning af tests, skrivning af en PR (pull request - en fletteanmodning, hvor en kodeændring sendes til teamgennemgang) forklaring og opdatering af dokumentationen. Kunstig intelligens (AI) er en hastighedsmultiplikator, der kan berøre næsten alle disse usete job. Men den første betingelse for at bruge det sikkert er at forstå, hvad det er, og hvad det ikke er.
I denne enhed forklarer vi først den underliggende teknologi for en kodningsassistent i almindeligt sprog; så laver vi et mentalt kort over modellens styrker og svagheder; Til sidst etablerer vi den grundlæggende arbejdsdisciplin, som vi vil bruge gennem hele modulet: foreslå, producere, verificere. Disse tre trin er rygraden i de næste elleve enheder.
Bemærk: Dette modul er en generel uddannelse. I sikkerhedskritisk software (betalingsbehandling, sundhedspleje, autentificering, kritisk infrastruktur) er AI-output ikke en erstatning for gennemgang og godkendelse af en kvalificeret ingeniør. AI er en assistent; Underskriveren er ingeniøren.
Hvad gør en kodningsassistent egentlig?
De fleste kodningsassistenter er bygget på en stor sprogmodel (LLM - en kunstig intelligens, der er trænet i enorme mængder tekst og kode, der forudsiger den næstmest sandsynlige "chunk"). Modellen "forstår" ikke koden som et menneske; Den genererer den mest sandsynlige fortsættelse af den kontekst, du giver den, baseret på de mønstre, den lærer fra en enorm pulje af eksempler. Denne tilsyneladende enkle mekanisme giver overraskende dygtige resultater i praksis - fordi det meste software består af gentagne mønstre: en HTTP-anmodning, en løkke, en nulkontrol, et testmønster.
Tre termer er kritiske her. Token er den mindste enhed, som modellen behandler ved at dividere teksten; Det er groft sagt nogle få bogstaver eller en del af et ord. Kontekstvinduet er mængden af tokens, som modellen kan "se" på én gang; Din kode, fejlmeddelelse og instruktion skal passe ind i dette vindue. En prompt er alle de instruktioner og kontekst, du giver til modellen. Kvaliteten af det output, du får, afhænger direkte af disse to: Jo bedre kontekst og klarere instruktioner du giver modellen, jo bedre resultat får du. Dårligt input producerer dårligt output, selvom det er en smart model - den klassiske "skrald ind, skrald ud" regel for software gælder også for AI.
Kort over styrker og svagheder
For at lede AI til de rigtige job er det nødvendigt at vide, hvor det skinner, og hvor det snubler. At huske dette kort vil få dig til at undre dig med hver næste mission: "Skal jeg outsource dette job til AI'en eller gøre det selv?" Det giver dig mulighed for at besvare spørgsmålet på få sekunder.
Dens styrker er: Generering af boilerplate-kode, oversættelse fra et sprog til et andet, skrivning af et regulært udtryk (regex), beskrivelse af en funktion, oprettelse af et testskelet, fortolkning af en fejlmeddelelse, udarbejdelse af dokumentation, forslag til variabel-/funktionsnavne og mindre refactorings (forbedring af kodens struktur uden at ændre dens adfærd).
Svagheder: At kende dine virksomhedsspecifikke forretningsregler, huske hele din kodebase, faktisk køre og verificere koden, at kende de nyeste biblioteksversioner med sikkerhed, opdage sikkerhedssårbarheder med hundrede procent garanti. Det farligste er hallucination: Modellen opfinder en ikke-eksisterende funktion, bibliotek eller API (grænseflade, der muliggør dataudveksling mellem applikationer) i et meget overbevisende sprog. Denne risiko kan faktisk vendes til din fordel, da koden, i modsætning til almindelig tekst, kan testes for at se, om den "virker" - du skal bare ikke springe bekræftelsestrinnet over.
Missionstype
AI's rolle
mands rolle
Fremstil kedelplade/skelet
producerer udkast
Tilpasser sig, anmeldelser
Kodebeskrivelse
Giver en hurtig opsummering
Verificerer den kritiske del i koden
at skrive prøver
Sagen foreslår
Bekræfter dækning og nøjagtighed
Sikkerhedskritisk logik
nyttig idé
Beslutning og ansvar påhviler udelukkende mennesker.
API/bibliotek brug
Generer prøve
Verificerer eksistens og version
arkitektonisk beslutning
Slags muligheder
Udvælger og forsvarer at kende konteksten
Trin for trin: Grundlæggende arbejdscyklus
- Afklar opgaven. Hvis du ikke kan skrive, hvad du vil i én sætning, kan modellen heller ikke. Jo tidligere usikkerhed siver ind i inputtet, jo større vokser det i outputtet.
- Giv kontekst. Tilføj den relevante kode, fuld fejlmeddelelse, sprog-/rammeversion og begrænsninger til prompten. Sig ikke "fix dette", sig "Python 3.11, FastAPI 0.110; denne funktion giver en 500 fejl, den eksploderer, når forespørgselsteksten er tom".
- Pålægsrolle og format. En ramme som "Du er en senior Go-udvikler; giv bare koden og en begrundelse med to sætninger" fokuserer outputtet.
- Spørg efter små. Opdel det i trin i stedet for én kæmpe anmodning; Bekræft hvert trin separat. Større ændringer er risikable, fordi de er svære at verificere og tilbøjelige til at skjule fejl.
- Verificere. Kør det, test det, læs det visuelt. Uverificeret AI-kode er en "skitse", ikke en "løsning". Dette er det mest uomsættelige trin i cyklussen.
Tre mini etuier
Case 1 — Tidsbesparelserne er reelle, men beskedne. Da et hold skelet til nye CRUD-slutpunkter (Create-Read-Update-Delete) med AI, faldt tiden for første udkast fra cirka 40 minutter til 8 minutter. Men med gennemgang og test var den samlede tid 25 minutter; så den reelle gevinst er fra 40 til 25, omkring 38%. Denne hastighed, målt i stedet for forventningen om "vi har accelereret 10 gange", er en bæredygtig gevinst.
Tilfælde 2 — Hallucination er dyrt. En udvikler brugte AI-suggested requests.get_json()-kaldet uden validering; Der var ingen sådan metode (præcis response.json()). 20 minutter gik tabt, da koden ikke kompilerede. Et simpelt "eksisterer denne metode virkelig?" verifikation ville nulstille tabet.
Case 3 — God kontekst fordobler output. For den samme fejl skrev en udvikler simpelthen "Jeg får en fejl", og den anden tilføjede den fulde stak-sporing, version og input-eksempel. Sidstnævnte fik den rigtige løsning i første forsøg; Den første brugte tre omgange. Forskellen lå ikke i modellen, men i inputtet.
Fire kopierbare skabeloner
En generel, kraftfuld opstartsprompt:
Rolle: Du er en erfaren {{language}} udvikler. Opgave: {{what_want}}Kontekst:- Ramme/version: {{framework_and_version}}- Begrænsninger: {{performance, style, dependency rules}}Regler:- Brug ikke ikke-eksisterende bibliotek/funktion; Hvis du ikke er sikker, skal du markere det som "bekræft". - Først skal du give en kort plan, derefter koden og derefter 2 begrundelsessætninger. - Fremstil testbar, fungerende kode.
Sådan filtrerer du usikkerheden tilbage i modellen:
Inden du løser opgaven nedenfor, skal du angive MINDST 3 punkter, som du synes mangler eller er uklare som spørgsmål. skriv IKKE kode, før jeg svarer.Opgave: {{opgave}}
For at få outputtet selvkontrolleret:
Du har lavet følgende kode. Skift nu din rolle og kritiser denne kode:- List 3 cases (kantsager), der måske ikke virker.- Er der nogen API'er/funktioner, du kunne have lavet? Mark.- Giv rettet version.Kode:{{code}}
Sådan opdeles en beslutning i muligheder:
Foreslå 2-3 løsninger til {{problem}}. For hver: kort beskrivelse, plus/minus, hvornår man skal vælge. Giv i tabelform. Vælg IKKE for mig; blot afklare muligheden.
Svag prompt / Stærk prompt
Svag: "Ret fejlen i denne kode." (Hvilken fejl? Hvilket sprog? Hvad er den forventede adfærd?)
Stærk: "Python 3.11 / FastAPI 0.110. Følgende slutpunkt returnerer 500 med KeyError, når forespørgselsteksten bliver tom; Jeg vil have, at den returnerer 400 og meningsfuld besked på tom krop. Forklar først årsagen, giv derefter den rettede funktion, og skriv derefter en test for dette scenarie. [kode]"
Kraftig version; Det giver sprog, version, faktisk fejl, forventet adfærd og outputformat. Modellen behøver ikke længere at forudsige.
Almindelige fejl
- Tillid uden bekræftelse. Den mest almindelige og dyreste fejl. Sig ikke "løst", før koden er kompileret og testet.
- At stille spørgsmål uden kontekst. Svaret uden version, fejltekst og begrænsninger er generisk og ofte forkert.
- En kæmpe anmodning. Ikke at kunne anmode om og gennemgå en 300-linjers produktion på én gang gør fejl usynlige.
- Forveksler modellens selvtillid som bevis. AI kan trygt sige noget forkert; Tone er ikke en indikator for nøjagtighed.
- Tilfældig indsættelse af firmahemmeligheden. Private nøgler, kundedata eller privat kildekode bør ikke indtastes i ikke-godkendte værktøjer (vi vil dykke ned i dette emne i enhed 10).
Tip: Behandl hvert AI-output som "dette er et udkast." Denne enkelte mentale vane udrydder de fleste af de risici, du vil se gennem hele modulet.
Sammenfattende
En kodningsassistent er en sprogmodel, der forudsiger det næstmest sandsynlige fragment; Den forstår ikke koden, den producerer mønstre. Det er derfor, han er stærk i gentagne, formelle job; Det bør bruges med forsigtighed til arbejde, der kræver verifikation, der er specifik for din kontekst. Den største risiko er hallucinationer, og den eneste modgift er verifikation. Den disciplin, vi vil følge gennem hele modulet, er klar: afklar opgaven, giv kontekst, spørg efter småt, valider hver leverance.
Ansøgningsopgave
Skriv tre softwareopgaver ned, du har udført i den sidste uge (f.eks. en fejlrettelse, en test, en README-opdatering). Se på "styrker og svagheder kortet" for hver og beskriv i én sætning, hvad din og AI's rolle ville være, hvis du fik AI'en til at gøre dette. Giv derefter en af disse opgaver til AI med "start-prompt"-skabelonen ovenfor, og kør og bekræft outputtet; Bemærk, hvor mange minutter du har sparet, og hvor mange fejl du skulle rette.
tjekliste
- [ ] Jeg indså, at LLM producerer mønstre, ikke "forstår" kode.
- [ ] Jeg kan forklare begreberne token, kontekstvindue og prompt i én sætning.
- [ ] Jeg kan skelne mellem typer af opgaver, hvor AI er stærk og svag.
- [ ] Jeg ved, hvad en hallucination er, og den eneste modgift er verifikation.
- [ ] Jeg tilpassede "foreslå, fremstille, verificere"-cyklussen til min egen opgave.
- [ ] Jeg kan vise forskellen mellem en stærk prompt og en svag prompt i et konkret eksempel.