Copilot Cowork: 9 mérnök, 1211 PR egy nap alatt

Mi történt?

A Microsoft Copilot Cowork csapata részletesen leírta, hogyan dolgozik agentekkel (Microsoft). A Copilot Cowork egy agentic végrehajtási réteg, amely több lépéses munkafolyamatokat visz végig a felhasználó helyett a Microsoft 365-ben.

A projekt január 13-án indult üres repóból, június 16-án lett világszerte elérhető. Október 21-én kilenc mérnök 1211 pull requestet mergelt a backend main ágába. A kód nagy részét agentek írták, a mérnökök a specifikációért, a határokért, illetve a kockázatos változások ellenőrzéséért feleltek.

Melyik a hat tanulság?

• Nincs kód előre megírt markdown spec nélkül: mit csinál a változás, honnan tudjuk, hogy működik, mit nem szabad elrontania.
• Szűk feladatú agentek futnak párhuzamosan, mindegyik a repó saját másolatán. A modell egy credential nélküli konténerben fut, az identitást, a policyt és a jóváhagyásokat egy megbízható host kezeli.
• A checkeknek bizonyítaniuk kell, hogy tényleg ellenőriztek valamit: minden check jelenti, hány fájlt nézett meg, illetve minden új checkhez tartozik egy teszt, amely szándékosan elbuktatja.
• A csapat tudása a repóba kerül: kb. 30 szabályfájlt olvasnak be az agentek minden munka elején.
• A kódbázist a párhuzamos munkához alakították: a Rust crate-ek négy szerepbe kerültek, az implementációk közti függőségek száma 216-ról nullára esett.
• Az automatizált loopoknak mérhető célt, attempt-limitet és olyan listát adtak, hogy mihez kell továbbra is ember, például a production deployhoz.

A review is agentekkel indul: a medián első visszajelzés nagyjából négy és fél perc alatt jön. Egy érzékeny változásnál viszont a reviewer agentek nem találtak hibát, a mérnökök ugyanabban a diffben négy blokkoló problémát. Ezért a kritikus változásoknál legalább egy emberi ellenőrzés kötelező maradt.

Hogyan sikerült a váltás Pythonról Rustra?

A Python runtime terhelés alatt akár 11,9 másodperces event loop akadásokat produkált, a session setupok 16,7 százaléka pontosan 5 másodpercig tartott egy rejtett timeout miatt. Ráadásul egy héten egyetlen clusteren 539-szer lőtte ki a memóriahiány.

A portolást úgy ellenőrizték, hogy a valódi Python kódot lefuttatták bemenetek sorozatán, a kimenetet JSON fixture-be mentették, a Rust tesztnek pedig ezt kellett pontosan visszaadnia. Kb. 430 ilyen fixture van. A forgalmat clusterenként, visszakapcsolható flagekkel vitték át: október 9-én törölték a Pythont (kb. 8000 fájl, 4,9 millió sor), október 10-én költözött az utolsó cluster.

Az első turn time to first tokenje p50-en 7,9-ről 2,7 másodpercre, p90-en 14,5-ről 6,2 másodpercre csökkent. A szerző szerint ennek jelentős része abból jön, hogy az agent loop kikerült a lassan induló konténerből. Költségről nem állítanak semmit, mert még nem mérték rendesen.

Mit vihetünk ebből haza?

A cikk nem a PR-számról szól, hanem arról, hova kerül az emberi figyelem, ha a kód gyorsabban érkezik, mint ahogy el lehet olvasni. A legolcsóbb kezdés, amit a szerző is javasol: fogj egy checket, amiben megbízol, aztán bizonyosodj meg róla, hogy tényleg el tud bukni.