Opin forskrift fyrir Codex-hljómsveitarstjórn: Symphony
Eftir Alex Kotliarskyi, Victor Zhu og Zach Brock
Fyrir sex mánuðum, þegar teymið okkar vann að innra framleiðniverkfæri, tókum við umdeilda ákvörðun (á þeim tíma): við myndum byggja geymsluna okkar án nokkurs kóða skrifaðs af mönnum. Hver einasta lína í verkefnageymslunni okkar þurfti að vera mynduð af Codex.
Til að láta það ganga upp endurhönnuðum við verkfræðiverkflæðið okkar frá grunni. Við byggðum geymslu sem er vingjarnleg fyrir fulltrúa, fjárfestum mikið í sjálfvirkum prófum og öryggisvörnum og komum fram við Codex sem fullgildan liðsfélaga. Við skráðum þá vegferð í fyrri bloggfærslu okkar um harness engineering.
Og það virkaði, en síðan rákumst við á næsta flöskuháls: samhengisskipti.
Til að leysa þetta nýja vandamál byggðum við kerfi sem kallast Symphony. Symphony(opnast í nýjum glugga) er hljómsveitarstjóri fulltrúa sem breytir verkefnastjórnartöflu eins og Linear í stjórnplan fyrir kóðunarfulltrúa. Hvert opið verkefni fær fulltrúa, fulltrúar keyra stöðugt og menn fara yfir niðurstöðurnar.
Þessi færsla útskýrir hvernig við bjuggum til Symphony—sem skilaði 500% aukningu í sameinuðum pull requests hjá sumum teymum—og hvernig þú getur notað það til að breyta þínum eigin málaskrá í sívirkan hljómsveitarstjóra fulltrúa.
Þakið á gagnvirkum kóðunarfulltrúum
Jafnvel þótt þeir verði auðveldari í notkun eru kóðunarfulltrúar—hvort sem nálgast má þá í gegnum vefforrit eða CLI—enn gagnvirk verkfæri.
Þegar umfang fulltrúavinnu jókst hjá OpenAI fundum við fyrir nýrri tegund byrði. Hver verkfræðingur opnaði nokkrar Codex-lotur, úthlutaði verkefnum, fór yfir úttakið, stýrði fulltrúanum og endurtók svo leikinn. Í reynd gátu flestir þægilega stjórnað þremur til fimm lotum í einu áður en samhengisskipti urðu sársaukafull. Umfram það dró úr framleiðni. Við gleymdum hvaða lota var að gera hvað, hoppuðum milli skeljaglugga til að ýta fulltrúum aftur á rétta braut og aflúsuðum langkeyrð verkefni sem stöðvuðust hálfnuð.
Fulltrúarnir voru hraðir, en við höfðum flöskuháls í kerfinu: athygli manna. Við höfðum í raun byggt teymi af afar hæfum yngri verkfræðingum og síðan falið mannlegu verkfræðingunum okkar að örstýra þeim. Það ætlaði ekki að skala.
Sjónarhornsbreyting
Við áttuðum okkur á að við vorum að hámarka rangan hlut. Við höfðum skipulagt kerfið okkar í kringum kóðunarlotur og sameinaðar PR, þegar PR og lotur eru í raun aðeins leið að markmiði. Hugbúnaðarverkflæði eru að mestu skipulögð í kringum afhendingar: mál, verkefni, miða, áfanga.
Því spurðum við okkur hvað myndi gerast ef við hættum að hafa beint eftirlit með fulltrúum og létum þá þess í stað sækja vinnu úr verkefnaskránni okkar.
Sú hugmynd varð að Symphony, skrifaðri forskrift sem gegnir hlutverki umsjónaraðila við að samhæfa fulltrúadrifið starf.
Að breyta málaskránni okkar í hljómsveitarstjóra fulltrúa
Symphony byrjaði á einfaldri hugmynd: sérhvert opið verkefni ætti að vera tekið upp og klárað af fulltrúa. Í stað þess að stjórna Codex-lotum í mörgum flipum gerðum við málaskrána okkar að stjórnplaninu.
Í þessari uppsetningu er hverju opnu Linear-máli varpað á sérstakt vinnusvæði fulltrúa. Symphony fylgist stöðugt með verkefnatöflunni og tryggir að hvert virkt verkefni hafi fulltrúa í gangi í lykkjunni þar til því er lokið. Ef fulltrúi hrynur eða festist endurræsir Symphony hann. Ef ný vinna birtist tekur Symphony hana upp og byrjar að skipuleggja verkið.
Við byggðum verkflæðið okkar á stöðu miða og notuðum verkefnastjórann Linear sem stöðuvél.
Í reynd aftengir Symphony vinnu frá lotum og frá pull requests. Sum mál leiða til margra PR þvert á geymslur; önnur eru hrein rannsókn eða greining sem snertir aldrei kóðagrunninn.
Þegar vinna er afmörkuð á þennan hátt geta miðar táknað miklu stærri vinnueiningar.
Við notum Symphony reglulega til að samhæfa flókna eiginleika og flutninga á innviðum. Til dæmis gætum við skráð verkefni þar sem fulltrúinn er beðinn um að greina kóðagrunninn, Slack eða Notion og skila útfærsluáætlun. Þegar við erum ánægð með áætlunina myndar fulltrúinn tré verkefna, brýtur verkið niður í áfanga og skilgreinir ósjálfstæði milli verkefna.
Fulltrúar byrja aðeins að vinna að verkefnum sem eru ekki stöðvuð, þannig að framkvæmdin þróast eðlilega og ákjósanlega samhliða fyrir þetta DAG (röð framkvæmdarskrefa). Í dæminu hér að neðan merktum við React-uppfærsluna sem stöðvaða af flutningi yfir í Vite. Eins og við var að búast byrjuðu fulltrúar að uppfæra React aðeins eftir að flutningi yfir í Vite var lokið.
Fulltrúar geta líka búið til vinnu sjálfir. Við útfærslu eða yfirferð taka þeir oft eftir umbótum sem falla utan umfangs núverandi verkefnis: afkastavandamál, tækifæri til endurskipulagningar eða betri högun. Þegar það gerist skrá þeir einfaldlega nýtt mál sem við getum metið og tímasett síðar—mörg þessara eftirfylgniverkefna eru líka tekin upp af fulltrúum. Þó við höfum yfirsýn yfir þetta ferli halda fulltrúar skipulagi og ýta verkinu áfram.
Þessi vinnuaðferð dregur verulega úr hugrænum kostnaði við að setja af stað óljósa vinnu. Ef fulltrúinn gerir eitthvað rangt eru það samt gagnlegar upplýsingar og kostnaðurinn fyrir okkur er nær enginn. Við getum mjög auðveldlega skráð miða fyrir fulltrúann til að fara í frumgerð og könnun og hent öllum könnunum sem okkur líkar ekki.
Þar sem hljómsveitarstjórinn keyrir á devboxes og sefur aldrei getum við bætt við verkefnum hvaðan sem er og vitað að fulltrúi taki þau upp. Til dæmis gerði einn verkfræðingur í teyminu okkar þrjár verulegar breytingar úr Linear-forritinu í símanum sínum úr notalegum kofa á lélegu wifi.
Aukin könnun með þessum vinnuhætti
Þegar við fylgdumst með áhrifum þess að vinna með Symphony var augljósasta breytingin afköst. Hjá sumum teymum hjá OpenAI sáum við fjölda sameinaðra PR aukast sexfalt á fyrstu þremur vikunum. Utan OpenAI benti stofnandi Linear, Karri Saarinen, á stökk í fjölda vinnusvæða sem voru búin til(opnast í nýjum glugga) þegar við gáfum Symphony út. En dýpri breytingin er hvernig teymi hugsa um vinnu.
Þegar verkfræðingarnir okkar eyða ekki lengur tíma í að hafa eftirlit með Codex-lotum breytist hagfræðin í kóðabreytingum algjörlega. Skynjaður kostnaður hverrar breytingar lækkar því við erum ekki lengur að leggja mannlega vinnu í að keyra sjálfa útfærsluna.
Það breytti hegðun okkar. Nú er orðið léttvægt að spinna upp tilgátukennd verkefni í Symphony. Prófaðu hugmynd, kannaðu endurskipulagningu, prófaðu tilgátu og haltu aðeins þeim niðurstöðum sem lofa góðu.
Þetta víkkar líka út hver getur hafið vinnu. Vörustjóri okkar og hönnuður geta nú skráð eiginleikabeiðnir beint inn í Symphony. Þau þurfa ekki að sækja geymsluna eða stjórna Codex-lotu. Þau lýsa eiginleikanum og fá til baka yfirferðarpakka sem inniheldur myndbandsleiðsögn um eiginleikann að virka inni í raunverulegu vörunni.
Symphony skarar einnig fram úr í stórum eingeymslum (eins og þeirri sem við höfum hjá OpenAI) þar sem síðasti áfanginn við að sameina PR er hægur og brothættur. Kerfið fylgist með CI, endurgrunnsetur þegar þarf, leysir árekstra, reynir aftur óáreiðanlegar athuganir og fylgir breytingum almennt í gegnum ferlið. Þegar miði nær Merging höfum við mikla vissu um að breytingin komist inn í aðalgreinina án þess að menn þurfi að vaka yfir henni.
Eftir að Symphony var innleitt felum við fulltrúum meira verk og einbeitum okkur að erfiðari og meira könnunarkenndum verkefnum.
Framfarir koma með ný, öðruvísi vandamál
Að starfa á þessu stigi felur í sér málamiðlanir. Þegar við færðum okkur frá því að stýra fulltrúum gagnvirkt yfir í að úthluta þeim vinnu á miðastigi misstum við getu til að ýta stöðugt við þeim á miðri leið og leiðrétta stefnu þegar þess þurfti. Stundum skilaði fulltrúinn einhverju sem gjörsamlega missti marks. Það var gagnlegt—slík mistök afhjúpuðu glufur í kerfinu og hjálpuðu okkur að gera það traustara.
Í stað þess að lagfæra niðurstöðuna handvirkt bættum við við öryggisvörnum og færni svo fulltrúarnir gætu tekist betur næst. Með tímanum leiddi þetta okkur til að bæta nýjum getuþáttum í umgjörðina okkar, eins og að keyra enda-til-enda próf, stýra forritinu í gegnum Chrome DevTools og stjórna QA smoke-prófum. Við bættum skjalfestinguna okkar verulega og skýrðum betur hvernig gott lítur út.
Ekki hvert verkefni hentar vinnustíl Symphony. Sum vandamál krefjast enn verkfræðinga sem vinna beint með gagnvirkum Codex-lotum, sérstaklega óljós vandamál eða vinna sem krefst sterks dómgreindar og sérþekkingar. Í reynd eru þetta yfirleitt áhugaverðustu og skemmtilegustu verkefnin fyrir verkfræðingana okkar að verja tíma í.
Munurinn er sá að Symphony getur séð um meginhluta venjubundinnar útfærsluvinnu. Það gerir verkfræðingum kleift að einbeita sér að einu erfiðu vandamáli í einu í stað þess að vera sífellt að skipta um samhengi milli smærri verkefna.
Við lærðum líka að það virkar ekki vel að meðhöndla fulltrúa sem stífa hnúta í stöðuvél. Líkön verða snjallari og geta leyst stærri vandamál en kassinn sem við reynum að troða þeim í. Til dæmis voru GitHub-samþættingar í fyrstu útgáfunum allar hluti af ytri umgjörðinni—til dæmis gerðu fyrstu útgáfur ráð fyrir að Codex gerði aðeins kóðabreytingar, en skilgreindu afganginn af ferlinu (að senda inn breytingar, keyra próf) í kóða. Í fyrstu útgáfum okkar af fulltrúadrifinni vinnu var Codex aðeins beðið um að útfæra verkefnið. Sú nálgun reyndist of takmarkandi. Codex er fullkomlega fært um að búa til mörg PR sem og að lesa yfirferðarábendingar og bregðast við þeim. Því gáfum við því verkfæri—gh CLI, færni til að lesa CI-kladda o.s.frv.—og nú getum við beðið Codex um að gera meira, eins og að loka gömlum PR eða draga fram skýrslur um lokið verk á móti yfirgefnu. Þessar tegundir verkefna féllu langt utan upphaflega kassans um eiginleikainnleiðingu.
Þannig færðumst við að lokum í átt að því að gefa fulltrúum markmið frekar en strangar tilfærslur, líkt og góður stjórnandi myndi úthluta markmiði til starfsmanns í sínu teymi. Máttur líkana kemur frá getu þeirra til röksemdafærslu, svo gefðu þeim verkfæri og samhengi og leyfðu þeim að elda.
Að nota Symphony til að byggja Symphony
Þegar þú opnar Symphony-geymsluna er það fyrsta sem þú tekur eftir að Symphony er tæknilega séð bara SPEC.md-skrá—skilgreining á vandanum og fyrirhugaðri lausn. Í stað þess að byggja flókið eftirlitskerfi skilgreindum við vandann og fyrirhugaðar lausnir og gáfum fulltrúum stýringu á háu stigi.
Viðmiðunarútfærslan er skrifuð í Elixir—því þegar kóði er í raun ókeypis geturðu loksins valið tungumál út frá styrkleikum þeirra, eins og samhliða vinnslu Elixir—en kjarnahugmyndina má setja fram í einföldu Markdown-skjali. Við hvetjum þig til að beina uppáhalds kóðunarfulltrúanum þínum að forskriftinni og láta hann útfæra sína eigin útgáfu.
Fyrsta útgáfan af Symphony var bara Codex-lota keyrð í tmux, sem kannaði Linear reglulega og ræsti undirfulltrúa fyrir ný verkefni. Hún virkaði, en var ekki sérlega áreiðanleg. Önnur útgáfan var inni í aðalverkefnageymslunni okkar, sem var byggð með fulltrúa í huga. Við höfðum þegar smíðað umgjörðina fyrir fulltrúa til að gefa þeim færni og samhengi til að skila vönduðu verki í þessari geymslu, svo Symphony tengir þetta einfaldlega allt saman.
Þegar grunnvirknin var komin til staðar notuðum við Symphony til að byggja Symphony.
Þegar við sýndum kerfið innanhúss, þar sem það stýrði verkefnum og bætti við sönnunarvinnumyndbandi sínu, voru viðbrögðin afar jákvæð: Symphony-rás verkefnisins okkar stækkaði og teymi um allt fyrirtækið fóru að nota það af sjálfsdáðum. Innri product-market fit er forsenda þess að opna eitthvað út á við hjá OpenAI. Byggt á notkuninni sem við sáum hjá OpenAI varð ljóst að við ættum að deila Symphony út fyrir veggi fyrirtækisins.
Þannig drógum við hugmyndina út í sjálfstætt SPEC.md og báðum Codex um að útfæra hana. Fyrir viðmiðunarútfærsluna völdum við Elixir, tiltölulega jaðartungumál með framúrskarandi grunneiningum til að samhæfa og hafa eftirlit með samhliða ferlum. Codex smíðaði Elixir-útfærsluna í einni atrennu, og síðan héldum við áfram að endurbæta bæði forskriftina og útfærsluna. Til að fínpússa forskriftina báðum við Codex jafnvel um að útfæra hana á nokkrum öðrum tungumálum—TypeScript, Go, Rust, Java, Python—og nota niðurstöðurnar til að finna tvíræðni og einfalda kerfið. Það tókst á hverju tungumáli.
Í ferlinu við að byggja Codex fjarlægðum við mikinn tilfallandi flækjustig, eins og ósjálfstæði á tilteknum geymslum eða Linear MCP. Symphony er ekki lengur háð innri geymslum okkar eða verkflæði. Kjarnaaðferðin varð einföld:
Fyrir hvert opið verkefni, tryggðu að fulltrúi sé í gangi í sínu eigin vinnusvæði.
Auk þess að hjálpa við virka vinnu er þróunarverkflæðið nú eitthvað sem fulltrúar þekkja og fylgja. Þróunarverkflæðið—vinna að máli, sækja geymslu, setja það í vinnslu svo PM viti að verið sé að vinna að því, bæta við PR, færa það í stöðuna Review, hengja við myndbönd o.s.frv.—er nú fest í einfaldri WORKFLOW.md-skrá. Allt þetta var ferli sem menn fylgdu, en það var aldrei skjalfest. Í stað þess að reiða okkur á þetta óbeina safn skrefa skjalfestum við það nú, og Symphony tryggir að fulltrúar fylgi því. Þetta gerir okkur kleift að byggja fulltrúa sem vinna með okkur. Ef við ákveðum að fulltrúar eigi líka að hengja við sjálfsígrundun með loknu verki bætum við því við WORKFLOW.md, og Symphony mun leiða fulltrúana að því skrefi.
Við fengum líka að nota Codex í app server mode(opnast í nýjum glugga), innbyggðum höfuðlausum ham fyrir Codex. Þessi hamur gerði okkur kleift að keyra Codex og eiga samskipti við það forritunarlega í gegnum vel skjalfest JSON-RPC API fyrir hluti eins og að hefja þráð eða bregðast við umferðum. Þetta er mun þægilegri og skalanlegri leið en að reyna að eiga samskipti við Codex í gegnum CLI eða lifandi tmux-lotur.
Codex App Server hentaði fullkomlega fyrir notkunartilvikið okkar: við nýtum okkur umgjörðina sem Codex veitir á meðan við höfum stillihnappa og króka til að tengjast við. Til dæmis, til að forðast að afhjúpa Linear-aðgangstókarann fyrir undirfulltrúum, notum við dynamic tool calls(opnast í nýjum glugga) til að afhjúpa hráa linear_graphql-fallið sem framkvæmir handahófskenndar beiðnir gegn Linear, án þess að reiða sig á MCP eða afhjúpa aðgangstókarann fyrir ílátum.
Hvað er næst
Symphony er viljandi lágmarks hljómsveitarstjórnarlag. Við gerum það opið til að sýna fram á mátt Codex App Server þegar það er parað við ólík verkflæðisverkfæri, eins og Linear. Sem slíkt ætlum við ekki að viðhalda Symphony sem sjálfstæðri vöru. Hugsaðu um það sem viðmiðunarútfærslu. Líkt og margir forritarar beindu kóðunarfulltrúum sínum að færslunni um harness engineering til að setja upp geymslur sínar, vonum við að þú beinir uppáhalds kóðunarfulltrúanum þínum að Symphony-forskriftinni(opnast í nýjum glugga) og geymslunni(opnast í nýjum glugga) til að byggja þínar eigin útgáfur sniðnar að þínum umhverfum.
Mátturinn kemur frá Codex og app server þess. Symphony var leið til að tengja Codex við Linear, tvo hluti sem við notuðum þegar, til að leysa vandann við verkstjórnun. Eftir því sem kóðunarfulltrúar verða betri í röksemdafærslu og að fylgja fyrirmælum grunum við að flöskuhálsinn hjá öðrum fyrirtækjum muni einnig færast frá því að skrifa kóða yfir í að stýra fulltrúadrifinni vinnu. Það spennandi er að þröskuldurinn fyrir tilraunir með þessi kerfi kóðunarfulltrúa er nú furðu lágur. Þú getur einfaldlega byggt hluti með Codex.
Hrós frá samfélaginu
Við erum himinlifandi að sjá verkfræðisamfélagið nota Symphony vikurnar eftir útgáfu, og það hefur hlotið yfir 15 þúsund GitHub-stjörnur(opnast í nýjum glugga) frá og með 23. apríl.