En kontroll som svarar olika är ingen kontroll
I en offert jag läste i somras låg tillgänglighetskontrollen som modellarbete. Varje gång en utvecklare skickar in en kodändring skulle en språkmodell granska att sidan uppfyller kraven, och det var prissatt med tokenkostnad.
Momentet i sig är rätt tänkt. Att kontrollera tillgänglighet automatiskt vid varje ändring är precis vad man ska göra i stället för att upptäcka bristerna vid en granskning tre månader senare.
Men det har funnits verktyg för exakt det i tio år. De är gratis, de är etablerade, och ger samma svar varje gång.
Det sista är inte en detalj. Det är hela poängen.
Vad en spärr är till för
En kontroll i byggkedjan finns för att stoppa något. Den ska säga ja eller nej. Och den ska säga samma sak i morgon som i dag om koden är oförändrad.
En språkmodell kan svara olika på samma fråga två gånger. Inte ofta, inte dramatiskt, men tillräckligt för att en spärr ska sluta vara en spärr. Den blir en åsikt som yttras vid varje ändring.
Och konsekvensen är värre än att den kostar pengar. Ett team som ser spärren fälla en ändring som gick igenom i går slutar lita på den. Då stängs den av, eller så förbigås den rutinmässigt. Kontrollen finns kvar i dokumentationen och inte i verkligheten.
Det är därför den här punkten inte är en prisfråga. Den är en fråga om att momentet inte blir gjort.
Var gränsen faktiskt går
Gränsen är inte mellan viktigt och oviktigt, eller mellan svårt och enkelt. Den går vid om innehållet är genuint tvetydigt.
Är det tvetydigt behövs bedömning. Gammalt ostrukturerat material som ska tolkas om till nya komponenter. Översättning där tonen ska bära över. Kvalitetsgranskning av innehåll där någon måste avgöra om det håller.
Är det inte tvetydigt behövs en regel. Spärrar i bygget. Automatiska kontroller som ska fungera som grind. Ren strukturell flytt av data från en struktur till en annan.
Det sista är värt att stanna vid, för det är oftast den dyraste posten i en migreringsoffert.
Migreringen som exempel
En 1:1-migrering är per definition deterministisk. Innehåll ska flyttas från struktur A till struktur B utan att förändras. Det är en mappning. Man skriver den en gång, kör den, och kostnaden per objekt är i princip noll.
En modell behövs bara där mappningen inte räcker. Där det gamla materialet är fritext som ska bli komponenter, eller där någon måste avgöra vad ett fält egentligen innehöll.
Så frågan är inte om migreringen ska köras med AI. Den är hur många objekt det handlar om totalt, och hur många av dem som behöver passera en modell.
Är svaret att alla ska det, då är upplägget dyrare än det behöver vara. Är svaret fyrahundra av tolvtusen, då är det trovärdigt. Då går kostnaden att räkna per objekt i stället för per natt, vilket är en helt annan sorts siffra att förhålla sig till.
Varför det ändå hamnar där
Jag tror inte att någon lägger in modellarbete där det inte behövs för att det ska bli dyrare. Det händer för att metoden är ny och entusiasmen är verklig.
När man just har sett vad en modell klarar av är det naturligt att räkna med den överallt. Den kan ju granska tillgänglighet. Den kan ju flytta innehåll. Det stämmer, och det är fortfarande fel verktyg för de momenten.
Det är inte okunskap om AI. Det är att den äldre kunskapen, om när determinism är ett krav, inte har hunnit möta den nyare.
Frågan att ställa
Två meningar räcker.
Vilka moment kräver bedömning, och varför just de? Och vad i den här kontrollen gör att den inte kan köras med ett verktyg som ger samma svar varje gång?
Ett bra svar skiljer på de två sorternas arbete och motiverar varje moment för sig. Ett svagt svar beskriver hela leveransen som AI-driven, som om det vore en egenskap hos projektet i stället för ett val per uppgift.
Skillnaden mellan de två svaren säger mer om leverantören än någon prisrad gör.
Se även: Agenttimmen är ingen enhet (serie 55) och Någon ska läsa det på morgonen (serie 57).