Domänkunskap multiplicerar AI-output — varför samma verktyg ger dramatiskt olika resultat
Experimentet som gjorde det synligt
Sjutton utvecklare, en uppgift: visualisera sjukfrånvarodata från en CSV-fil med AI-verktyg, valfri teknikstack, 90 minuter.
Samma data. Samma tillgängliga verktyg. Samma generella instruktioner. Observationen gjordes med utvecklare, men mönstret det avslöjar gäller i alla professionella sammanhang där domänexpertis möter AI-verktyg — analytiker, konsulter, dokumentprofessionella, alla som arbetar med AI på problem med verkliga begränsningar.
En grupp producerade en visualisering med full WCAG-tillgänglighetsefterlevnad — testad med Wave och Lighthouse, noll fel. En annan grupp producerade en visualisering helt utan tillgänglighetshänsyn. Båda grupperna använde Python och Flask. Båda fick fungerande output.
Skillnaden: den första gruppen inkluderade tillgänglighet och offentlig sektors krav i sin kontext. De nämnde, tidigt i sin första prompt, att deras produkt används i offentliga miljöer där tillgänglighet är ett krav. Den andra gruppen beskrev data och visualiseringsmålet, men nämnde inte tillgänglighet.
AI frågade inte. AI kan inte fråga om krav den inte vet existerar. Den första gruppens domänkunskap formade deras initiala prompt. Den andra gruppens initiala prompt beskrev uppgiften bokstavligen.
Samma verktyg. Dramatiskt olika output. Domänkunskap var variabeln.
Säsongsmönstret som dök upp av sig självt
En separat grupp — med design och UX-bakgrund — startade sin session annorlunda. Innan de skrev någon kod lät de AI analysera CSV-datan för att förstå dess struktur. De beskrev sin kontext: deras organisation bygger system för arbetsmiljö och hälsa, deras användare följer sjukfrånvarotrender, deras intressenter bryr sig om organisatoriska mönster.
AI rekommenderade att visualisera säsongsmönster i sjukfrånvarodata.
Ingen annan grupp fick den rekommendationen. Ingen annan grupp bad om den. Den fanns inte i uppgiftsbeskrivningen.
Gruppen hade beskrivit sin affärskontext — vad datan betyder, vem som använder den, vilka beslut den informerar. AI använde den kontexten för att rekommendera ett visualiseringsupplägg som skulle vara mer värdefullt för de faktiska användarna av systemet.
Utan kontexten optimerade AI för uppgiften som angiven: visualisera datan. Med kontexten optimerade AI för målet bakom uppgiften: ge användarna användbar insikt.
Det är inte magi. Det är kontextfönstret som fungerar korrekt. Den information du tillhandahåller avgör optimeringsmålet.
Varför det inte handlar om prompt engineering
Resonemanget att "domänkunskap spelar roll" översätts ofta till "bättre prompts spelar roll" — och sedan till "lär dig prompt engineering-tekniker."
Det resonemanget missar poängen.
Prompt engineering-tekniker — chain-of-thought, few-shot-exempel, strukturerad outputformatering — är användbara. Men de är tekniker för att extrahera bättre beteende från en modell givet en uppgift. De förändrar inte vilken uppgift du ger.
Tillgänglighetsexemplet handlar inte om promptstruktur. Det handlar om att veta att tillgänglighet är ett krav överhuvudtaget. En utvecklare som inte vet att offentliga gränssnitt kräver WCAG-efterlevnad kan inte prompta för det, oavsett hur avancerad deras promptteknik är. De känner inte till att kravet existerar.
Domänkunskap är den information som formar vad du ber om. Promptteknik formar hur du ber om det. Det första är viktigare än det andra.
Seniorutvecklarens fördel, konkretiserat
Det finns en vanlig oro i utvecklingsteam som adopterar AI-verktyg: att juniora utvecklare med AI-stöd kommer att komma ikapp seniora utvecklare och radera värdet av ackumulerad erfarenhet.
Tillgänglighets- och säsongsmönsterobservationerna pekar i en annan riktning.
Seniora utvecklare bär domänkunskap som formar varje prompt de skriver — inte för att de explicit resonerar om vad de ska inkludera, utan för att deras mentala modell av problemrymden naturligt omfattar krav, begränsningar och kantfall som juniora utvecklare ännu inte stött på.
När en senior utvecklare beskriver en uppgift för ett AI-verktyg inkluderar de den här kontexten implicit. "Bygg ett formulär som hanterar det här flödet" från en senior utvecklare inkluderar antaganden om felhantering, tillgänglighet, kantfall i datan, efterlevnadskrav — även när inget av dessa ord syns i prompten.
Samma prompt från en junior utvecklare är troligare en bokstavlig beskrivning av den synliga uppgiften. Outputen reflekterar vad som frågades, inte vad som behövdes.
AI fyller inte i det som saknas. Den optimerar för vad den gavs. Domänexpertis är källan till de specifikationer som formar den optimeringen.
38-stegsregeln
En observation från sessionen: AI förändrade inte antalet valideringssteg som en process kräver. Om din manuella process har 38 valideringssteg — kontrollera datakvalitet, verifiera kantfall, bekräfta output mot kända värden — är de fortfarande 38 steg med AI-stöd.
Vad som förändrades: vem som skriver koden som implementerar de stegen. AI kan skriva den koden snabbare än en människa. Men att veta att 38 steg krävs, veta vilka de är, veta vilka fel i varje steg som indikerar verkliga problem kontra acceptabel varians — den kunskapen måste komma någonstans ifrån. Den kommer från domänexpertis.
Processen förändras inte. Den som kodar förändras. Domänexperten som känner till processen blir mer produktiv, inte mindre nödvändig.
En utvecklare utan domänexpertis som använder AI-verktyg producerar kod som saknar steg de inte visste krävdes. Upptäckten sker i produktion. Det är det scenariot som producerar slutsatsen "AI-genererad kod är opålitlig" — och slutsatsen är fel. Processen är opålitlig. Domänkunskapen saknades i kontexten. AI gjorde vad den ombads att göra.
Praktisk implikation: behandla kontext som investering, inte overhead
Innan ett signifikant AI-assisterat arbetspass, lägg tid på att bygga den kontext som formar outputen:
Domänkrav: Vilka begränsningar gäller som inte syns i uppgiftsbeskrivningen? Efterlevnadskrav, prestandabudgetar, användargruppegenskaper, integrationsbegränsningar.
Affärskontext: Vilket beslut stödjer den här funktionen? Hur ser framgång ut för användaren, inte bara för outputen? Vad skulle göra det mer värdefullt än tekniskt korrekt?
Historisk kontext: Vad har prövats tidigare och varför fungerade det inte? Vilka kantfall hanterar den befintliga processen på icke-uppenbara sätt?
Det här är inte overhead. Det är det arbete som avgör om AI-stöd producerar bra output eller generisk output. Tiden som läggs på att bygga kontext återvinns nästan alltid i den första genereringen — för att outputen kräver färre revideringsrundor.
De yrkesverksamma som rapporterar störst produktivitetsvinster från AI-verktyg är, konsekvent, de som investerar i kontext. De som rapporterar frustration med AI-outputkvalitet är, konsekvent, de som beskriver uppgiften bokstavligen och förväntar sig att AI ska sluta sig till de krav de inte angav.