Lineair ingenieur Mufeez Amjad heeft een gedetailleerd verslag gepubliceerd van hoe het bedrijf zijn continue integratiepijplijn heeft herwerkt nadat AI-codeeragenten CI tot het grootste knelpunt hadden gemaakt: de wachttijd voor pull-aanvragen werd teruggebracht van meer dan zes naar iets meer dan vijf minuten, terwijl de testsuites sinds het begin van het jaar bijna verviervoudigden.

Het bericht, gepubliceerd op de technische blog van Linear op 21 september, begon, zoals dit soort dingen vaak doen, met een kort kaartje van bovenaf. Eerder dit jaar opende Amjad Linear en ontdekte dat Tuomas, de CTO van het bedrijf, hem een ​​probleem had toegewezen met de titel "CI-kosten zijn hoog" - en hem had gevraagd CI sneller te maken terwijl hij toch bezig was. Voor meer context over dit verhaal, zie onze voortdurende AI-industrieverslaggeving.

Wanneer agenten de validatie overtreffen

Het probleem is structureel en niet incidenteel. "Agenten hebben het exponentieel sneller gemaakt om code te verzenden", schreef Amjad, "maar het valideren van die wijzigingen is niet helemaal in hetzelfde tempo gebleven." Elke pull-request moet nog steeds via CI gaan, dus naarmate de ontwikkeling versnelt, wordt CI het knelpunt, waardoor de infrastructuurkosten stijgen en ontwikkelaars en hun agenten langer op feedback wachten.

Lineair geoptimaliseerd voor twee statistieken: hoe lang een PR op CI wacht en hoeveel runner-tijd deze verbruikt. De resultaten na maanden werken: ondanks dat de testsuites sinds januari bijna zijn verviervoudigd, daalde de wachttijd voor pull-aanvragen van ruim zes naar iets meer dan vijf minuten, en werd de runnertijd per test grofweg gehalveerd.

Het werk viel grofweg in vier categorieën uiteen: verbeterde infrastructuur en tooling, optimaliseerde de taken die ander werk mogelijk maakten, verminderde herhaalde instellingen en maakte de testuitvoering efficiënter. De codebasis van Linear is voornamelijk TypeScript, maar veel van de optimalisaties zijn van toepassing op verschillende talen en toolchains.

Snellere machines en een native compiler

Voor sommige van de vroegste resultaten was vrijwel geen optimalisatie van de CI zelf nodig. Het verplaatsen van werklasten van GitHub Actions naar hardlopers van derden met snellere CPU's, opslag met hogere prestaties en een betere cache-infrastructuur wierp onmiddellijk vruchten af: in een vergelijkbare vergelijking van de twee dagen aan weerszijden van de overstap, liepen taken gemiddeld 34% sneller, waarbij sommige werklasten zoals `tsc` met 52% daalden.

Het moderniseren van de toolchain maakte de winst nog groter. Door over te schakelen naar `tsgo`, de oorspronkelijke TypeScript-compiler, werd de wekelijkse mediaan van de typecontrole met 73% verlaagd – groot genoeg om het knelpunt volledig uit de typecontrole te verwijderen.

Linting Zonder de typegrafiek

Linting was een ander vroeg doelwit. Een handvol aangepaste ESLint-regels van Linear was afhankelijk van TypeScript-type-informatie, waardoor elke lint-run gedwongen werd om de volledige typegrafiek op te bouwen voordat deze werd geëvalueerd - waardoor linting een van de meest geheugenintensieve CI-taken werd.

Het team herschreef de regels om statische analyse van de abstracte syntaxisboom te gebruiken, waarbij functie-achtige constructies en bewakingspatronen werden geïdentificeerd zonder enige type-informatie. Hierdoor kon ESLint TypeScript volledig laten vallen, waardoor de API-linttijd met 68% en de volledige repository-linttijd met 55% werd verminderd, waarbij het geheugengebruik aanzienlijk daalde. Het vergemakkelijkte ook de latere migratie naar Oxlint, waardoor de CI-runner-minuten die aan linting werden besteed verder werden verminderd.

Het kritieke pad verkleinen

Omdat individuele controles sneller gingen, zoomde Linear uit en behandelde CI als een systeem. Dat vestigde de aandacht op de kleine taken die vóór al het andere gaan: detectie van padwijzigingen en cachecontroles van testresultaten die op taakniveau plaatsvinden, wat betekent dat geen van de acht API-testscherven kan starten voordat ze klaar zijn.

De oplossingen waren gedetailleerd maar additief. Het afdekken van de ophaaldiepte bracht de langzaamste poort van 94 seconden naar 20. Door het volledig afrekenen van taken waarvoor nooit een werkende boom nodig was, werd die van 27 seconden teruggebracht naar 7. Een spaarzaam, vlekkeloos afrekenen met een beperkte geschiedenis bespaarde nog eens 11 seconden voor push- en merge-wachtrijgebeurtenissen. In totaal daalde de mediane duur van de veranderingsdetectietaak van 26 seconden naar 8, de p90 van 31 naar 12 en de langzaamste taak van 138 seconden naar 37.

De betrouwbaarheid van de kassa had ook werk nodig: omdat de externe runners buiten het netwerk van GitHub zitten en afhankelijk zijn van een directe IP-link, liep de afbraak van de link af en toe vast bij het ophalen. Linear heeft `actions/checkout` vervangen door zijn eigen samengestelde actie die opnieuw probeert met uitstel, stelt `GIT_HTTP_LOW_SPEED_LIMIT` en `GIT_HTTP_LOW_SPEED_TIME` zo in dat een vastgelopen verbinding na ongeveer 30 seconden wordt afgebroken in plaats van vast te lopen, en gebruikt een checkout-cache die een persistente git-mirror op een plakkerige schijf bewaart.

Eén subtiele oplossing maakte een einde aan de verspilde tijd in de samenvoegwachtrij: cachemarkeringen werden geschreven als onderdeel van de laatste controle vóór het samenvoegen, zodat een PR zelfs nadat de tests waren geslaagd in de wachtrij kon blijven staan. Door dat schrijven naar een niet-gating-taak te verplaatsen, werd 42 seconden van het samenvoegpad geschoren voor elke API-pull-aanvraag en merge-wachtrij-invoer. Samen namen deze wijzigingen ongeveer een minuut af van de vereiste controles op API PR's bij cache-missers, terwijl het aantal runner-starts werd verminderd.

Minder verspilde seconden per taak

De laatste categorie viel de installatiekosten aan, die voor elke taak herhaald werden. Elke API-testshard besteedde bij elke run 7 tot 8 seconden aan het installeren van dezelfde Postgres-client met apt; Door het naast Node naar een kleine CI-basisimage te verplaatsen, konden scherven klaar zijn voor gebruik. Het team voegde later native build-headers toe aan de image nadat ze ontdekten dat het downloaden ervan tijdens de installatie af en toe kon vastlopen.

Waarom het resoneerde

Het bericht raakte de ontwikkelaars: het bereikte de voorpagina van Hacker News en trok binnen een dag ongeveer 250 punten en ongeveer 280 reacties. De reactie is eenvoudig uit te leggen: de ervaring van Linear noemt de kosten van AI-ondersteunde ontwikkeling waarmee de meeste technische organisaties nu pas worden geconfronteerd. Agenten die binnen enkele minuten pull-aanvragen genereren, wachten nog steeds op validatiepijplijnen die zijn ontworpen voor menselijke cadans, en elke minuut van die wachttijd wordt vermenigvuldigd met elke agent die parallel werkt.

De les uit de herwerking van Linear is dat het knelpunt verplaatsbaar is, maar alleen door de niet-glamoureuze opeenstapeling van veel kleine oplossingen (snellere runners, goedkopere typechecks, pluisregels op syntaxisniveau, capped fetches, veerkrachtige checkouts, vooraf gebouwde afbeeldingen) in plaats van een enkele wondermiddel.

---

Blijf AI een stap voor

Ontvang het laatste AI-nieuws, analyses en doorbraken – allemaal op één plek.

Lees meer AI-nieuws →