Gevinster:
- Evne til å skrive funksjoner, klasser og moduler til AI med klare input-output og begrensningsdefinisjoner
- Evne til å bruke AI som en parprogrammeringspartner og fremgang steg for steg, i små, verifiserbare biter
- Evne til å fange opp logikk- og kantfeil ved å kompilere koden generert av AI og kjøre den med små eksempler
Parprogrammering er når to utviklere jobber med det samme problemet, hvor den ene skriver og den andre reviderer. Koding med AI er den digitale versjonen av nettopp dette forholdet: du setter retningen, begrensningene og akseptkriteriene; AI produserer raskt utkast; Du bekrefter hvert trinn ved å kompilere og teste det. Den største fellen her er å fortelle AI-en "skriv meg denne applikasjonen fra start til slutt" og blindt godta en 200-linjers blokk. God parprogrammering foregår i små trinn: hvert trinn skal være forståelig, testbart og reversibelt.
I denne enheten lærer du hvordan du skriver ut funksjoner, klasser og moduler med en tydelig input-output kontrakt; Hvordan veilede AI steg for steg; og vi skal se hvordan du fanger opp logikk- og kantfeil ved å kjøre koden den produserer med små eksempler. Målet er ikke hastighet, men verifisert hastighet.
Konsepter: Input-output kontrakt: En klar definisjon av hvilke input en funksjon tar og hvilken utgang og feilatferd den lover. Edge case: Inndata som ikke er vanlig, men som faktisk kan forekomme (tom, null, negativ, veldig stor, null). Inkrementell utvikling: Fortsetter med små, arbeidsstykker og validerer hvert trinn.
Utskriftskode med nettkontrakt
Grunnlaget for kvalitetskoden er å definere nøyaktig «hva du vil ha» før du starter arbeidet. Når du skriver en funksjon til AI, gi den fem ting: språk og versjon, inputtyper og betydninger, utdata, feiltilstander og begrensninger (ytelse, eksternt bibliotekforbud, stil). Dette forhindrer AI fra å gjette.
- Skriv kontrakten. Input, output, error, constraint.
- Be om en liten enhet. En funksjon med ett enkelt ansvar; Det er ikke en stor modul.
- Be om en testblokk. Legg til noen prøvekjøringer/tester ved siden av koden.
- Kompiler og kjør. Prøv det med kantsaker, verifiser resultatet med øyet.
- Gå til neste trinn. Når et stykke er bekreftet, bygg på det.
Contracted function prompt: "Skriv en funksjon for TypeScript 5. Formål: beregne total mengde varer i en handlekurv. Input: { price: number, quantity: number }[] array. Output: number (total). Regler: kast Feil hvis mengde eller pris er negativ; return 0 for tom array; avrund feil plasser til 2 Ikke bruk desimaler. 5 testtilfeller under funksjonen (normal, tom, negativ mengde, desimalpris, enkelt vare).
Veileder AI som et par
God fremgang i parprogrammering er en dialog snarere enn en stor forespørsel. Først, be om skjelettet og kjør det; legg deretter til en kanttilstand; så får du fikset en feil. Denne tilnærmingen holder koden forståelig og gir deg kontroll på hvert trinn.
Inkrementell fremdriftsmelding: "Vi vil skrive en leser som leser en CSV-fil og konverterer linjene til et objekt. La oss gå STEG FOR TRINN, og gå videre til neste trinn uten at jeg bekrefter hvert trinn. Trinn 1: bare skriv skjelettet som deler filen i linjer og skiller overskriftslinjen. Ikke legg til typekonvertering eller feilhåndtering ennå."
Forklar og begrunn kodeoppfordringen: "Forklar funksjonen du nettopp skrev, ikke linje for linje, men beslutning for beslutning: hvilken designbeslutning du tok og hvorfor, hvilken kantsak du håndterte og hvordan, hvilke saker du bevisst ekskluderte? Skriv opp 3 antakelser i koden som jeg ikke bør gå glipp av."
Tips: Ikke godta den AI-genererte koden uten å forstå den. "Forklar dette for meg, hvilke antakelser gjorde du?" Spørsmålet avslører både skjulte feil og lar deg forsvare den koden, siden koden forblir ditt ansvar. Å sette kode du ikke forstår i produksjon er som å sende ut en kontrakt uten å signere den.
Svak forespørsel / sterk forespørsel
SVAK:"Skriv en sorteringsfunksjon."(Resultat: hvilket språk, hva som sorteres, er det stabilt, hva er ytelsesbegrensningen, kode som er vag og som sannsynligvis ikke passer til kravet.)STERK:"For Java 17, skriv en metode som sorterer et List<Ansatt>-objekt først etter avdeling (alfabetisk), deretter etter lønn (IKKE returnerer den nye avdelingen, skal ikke returnere den nye avdelingen). sist. Forklar kompleksiteten til metoden i kommentarlinjen, legg til en hovedtestblokk med 4 prøver.
Kraftig ledetekst; Inkluderer sorteringskriterium (to-nivå), bivirkningsregel (erstatter original), nulladferd og testforventning. Uten disse detaljene produserer AI en plausibel, men feil løsning; for eksempel kan det ødelegge den opprinnelige listen, og dette vil føre til en stille feil andre steder.
Validering med Edge Cases og Small Samples
Koden som fungerer i det lykkelige scenarioet er ikke den riktige koden. Tving bevisst frem hver funksjon som produseres:
Kantkassetype
eksempelinngang
forventet oppførsel
tom inngang
Tom array/streng
Ikke en feil, logisk tomt resultat
Null/negativ
0, -1
Definert og riktig oppførsel
stor verdi
Millioner av rekorder
Overløp/ytelseskontroll
null/udefinert
manglende plass
Kontrollert feil eller standard
Duplikat/uvanlig
repeterende, omvendt rekkefølge
riktig resultat
Minivesker
Tilfelle 1 — Stille avrundingsfeil. AI skriver en funksjon som samler inn penger med desimaltyper (float); 0,1 + 0,2 gir 0,300000000000000004. Feilen løses når ingeniøren legger til regelen "Rund av til 2 siffer og bruk hele pennies". En 3-linjers regel forhindrer tusenvis av pennies av variasjon i den månedlige avstemmingen.
Tilfelle 2 — Bivirkningsfelle. AI skriver en metode som "sorterer" en liste, men endrer den opprinnelige listen på plass. Uventet oppførsel oppstår fordi en annen modul bruker den samme listen. Hvis "endre original"-begrensningen var i ledeteksten, ville feilen aldri oppstå; blir fanget i kodegjennomgang og forhindrer 2 timers feilsøking.
Tilfelle 3 — Inntjening trinn for trinn. En utvikler skriver ut en 150-linjers importmodul på en gang; Når han finner en feil, kan han ikke finne hvor den kom fra. En annen utvikler deler det samme arbeidet i 5 små trinn, tester hvert trinn på 2 minutter og fanger opp feilen umiddelbart i 3. trinn.
Vanlige feil
- Utskrift av store blokker på én forespørsel. Risikofylt kode som er vanskelig å forstå og feilsøking er født.
- Be om en kode uten å gi en kontrakt. Hvis input-output-error er tvetydig, vil AI gjette og ta feil.
- Bare tester det lykkelige scenarioet. Hvis tomt, null, negativ og stor input ikke prøves, overlates feilen til produksjon.
- Godta uten å forstå. Koden du ikke oppgir er en gjeld du ikke kan forsvare.
- Ignorerer sensitive typer som bivirkninger og penger/dato. Float-penger med tidløs historie er en klassisk feilkilde.
Oppsummert
Å skrive kode med AI er disiplinert parprogrammering: klar kontrakt, små trinn, bygg og test på hvert trinn. Å gi input-output-error-constraint-kvartetten fra begynnelsen bestemmer kvaliteten på koden. Å forklare koden den produserer og tvinge den med kantsaker bringer til overflaten feilene som er skjult under det lykkelige scenariet. Kilden til fart er ikke blind aksept; er hurtigutkast pluss rask verifisering.
Søknadsoppgave
Velg en liten, men reell funksjon (f.eks. kurvtotal, datoforskjell, tekstparsing). Skriv ut ved å bruke den avtalte funksjonsprompten; Legg til minst 5 testscenarier ved siden av. Kjør koden og prøv 5 kantsaker bevisst, bruk tabellen som en guide. Finn en feil i minst ett kanttilfelle (hvis ikke, design en ny inngang for å tvinge funksjonen), fiks den med AI, og bekreft ved å teste på nytt at reparasjonen fungerte.
sjekkliste
- [ ] Jeg skrev en kontrakt som inkluderer input, output, feil og begrensninger.
- [ ] Jeg genererte koden i små trinn i stedet for en stor blokk.
- [ ] Jeg la til en test-/prøvekjøringsblokk ved siden av koden.
- [ ] Jeg har bevisst testet minst 5 kantsaker.
- [ ] Jeg forklarte koden til AI og gjennomgikk dens antakelser.
- [ ] Jeg rettet feilen som ble funnet og bekreftet rettelsen ved å teste på nytt.