Harness engineering: એજન્ટ-ફર્સ્ટ દુનિયામાં Codex નો લાભ લેતા

છેલ્લા પાંચ મહિનાથી, અમારી ટીમ એક પ્રયોગ ચલાવી રહી છે: હાથેથી લખાયેલા કોડની 0 લાઈનો સાથે સોફ્ટવેર પ્રોડક્ટનું આંતરિક બેટા બનાવી અને શિપ કરી રહી છે.

આ પ્રોડક્ટના આંતરિક દૈનિક વપરાશકર્તાઓ અને બાહ્ય આલ્ફા ટેસ્ટરો છે. તે શિપ થાય છે, ડિપ્લોય થાય છે, તૂટી પડે છે અને પછી ઠીક પણ થાય છે. તફાવત એટલો છે કે કોડની દરેક લાઇન—એપ્લિકેશન લોજિક, ટેસ્ટ્સ, CI કન્ફિગરેશન, ડોક્યુમેન્ટેશન, ઓબ્ઝર્વેબિલિટી અને આંતરિક ટૂલિંગ—Codex દ્વારા લખાઈ છે. અમારો અંદાજ છે કે આ બધું અમે હાથેથી કોડ લખતાં જેટલો સમય લાગ્યો હોત તેના લગભગ 1/10 સમયમાં બનાવી લીધું.

માણસો દિશા આપે છે. એજન્ટ અમલ કરે છે.

અમે જાણપૂર્વક આ મર્યાદા પસંદ કરી હતી જેથી એન્જિનિયરિંગ વેગને ગુણોત્તરીય રીતે વધારવા માટે ખરેખર જે જરૂરી હતું તે જ બનાવી શકીએ. અમારે પાસે શિપ કરવા માટે માત્ર થોડા અઠવાડિયા હતા, અને અંતે તે દસ લાખ લાઇનોના કોડ જેટલું બન્યું. આવું કરવા માટે અમારે સમજવું પડ્યું કે જ્યારે સોફ્ટવેર એન્જિનિયરિંગ ટીમનું મુખ્ય કામ હવે કોડ લખવું ન રહી, પરંતુ પર્યાવરણ ડિઝાઇન કરવું, ઇરાદા સ્પષ્ટ કરવું અને Codex એજન્ટોને વિશ્વસનીય રીતે કામ કરવા દે એવા ફીડબેક લૂપ્સ બનાવવું બની જાય, ત્યારે શું બદલાય છે.

આ પોસ્ટ અમે એજન્ટોની ટીમ સાથે બિલકુલ નવું પ્રોડક્ટ બનાવતાં શું શીખ્યા તે વિશે છે—શું તૂટી ગયું, શું ગતિ પકડી, અને અમારા એકમાત્ર ખરેખર દુર્લભ સ્રોત, માનવીય સમય અને ધ્યાન,ને કેવી રીતે મહત્તમ બનાવવું.

ખાલી રિપોઝિટરીમાં પ્રથમ commit ઓગસ્ટ 2025ના અંત તરફ આવ્યો.

પ્રારંભિક scaffold—રિપોઝિટરીની રચના, CI કન્ફિગરેશન, ફોર્મેટિંગ નિયમો, package manager સેટઅપ અને એપ્લિકેશન framework—Codex CLI દ્વારા GPT‑5 નો ઉપયોગ કરીને, પહેલાથી અસ્તિત્વમાં રહેલા થોડા templatesના માર્ગદર્શન હેઠળ જનરેટ કરવામાં આવ્યો. રિપોઝિટરીમાં એજન્ટોને કેવી રીતે કામ કરવું તે જણાવતી શરૂઆતની AGENTS.md ફાઇલ પણ Codex એ જ લખી હતી.

સિસ્ટમને ટેકો આપે એવું પહેલેથી લખાયેલું કોઈ માનવીય કોડ ન હતું. શરૂઆતથી જ, રિપોઝિટરીને એજન્ટે આકાર આપ્યો હતો.

પાંચ મહિના પછી, રિપોઝિટરીમાં એપ્લિકેશન લોજિક, ઇન્ફ્રાસ્ટ્રક્ચર, ટૂલિંગ, ડોક્યુમેન્ટેશન અને આંતરિક ડેવલપર યુટિલિટીઝ મળીને અંદાજે દસ લાખ લાઇનોનો કોડ છે. આ સમયગાળામાં માત્ર ત્રણ એન્જિનિયરોએ Codex ને આગળ ધપાવીને લગભગ 1,500 pull request ખોલી અને મર્જ કરી છે. તેનો અર્થ સરેરાશ દર એન્જિનિયર દીઠ દરરોજ 3.5 PRsનો થ્રૂપુટ થાય છે, અને આશ્ચર્યજનક રીતે, ટીમ હવે સાત એન્જિનિયરો સુધી વધતાં થ્રૂપુટ વધ્યો છે. મહત્ત્વપૂર્ણ વાત એ છે કે આ ફક્ત output માટે output નહોતું: પ્રોડક્ટનો આંતરિક રીતે સૈંકડો વપરાશકર્તાઓએ, તેમાં પણ દૈનિક power usersએ, ઉપયોગ કર્યો છે.

સમગ્ર વિકાસ પ્રક્રિયામાં, માણસોએ ક્યારેય સીધો કોઈ કોડ આપ્યો નથી. આ ટીમ માટે એક મૂળભૂત ફિલસૂફી બની: હાથેથી લખાયેલો કોઈ કોડ નહીં.

માણસો દ્વારા સીધું કોડ ન લખવાને કારણે એન્જિનિયરિંગના અલગ પ્રકારના કામની શરૂઆત થઈ, જે સિસ્ટમો, scaffolding અને leverage પર કેન્દ્રિત હતું.

શરૂઆતની પ્રગતિ અમારી અપેક્ષા કરતાં ધીમી હતી, Codex અસમર્થ હતો તેથી નહીં, પરંતુ પર્યાવરણ પૂરતું સ્પષ્ટ ન હતું તેથી. એજન્ટ પાસે ઉચ્ચ-સ્તરના લક્ષ્યો તરફ આગળ વધવા માટે જરૂરી ટૂલ્સ, abstraction અને આંતરિક રચના નહોતી. અમારી એન્જિનિયરિંગ ટીમનું મુખ્ય કામ એજન્ટોને ઉપયોગી કામ કરી શકે તેવું બનાવવાનું બની ગયું.

વ્યવહારમાં, તેનો અર્થ depth-first રીતે કામ કરવાનો હતો: મોટા લક્ષ્યોને નાના building blocksમાં વહેંચવા (design, code, review, test, વગેરે), એજન્ટને તે blocks બનાવવા માટે પ્રોમ્પ્ટ કરવું અને પછી વધુ જટિલ કાર્યો અનલૉક કરવા માટે તેનો ઉપયોગ કરવો. જ્યારે કંઈક નિષ્ફળ જતું, ત્યારે ઉપાય લગભગ ક્યારેય “વધુ જોરથી પ્રયાસ કરો” એવો ન હોતો. કારણ કે પ્રગતિ કરવાનો એકમાત્ર રસ્તો Codex પાસેથી કામ કરાવવાનો હતો, તેથી માનવીય એન્જિનિયરો હંમેશા કાર્યમાં પ્રવેશી અને પૂછતા: “કઈ ક્ષમતા ગાયબ છે, અને આપણે તેને એજન્ટ માટે વાંચી શકાય તેવી તથા અમલમાં મૂકી શકાય તેવી કેવી રીતે બનાવીએ?”

માણસો સિસ્ટમ સાથે લગભગ સંપૂર્ણપણે પ્રોમ્પ્ટ્સ દ્વારા ક્રિયા કરે છે: એન્જિનિયર કાર્ય વર્ણવે છે, એજન્ટ ચલાવે છે અને તેને pull request ખોલવા દે છે. PR ને પૂર્ણતા સુધી પહોંચાડવા માટે, અમે Codex ને તેના પોતાના ફેરફારોની local review કરવા, local તથા cloud બંનેમાં વધારાના ચોક્કસ એજન્ટ reviews માંગવા, માનવીય કે એજન્ટ દ્વારા આપવામાં આવેલા પ્રતિસાદનો જવાબ આપવા અને બધા એજન્ટ reviewers સંતોષ પામે ત્યાં સુધી loopમાં iterate કરવા સૂચના આપીએ છીએ (અસરકારક રીતે આ Ralph Wiggum Loop⁠(નવી વિન્ડોમાં ખૂલે છે) છે). Codex માનવો CLIમાં copy-paste કર્યા વિના સંદર્ભ મેળવવા માટે અમારા standard development tools (gh, local scripts અને repository-embedded skills)નો સીધો ઉપયોગ કરે છે.

માણસો pull request review કરી શકે છે, પરંતુ તે જરૂરી નથી. સમય સાથે, અમે લગભગ આખો review પ્રયત્ન એજન્ટ-થી-એજન્ટ રીતે સંભાળવામાં ધકેલી દીધો છે.

જેમ જેમ કોડ થ્રૂપુટ વધ્યો, તેમ આપણું bottleneck માનવીય QA ક્ષમતા બન્યું. કારણ કે નિશ્ચિત મર્યાદા માનવીય સમય અને ધ્યાન રહી છે, તેથી અમે એપ્લિકેશન UI, logs અને app metrics જેવી બાબતોને સીધા Codex માટે વાંચી શકાય તેવી બનાવી એજન્ટમાં વધુ ક્ષમતા ઉમેરવાનું કામ કર્યું છે.

ઉદાહરણ તરીકે, અમે એપને દરેક git worktree દીઠ boot કરી શકાય તેવી બનાવી, જેથી Codex દરેક ફેરફાર દીઠ એક instance લોન્ચ કરી અને ચલાવી શકે. અમે Chrome DevTools Protocol ને એજન્ટ runtimeમાં wire કર્યું અને DOM snapshots, screenshots અને navigation સાથે કામ કરવા માટે skills બનાવી. આથી Codex ને bugs ફરીથી ઊભા કરવા, fixes ચકાસવા અને UI વર્તન વિશે સીધો તર્ક કરવાની ક્ષમતા મળી.

ઓબ્ઝર્વેબિલિટી ટૂલિંગ માટે પણ અમે આવું જ કર્યું. Logs, metrics અને traces કોઈ પણ worktree માટે ephemeral એવા local observability stack મારફતે Codexને ઉપલબ્ધ છે. Codex આ એપના સંપૂર્ણપણે isolated version પર કામ કરે છે—તેના logs અને metrics સહિત, જે તે કાર્ય પૂર્ણ થતા જ દૂર કરી દેવામાં આવે છે. એજન્ટો LogQL વડે logs અને PromQL વડે metrics query કરી શકે છે. આ સંદર્ભ ઉપલબ્ધ હોવાથી, “service startup 800msથી ઓછા સમયમાં પૂરો થાય તેની ખાતરી કરો” અથવા “આ ચાર critical user journeysમાં કોઈ span બે સેકન્ડથી વધુ ન જાય” જેવા પ્રોમ્પ્ટ્સ કાર્યક્ષમ બને છે.

અમે વારંવાર જોીએ છીએ કે Codex ની એક જ run એક જ કાર્ય પર છ કલાકથી વધુ સમય સુધી કામ કરે છે, ઘણી વાર ત્યારે જ્યારે માણસો ઊંઘી રહ્યા હોય.

મોટા અને જટિલ કાર્યોમાં એજન્ટોને અસરકારક બનાવવા માટે context management સૌથી મોટા પડકારોમાંનું એક છે. અમે શરૂઆતમાં શીખેલા પાઠોમાંથી એક ખૂબ સરળ હતો: Codex ને નકશો આપો, 1,000 પાનાંની સૂચના-પુસ્તિકા નહીં.

અમે “એક મોટું AGENTS.md⁠(નવી વિન્ડોમાં ખૂલે છે)” વાળો અભિગમ અજમાવ્યો. તે અનુમાનિત રીતોથી નિષ્ફળ ગયો:

• Context એક દુર્લભ સ્રોત છે. વિશાળ સૂચના ફાઇલ કાર્ય, કોડ અને સંબંધિત docsને દબાવી દે છે—એટલે એજન્ટ મુખ્ય મર્યાદાઓ ચૂકી જાય છે અથવા ખોટી બાબતો માટે optimize કરવાનું શરૂ કરે છે.
• અતિશય માર્ગદર્શન માર્ગદર્શન ન હોવું બની જાય છે. જ્યારે બધું જ “મહત્ત્વપૂર્ણ” હોય, ત્યારે કંઈ પણ મહત્ત્વનું રહેતું નથી. એજન્ટો ઈરાદાપૂર્વક navigate કરવાની બદલે local pattern-matching કરવા લાગે છે.
• તે તરત જ જૂનું પડી જાય છે. એક monolithic manual બેસવાટ પામી ગયેલા નિયમોના કબ્રસ્તાનમાં ફેરવાઈ જાય છે. એજન્ટો સમજી શકતા નથી કે શું હજી સાચું છે, માણસો તેને જાળવવાનું બંધ કરી દે છે, અને ફાઇલ શાંતિથી આકર્ષક પણ નુકસાનકારક બની જાય છે.
• તે ચકાસવું મુશ્કેલ છે. એક જ blob યાંત્રિક checks (coverage, freshness, ownership, cross-links) માટે અનુકૂળ નથી, તેથી drift અનિવાર્ય બને છે.

એટલે AGENTS.md ને વિશ્વકોશ માનવાને બદલે, અમે તેને વિષયસૂચિ માનીએ છીએ.

રિપોઝિટરીનો knowledge base એક રચનાબદ્ધ docs/ ડિરેક્ટરીમાં રહે છે, જેને system of record તરીકે ગણવામાં આવે છે. નાનું AGENTS.md (લગભગ 100 લાઇનો) contextમાં inject થાય છે અને મુખ્યત્વે નકશા તરીકે કામ કરે છે, જેમાં બીજે આવેલા ઊંડા source of truth તરફ pointers હોય છે.

ડિઝાઇન ડોક્યુમેન્ટેશનને catalog અને index કરવામાં આવે છે, જેમાં verification status અને એજન્ટ-ફર્સ્ટ ઓપરેટિંગ principles વ્યાખ્યાયિત કરતી core beliefsનો સેટ પણ છે. Architecture documentation⁠(નવી વિન્ડોમાં ખૂલે છે) domains અને package layering નો top-level નકશો આપે છે. quality document દરેક product domain અને architectural layerને grade કરે છે અને સમય સાથેના gaps ટ્રૅક કરે છે.

Plans ને first-class artifacts તરીકે ગણવામાં આવે છે. નાના ફેરફારો માટે ephemeral lightweight plans વપરાય છે, જ્યારે જટિલ કામ execution plans⁠(નવી વિન્ડોમાં ખૂલે છે) માં કૅપ્ચર થાય છે, જેમાં progress અને decision logs હોય છે અને તે repositoryમાં check in થાય છે. active plans, completed plans અને જાણીતી technical debt બધું versioned અને co-located હોય છે, જેથી એજન્ટો બાહ્ય context પર નિર્ભર થયા વિના કામ કરી શકે.

આથી progressive disclosure શક્ય બને છે: એજન્ટો નાના, સ્થિર entry pointથી શરૂઆત કરે છે અને પછી ક્યાં જોવું તે શીખે છે, શરૂઆતમાં જ બધાથી ઘેરાઈ જતા નથી.

અમે આને યાંત્રિક રીતે અમલમાં મૂકીએ છીએ. સમર્પિત linters અને CI jobs knowledge base અપ-ટુ-ડેટ, cross-linked અને યોગ્ય રીતે structured છે તેની ચકાસણી કરે છે. વારંવાર ચલાવવામાં આવતો “doc-gardening” એજન્ટ stale અથવા obsolete ડોક્યુમેન્ટેશન શોધે છે, જે વાસ્તવિક કોડના વર્તનને પ્રતિબિંબિત કરતું નથી, અને fix-up pull request ખોલે છે.

જેમ કોડબેઝ વિકસ્યો, તેમ ડિઝાઇન નિર્ણયો માટે Codex નો framework પણ વિકસવો જરૂરી હતો.

કારણ કે રિપોઝિટરી સંપૂર્ણપણે એજન્ટ-જનરેટેડ છે, તે પ્રથમ Codexની legibility માટે optimize કરવામાં આવી છે. જે રીતે ટીમો નવા એન્જિનિયરિંગ hires માટે પોતાના કોડની navigability સુધારવાનો પ્રયત્ન કરે છે, તે જ રીતે અમારા માનવીય એન્જિનિયરોનું લક્ષ્ય એજન્ટ માટે સંપૂર્ણ business domain વિશે સીધું repositoryમાંથી જ તર્ક કરવું શક્ય બનાવવાનું હતું.

એજન્ટના દૃષ્ટિકોણથી, જે કંઈ તેને ચલાવતા સમયે in-context ઍક્સેસ કરી શકાતું નથી, તે અસરકારક રીતે અસ્તિત્વમાં જ નથી. Google Docs, chat threads અથવા લોકોના મનમાં રહેલું જ્ઞાન સિસ્ટમ માટે ઍક્સેસિબલ નથી. repository-local, versioned artifacts (જેમ કે code, markdown, schemas, executable plans) જ તે જોઈ શકે છે.

અમે શીખ્યા કે સમય સાથે અમારે વધુને વધુ context repoમાં ધકેલવો પડ્યો. આર્કિટેક્ચરલ pattern પર ટીમને એકસરખી સમજ અપાવતી Slack ચર્ચા? જો એજન્ટ તેને શોધી શકતો ન હોય, તો તે એટલી જ અગમ્ય છે જેટલી ત્રણ મહિના પછી જોડાયેલા નવા hire માટે અજાણી હોય.

Codex ને વધુ context આપવાનો અર્થ એજન્ટ તેના પર તર્ક કરી શકે તે માટે યોગ્ય માહિતી ગોઠવવી અને ખુલ્લી મૂકવી, ના કે તેને ad-hoc સૂચનાઓથી ઘેરી દેવી. જેમ તમે કોઈ નવા ટીમસભ્યને product principles, engineering norms અને team culture (emoji પસંદગીઓ સહિત) વિશે onboarding કરાવતા હો, તેમ એજન્ટને આ માહિતી આપવાથી વધુ સારી રીતે aligned output મળે છે.

આ framingએ ઘણા tradeoffs સ્પષ્ટ કર્યા. અમે એવી dependencies અને abstractionsને પ્રાથમિકતા આપી કે જેને સંપૂર્ણ રીતે આંતરિક બનાવી repoમાં જ સમજી શકાય. ઘણી વાર “boring” તરીકે વર્ણવાતી technologies એજન્ટો માટે composability, API stability અને training setમાં representationને કારણે model કરવી વધુ સરળ હોય છે. કેટલાક કિસ્સાઓમાં, public librariesના opaque upstream વર્તનને ચક્કર ખાવા કરતાં કાર્યક્ષમતાના કેટલાક ભાગો એજન્ટથી ફરી અમલમાં મૂકાવવું સસ્તુ પડ્યું. ઉદાહરણ તરીકે, generic p-limit-style package લાવવાને બદલે અમે અમારી પોતાની map-with-concurrency helper અમલમાં મૂકી: તે અમારી OpenTelemetry instrumentation સાથે કડક રીતે સંકળાયેલી છે, તેની 100% test coverage છે, અને તે અમારા runtimeની અપેક્ષા મુજબ જ વર્તે છે.

સિસ્ટમના વધુ ભાગોને એવી રચનામાં લાવવાથી જેને એજન્ટ સીધું inspect, validate અને modify કરી શકે, leverage વધે છે—ફક્ત Codex માટે જ નહીં, પણ codebase પર કામ કરતા અન્ય એજન્ટો માટે પણ (જેમ કે Aardvark).

ફક્ત documentation સંપૂર્ણપણે એજન્ટ-જનરેટેડ codebaseને coherent રાખતી નથી. અમલના સૂક્ષ્મ નિયંત્રણ કરતાં invariants અમલમાં મૂકી, અમે એજન્ટોને પાયો નબળો કર્યા વગર ઝડપથી ship કરવા દઈએ છીએ. ઉદાહરણ તરીકે, અમે Codex પાસે boundary પર data shapes parse⁠(નવી વિન્ડોમાં ખૂલે છે) કરવાની માંગ કરીએ છીએ, પરંતુ તે કેવી રીતે થાય એ બાબતે prescriptive નથી (મોડલને Zod ગમતું લાગે છે, પણ અમે એ ચોક્કસ library નક્કી કરી નથી).

એજન્ટો કડક boundaries અને અનુમાનિત structure⁠(નવી વિન્ડોમાં ખૂલે છે) ધરાવતા environmentsમાં સૌથી અસરકારક હોય છે, તેથી અમે એપ્લિકેશનને કડક architectural model આસપાસ બનાવી. દરેક business domain ને સ્તરોના નિશ્ચિત સમૂહમાં વહેંચવામાં આવે છે, જેમાં dependency directions કડક રીતે validate થાય છે અને અનુમતિપાત્ર edgesનો મર્યાદિત સમૂહ હોય છે. આ મર્યાદાઓ custom linters (નિશ્ચિતપણે Codex-જનરેટેડ!) અને structural tests દ્વારા યાંત્રિક રીતે અમલમાં મૂકાય છે.

નીચેનું આકૃતિચિત્ર નિયમ બતાવે છે: દરેક business domainમાં (જેમ કે App Settings), કોડ માત્ર સ્તરોના નિશ્ચિત સમૂહમાં “આગળ” depend કરી શકે છે (Types → Config → Repo → Service → Runtime → UI). Cross-cutting concerns (auth, connectors, telemetry, feature flags) એક જ સ્પષ્ટ interface, એટલે Providers, મારફતે પ્રવેશે છે. બાકી બધું નિષેધિત છે અને યાંત્રિક રીતે અમલમાં મૂકાય છે.

આ એવી પ્રકારની આર્કિટેક્ચર છે જેને તમે સામાન્ય રીતે સૈંકડો એન્જિનિયરો થાય ત્યાં સુધી મુલતવી રાખો. coding એજન્ટો સાથે, આ શરૂઆતથી જ જરૂરી શરત બને છે: આ મર્યાદાઓ જ એવી છે જે ક્ષય કે architectural drift વિના ઝડપ શક્ય બનાવે છે.

વ્યવહારમાં, અમે custom linters અને structural tests સાથે, થોડા “taste invariants” વડે આ નિયમો અમલમાં મૂકીએ છીએ. ઉદાહરણ તરીકે, structured logging, schemas અને types માટે naming conventions, file size limits અને platform-specific reliability requirements અમે custom lints વડે statically અમલમાં મૂકીએ છીએ. કારણ કે lints custom છે, અમે error messages એમ લખીએ છીએ કે remediation instructions એજન્ટ contextમાં inject થાય.

માનવ-પ્રથમ workflowમાં, આ નિયમો કદાચ અતિસૂક્ષ્મ અથવા બાંધછોડ કરનારા લાગે. એજન્ટો સાથે, તેઓ multipliers બની જાય છે: એકવાર encode થઈ જાય પછી, તેઓ એકસાથે દરેક જગ્યાએ લાગુ પડે છે.

સાથે સાથે, અમે ક્યાં મર્યાદાઓ મહત્વપૂર્ણ છે અને ક્યાં નથી તે અંગે સ્પષ્ટ રહીએ છીએ. આ મોટું engineering platform organization ચલાવવાનું જેવું છે: boundaries કેન્દ્રિય રીતે અમલમાં મૂકો, local autonomyને મંજૂરી આપો. તમને boundaries, correctness અને reproducibilityની ઘણી ચિંતા હોય છે. એ boundariesની અંદર, તમે teams—અથવા એજન્ટો—ને ઉકેલો કેવી રીતે વ્યક્ત કરવા તે અંગે નોંધપાત્ર સ્વતંત્રતા આપો છો.

પરિણામે મળતો કોડ હંમેશા માનવીય શૈલીગત પસંદગીઓ સાથે મેળ ખાતો નથી, અને તે ઠીક છે. જેટલા સમય સુધી output સાચું, maintainable અને ભવિષ્યના એજન્ટ runs માટે legible છે, તેટલા સમય સુધી તે ધોરણ પૂરો કરે છે.

માનવીય taste સતત સિસ્ટમમાં પાછું ફીડ કરવામાં આવે છે. Review comments, refactoring pull request અને user-facing bugs ને documentation updates તરીકે કૅપ્ચર કરવામાં આવે છે અથવા toolingમાં સીધા encode કરવામાં આવે છે. જ્યારે documentation પૂરતી ન પડે, ત્યારે અમે નિયમને codeમાં પ્રોત્સાહિત કરીએ છીએ

જેમ Codex નો થ્રૂપુટ વધ્યો, તેમ ઘણા પરંપરાગત engineering norms પ્રતિકૂળ બન્યા.

રિપોઝિટરી ઓછામાં ઓછા blocking merge gates સાથે ચાલે છે. Pull request ટૂંકા સમય માટે જીવંત રહે છે. Test flakesને ઘણી વાર અનંત સુધી પ્રગતિ અટકાવવાને બદલે follow-up runs દ્વારા સંભાળવામાં આવે છે. એવી સિસ્ટમમાં જ્યાં એજન્ટ થ્રૂપુટ માનવીય ધ્યાન કરતાં ઘણો વધુ હોય, corrections સસ્તા હોય છે અને રાહ જોવી મોંઘી પડે છે.

ઓછા થ્રૂપુટવાળા પર્યાવરણમાં આ બેદરકારીભર્યું ગણાત. અહીં, આ ઘણી વાર યોગ્ય tradeoff હોય છે.

જ્યારે અમે કહીએ છીએ કે codebase Codex એજન્ટો દ્વારા જનરેટ થાય છે, ત્યારે અમારો અર્થ codebaseમાં રહેલી દરેક વસ્તુથી છે.

એજન્ટો બનાવે છે:

• પ્રોડક્ટ કોડ અને tests
• CI configuration અને release tooling
• આંતરિક developer tools
• Documentation અને design history
• Evaluation harnesses
• Review comments અને responses
• રિપોઝિટરીને જ સંચાલિત કરતા scripts
• Production dashboard definition files

માણસો હંમેશા loopમાં રહે છે, પરંતુ અમે પહેલાં કરતાં abstractionના અલગ સ્તરે કામ કરીએ છીએ. અમે કામને પ્રાથમિકતા આપીએ છીએ, user feedbackને acceptance criteriaમાં રૂપાંતરિત કરીએ છીએ અને outcomes validate કરીએ છીએ. જ્યારે એજન્ટને મુશ્કેલી પડે, ત્યારે અમે તેને signal તરીકે લઈએ છીએ: શું ગાયબ છે તે ઓળખીએ—tools, guardrails, documentation—અને તેને repositoryમાં પાછું ફીડ કરીએ, અને fix પણ હંમેશા Codex પાસે જ લખાવીએ.

એજન્ટો અમારા standard development toolsનો સીધો ઉપયોગ કરે છે. તેઓ review feedback ખેંચે છે, inline જવાબ આપે છે, updates push કરે છે અને ઘણી વાર પોતાની pull request પોતે squash અને merge પણ કરે છે.

જેમ વિકાસ loopના વધુ ભાગો સીધા સિસ્ટમમાં encode થયા—testing, validation, review, feedback handling અને recovery—તેમ રિપોઝિટરીએ તાજેતરમાં એક અર્થપૂર્ણ threshold પાર કરી છે જ્યાં Codex end-to-end નવી feature આગળ ધપાવી શકે છે.

એક જ prompt મળ્યા પછી, એજન્ટ હવે આ કરી શકે છે:

• codebaseની વર્તમાન સ્થિતિ validate કરવી
• રિપોર્ટ થયેલ bug ફરીથી ઊભો કરવો
• નિષ્ફળતા દર્શાવતો video record કરવો
• fix અમલમાં મૂકવી
• એપ્લિકેશન ચલાવી fix validate કરવી
• ઉકેલ દર્શાવતો બીજો video record કરવો
• pull request ખોલવી
• એજન્ટ અને માનવીય feedbackનો જવાબ આપવો
• build failures શોધી અને remediate કરવી
• જ્યારે નિર્ણય જરૂરી હોય ત્યારે જ માનવી સુધી escalate કરવું
• ફેરફાર merge કરવો

આ વર્તન આ રિપોઝિટરીની ચોક્કસ રચના અને tooling પર ભારે રીતે આધાર રાખે છે અને સમાન રોકાણ વિના સામાન્યીકૃત થઈ જશે એવું માનવું નહીં—ઓછામાં ઓછું, હજી તો નહીં.

પૂર્ણ એજન્ટ સ્વાયત્તતા નવા પ્રકારની સમસ્યાઓ પણ લાવે છે. Codex રિપોઝિટરીમાં પહેલેથી હાજર patternsને જ નકલ કરે છે—અસમ અથવા ઉપપરિણામી હોય તેવા patternsને પણ. સમય સાથે, આ અનિવાર્ય રીતે drift તરફ દોરી જાય છે.

શરૂઆતમાં, માણસો આને હાથથી સંભાળતા. અમારી ટીમ દર શુક્રવારે “AI slop” સાફ કરવામાં ખર્ચતી (અઠવાડિયાનો 20%). આશ્ચર્ય નથી કે આ સ્કેલ થયું નહીં.

તેના બદલે, અમે જેને “golden principles” કહીએ છીએ તેને સીધા રિપોઝિટરીમાં encode કરવાનું શરૂ કર્યું અને વારંવાર ચાલે એવી cleanup process બનાવી. આ principles મંતવ્યાંકિત, યાંત્રિક નિયમો છે જે ભવિષ્યના એજન્ટ runs માટે codebaseને legible અને consistent રાખે છે. ઉદાહરણ તરીકે: (1) invariants કેન્દ્રિત રાખવા માટે અમે hand-rolled helpers કરતાં shared utility packages પસંદ કરીએ છીએ, અને (2) અમે dataને “YOLO-style” probe કરતા નથી—we validate boundaries અથવા typed SDKs પર નિર્ભર રહીએ છીએ જેથી એજન્ટ અનુમાનિત shapes પર અચાનક build ન કરી બેસે. નિયમિત cadence પર, અમે background Codex tasksનો સેટ ચલાવીએ છીએ જે deviations શોધે છે, quality grades update કરે છે અને targeted refactoring pull request ખોલે છે. આમાંથી મોટાભાગની એક મિનિટથી ઓછા સમયમાં review કરી શકાય છે અને automerge થઈ જાય છે.

આ garbage collection જેવી રીતે કામ કરે છે. Technical debt ઊંચા વ્યાજવાળી લોન જેવી છે: તેને સતત નાના હપ્તામાં ઘટાડવી લગભગ હંમેશા વધુ સારી હોય છે, બદલે કે તેને compounded થવા દેવી અને પછી દુખદાયક ફાટકામાં હલ કરવી. માનવીય taste એક વખત capture થાય છે, પછી કોડની દરેક લાઇન પર સતત અમલમાં મૂકાય છે. આ અમને ખરાબ patternsને દરરોજ શોધવા અને ઉકેલવા પણ દે છે, બદલે કે તે code baseમાં દિવસો કે અઠવાડિયાઓ સુધી ફેલાતા રહે.

આ વ્યૂહરચના અત્યાર સુધી OpenAIમાં આંતરિક લોન્ચ અને અપનાવટ સુધી સારી રીતે કાર્યરત રહી છે. ખરેખર વપરાશકર્તાઓ માટે ખરેખરનું પ્રોડક્ટ બનાવવાથી અમારા રોકાણો વાસ્તવિકતા સાથે જોડાયેલા રહ્યા અને લાંબા ગાળાની maintainability તરફ અમને માર્ગદર્શન મળ્યું.

અમને હજી ખબર નથી કે સંપૂર્ણપણે એજન્ટ-જનરેટેડ સિસ્ટમમાં વર્ષો દરમિયાન આર્કિટેક્ચરલ coherence કેવી રીતે વિકસે છે. અમે હજી શીખી રહ્યા છીએ કે માનવીય નિર્ણય સૌથી વધુ leverage ક્યાં ઉમેરે છે અને એ નિર્ણયને એવી રીતે કેવી રીતે encode કરવો કે તે compounded થાય. સમય સાથે મોડલો વધુ સક્ષમ બનતા જાય ત્યારે આ સિસ્ટમ કેવી રીતે વિકસશે તે પણ અમને હજી ખબર નથી.

એક વાત સ્પષ્ટ થઈ છે: સોફ્ટવેર બનાવવું હજી પણ શિસ્ત માંગે છે, પરંતુ હવે એ શિસ્ત કોડ કરતાં scaffoldingમાં વધુ દેખાય છે. કોડબેઝને coherent રાખતા tooling, abstractions અને feedback loops વધતી જતી રીતે વધુ મહત્વપૂર્ણ બની રહ્યા છે.

અમારા સૌથી મુશ્કેલ પડકારો હવે એવા environments, feedback loops અને control systems ડિઝાઇન કરવા પર કેન્દ્રિત છે, જે એજન્ટોને અમારા લક્ષ્ય સુધી પહોંચવામાં મદદ કરે: વિશાળ પાયે જટિલ, વિશ્વસનીય સોફ્ટવેર બનાવવું અને જાળવવું.

Codex જેવા એજન્ટો સોફ્ટવેર lifecycleના મોટા ભાગો સંભાળવા લાગે છે તેમ આ પ્રશ્નો વધુ મહત્વના બનશે. અમને આશા છે કે કેટલાક પ્રારંભિક પાઠો શેર કરવાથી તમે તમારો પ્રયત્ન ક્યાં રોકવો તે વિશે વિચાર કરી શકશો જેથી તમે ફક્ત વસ્તુઓ બનાવી શકો.