Linjäringenjören Mufeez Amjad har publicerat en detaljerad redogörelse för hur företaget omarbetade sin kontinuerliga integrationspipeline efter att AI-kodningsagenter förvandlade CI till sin värsta flaskhals – minskade väntetiden för pull-begäran från mer än sex minuter till drygt fem medan dess testsviter nästan fyrdubblades sedan början av året.

Inlägget, som publicerades på Linears ingenjörsblogg den 21 september, började, som dessa saker ofta gör, med en kortfattad biljett från ovan. Tidigare i år öppnade Amjad Linear för att finna att Tuomas, företagets CTO, hade tilldelat honom en fråga med titeln "CI-kostnader är höga" — och bad honom att göra CI snabbare medan han höll på. För mer sammanhang om den här historien, se vår pågående AI-industribevakning.

När agenter överskrider valideringen

Problemet är strukturellt, inte tillfälligt. "Agenter har gjort det exponentiellt snabbare att skicka kod," skrev Amjad, "men att validera dessa ändringar har inte riktigt hållit igång i samma takt." Varje pull-begäran måste fortfarande passera genom CI, så när utvecklingen accelererar blir CI chokepunkten – vilket driver upp infrastrukturkostnaderna och låter utvecklare och deras agenter vänta längre på feedback.

Linjär optimerad för två mätvärden: hur länge en PR väntar på CI och hur mycket löpartid den förbrukar. Resultaten efter månaders arbete: trots att testsviterna nästan fyrdubblats sedan januari, sjönk väntetiden för pull request från mer än sex minuter till drygt fem, och löpartiden per test halverades ungefär.

Arbetet delas i stort sett in i fyra kategorier: uppgraderad infrastruktur och verktyg, optimerade jobben som leder till annat arbete, minskade upprepade installationer och effektiviserade testkörning. Linears kodbas är i första hand TypeScript, men många av optimeringarna gäller över språk och verktygskedjor.

Snabbare maskiner och en inbyggd kompilator

Några av de tidigaste vinsterna krävde nästan ingen optimering av själva CI. Att flytta arbetsbelastningar från GitHub Actions till tredje parts löpare med snabbare processorer, högre prestanda lagring och bättre cache-infrastruktur lönade sig omedelbart: i en likvärdig jämförelse av de två dagarna på vardera sidan av switchen, körde jobb 34 % snabbare i genomsnitt, med vissa arbetsbelastningar som "tsc" som sjönk 52 %.

Moderniseringen av verktygskedjan förvärrade vinsten. Genom att byta till `tsgo`, den inbyggda TypeScript-kompilatorn, minskade den veckovisa medianen för typkontrollen med 73 % – tillräckligt stor för att helt flytta flaskhalsen från typkontroll.

Linting utan typgrafen

Linting var ett annat tidigt mål. En handfull av Linears anpassade ESLint-regler berodde på TypeScript-typinformation, vilket tvingade varje lintkörning att bygga hela grafen innan de utvärderades – vilket gjorde linting till ett av de mest minneskrävande CI-jobben.

Teamet skrev om reglerna för att använda statisk analys över det abstrakta syntaxträdet, identifiera funktionsliknande konstruktioner och skyddsmönster utan någon typinformation. Det lät ESLint sänka TypeScript helt, vilket minskade API-luddtiden med 68 % och luddtiden i hela arkivet med 55 %, med minnesanvändningen minskande avsevärt. Det underlättade också den senare migreringen till Oxlint, vilket ytterligare minskade CI-löparminuter som spenderades på ludd.

Krymper den kritiska vägen

Med individuella kontroller snabbare zoomade Linear ut och behandlade CI som ett system. Det uppmärksammade de små jobben som ligger framför allt annat - sökvägsändringsdetektering och testresultatcache kontrollerar den porten på jobbnivå, vilket betyder att ingen av de åtta API-testbitarna kan starta förrän de är klara.

Fixningarna var granulära men additiva. Att täcka hämtningsdjupet tog den långsammaste grinden från 94 sekunder till 20. Att ta bort kassan helt från jobb som aldrig behövde ett fungerande träd skar dem från 27 sekunder till 7. En gles, bloggfri kassa med begränsad historik sparade ytterligare 11 sekunder för push- och sammanslagningsköhändelser. Sammantaget sjönk ändringsdetekteringsjobbets medianlängd från 26 sekunder till 8, dess p90 från 31 till 12 och dess långsammaste körning från 138 sekunder till 37.

Tillförlitligheten i kassan behövde också fungera: eftersom tredje parts löpare sitter utanför GitHubs nätverk och förlitar sig på en direkt IP-länk, stoppade intermittent länkförsämring ibland hämtningar. Linear ersatte `actions/checkout` med sin egen sammansatta åtgärd som försöker igen med backoff, ställer `GIT_HTTP_LOW_SPEED_LIMIT` och `GIT_HTTP_LOW_SPEED_TIME` så att en avstängd anslutning avbryts efter cirka 30 sekunder istället för att hänga, och använder en kassacache som behåller en beständig spegel på en giyt-disk.

En subtil korrigering tog bort bortkastad sammanslagningskötid: cachemarkörer skrevs som en del av den sista kontrollen innan sammanslagning, så en PR kunde sitta i kön även efter att testerna hade godkänts. Att flytta den skrivningen till ett jobb som inte är grindande rakade 42 sekunder från sammanfogningssökvägen för varje API pull-begäran och sammanslagningsköpost. Tillsammans tog dessa förändringar ungefär en minut från de erforderliga kontrollerna för API PR:er på cachemissar samtidigt som de minskade antalet löparestarter.

Färre bortkastade sekunder per jobb

Den sista kategorin attackerade installationskostnaden upprepas över alla jobb. Varje API-testfragment tillbringade 7 till 8 sekunder med att installera samma Postgres-klient med apt vid varje körning; att flytta den till en liten CI-basbild bredvid Node innebar att skärvor kunde börja köras. Teamet lade senare till inbyggda byggrubriker till bilden efter att ha upptäckt att nedladdning av dem under installationen ibland kunde hänga sig.

Varför det gav resonans

Inlägget slog en nerv i utvecklarna: det nådde framsidan av Hacker News och drog ungefär 250 poäng och cirka 280 kommentarer inom en dag. Reaktionen är lätt att förklara — Linears erfarenhet nämner en kostnad för AI-stödd utveckling som de flesta ingenjörsorganisationer konfronteras med först nu. Agenter som genererar pull-förfrågningar på några minuter väntar fortfarande på valideringspipelines designade för mänsklig kadens, och varje minut av den väntan multipliceras med varje agent som arbetar parallellt.

Lärdomen från Linears omarbetning är att flaskhalsen är flyttbar, men bara genom den oglamorösa ackumuleringen av många små fixar – snabbare löpare, billigare typkontroller, lintregler på syntaxnivå, capped hämtningar, spänstiga kassar, förbyggda bilder – snarare än någon enskild silverkula.

---

Stay ahead of AI

Få de senaste AI-nyheterna, analyserna och genombrotten – allt på ett ställe.

Läs mer AI-nyheter →