Att estimera en Drupal-uppgradering är ett av de enformigaste och viktigaste momenten att få rätt. Det är timmar av composer-utforskning, modulinventering och risktänk som ska bli ett spann kunden kan lita på. Så när jag stod inför en Drupal 10 till 11-uppgradering på ett kundprojekt testade jag något jag funderat på ett tag: jag lät två AI-agenter göra varsitt estimat på samma kodbas, med samma instruktioner, och jämförde med min egen magkänsla.
Modellerna var Claude (Fable 5, high) den korta stund vi fick använda den och Codex (GPT-5.5, high), båda körda som agenter i terminalen med en estimate-skill jag byggt. Skillen beskriver hur ett estimat ska se ut: spann hellre än punktsiffror, staged plan om det behövs, QA-steg och öppna frågor. Ingen av dem fick några verktygstips utöver det. Hela prompten var några rader:
We will estimate this drupal 10 to drupal 11 upgrade.
Also contrib modules and our two custom modules.
Remember contrib modules can exist in multiple placed.
Include plan on if we need to split upgrade in different stages.
Write the estimate to correct place in the vault and add claude/codex
to title so we know its yours.
Ask questions if needed and plan and document QA steps.
Also feel free to check themes and db if needed.Projektet i korthet, utan detaljer som pekar ut projektet: en större företagssajt på Drupal 10, flerspråkig och multidomän, med ett femtiotal contrib-moduler och egna custom-moduler skrivna av olika utvecklare under flera år.
Siffrorna
Min egen magkänsla, nedskriven innan jag läste deras svar, låg under bägge estimaten. Claude landade ungefär en fjärdedel över min siffra, med ett sammanhållet spann och en viktad totalsumma. Codex landade runt det dubbla, med ett bredare spann och ett rekommenderat offertintervall ovanpå det.
Tokenåtgången var den omvända mot vad jag gissat: Claude använde runt 100k tokens, Codex runt 169k. Modellen som gjorde det mest grundliga jobbet använde alltså klart färre tokens. Vart de tog vägen kommer vi till.
Det intressanta är inte gapet, utan varför
Två estimat som skiljer sig nästan en faktor två på samma kodbas kan kännas som att något har gått fel. Men när jag ställde upp dem sida vid sida visade sig nästan hela skillnaden bero på en enda sak: hur de hanterar osäkerhet.
Claude omvandlade osäkerhet till fakta. Den installerade upgrade_status, körde en deprecation-scan över den befintliga custom-koden, sökte upp releasestatus på drupal.org för varje blockerad contrib-modul och tittade i databasen. Scanningen visade att custom-koden i princip var ren, en enda deprecation. Databasuppslaget visade att flera av de upplevda blockerarna inte var blockerare alls: en modul vars funktion redan flyttat in i core, en gammal editor som inte längre användes av något textformat, ett bibliotek vars enda funktion var avstängd. Varje sådan upptäckt krympte estimatet.
Codex prissatte osäkerheten istället. Den höll sig strikt till read-only, composer why-not och drush status, och scannade aldrig koden. Custom-modulerna fick risknivå medium-high baserat på antaganden, och listan med blockers var composer-utskriften rakt av. Det är inte fel, olika modeller löser problem på olika sätt, men det är försiktigt. Varje antagande som Claude verifierade låg kvar i Codex spann som risk som kostar tid.
Det billigare estimatet kom alltså från modellen som gjorde mest research.
Samma mening, två tolkningar
Det som gör det här till något mer än en sifferjämförelse är att båda fick exakt samma frihet. Prompten sa feel free to check themes and db if needed. Claude läste det som tillstånd att installera ett analysverktyg, använda det och avinstallera det efteråt. Codex läste samma ord som ett read-only-mandat.
Ingen av tolkningarna är fel. I en annan kontext hade jag varit tacksam för agenten som inte installerar saker i ett kundprojekt utan att fråga. Men det betyder att skillnaden mellan estimaten i grunden inte handlade om Drupal-kunskap utan om initiativ: hur mycket en agent vågar göra för att slippa gissa.
En liten detalj i samma tema: prompten avslutades med ask questions if needed. Claude frågade om vem som tar hand om deploy. Codex valde att inte fråga om något. Båda levererade en sektion med öppna frågor i slutet av dokumentet. Dagens agenter kan ibland vara bättre på att skriva frågor än ställa dem.
Vad de var bra på var sitt håll
Claude skrev det estimat jag förmodligen skulle vilja lämna till en kund: tydlig release-uppdelning, risker prissatta i tid, QA-checklista som refererade verkliga detaljer i projektet och en plan som frikopplade vårt arbete från den externa leverantörens tidplan. Den använde också kontext från vår kunskapsbas, bland annat ett scope-beslut från samma dag, och avgränsade estimatet därefter.
Codex fångade saker Claude tonade ner: contrib-moduler som låg dubblerade på två ställen i repostrukturen och behöver ett beslut på action, en versionsskillnad mellan lokal kod och produktion som borde redas ut innan man estimerar vidare, och en snyggare trestegsmodell för releaserna. Dess QA-kommandolista var också den bättre av de två.
Och på de stora hela var de helt överens: dela upp uppgraderingen i en hardening release på Drupal 10 före själva 11-uppgraderingen, domänhanteringen är den största risken, samma moduler bör bort helt. När två modeller som jobbat oberoende landar i samma planform litar jag mer på planens riktning. Timmarna är fortfarande en separat fråga.
Vad jag tar med mig
Min estimering låg närmast Claudes siffra, och jag tror inte det är en slump. Jag har arbetat med Claude i flera projekt och byggt mina processer med den i åtanke, så det är inte konstigt att den matchar min magkänsla bättre än Codex. Codex antog motsatsen och prissatte den. Ett estimat är i grunden en lista med antaganden där varje antagande har en kostnad, och värdet i AI-estimering visade sig ligga mindre i slutsiffran och mer i vilka antaganden som hinner bli fakta innan man landar i den.
Skillnaden mot min egen siffra var också lärorik åt andra hållet. Claude låg över min magkänsla, och när jag läste varför får jag ge den rätt: koordinering, runbooks och två QA-rundor som mitt estimat gärna tonar ner när jag tänker för mycket i ren utvecklingstid.
Och kostnaden? Båda körningarna tillsammans kostade tokens för en bråkdel av vad motsvarande manuella genomgång hade kostat i seniortid. Att låta två modeller estimera oberoende och triangulera mot sin egen erfarenhet ger ett billigt extra perspektiv. Jag kommer göra om det på nästa större uppgradering, och då är det förmodligen estimaten som får agera baseline åt varandra.
Vad det här gör med skillen
När jag läste estimaten sida vid sida upptäckte jag något jag borde sett tidigare: min estimate-skill har begränsningar. Den beskriver hur man inventerar en Figma-fil och hittar det som inte syns i skisserna. Den har med sektioner om risker, QA och uppgradering men inte en enda rad som säger att modellen ska göra research, eller hur den ska hantera osäkerhet.
Det förklarar mer än jag först trodde. Skillen gav båda modellerna output-kontraktet: spann istället för punktsiffror, viktad totalsumma, antaganden, exklusioner, risker och öppna frågor. Det följde båda nästan till punkt och pricka, och det syns i resultatet: två estimat med nästan identisk form och helt olika metod. Skillen styrde formen. Metoden fick modellerna improvisera fram själva, och det var där de gick isär.
Så nästa version av skillen får ett eget läge för uppgraderingsestimat, byggt på det den här jämförelsen lärde mig:
En verifieringstrappa istället för fritt initiativ. Kolla om en kompatibel release redan finns för varje blockerad modul, kolla om blockeraren ens används, kör en deprecation-scan på koden vi ansvarar för. Initiativ ska inte vara ett temperamentsdrag hos modellen, det ska stå i instruktionen.
Ett tydligt mandat. Vad agenten får installera lokalt och ska städa upp efteråt, och vad den aldrig får röra. Skillnaden mellan modellernas tolkningar av samma fria formulering blev hela den här artikeln.
Ett antagande-register i outputen. Varje antagande är antingen verifierat med belägg eller prissatt i timmar. Osäkerheten ska synas i estimatet, inte ligga inbakad i spannet.
Jag la till en decision split. Kan en obesvarad fråga flytta totalen med mer än en femtedel ska agenten stanna och fråga, inte skriva en prydlig frågesektion längst ner i ett färdigt dokument.
Och en regel som inte handlar om agenten: skriv ner din egen magkänsla innan du läser dess svar. Den disciplinen var det närmaste jag kom en kontrollgrupp i det här experimentet, och den kostade ingenting.
Sedan ska jag vara ärlig med att nya versionen är ett antagande i sig. Det som gjorde det bättre estimatet bra var initiativ som modellen tog själv, och det går inte att utesluta att en hårt styrd skill trycker undan just den sortens omdöme. Det får nästa skarpa estimat visa. Och det riktiga facit kommer först när uppgraderingen är levererad och timmarna kan jämföras med alla tre estimaten.
Jag funderar på att lägga upp skillen publikt när nya versionen är testad på ett skarpt estimat till. Hör av dig om du vill ha den, så vet jag om det är värt att städa upp den för publik användning.
Jag skrev också en separat artikel om vad tokenåtgången lärde mig om tydligare agentinstruktioner.
