AI Fluency for udviklere
For produktfolk, designere og udviklere, der ejer hele forløbet fra kundeproblem til løsning i produktion. To grundsætninger bærer denne udgave: Et første udkast til implementering er den største Delegation, der normalt betaler sig, og dømmekraft kan slet ikke delegeres. Og de fleste AI-fejl kan spores tilbage til fejl i Description, Discernment eller Diligence, der blev begået tidligere.
- Delegér første udkast til implementering op mod test, du selv definerer. Behold empati, dømmekraft og beslutningen om at sende i produktion
- Spor produktfejl tilbage gennem Description-kæden
- Evaluer kode gennem de fem linser, fra at køre den til vurdering med dømmekraft alene
- Kør Diligence-porten før produktionsættelse, før noget sendes i produktion
Velkommen og udviklerbriefen
Udviklere står i en usædvanlig position med AI: Den kan nu producere på minutter, hvad dit team tidligere brugte dage på, så den knappe færdighed er ikke længere at producere. Det er at vide, hvad der skal produceres, vurdere det, der blev produceret, og stå inde for det, der sendes i produktion.
Før alt andet skal du skrive et genbrugeligt kontekstdokument, som du kan indsætte i AI-samarbejder. Fire afsnit:
- Hvad du bygger, og for hvem.
- Din rolle, og hvad du personligt ejer.
- Begrænsninger, inklusive din stack og dine ufravigelige krav.
- Hvor AI er ønsket i din proces, og hvor den ikke er.
Fuldfør derefter sætningen: "Hvis AI kunne håndtere ___, kunne jeg bruge mere tid på ___." Den sætning er dit Delegation-kompas gennem hele kurset.
- Første udkast af implementering kan delegeres, målt mod tests du selv definerer først. Dømmekraft kan slet ikke delegeres.
- En skriftlig brief slår at forklare din verden igen i hver samtale.
De to sløjfer
De fire D'er organiseres i to sløjfer. Den indre sløjfe, Description og Discernment, guider dine daglige interaktioner: Fortæl AI'en, hvad du har brug for, vurder det, der kommer tilbage, og forfin. Den ydre sløjfe, Delegation og Diligence, guider de større beslutninger: om AI overhovedet hører hjemme i arbejdet, og hvordan du tager ansvar for resultatet.
Gå tilbage til din udviklerbrief, og markér hvert punkt med den kompetence, det træner. Den, der dukker oftest op, er der hvor din opmærksomhed allerede er rettet, og som regel der hvor du hurtigst vil se fremskridt.
- Indre sløjfe til det daglige, ydre sløjfe til om og hvor meget.
Kapaciteter og begrænsninger, udviklertest
Egenskaberne på maskinsiden (forudsigelse, viden, arbejdshukommelse, styrbarhed) gennemgås fuldt ud i AI's muligheder og begrænsninger. Her er, hvordan en udvikler tester dem på sin egen bane:
- Alsidighedstest. Bed AI'en forklare dit system på tre måder: til en produktchef, til en mellem-erfaren ingeniør, til en senior reviewer. Ændrede dybden sig faktisk, eller kun ordforrådet?
- Hallucinationstest. Bed den anbefale biblioteker til et reelt behov, og stikprøv derefter, at hvert bibliotek findes, at den API, den beskrev, er ægte, og at versionen er aktuel.
- Cutoff- og ræsonnementstest. Spørg om en nylig deprecation i din stack. Løste den forvirringen, eller gentog den bare svaret mere selvsikkert?
Kør det samme emne gennem et andet AI-værktøj, og sammenlign fejlmønstrene. Forskellige værktøjer fejler forskelligt, og at kende dine værktøjers vaner er platformforståelse i praksis.
- Test kapaciteter på dit eget system, ikke på legetøjseksempler.
- Biblioteksanbefalinger er et hotspot for hallucination: verificér eksistens, API og version.
Delegation og udviklerens værktøjskasse
Det forkerte spørgsmål er "skal jeg bruge AI her?" Det rigtige spørgsmål er "jeg har et kundeproblem; hvordan deler jeg det op, og hvilken rolle spiller AI i hver del?"
Tænk på det at bygge som seks kapaciteter, rangeret efter hvor AI er stærk:
- Empati. AI er svag her. Den kan fremhæve data og personaer, den kan ikke mærke afstanden mellem det, brugere siger, og det de mener.
- Design. AI hjælper, smagen forbliver din.
- Arkitektur. AI rådgiver godt, når du giver begrænsninger.
- Implementering. AI er stærkest her. Et første udkast til fungerende kode er den største Delegation, der normalt betaler sig, på én betingelse: Beslut, hvordan korrekt ser ud, før du spørger, og tjek det, der kommer tilbage, op imod det. Indsatsen ændrer svaret, og kode, der berører sikkerhed, penge eller persondata, kræver mere gennemgang, ikke mindre.
- Dømmekraft. Din. Hvad der skal bygges, om det er godt, om det sendes i produktion.
- Lancering. Dit ansvar: ansvarligheden kan ikke delegeres.
Skriv accepttest før kode. De giver dig og AI'en en fælles definition af færdigt. Og når AI accelererer implementering, flytter din værdi sig til at rammesætte problemer og hæve barren.
En lokal klinik ønsker, at patienter kan se forventede ventetider. Skriv bevidst ingen kode i denne lektion. Lav tre artefakter:
- En problembeskrivelse: hvilke patienter, hvilket resultat, hvordan føles fremragende?
- En delegationsplan, der kortlægger de seks kapaciteter i forhold til Automation, Augmentation eller Agency.
- Fem til syv accepttest, som en fremmed ville kunne verificere. "Viser ventetiden på under 30 sekunder uden at oprette en konto" er en test. "Nem at bruge" er ikke.
- AI står stærkest i midten af værktøjskassen. Empati, dømmekraft og levering forbliver menneskelige opgaver.
- Accepttest først: en fælles, verificerbar definition af, hvornår noget er færdigt.
Beskrivelseskæden
Prompt engineering er kun ét led i kæden. Den fulde kæde ser således ud: brugerens stemme → krav → teknisk specifikation → AI-instruktion, og udvikleren fungerer som oversætter i hvert eneste trin. AI kan ikke høre det, brugeren ikke sagde. Det var kun dig, der var i rummet.
Den efterfølgende diagnose: Kode, der virker, men et produkt, der ikke gør, skyldes en fejl i beskrivelsen. Find ud af, hvilket led der svigtede tidligere i forløbet. Blev kravet fejlfortolket ud fra brugerens stemme? Blev specifikationen fejlfortolket ud fra kravet? Blev prompten fejlfortolket ud fra specifikationen?
- Test er den mest præcise form for beskrivelse. En bestået test med en utilfreds bruger betyder, at du har beskrevet den forkerte hensigt.
- Hvert eneste adjektiv bør være en beslutning, du kan forsvare. Hvis du skriver "hurtig", så skriv, hvor hurtig.
Byg den mindste del af dit klinikprojekt med AI, og giv den derefter til en partner, der spiller patienten. Forklar ingenting. Hjælp ikke. Hvis dine testresultater og deres tilfredshed ikke stemmer overens, skal du følge kæden tilbage og finde det svage led.
- Brugerens stemme, krav, specifikation, instruktion: fire led, og du oversætter i hvert af dem.
- Adjektiver er beslutninger. Gør dem så vidt muligt til tal, der kan forsvares.
Discernment i kodning
Når AI kan skabe et fungerende produkt på få minutter, er det ikke længere nok, at det bare "virker". Evaluer ud fra fem vinkler, rangeret fra praktisk afprøvning til ren dømmekraft:
- Funktionel integritet. Virker det med rigtige data? Den typiske AI-fejl: koden består sine unit-test, men går i stykker ved data, som prompten aldrig tog højde for.
- Driftsklarhed. Fejlhåndtering, logning, ydeevne under belastning, sikkerhedsniveau.
- Problemmatch. Er dette overhovedet den rigtige løsning på det faktiske problem?
- Oplevelseskvalitet. Ville nogen have lyst til at bruge det? Noget, der er funktionelt, men forvirrende, langsomt eller klodset, er en fejl i oplevelseskvaliteten.
- Ansvarlig effekt. Hvem kan dette skade, udelukke eller vildlede?
AI har forudsigelige blinde vinkler inden for samtidighed, sikkerhed og alt det, der først går i stykker, når det skal skaleres. Og god smag er en udviklerkompetence: AI leverer det funktionelle, men det er op til dig at gøre det værd at bruge.
En tankevækkende overvejelse: Når resultatet ikke er godt nok, er din første indskydelse så at rette det selv eller at beskrive det bedre? Den anden indskydelse kan skaleres, det kan den første ikke.
AI-skrevet kode består alle unit-test, men går ned på den første dag med rigtige kundedata. Hvilken vinkel svigtede?
At bestå unit tests, men fejle på data, som prompten aldrig dækkede, er det klassiske AI-svigt i funktionel integritet. Virkelige input er den test, der tæller.
- Fem linser: funktionel integritet, driftsklarhed, problem-match, oplevelseskvalitet og ansvarlig effekt.
- Concurrency, sikkerhed og adfærd i stor skala er de faste blinde vinkler.
Discernment for brugeroplevelse
Når implementering går hurtigt, bliver oplevelsen det, der gør forskellen, og "få det til at se godt ud" er et ønske, ikke en specifikation. Vurder AI-genererede grænseflader ud fra fire principper:
- Klarhed. Forstår brugeren straks, hvad skærmen er til?
- Hierarki. Falder øjet først på det vigtigste?
- Tilgængelighed. AI rammer ikke tilgængelighed rigtigt som standard. Angiv det, og gennemgå derefter det, du får tilbage: kontrast, fokusrækkefølge, labels og tastaturveje.
- Feedback. Bliver hver handling synligt anerkendt?
Endnu en færdighed: en god kritik og en handlingsrettet AI-beskrivelse er to forskellige ting. "Hierarkiet er uklart" er en kritik. "Gør ventetiden til det største element, nedton klinikkens logo, og flyt opdateringshandlingen under folden" er en beskrivelse. Lær at oversætte mellem dem.
- Klarhed, hierarki, tilgængelighed, feedback: gennemgå alle fire i alt, der er AI-designet.
- Omsæt kritik til konkrete, handlingsrettede beskrivelser.
Stå inde for det, du bygger
Du ejer resultatet, ikke outputtet. "AI skrev det" forklarer ingenting og undskylder ingenting. Diligence for udviklere er en port, du går igennem, før noget bliver sendt ud:
- Forståelse. Kan du forklare, hvad det gør, ikke hvad det burde gøre?
- Test. Er edge cases afprøvet, ikke kun det nemme forløb?
- Adgang. Hvem bliver ikke betjent? Tjek, hvem dine antagelser udelukker, før du kalder noget sendt ud.
- Ansvar. Potentialet for misbrug er overvejet, og AI's rolle er oplyst, hvor det betyder noget.
- Feedback-sløjfe. Hvordan ved du, at det virker, efter det er sendt ud?
Derudover har shipping sit eget tekniske ordforråd: migrations, versionering, rate limits og feature flags, som AI ikke bringer frem, medmindre du beder om det. Lav prototyper frit, men send selektivt ud. Og den undervurderede færdighed, ingen lærer dig: at udfase dit eget arbejde ordentligt.
- Porten før deploy: forståelse, test, adgang, ansvar og feedback-sløjfe.
- Lav prototyper frit, men send selektivt ud.
Afslutning
AI er stærkest midt i værktøjskassen. Uddeleger første udkast til implementering ud fra test, du selv har fastlagt først. Behold empati, dømmekraft og shipping i dine egne hænder. Og husk, at de 4D'er er dynamiske, ikke en rækkefølge: at bevæge sig frit mellem dem, mens du bygger, er sådan fluency ser ud i praksis.
Vælg en opgave, der har ventet: en feature request, du har undgået, brugerfeedback, du ikke har sammenfattet, en specifikation, du ikke har skrevet, eller et hjørne af kodebasen, du er bange for at teste. Kør den gennem alle fire D'er i denne uge.
Kursustest
Kreditering. Tilpasset fra AI Fluency-kursusmaterialet, der er udviklet i samarbejde med Anthropic og CodePath, CC BY-NC-SA 4.0. Denne tilpasning © 2026 AI Literacy Foundation, delt under samme licens.