Google Jules: asynkron kodning behöver en granskningsbudget

Google meddelade offentlig beta för Jules den 20 maj 2025 efter en tidigare presentation i december 2024. En separat ändringslogg för Jules är daterad den 19 maj 2025; datumen hör till olika publicerade dokument. Betapresentationen beskrev hur kodförrådet klonades till en virtuell maskin i Google Cloud, hur Gemini 2.5 Pro användes och hur tester, buggfixar och beroendeuppdateringar kunde utföras asynkront. Planer, resonemang och diffar ingick i granskningsflödet. Den här historiska analysen publiceras den 25 oktober 2026. Den fastställer inte aktuella versioner, priser, abonnemangsgränser eller tillgänglighet. Skillnaden är viktig eftersom ett lanseringsdokument beskriver beskedet vid en viss tidpunkt, inte tjänstens hela beteende mer än ett år senare. Ett införandebeslut behöver en ny kontroll av faktisk konfiguration och avtal. 1

Asynkront arbete gör att utvecklaren kan lämna en uppgift och arbeta med annat. Det förändrar planeringen men tar inte bort behovet av tekniskt omdöme. Om många uppgifter blir klara samtidigt kan flaskhalsen flyttas från implementation till granskning. Mät hur länge ändringar väntar och hur många öppna förslag varje förvaltare ansvarar för. Mer parallellt arbete är inte automatiskt fler leveranser när samma personer måste förstå och godkänna allt.

Att klona kodförrådet är bara början på en reproducerbar utvecklingsmiljö. Privata paket, genererade filer, saknade testdata och odokumenterad konfiguration kan stoppa meningsfull testning. Skilj i piloten på agentens resonemangsfel och fel i miljön. Ge en minimal installationsväg och pröva den utan personliga datorinställningar. Dela inte ut breda produktionsbehörigheter bara för att få uppgiften att fungera; ett rent bygge ska inte vara beroende av oavsiktlig åtkomst.

Beroendeuppdateringar med tydliga tester, isolerade buggfixar och dokumentationsändringar är lättare att delegera än arkitekturbeslut som kräver återkommande förankring. Skriv önskat beteende och avgränsningar innan arbetet startar. När två agenter berör gemensamma gränssnitt behöver arbetet ordnas i följd eller få en tydlig ägare. Förvänta er inte automatisk samordning. En avslutad uppgift ska innehålla en begriplig diff och belägg för relevanta kontroller, inte bara påståendet att arbetet är klart.

Börja en pilot för asynkron kodning med granskarnas kapacitet, inte med antalet uppgifter en agent kan starta. För Jules bör beställningsmallen ange acceptanskriterier, tillåtna filer, beroenden och vilka belägg som ska följa med en pull request. Utse granskare före start och begränsa pågående arbete så att genererade ändringar inte samlas utan ägare. Skilj små oberoende rättningar från uppgifter som förändrar samma gränssnitt; annars skapar parallellt arbete ett seriellt integrationsproblem. Koppla uppgiftsunderlaget till förvaltad företagskunskap och använd agentsäkerhet för att ange vilka handlingar som kräver godkännande. Detta är föreslagna köregler, inte påståenden om automatiska produktskydd. Bestäm också vem som tar över när den ursprungliga granskaren är frånvarande.

Mät tiden från accepterad beställning till granskad integration, inklusive väntan på människor, begärda korrigeringar och konflikthantering. Räkna övergivna pull requests som förbrukad kapacitet i stället för att ta bort dem ur resultatet. Sätt en åldersgräns för kön: en inaktuell ändring behöver uppdaterad bas och nya kontroller innan granskningen fortsätter. Pausa nya beställningar när belastningen på granskarna överstiger överenskommen nivå. AI-rådgivning kan hjälpa till att sätta ett servicemål för kön, medan en AI-föreläsning kan skilja synlig agentaktivitet från levererat utvecklingsvärde. Utöka först när det godkända flödet förbättras utan undanträngd mänsklig granskning eller fler fel efter integration. Följ även hur ofta granskaren måste återskapa uppgiftens ursprungliga sammanhang.