General Motors (GM) autonóm vezetési részlegén dolgozó szoftvermérnökök átlagosan mindössze a munkaidejük 15%-át töltik kódírással — mondta Rashed Haq, a GM autonóm járművekért felelős alelnöke a VB Transform 2026 konferencián egy főszínpadi beszélgetés során. A fennmaradó 85% feladatok nagy részét a vállalat most ügynököknek nevezett AI-rendszerekkel gyorsítja fel: a járműadatok elemzésétől és problémák triázsán át kísérletek futtatásáig és javítások teszteléséig.
Mire vezetett a változtatás?
Haq szerint az ügynökök bevezetése után a GM autonóm járművek fejlesztési szervezetén belül megközelítőleg háromszorosára nőtt a merge-elt (összevont) pull requestek száma. Emellett gyorsabbá váltak a kiadások, és kevesebb olyan hiba került át a fejlesztési fázisokon, amely később problémát okozott volna.
Nem csak kódkiegészítők: munkafolyamatok újratervezése
A GM eredményeit úgy érte el, hogy nem pusztán AI-alapú kódsegédet adott a fejlesztőknek, hanem az egész mérnöki munkafolyamatokat újratervezte az ügynökök köré. Haq rámutatott: „Ha csak egy chatbotot adsz valakinek, amely tud kódot írni, akkor a folyamatban továbbra is sok hatékonysághiány marad.” A cél az volt, hogy az egyes fejlesztési hurkokon — szimulációs fejlesztés és tesztelés, nyilvános úti tesztelés, valamint a járművek ügyfelekhez kerülése utáni monitorozás — feltérképezzék a leghosszabb szűk keresztmetszetet, azt automatizálják, majd ismételjék a folyamatot.
Ügynökök hozzáférése belső eszközökhöz és adatokhoz
A GM ügynököket összekapcsolta belső eszközökkel és petabájtos vállalati adatmennyiséggel egy egyedi Model Context Protocol (MCP) szerveren keresztül. Emellett verziókövetett „skills” (képesség/instrukció) dokumentumokat hoztak létre, amelyek meghatározzák, hogyan hajtson végre egy ügynök konkrét feladatokat.
Egyik fontos alkalmazás a nyilvános utakon gyűjtött telemetria elemzése: az ügynökök képesek első körös triázst végezni, problémákat létrehozni a fejlesztők számára, és az MCP-kapcsolatokon keresztül a WebViz által használt eszközöket közvetlenül meghívni, nem csupán a felhasználói grafikus felületet használva.
Emberi átláthatóság és jogosultságok
Haq hangsúlyozta, hogy az ügynökök kimenetének értelmezhetőnek kell lennie a mérnökök számára: az ügynök meg tudja határozni egy lehetséges problémát, beazonosítani az érintett komponenst, keresni hasonló korábbi eseményeket és példákat adni a megállapítás alátámasztására. Az ügynökök jogosultságait a hozzájuk tartozó mérnök jogosultságaihoz igazítják — ha egy mérnök hozzáfér bizonyos eszközökhöz a feladat elvégzéséhez, akkor az ő ügynökének is szüksége van ezekre a hozzáférésekre. Ugyanakkor a mérnök marad felelős az ügynök kimenetéért.
Párhuzamos kísérletezés és csapatmunka
A GM háttérügynököket is alkalmaz, amelyek párhuzamosan futtatnak gépi tanulási kísérleteket: a mérnök definiálja a kísérletet és paramétereit, az ügynökök pedig végrehajtják a teszteket és gyűjtik az eredményeket. A belső ügynökplatformot termékként kezelték: négy, az üzemeltetett platformon dolgozó fejlesztőt rendeltek ki, akik közvetlenül dolgoznak a mérnöki csapatokkal, segítik a hasznos munkafolyamatok azonosítását, a bevált gyakorlatok elterjesztését és az eszközök bevezetését.
Teljesítménymérés, minőségellenőrzés és meglepetések
A növekedés nem csupán nagyobb kódmennyiséget tükröz: Haq szerint nagyobb lett az új funkciók kiadási sebessége, miközben kevesebb tesztesés és hibaszivárgás történt. A cég strukturált és strukturálatlan teszteket, valamint teljesítménymutatókat állított fel még az ügynökök által gyorsított munkafolyamatok előtt; a mérnökök felülvizsgálják ezeket az eredményeket és eldöntik, hogy a tesztek továbbra is a célkitűzést mérik-e, mielőtt a munka a produkció felé halad.
Haq elmondása szerint a GM kezdetben szerényebb termelékenység-növekedésre számított, és „az egyetlen meglepetés az volt, hogy mennyit tudtunk megcsinálni.”
Kontextus: miért nem elég csak a kódírás gyorsítása?
A GM adatai szerint a fejlesztők korábban a munkaidejük kis részét töltötték kódírással, és ezt más kutatások is alátámasztják: egy 2019-es Microsoft-vizsgálatban 5 971 fejlesztő válaszai alapján jó munkanapon átlagosan 96 percet, rossz napokon 66 percet töltöttek kódírással — ez körülbelül 20% és 14% egy nyolcórás napból. Egy 2018-as Stripe-felmérés pedig azt találta, hogy az átlagos fejlesztő heti több mint 17 órát töltött karbantartási munkákkal, például hibakereséssel és refaktorálással. Ezek az adatok megerősítik Haq központi állítását: a kódírás csak egy része a szoftvermérnöki munkának, és ha csak ezt gyorsítjuk, a fejlesztési folyamat többi része változatlan marad.
Összegzés
A GM megközelítése nem az volt, hogy minden fejlesztőnek azonnal generátort adjanak kódíráshoz, hanem hogy a problémamegoldástól a verifikált javításig tartó teljes útvonalat feltérképezzék mindhárom fejlesztési hurokban, majd célzott, kontrollált hozzáféréssel rövidítsék meg a leghosszabb akadályokat. Ennek eredménye a háromszorosára növekedett összevont pull request-szám, gyorsabb kiadások és kevesebb későbbi hibaszivárgás a GM autonóm járműfejlesztésében.
