ከስድስት ወራት በፊት፣ በውስጣዊ የምርታማነት መሳሪያ ላይ እየሰራን ሳለ፣ ቡድናችን በዚያን ጊዜ አከራካሪ የነበረ ውሳኔ አደረገ፦ የእኛን ማከማቻ ምንም በሰው እጅ የተጻፈ ኮድ ሳይኖር እንገነባዋለን። በፕሮጀክታችን ማከማቻ ውስጥ ያለ እያንዳንዱ መስመር በ Codex መፈጠር ነበረበት።
ይህ እንዲሰራ፣ የኢንጂነሪንግ የስራ ሂደታችንን ከሥሩ እንደገና ነደፍን። ለወኪሎች ተስማሚ የሆነ ማከማቻ ገነባን፣ በራስ-ሰር ሙከራዎች እና መከላከያዎች ላይ በጣም ብዙ ኢንቨስት አደረግን፣ እና Codex ን እንደ ሙሉ ተባባሪ ቆጠርነው። ያንን ጉዞ በቀድሞው ስለ harness engineering ብሎግ ልጥፋችን ውስጥ ሰነድ አድርገነዋል።
እና ሰርቷል፣ ግን ከዚያ ቀጣዩን የማነቆ ነጥብ አጋጠመን፦ የአውድ መቀያየር።
ይህን አዲስ ችግር ለመፍታት፣ Symphony የተባለ ስርዓት ገነባን። Symphony(በአዲስ መስኮት ውስጥ ይክፈታል) እንደ Linear ያለ የፕሮጀክት አስተዳደር ሰሌዳን ለኮድ ወኪሎች የመቆጣጠሪያ ንብርብር የሚያደርግ የወኪል አቀናባሪ ነው። እያንዳንዱ ክፍት ተግባር ወኪል ያገኛል፣ ወኪሎች ያለማቋረጥ ይሰራሉ፣ እና ሰዎች ውጤቶቹን ይገመግማሉ።
ይህ ልጥፍ Symphony እንዴት እንደፈጠርነው—በአንዳንድ ቡድኖች ላይ የተቀላቀሉ pull request መጠን 500% እንዲጨምር ያደረገውን—እና የራስዎን issue tracker ሁልጊዜ የሚሰራ የወኪል አቀናባሪ እንዴት እንደሚያደርጉት ያብራራል።
የተግባቦታዊ ኮድ ወኪሎች ገደብ
ለመጠቀም እየቀለሉ ቢመጡም፣ የኮድ ወኪሎች—በድር መተግበሪያዎችም ሆነ በ CLI የሚደረስባቸው—አሁንም ተግባቦታዊ መሳሪያዎች ናቸው።
በ OpenAI ውስጥ የወኪል ስራ መጠን ሲጨምር፣ አዲስ ዓይነት ሸክም አገኘን። እያንዳንዱ ኢንጂነር ጥቂት የ Codex ክፍለ ጊዜዎችን ይከፍታል፣ ተግባራትን ይመድባል፣ ውጤቱን ይገመግማል፣ ወኪሉን አቅጣጫ ይሰጠዋል፣ እና ይደግማል። በተግባር፣ አብዛኞቹ ሰዎች የአውድ መቀያየር ከባድ ከመሆኑ በፊት በአንድ ጊዜ ሶስት እስከ አምስት ክፍለ ጊዜዎችን በምቾት ማስተዳደር ይችሉ ነበር። ከዚያ በላይ ምርታማነት ይቀንስ ነበር። የትኛው ክፍለ ጊዜ ምን እንደሚሰራ እንረሳ ነበር፣ ወኪሎችን ወደ መስመር ለመመለስ መካከል በቴርሚናሎች እንዘላለን ነበር፣ እና ግማሽ መንገድ ላይ የቆሙ ረጅም ጊዜ የሚወስዱ ተግባራትን እንስተካክል ነበር።
ወኪሎቹ ፈጣኖች ነበሩ፣ ግን የስርዓት ማነቆ ነበረን፦ የሰው ትኩረት። በተግባር በጣም ብቃት ያላቸው ጁኒየር ኢንጂነሮች ቡድን ገንብተን ነበር፣ ከዚያም የሰው ኢንጂነሮቻችንን እነሱን በቅርብ እንዲቆጣጠሩ መድበናቸው ነበር። ይህ ሊሰፋ የሚችል አልነበረም።
የአመለካከት ለውጥ
የተሳሳተውን ነገር እያሻሻልን እንዳለን ተገነዘብን። ስርዓታችንን በኮድ ክፍለ ጊዜዎች እና በተዋሃዱ PRዎች ዙሪያ እያደራጀን ነበር፣ ነገር ግን PRዎች እና ክፍለ ጊዜዎች በእውነት ወደ ግብ የሚወስዱ መንገዶች ብቻ ናቸው። የሶፍትዌር የስራ ሂደቶች በአብዛኛው በሚደርሱ ውጤቶች ዙሪያ ይደራጃሉ፦ issues፣ tasks፣ tickets፣ milestones።
ስለዚህ ወኪሎችን በቀጥታ መቆጣጠር ብናቆም እና በምትኩ ከተግባር መከታተያችን ስራን እንዲወስዱ ብንፈቅድላቸው ምን እንደሚሆን ራሳችንን ጠየቅን።
ያ ሐሳብ Symphony ሆነ፣ እሱም የወኪል ስራን ለማቀናበር እንደ ተቆጣጣሪ የሚሰራ የተጻፈ spec ነው።
የእኛን issue tracker ወደ የወኪል አቀናባሪ መቀየር
Symphony በቀላል ጽንሰ ሐሳብ ተጀመረ፦ ማንኛውም ክፍት ተግባር በወኪል መወሰድ እና መጠናቀቅ አለበት። የ Codex ክፍለ ጊዜዎችን በብዙ ታቦች ውስጥ ከማስተዳደር ይልቅ፣ issue tracker ን የመቆጣጠሪያ ንብርብራችን አደረግነው።
በዚህ አወቃቀር ውስጥ፣ እያንዳንዱ ክፍት የ Linear issue ከተለየ የወኪል የስራ ቦታ ጋር ይዛመዳል። Symphony የተግባር ሰሌዳውን በቀጣይነት ይከታተላል እና እያንዳንዱ ንቁ ተግባር እስኪጠናቀቅ ድረስ በሂደቱ ውስጥ የሚሰራ ወኪል እንዳለው ያረጋግጣል። ወኪል ከተበላሸ ወይም ከቆመ፣ Symphony እንደገና ይጀምረዋል። አዲስ ስራ ከተገኘ፣ Symphony ይወስደዋል እና ስራውን ማደራጀት ይጀምራል።
የስራ ሂደታችንን በቲኬት ሁኔታዎች ላይ መስርተን ገንብተናል፣ የተግባር አስተዳዳሪውን Linear እንደ ሁኔታ ማሽን በመጠቀም።
በተግባር፣ Symphony ስራን ከክፍለ ጊዜዎች እና ከ pull requestዎች ይለያያል። አንዳንድ issues በተለያዩ ማከማቻዎች ውስጥ ብዙ PRዎችን ይፈጥራሉ፤ ሌሎች ግን ኮድ መሠረቱን ፈጽሞ የማይነኩ ንጹህ ምርመራ ወይም ትንተና ናቸው።
ስራ በዚህ መንገድ ሲወሰን፣ ቲኬቶች በጣም ትልቅ የስራ ክፍሎችን ሊወክሉ ይችላሉ።
እኛ በመደበኛነት Symphony ን ውስብስብ ባህሪያትን እና የመሠረተ ልማት ፍልሰቶችን ለማቀናበር እንጠቀማለን። ለምሳሌ፣ ወኪሉ ኮድ መሠረቱን፣ Slack ወይም Notion እንዲተነትን እና የትግበራ እቅድ እንዲያቀርብ የሚጠይቅ ተግባር ልንከፍት እንችላለን። በእቅዱ ደስ ካለን በኋላ፣ ወኪሉ የተግባራት ዛፍ ይፈጥራል፣ ስራውን ወደ ደረጃዎች ይከፋፍላል እና በተግባራት መካከል ጥገኝነቶችን ይገልጻል።
ወኪሎች የሚጀምሩት የማይታገዱ ተግባራት ላይ ብቻ ነው፣ ስለዚህ አፈጻጸሙ ለዚህ DAG (የአፈጻጸም ደረጃዎች ቅደም ተከተል) በተፈጥሯዊ እና በተመቻቸ ሁኔታ በትይዩ ይቀጥላል። ከታች ባለው ምሳሌ፣ የ React ማሻሻያውን በ Vite ፍልሰት ላይ እንደታገደ ምልክት አድርገናል። እንደተጠበቀው፣ ወኪሎች React ን ማሻሻል የጀመሩት ወደ Vite የሚደረገው ፍልሰት ከተጠናቀቀ በኋላ ብቻ ነው።
ወኪሎች ራሳቸውም ስራ ሊፈጥሩ ይችላሉ። በትግበራ ወይም በግምገማ ጊዜ፣ ብዙ ጊዜ ከአሁኑ ተግባር ወሰን ውጭ ያሉ ማሻሻያዎችን ያስተውላሉ፦ የአፈጻጸም ችግር፣ እንደገና የማዋቀር እድል፣ ወይም የተሻለ አርክቴክቸር። ይህ ሲከሰት፣ በቀላሉ በኋላ ልንገመግመው እና መርሐግብር ልናወጣለት የምንችለውን አዲስ issue ይከፍታሉ—ከእነዚህ ተከታታይ ተግባራት ብዙዎቹም በወኪሎች ይወሰዳሉ። እኛ ይህን ሂደት ስንቆጣጠር፣ ወኪሎች የተደራጁ ሆነው ይቆያሉ እና ስራውን ወደፊት ያንቀሳቅሳሉ።
ይህ የስራ መንገድ ግልጽ ያልሆነ ስራን ለመጀመር የሚኖረውን የአእምሮ ወጪ በእጅጉ ይቀንሳል። ወኪሉ አንድ ነገር ቢሳሳትም፣ ያ አሁንም ጠቃሚ መረጃ ነው፣ እና ለእኛ የሚያስከፍለው ወጪ ወደ ዜሮ ቅርብ ነው። ወኪሉ ፕሮቶታይፕ እንዲያደርግ እና እንዲያሰሳ ቲኬቶችን በጣም ዝቅተኛ ወጪ ማስገባት እንችላለን፣ እና የማንወዳቸውን አሰሳዎች መጣል እንችላለን።
አቀናባሪው በ devboxes ላይ ስለሚሰራ እና ፈጽሞ ስለማይተኛ፣ ተግባራትን ከማንኛውም ቦታ ማከል እንችላለን እና ወኪል እንደሚወስደው እናውቃለን። ለምሳሌ፣ በቡድናችን ውስጥ አንድ ኢንጂነር ደካማ ዋይፋይ ባለበት ምቹ ጎጆ ውስጥ ሆኖ ከስልኩ በ Linear መተግበሪያ ሶስት አስፈላጊ ለውጦችን አድርጓል።
በዚህ መንገድ ከመስራት የተነሳ የአሰሳ ጭማሪ
ከ Symphony ጋር መስራት የሚያመጣውን ተፅዕኖ ስንመለከት፣ በጣም ግልጽ የነበረው ለውጥ ውጤት ነበር። በ OpenAI ውስጥ በአንዳንድ ቡድኖች፣ የተቀላቀሉ PRዎች ቁጥር በመጀመሪያዎቹ ሦስት ሳምንታት ውስጥ 6X እንደጨመረ አየን። ከ OpenAI ውጭ፣ የ Linear መስራች Karri Saarinen Symphony ን ስንለቅቅ በተፈጠሩ የስራ ቦታዎች ላይ የታየ ጉልህ ጭማሪ(በአዲስ መስኮት ውስጥ ይክፈታል) አስቀምጧል። ሆኖም ጥልቁ ለውጥ ቡድኖች ስለ ስራ እንዴት እንደሚያስቡ ነው።
ኢንጂነሮቻችን የ Codex ክፍለ ጊዜዎችን ለመቆጣጠር ጊዜ ሲያቆሙ፣ የኮድ ለውጦች ኢኮኖሚ ሙሉ በሙሉ ይለወጣል። የእያንዳንዱ ለውጥ የሚታሰበው ወጪ ይቀንሳል፣ ምክንያቱም ትግበራውን ራሱ ለመንዳት ከእንግዲህ በኋላ የሰው ጥረት አንፈጅም።
ይህ ባህሪያችንን ለወጠው። በ Symphony ውስጥ ግምታዊ ተግባራትን መጀመር ቀላል ሆኗል። ሐሳብ ሞክር፣ እንደገና ማዋቀር አስስ፣ ግምት ፈትሽ፣ እና ተስፋ የሚሰጡ ውጤቶችን ብቻ አቆይ።
ይህ ስራን ማን መጀመር እንደሚችልም ያሰፋዋል። የምርት አስተዳዳሪያችን እና ዲዛይነራችን አሁን የባህሪ ጥያቄዎችን በቀጥታ ወደ Symphony ማስገባት ይችላሉ። ማከማቻውን መክፈት ወይም የ Codex ክፍለ ጊዜ ማስተዳደር አያስፈልጋቸውም። ባህሪውን ይገልጻሉ እና ባህሪው በእውነተኛው ምርት ውስጥ ሲሰራ የሚያሳይ የቪዲዮ ጉብኝት ያካተተ የግምገማ ፓኬት ይመለስላቸዋል።
Symphony በትልቅ monorepoዎች ውስጥም ይበራል (እንደ እኛ በ OpenAI ያለው)፣ እዚያ የ PR መጨረሻ ማረፊያ ዘገምተኛ እና ደካማ ነው። ስርዓቱ CI ን ይከታተላል፣ አስፈላጊ ሲሆን rebase ያደርጋል፣ ግጭቶችን ይፈታል፣ የማይረጋጉ ፍተሻዎችን እንደገና ይሞክራል፣ እና በአጠቃላይ ለውጦቹን በሂደቱ ውስጥ ያሳልፋል። ቲኬት ወደ Merging ሲደርስ፣ ለውጡ ያለ የሰው እንክብካቤ ወደ ዋናው ቅርንጫፍ እንደሚገባ ከፍተኛ እምነት አለን።
እድገት ከአዲስ፣ የተለያዩ ችግሮች ጋር ይመጣል
በዚህ ደረጃ መስራት የሚጠይቀው መስዋዕት አለው። ከወኪሎችን በተግባቦት መምራት ወደ በቲኬት ደረጃ ስራ መመደብ በሄድን ጊዜ፣ በመካከለኛው ጉዞ ላይ ያለማቋረጥ መገፋፋትና አስፈላጊ ሲሆን አቅጣጫ ማስተካከል የምንችለውን ችሎታ አጣን። አንዳንድ ጊዜ ወኪሉ ፈጽሞ ዒላማውን ያልመታ ነገር ይፈጥር ነበር። ያ ጠቃሚ ነበር—እነዚያ ውድቀቶች በስርዓቱ ውስጥ ያሉ ክፍተቶችን ገልጠዋል እና የበለጠ ጽኑ እንዲሆን እርዳታ አድርገዋል።
ውጤቱን በእጅ ከማስተካከል ይልቅ፣ ወኪሎቹ በሚቀጥለው ጊዜ እንዲሳካላቸው መከላከያዎችን እና ክህሎቶችን ጨመርን። በጊዜ ሂደት፣ ይህ በ harness ውስጥ አዳዲስ ችሎታዎችን እንድንጨምር አደረገን፣ እንደ end-to-end ሙከራዎችን ማስኬድ፣ መተግበሪያውን በ Chrome DevTools መንዳት፣ እና የ QA smoke tests ማስተዳደር። ሰነዶቻችንን በእጅጉ አሻሽለናል እና ጥሩ ምን እንደሚመስል ግልጽ አድርገናል።
ሁሉም ተግባር ለ Symphony የስራ ዘይቤ አይመችም። አንዳንድ ችግሮች አሁንም ኢንጂነሮች በቀጥታ ከተግባቦታዊ Codex ክፍለ ጊዜዎች ጋር እንዲሰሩ ይጠይቃሉ፣ በተለይም ግልጽ ያልሆኑ ችግሮች ወይም ጠንካራ ውሳኔ እና ሙያ የሚፈልጉ ስራዎች። በተግባር፣ እነዚህ ብዙ ጊዜ ኢንጂነሮቻችን ጊዜ ለማሳለፍ በጣም አስደሳች እና አስተማማኝ ተግባራት ናቸው።
ልዩነቱ ግን Symphony የመደበኛ ትግበራ ስራውን አብዛኛውን ሊይዝ መቻሉ ነው። ይህ ኢንጂነሮች በትንንሽ ተግባራት መካከል ያለማቋረጥ ከአውድ ወደ አውድ ከመቀያየር ይልቅ በአንድ ጊዜ በአንድ ከባድ ችግር ላይ እንዲያተኩሩ ያደርጋል።
ወኪሎችን በሁኔታ ማሽን ውስጥ እንደ ጠንካራ ማነቃነቆች መቆጠር ጥሩ እንደማይሰራም ተማርን። ሞዴሎች ይበልጥ ብልህ እየሆኑ ይሄዳሉ እና እኛ ልናስገባቸው ከምንሞክረው ሳጥን የበለጠ ትልልቅ ችግሮችን ሊፈቱ ይችላሉ። ለምሳሌ፣ ቀደምት ስሪቶች ሁሉንም የ GitHub ውህደቶች እንደ ውጫዊ harness ክፍል አድርገው ነበር—ለምሳሌ፣ ቀደምት ስሪቶች Codex ኮድ ለውጦችን ብቻ እንዲያደርግ ይጠብቁ ነበር፣ ቀሪውን ሂደት (ለውጦችን ማስገባት፣ ሙከራዎችን ማስኬድ) በኮድ ይወስኑ ነበር። የመጀመሪያ የወኪል ስራ ስሪቶቻችን Codex ተግባሩን እንዲተገብር ብቻ መጠየቅ ነበር። ያ አቀራረብ በጣም የሚገድብ መሆኑ ታየ። Codex ብዙ PRዎችን መፍጠር እንዲሁም የግምገማ አስተያየቶችን ማንበብ እና ምላሽ መስጠት ፍጹም ይችላል። ስለዚህ መሳሪያዎችን ሰጠነው—gh CLI፣ CI logs ለማንበብ ክህሎቶች፣ ወዘተ—እና አሁን Codex እንደ አሮጌ PRዎችን መዝጋት ወይም ስለ የተጠናቀቀ እና የተተወ ስራ ሪፖርቶችን ማውጣት ያሉ ብዙ ነገሮች እንዲያደርግ መጠየቅ እንችላለን። እነዚህ ዓይነት ተግባራት ከመጀመሪያው የባህሪ ትግበራ ሳጥን እጅግ ውጭ ነበሩ።
ስለዚህ በመጨረሻ ለወኪሎች ጥብቅ ሽግግሮች ከመስጠት ይልቅ ዓላማዎች ለመስጠት ተመለስን፣ ጥሩ አስተዳዳሪ በቡድኑ ውስጥ ለቀጥታ ሪፖርቱ ግብ እንደሚሰጥ በመሳሰሉ መልኩ። የሞዴሎች ኃይል ከማመዛዘን ችሎታቸው ይመነጫል፣ ስለዚህ መሳሪያዎችን እና አውድን ስጧቸው እና ስራቸውን እንዲሰሩ ፍቀዱላቸው።
Symphony ን በመጠቀም Symphony ን መገንባት
የ Symphony ማከማቻን ሲከፍቱ፣ መጀመሪያ የሚያስተውሉት Symphony በቴክኒክ ደረጃ ብቻ አንድ SPEC.md ፋይል መሆኑን ነው—የችግሩ እና የታሰበው መፍትሄ መግለጫ። ውስብስብ የቁጥጥር ስርዓት ከመገንባት ይልቅ፣ ችግሩን እና የታሰቡ መፍትሄዎችን ገለጽን፣ ለወኪሎችም ከፍተኛ ደረጃ መምሪያ ሰጠናቸው።
የማጣቀሻ ትግበራው በ Elixir ተጽፏል—ምክንያቱም ኮድ በተግባር ነጻ በሆነ ጊዜ፣ በመጨረሻ ቋንቋዎችን በጥንካሬያቸው መሠረት መምረጥ ይቻላል፣ እንደ Elixir ያለው ተመሳሳይ ሂደት አፈጻጸም—ነገር ግን ዋናው ሐሳብ በቀላል Markdown ሰነድ ሊገለጽ ይችላል። የምትወዱትን የኮድ ወኪል ወደ spec እንዲመለከት እና የራሱን ስሪት እንዲተገብር እናበረታታችኋለን።
የ Symphony የመጀመሪያው ስሪት በ tmux ውስጥ የሚሰራ Codex ክፍለ ጊዜ ብቻ ነበር፣ Linear እየተመለከተ ለአዲስ ተግባራት ንዑስ-ወኪሎችን ይጀምር ነበር። ይሰራ ነበር፣ ግን በተለይ አስተማማኝ አልነበረም። ሁለተኛው ስሪት በዋናው የፕሮጀክት ማከማቻችን ውስጥ ነበር፣ እሱም ወኪሎችን በአእምሮ ውስጥ አድርጎ የተገነባ ነበር። በዚህ ማከማቻ ውስጥ ወኪሎች ከፍተኛ ጥራት ያለው ስራ እንዲሰሩ ክህሎቶችን እና አውድን ለመስጠት የወኪል harness አስቀድመን ገንብተን ነበር፣ ስለዚህ Symphony በቀላሉ ይህን ሁሉ ያገናኛል።
መሠረታዊ ተግባራዊነቱ ካለ በኋላ፣ Symphony በመጠቀም Symphony ራሱን ገነባን።
ስርዓቱ ተግባራትን ሲያስተዳድር እና የሥራ ማረጋገጫ ቪዲዮውን ሲያያይዝ ውስጣዊ ዴሞ ስናቀርብ፣ ምላሹ እጅግ አዎንታዊ ነበር፦ የ Symphony ፕሮጀክት ቻናላችን አደገ፣ እና በድርጅቱ አቀፍ ቡድኖች በራሳቸው ፈቃድ መጠቀም ጀመሩ። በ OpenAI ውጭ ለማስጀመር ከዚያ በፊት በውስጥ የምርት-ገበያ ተስማሚነት ማግኘት ቅድመ ሁኔታ ነው። በ OpenAI ያየነውን አጠቃቀም መሠረት በማድረግ፣ Symphony ከኩባንያው ቅጥር ውጭም ልናጋራው እንዳለብን ግልጽ ሆነ።
ስለዚህ ሐሳቡን ወደ ብቻውን የቆመ SPEC.md አወጣነው እና Codex እንዲተገብረው ጠየቅነው። ለማጣቀሻ ትግበራው፣ በአንጻራዊነት በጣም ያልተለመደ ቋንቋ ቢሆንም ተመሳሳይ ሂደቶችን ለማቀናበር እና ለመቆጣጠር እጅግ ጥሩ መሠረታዊ መሳሪያዎች ያሉትን Elixir መረጥን። Codex የ Elixir ትግበራውን በአንድ ሙከራ ገነባ፣ ከዚያም spec እና implementation ሁለቱንም ማሻሻል ቀጠልን። spec እንዲበልጥ እንኳን፣ Codex በሌሎች ብዙ ቋንቋዎች—TypeScript፣ Go፣ Rust፣ Java፣ Python—እንዲተገብረው ጠየቅነው እና ውጤቶቹን ግልጽ ያልሆኑ ነጥቦችን ለመለየትና ስርዓቱን ለማቃለል ተጠቀምንባቸው። በሁሉም ቋንቋዎች ተሳክቶለታል።
Codex በመገንባት ሂደት ውስጥ፣ ብዙ አጋጣሚያዊ ውስብስብነት አስወግደናል፣ እንደ ተወሰኑ ማከማቻዎች ወይም Linear MCP ላይ ያሉ ጥገኞች። Symphony ከእንግዲህ በኋላ በውስጣዊ ማከማቻዎቻችን ወይም የስራ ሂደቶቻችን ላይ አይመሰረትም። ዋናው አቀራረብ ቀላል ሆነ፦
ለእያንዳንዱ ክፍት ተግባር፣ ወኪል በራሱ የስራ ቦታ ውስጥ እየሰራ መሆኑን አረጋግጥ።
ከንቁ ስራ ጋር በተጨማሪ እየረዳ መሆኑ ብቻ ሳይሆን፣ የልማት የስራ ሂደት አሁን ወኪሎች የሚያውቁት እና የሚከተሉት ነገር ሆኗል። የልማት የስራ ሂደቱ—በ issue ላይ መስራት፣ ማከማቻ መክፈት፣ PM እየተሰራበት እንዳለ እንዲያውቅ ወደ in progress ማስገባት፣ PR ማከል፣ ወደ Review ሁኔታ ማንቀሳቀስ፣ ቪዲዮዎችን ማያያዝ፣ ወዘተ—አሁን በቀላል WORKFLOW.md ፋይል ውስጥ ተመዝግቧል። ይህ ሁሉ ሰዎች የሚከተሉት ሂደት ነበር፣ ግን በፍጹም ሰነድ አልተደረገለትም። በዚህ ተዋረድ ያለ የእርምጃ ስብስብ ላይ ከመመርኮዝ ይልቅ፣ አሁን ሰነድ እናደርገዋለን፣ Symphony ም ወኪሎች እንዲከተሉት ያረጋግጣል። ይህ ከእኛ ጎን ለጎን የሚሰሩ ወኪሎችን እንድንገነባ ያስችለናል። ወኪሎች በተጠናቀቀ ስራ ላይ የራሳቸውን ነጸብራቅ ደግሞ እንዲያያይዙ ብንወስን፣ ያንን ወደ WORKFLOW.md እንጨምራለን፣ እና Symphony ወኪሎቹን ወደዚያ እርምጃ ይመራቸዋል።
እኛ ደግሞ Codex ን በ app server mode(በአዲስ መስኮት ውስጥ ይክፈታል) መጠቀም ቻልን፣ እሱም ለ Codex የተገነባ ራስ-አልባ ሞድ ነው። ይህ ሞድ Codex ን እንድናስኬድ እና እንደ thread መጀመር ወይም ለ turns ምላሽ መስጠት ላሉ ነገሮች በጥሩ ሁኔታ የተሰነደ የ JSON-RPC API በመጠቀም ፕሮግራማዊ መንገድ እንድንነጋገር አስችሎናል። Codex ን በ CLI ወይም በቀጥታ tmux ክፍለ ጊዜዎች በኩል ለመገናኘት ከመሞከር ይልቅ ይህ እጅግ የበለጠ ምቹ እና ሊሰፋ የሚችል መንገድ ነው።
Codex App Server ለእኛ የአጠቃቀም ጉዳይ ፍጹም ተስማሚ ነበር፦ Codex የሚሰጠውን harness እየተጠቀምን ሳለ የምንገጥምበት መቆጣጠሪያዎችና መንጠቆዎች አሉን። ለምሳሌ፣ የ Linear የመዳረሻ token ን ለንዑስ ወኪሎች እንዳናጋልጥ፣ በ dynamic tool calls(በአዲስ መስኮት ውስጥ ይክፈታል) በመጠቀም በ Linear ላይ የሚፈጸሙ ማንኛውንም ጥያቄዎች የሚያስኬድ የጥሬ linear_graphql ተግባርን እናቀርባለን፣ MCP ላይ ሳንመሰረት ወይም የመዳረሻ token ን ለኮንቴነሮች ሳናጋልጥ።
ቀጣዩ ምንድን ነው
Symphony ሆን ተብሎ በትንሹ የተዘጋጀ የአቀናበር ንብርብር ነው። እንደ Linear ካሉ የተለያዩ የስራ ሂደት መሳሪያዎች ጋር ሲጣመር የ Codex App Server ኃይልን ለማሳየት ክፍት ምንጭ እያደረግነው ነው። እንደዚህ ስለሆነ፣ Symphony ን እንደ ብቻውን የቆመ ምርት ለመጠበቅ አናቅድም። እንደ ማጣቀሻ ትግበራ ይመልከቱት። ብዙ አበልፀግያ መሳርያ አበልፀጎች ማከማቻዎቻቸውን ለመጀመር የ harness engineering ልጥፉን እንደጠቀሙበት ሁሉ፣ እናንተም የምትወዱትን የኮድ ወኪል ወደ Symphony spec(በአዲስ መስኮት ውስጥ ይክፈታል) እና ማከማቻ(በአዲስ መስኮት ውስጥ ይክፈታል) እንዲመለከት እና ለእናንተ አካባቢዎች ተስማሚ የሆኑ የራሳችሁን ስሪቶች እንዲገነባ ተስፋ እናደርጋለን።
ኃይሉ የሚመጣው ከ Codex እና ከ app server ነው። Symphony እኛ አስቀድመን እንጠቀምባቸው የነበሩ ሁለት ነገሮችን—Codex እና Linear—ለስራ አስተዳደር ችግር መፍታት ለማገናኘት የረዳ መንገድ ነበር። የኮድ ወኪሎች በማመዛዘን እና መመሪያዎችን በመከተል የተሻሉ ሲሆኑ፣ በሌሎች ኩባንያዎችም ማነቆው ከኮድ መጻፍ ወደ የወኪል ስራ አስተዳደር እንደሚሸጋገር እንገምታለን። አስደሳቹ ክፍል የእነዚህ የኮድ ወኪል ስርዓቶች ሙከራ ለማድረግ ያለው እንቅፋት አሁን በሚያስደንቅ ሁኔታ ዝቅተኛ መሆኑ ነው። በቀላሉ Codex በመጠቀም ነገሮችን መገንባት ትችላላችሁ።
የማህበረሰብ ምስጋናዎች
ከልቀቱ በኋላ ባሉት ሳምንታት ውስጥ የኢንጂነሪንግ ማህበረሰቡ Symphony ን ሲጠቀም ማየታችን እጅግ አስደስቶናል፣ እና እስከ ኤፕሪል 23 ድረስ 15K GitHub stars(በአዲስ መስኮት ውስጥ ይክፈታል) በላይ አግኝቷል።