En specifikationsmall som faktiskt fungerar

En bra AI-specifikation är inte en begäran om kommentarer (RFC). Det är ett verktyg som gör avvikelser dyra och korrekthet billig. Osmanis rekommendation är att börja med en kortfattad produktbeskrivning, låta agenten utarbeta en mer detaljerad specifikation och sedan korrigera den till en levande referens som du kan återanvända mellan sessionerna. Det är bra, men det verkliga värdet kommer från de specifika komponenterna du inkluderar. Baserat på Osmanis arbete och mina egna observationer av framgångsrika team måste en funktionell AI-specifikation innehålla några icke-förhandlingsbara element.

För det första behöver du mål och icke-mål. Det räcker inte att skriva ett stycke om målet. Du måste lista vad som uttryckligen ligger utanför ramen. Icke-mål förhindrar oavsiktliga omskrivningar och ”hjälpsamma” avvikelser från ramen där AI:n beslutar att omstrukturera hela ditt CSS-ramverk medan den rättar ett stavfel.

För det andra behöver du kontext som modellen inte kan utläsa. Detta inkluderar arkitektoniska begränsningar, domänregler, säkerhetskrav och integrationspunkter. Om det är viktigt för affärslogiken måste du säga det. AI:n kan inte gissa dina gränser för efterlevnad.

För det tredje, och kanske viktigast, behöver du gränser. Du behöver uttryckliga ”rör inte”-listor. Dessa är skyddsräcken som hindrar praktikanter från att radera produktionsdatabasens konfiguration, begå hemligheter eller modifiera äldre leverantörskataloger som håller ihop systemet.

Slutligen behöver du acceptanskriterier. Vad betyder ”klart”? Detta bör uttryckas i kontroller: tester, invariabler och ett par gränsfall som tenderar att missas. Om du tycker att detta låter som bra teknik (eller till och med bra ledning), har du rätt. Det är det. Vi återupptäcker den disciplin som vi har låtit försvinna, klädd i nya verktyg.

Kontext är en produkt, inte en prompt

En anledning till att utvecklare blir frustrerade över agenter är att vi behandlar prompting som en engångsaktivitet, vilket det inte är. Det är närmare att skapa en arbetsmiljö. Osmani påpekar att stora promptar ofta misslyckas, inte bara på grund av begränsningar i den råa kontexten, utan också för att modellerna presterar sämre när man staplar på för många instruktioner på en gång. 

Anthropic beskriver samma disciplin som ”kontextteknik”. Du måste strukturera bakgrund, instruktioner, begränsningar, verktyg och önskat resultat så att modellen på ett tillförlitligt sätt kan följa det som är viktigast.

Detta förskjuter utvecklarens arbetsbeskrivning till något som liknar ”kontextarkitekt”. En utvecklares värde ligger inte i att känna till syntaxen för ett specifikt API-anrop (AI:n kan det bättre än vi), utan snarare i att veta vilket API-anrop som är relevant för affärsproblemet och se till att AI:n också vet det.

Det är värt att notera att Ethan Mollicks inlägg ”On-boarding your AI intern” uttrycker detta i klartext. Han säger att man måste lära sig var praktikanten är användbar, var den är irriterande och var man inte bör delegera eftersom felfrekvensen är för kostsam. Det är ett finare sätt att säga att man behöver omdöme. Vilket är ett annat sätt att säga att man behöver expertis.

Fällan med kodägande

Det finns naturligtvis en fara här.

Om vi överlåter implementeringen till AI och bara fokuserar på specifikationen riskerar vi att tappa kontakten med verkligheten i programvaran. Charity Majors, cto på Honeycomb, har slagit larm om just denna risk. Hon skiljer mellan ”kodförfattarskap” och ”kodägande”. AI gör författarskapet billigt – nästan gratis. Men ägandet (förmågan att felsöka, underhålla och förstå koden i produktion) blir dyrt.

Majors hävdar att ”när du förlitar dig för mycket på AI-verktyg, när du övervakar istället för att göra, försämras din egen expertis ganska snabbt”. Detta skapar en paradox för modellen ”utvecklare som chef”. För att skriva en bra specifikation, som Osmani råder, behöver du djup teknisk förståelse. Om du lägger all din tid på att skriva specifikationer och låter AI skriva koden, kan du långsamt förlora den djupa tekniska förståelsen. Lösningen är sannolikt en hybridmodell.

Utvecklaren Sankalp Shubham kallar detta för att ”köra på lägre växlar”. Shubham använder analogin med en bil med manuell växellåda. För enkla, rutinmässiga uppgifter kan du växla upp och låta AI:n köra fort (hög automatisering, låg kontroll). Men för komplexa, nya problem måste du växla ner. Du kan skriva pseudokoden själv.

Du kan skriva den svåra algoritmen för hand och be AI:n att bara skriva testfallen.

Du förblir föraren. AI:n är motorn, inte chauffören.

Framtiden är specifikationsdriven

Det ironiska i allt detta är att många utvecklare valde sin karriär just för att undvika att bli chefer. De gillar kod eftersom den är deterministisk. Datorer gör vad de blir tillsagda (för det mesta). Människor (och i förlängningen praktikanter) är röriga, tvetydiga och behöver vägledning.

Nu har utvecklarnas primära verktyg blivit rörigt och tvetydigt.

För att lyckas i denna nya miljö måste utvecklare utveckla mjuka färdigheter som faktiskt är ganska svåra. Du måste lära dig att formulera en vision tydligt. Man måste lära sig att bryta ner komplexa problem i isolerade, modulära uppgifter som en AI kan hantera utan att förlora sammanhanget. 

De utvecklare som lyckas i denna era kommer inte nödvändigtvis att vara de som kan skriva snabbast eller memorera flest standardbibliotek. Det kommer att vara de som kan översätta affärskrav till tekniska begränsningar så tydligt att inte ens en stokastisk papegoja kan förstöra det.