ஹார்னஸ் பொறியியல்: ஏஜென்ட்-முதன்மை உலகில் Codex ஐ பயன்படுத்துதல்

கடந்த ஐந்து மாதங்களாக, எங்கள் குழு ஒரு பரிசோதனையை நடத்தி வருகிறது: கைமுறையாக எழுதப்பட்ட குறியீட்டின் 0 வரிகளைக் கொண்ட ஒரு மென்பொருள் தயாரிப்பின் உள் பீட்டாவை உருவாக்கி அனுப்புதல்.

தயாரிப்பில் உள்ளூர் தினசரி பயனர்களும் வெளிப்புற ஆல்பா சோதனையாளர்களும் உள்ளனர். இது அனுப்பப்படுகிறது, வெளியிடப்படுகிறது, உடைகிறது, மற்றும் சரிசெய்யப்படுகிறது. வேறுபாடு என்னவென்றால், ஒவ்வொரு குறியீட்டு வரியும்—செயலி தர்க்கம், சோதனைகள், CI கட்டமைப்பு, ஆவணங்கள், கண்காணிப்பு திறன், மற்றும் உள் கருவிகள்—Codex மூலம் எழுதப்பட்டுள்ளது. கையால் குறியீட்டை எழுத எடுத்திருக்கும் நேரத்தின் சுமார் பத்தில் ஒரு பங்கு நேரத்தில் இதை நாங்கள் உருவாக்கினோம் என்று நாங்கள் மதிப்பிடுகிறோம்.

மனிதர்கள் வழிநடத்துகின்றனர். ஏஜென்ட்கள் செயல்படுகின்றன.

பொறியியல் வேகத்தை பல மடங்கு உயர்த்த தேவையானதை உருவாக்குவதற்காகவே இந்த கட்டுப்பாட்டை நாங்கள் திட்டமிட்டு தேர்ந்தெடுத்தோம். ஒரு மில்லியன் குறியீடு வரிகளாக முடிந்ததை அனுப்ப எங்களுக்கு வாரங்கள் இருந்தன. அதைச் செய்ய, ஒரு மென்பொருள் பொறியியல் குழுவின் முதன்மை பணி இனி குறியீடு எழுதுவது அல்ல, மாறாக சூழல்களை வடிவமைத்தல், நோக்கத்தை விவரித்தல், மற்றும் Codex ஏஜென்ட்கள் நம்பகமாக வேலை செய்ய அனுமதிக்கும் பின்னூட்டச் சுழற்சிகளை உருவாக்குதல் ஆகும் போது என்ன மாற்றங்கள் ஏற்படுகின்றன என்பதை நாங்கள் புரிந்துகொள்ள வேண்டும்.

இந்த பதிவு, ஏஜென்ட்கள் கொண்ட குழுவுடன் முற்றிலும் புதிய தயாரிப்பை உருவாக்கியதில் நாங்கள் கற்றுக்கொண்டதைப் பற்றி—எது முறிந்தது, எது அதிகரித்தது, மேலும் எவ்வாறு நமது அரிதான மனித நேரத்தையும் கவனத்தையும் அதிகபட்சமாகப் பயன்படுத்துவது என்பதையும்—விவரிக்கிறது.

காலியான ரிபாசிட்டரிக்கான முதல் கமிட் 2025 ஆகஸ்ட் மாத இறுதியில் செய்யப்பட்டது.

ஆரம்ப ஸ்காஃபோல்ட்—ரிபாசிட்டரி அமைப்பு, CI கட்டமைப்பு, வடிவமைப்பு விதிகள், பேக்கேஜ் மேனேஜர் அமைப்பு, மற்றும் பயன்பாட்டு ஃப்ரேம்வொர்க்—GPT‑5 ஐப் பயன்படுத்தி Codex CLI மூலம், ஏற்கனவே உள்ள சில டெம்ப்ளேட்களின் சிறிய தொகுப்பின் வழிகாட்டுதலுடன் உருவாக்கப்பட்டது. AGENTS.md கோப்பின் ஆரம்ப பதிப்பே, ரிப்பாசிட்டரியில் ஏஜென்ட்கள் எவ்வாறு வேலை செய்ய வேண்டும் என்பதை வழிகாட்டுகிறது, Codex மூலம் எழுதப்பட்டது.

சிஸ்டத்தை நிலைநிறுத்துவதற்கு முன்பே இருந்த மனிதர்கள் எழுதிய குறியீடு எதுவும் இல்லை. தொடக்கத்திலிருந்தே, ரிபாசிட்டரி ஏஜென்ட் மூலம் வடிவமைக்கப்பட்டது.

ஐந்து மாதங்கள் கழித்து, ரிபாசிட்டரியில் செயலி லாஜிக், உள்கட்டமைப்பு, கருவிகள், ஆவணங்கள், மற்றும் உள்துறை டெவலப்பர் உபயோகங்கள் ஆகியவற்றை உள்ளடக்கி, சுமார் ஒரு மில்லியன் வரிகள் அளவிலான குறியீடு உள்ளது. அந்த காலப்பகுதியில், சுமார் 1,500 pull requests திறக்கப்பட்டு ஒன்றிணைக்கப்பட்டன; Codex ஐ முன்னெடுத்துச் செல்ல மூன்று பொறியாளர்களைக் கொண்ட ஒரு சிறிய குழு செயல்பட்டது. இது ஒரு பொறியாளருக்கு ஒரு நாளுக்கு சராசரியாக 3.5 PRs என்ற த்ரூபுட் ஆக மொழிபெயர்கிறது, மேலும் ஆச்சரியமாக குழு இப்போது ஏழு பொறியாளர்களாக வளர்ந்துள்ள நிலையில் த்ரூபுட் அதிகரித்துள்ளது. முக்கியமாக, இது வெளியீட்டிற்காக வெளியீடு அல்ல: இந்த தயாரிப்பு நூற்றுக்கணக்கான உள் பயனர்களால் பயன்படுத்தப்பட்டுள்ளது, இதில் தினசரி உள் சக்தி பயனர்களும் அடங்குவர்.

மேம்பாட்டு செயல்முறை முழுவதும், மனிதர்கள் ஒருபோதும் எந்தக் குறியீட்டையும் நேரடியாகச் சேர்க்கவில்லை. இது குழுவின் முக்கிய தத்துவமாக மாறியது: கைமுறையாக எழுதப்பட்ட குறியீடு இல்லை.

கைகளால் செய்து பார்க்கும் மனித குறியீட்டின் பற்றாக்குறை சிஸ்டம்கள், ஸ்காஃபோல்டிங், மற்றும் நிபுணத்துவம் மீது கவனம் செலுத்தும் வேறொரு வகையான பொறியியல் பணியை அறிமுகப்படுத்தியது.

ஆரம்ப முன்னேற்றம் நாங்கள் எதிர்பார்த்ததை விட மெதுவாக இருந்தது, Codex திறனற்றதனால் அல்ல, ஆனால் சூழல் போதுமான அளவில் விவரிக்கப்படாததால். ஏஜென்டுக்கு உயர்நிலை இலக்குகளை நோக்கி முன்னேற்றம் அடைய தேவையான கருவிகள், சுருக்கங்கள் மற்றும் உள் அமைப்பு இல்லை. எங்கள் பொறியியல் குழுவின் முதன்மை பணி, ஏஜென்ட்கள் பயனுள்ள வேலை செய்ய இயலுமாறு செய்வதாக மாறியது.

நடைமுறையில், இதன் பொருள் ஆழம்-முதலில் வேலை செய்வதாக இருந்தது: பெரிய இலக்குகளை சிறிய கட்டுமானத் தொகுதிகளாக (வடிவமைப்பு, குறியீடு, மதிப்பாய்வு, சோதனை, etc) பிரித்து, அந்தத் தொகுதிகளை உருவாக்க ஏஜென்ட்டைத் தூண்டி, மேலும் சிக்கலான பணிகளைத் திறக்க அவற்றைப் பயன்படுத்துவது. ஏதாவது தோல்வியடைந்தபோது, அதற்கான தீர்வு பெரும்பாலும் “மேலும் முயற்சி செய்யுங்கள்” என்பதல்ல. முன்னேற்றம் அடைவதற்கான ஒரே வழி Codex வேலை செய்யச் செய்வதுதான் என்பதால், மனித பொறியாளர்கள் எப்போதும் அந்த பணியில் தலையிட்டு இவ்வாறு கேட்டார்கள்: “எந்த திறன் குறைவாக உள்ளது, மேலும் அதை ஏஜென்டுக்கு புரியக்கூடியதாகவும் அமல்படுத்தக்கூடியதாகவும் எப்படிச் செய்வது?”

மனிதர்கள் அமைப்புடன் பெரும்பாலும் ப்ராம்ப்ட்கள் மூலம் தொடர்பு கொள்கிறார்கள்: ஒரு பொறியாளர் ஒரு பணியை விவரிக்கிறார், ஏஜென்ட்டை இயக்குகிறார், மேலும் அது pull request ஐ திறக்க அனுமதிக்கிறது. ஒரு PR ஐ நிறைவு செய்ய, Codex தன் சொந்த மாற்றங்களை உள்ளூரில் மதிப்பாய்வு செய்ய, உள்ளூரிலும் கிளவுடிலும் கூடுதல் குறிப்பிட்ட ஏஜென்ட் மதிப்பாய்வுகளை கோர, மனிதர் அல்லது ஏஜென்ட் வழங்கிய எந்த பின்னூட்டத்திற்கும் பதிலளிக்க, மற்றும் அனைத்து ஏஜென்ட் மதிப்பாய்வாளர்களும் திருப்தி அடையும் வரை ஒரு லூப்பில் மீண்டும் மீண்டும் செய்யுமாறு நாங்கள் அறிவுறுத்துகிறோம் (உண்மையில் இது ஒரு Ralph Wiggum Loop⁠(புதிய சாளரத்தில் திறக்கும்)). மனிதர்கள் CLI-யில் நகலெடுத்து ஒட்டாமல் சூழலைச் சேகரிக்க Codex எங்கள் நிலையான மேம்பாட்டுக் கருவிகளை நேரடியாக (gh, உள்ளூர் ஸ்கிரிப்டுகள் மற்றும் ரிபாசிட்டரி உட்பொதிக்கப்பட்ட திறன்கள்) பயன்படுத்துகிறது.ரிபாசிட்டரி

மனிதர்கள் pull request களை மதிப்பாய்வு செய்யலாம், ஆனால் அவ்வாறு செய்ய வேண்டிய அவசியம் இல்லை. காலப்போக்கில், மதிப்பாய்வு முயற்சியின் பெரும்பகுதியை ஏஜென்ட்-மூலம்-ஏஜென்ட் முறையில் கையாளப்படுமாறு நாங்கள் மாற்றியுள்ளோம்.

குறியீட்டு த்ரூபுட் அதிகரித்தபோது, எங்கள் bottleneck மனித QA திறனாக மாறியது. மனித நேரமும் கவனமும் நிலையான கட்டுப்பாடாக இருப்பதால், செயலி பயனர் இடைமுகம், பதிவுகள், மற்றும் செயலி அளவீடுகளை Codex க்கு நேரடியாக வாசிக்கக்கூடியதாக மாற்றுவதன் மூலம், ஏஜென்ட்டிற்கு மேலும் திறன்களைச் சேர்க்க நாங்கள் முயன்றுள்ளோம்.

உதாரணமாக, ஒவ்வொரு git worktree க்கும் ஒரு செயலியை தொடங்கக்கூடியதாக நாங்கள் மாற்றினோம், இதனால் Codex ஒவ்வொரு மாற்றத்திற்கும் ஒரு நிகழ்வை தொடங்கி இயக்க முடிந்தது. நாங்கள் Chrome DevTools Protocol-ஐ ஏஜென்ட் ரன்டைமில் இணைத்து, DOM ஸ்நாப்ஷாட்கள், ஸ்கிரீன்ஷாட்கள் மற்றும் வழிசெலுத்தலுடன் வேலை செய்வதற்கான திறன்களை உருவாக்கினோம். இது Codex க்கு பிழைகளை மீண்டும் உருவாக்க, திருத்தங்களை சரிபார்க்க, மற்றும் UI நடத்தை பற்றி நேரடியாக காரணமிட உதவியது.

நாங்கள் கவனிப்புத் திறன் கருவிகளுக்கும் அதே செயல்களை மேற்கொண்டோம். பதிவுகள், அளவீடுகள், மற்றும் தடயங்கள், ஒவ்வொரு worktree க்கும் தற்காலிகமான உள்ளூர் கண்காணிப்பு ஸ்டாக் மூலம் Codex-க்கு வெளிப்படுத்தப்படுகின்றன. Codex அந்த செயலியின் முழுமையாக தனிமைப்படுத்தப்பட்ட பதிப்பில் இயங்குகிறது—அதன் பதிவுகள் மற்றும் அளவீடுகள் உட்பட, அந்த பணியை முடித்தவுடன் அவை அகற்றப்படும். ஏஜென்ட்கள் LogQL மூலம் பதிவுகளை வினவலாம் மற்றும் PromQL மூலம் அளவீடுகளை வினவலாம். இந்த சூழல் கிடைப்பதால், “800ms க்குள் சேவை தொடக்கம் முடிவடைவதை உறுதிசெய்யவும்” அல்லது “இந்த நான்கு முக்கிய பயனர் பயணங்களில் எந்த ப்ராம்ப்டும் இரண்டு விநாடிகளை மீறக்கூடாது” போன்ற ப்ராம்ப்ட்கள் நடைமுறையில் சாத்தியமாகின்றன.

நாங்கள் அடிக்கடி ஒற்றை Codex ரன்கள் ஒரு பணியில் ஆறு மணிநேரத்திற்கும் மேலாக வேலை செய்வதைப் பார்க்கிறோம் (பல நேரங்களில் மனிதர்கள் தூங்கிக்கொண்டிருக்கும் போது).

பெரிய மற்றும் சிக்கலான பணிகளை திறமையாகச் செய்ய ஏஜென்ட்களை உருவாக்குவதில் சூழல் மேலாண்மை மிகப்பெரிய சவால்களில் ஒன்றாகும். நாங்கள் கற்றுக்கொண்ட ஆரம்பகால பாடங்களில் ஒன்று எளிதானது: Codex க்கு 1,000 பக்க வழிமுறை கையேடு அல்ல, ஒரு வரைபடத்தை வழங்குங்கள்.

நாங்கள் “ஒரு பெரிய AGENTS.md⁠(புதிய சாளரத்தில் திறக்கும்)” ஐ முயற்சித்தோம் அணுகுமுறை. இது எதிர்பார்க்கப்பட்ட வழிகளில் தோல்வியடைந்தது:

• சூழல் ஒரு அரிதான வளம். ஒரு மிகப் பெரிய வழிமுறை கோப்பு பணியை, குறியீட்டை மற்றும் தொடர்புடைய ஆவணங்களை நெருக்கி விடுகிறது, அதனால் ஏஜென்ட் முக்கிய கட்டுப்பாடுகளை தவறவிடுகிறார் அல்லது தவறானவற்றுக்காக மேம்படுத்தத் தொடங்குகிறார்.
• அதிகப்படியான வழிகாட்டுதல் வழிகாட்டுதலின்மையாகமாறிவிடும். எல்லாவற்றையும் “முக்கியம்” என்று கூறினால், எதுவும் முக்கியமில்லை. ஏஜென்ட்கள் வேண்டுமென்றே வழிசெலுத்துவதற்குப் பதிலாக உள்ளூரில் வடிவப் பொருத்தத்தை முடிக்கிறார்கள்.
• இது உடனடியாக அழுகிவிடுகிறது. ஒரு மாபெரும் கையேடு பழைய விதிகளின் கல்லறையாக மாறுகிறது. ஏஜென்ட்கள் எது இன்னும் உண்மை என்பதை கண்டறிய முடியாது, மனிதர்கள் அதை பராமரிக்காமல் விடுகிறார்கள், மேலும் அந்த கோப்பு அமைதியாகவே ஒரு கவர்ச்சிகரமான தொல்லையாக மாறுகிறது.
• சரிபார்க்க இது கடினம். ஒரே ஒரு ப்ளாப் இயந்திரச் சரிபார்ப்புகளுக்கு (கவரேஜ், புதுமை, உரிமை, குறுக்கு-இணைப்புகள்) ஏற்றதாக இல்லை, எனவே விலகல் தவிர்க்க முடியாதது.

எனவே AGENTS.md ஐ கலைக்களஞ்சியமாகக் கருதுவதற்குப் பதிலாக, அதை உள்ளடக்க அட்டவணையாகக் கருதுகிறோம்.

ரிபாசிட்டரியின் அறிவுத்தளம், சிஸ்டம் ஆஃப் ரெக்கார்டாகக் கருதப்படும் கட்டமைக்கப்பட்ட docs/ அடைவில் உள்ளது. ஒரு குறுகிய AGENTS.md (தோராயமாக 100 வரிகள்) சூழலில் செலுத்தப்பட்டு முதன்மையாக ஒரு வரைபடமாக செயல்படுகிறது, மற்ற இடங்களில் உள்ள ஆழமான உண்மை மூலங்களுக்கான சுட்டிகளுடன்.

வடிவமைப்பு ஆவணங்கள் பட்டியலிடப்பட்டு குறியிடப்பட்டுள்ளன, இதில் சரிபார்ப்பு நிலையும், ஏஜென்ட்-முதன்மை செயல்பாட்டு கொள்கைகளை வரையறுக்கும் முக்கிய நம்பிக்கைகளின் தொகுப்பும் அடங்கும். கட்டமைப்பு ஆவணங்கள்⁠(புதிய சாளரத்தில் திறக்கும்) டொமைன்கள் மற்றும் தொகுப்பு அடுக்குகளின் மேல்நிலை வரைபடத்தை வழங்குகிறது. ஒரு தர ஆவணம் ஒவ்வொரு தயாரிப்பு துறையையும் மற்றும் கட்டமைப்பு அடுக்கையும் தரப்படுத்தி, காலப்போக்கில் பிழைகளை கண்காணிக்கிறது.

திட்டங்கள் முதல் தர கலைப்பொருட்களாகக் கருதப்படுகின்றன. சிறிய மாற்றங்களுக்கு தாற்காலிக இலகுரக திட்டங்கள் பயன்படுத்தப்படுகின்றன, ஆனால் சிக்கலான வேலைகள் முன்னேற்றம் மற்றும் முடிவு பதிவுகளுடன் செயலாக்க திட்டங்களில்⁠(புதிய சாளரத்தில் திறக்கும்) பதிவு செய்யப்பட்டு ரிபாசிட்டரியில் செக்-இன் செய்யப்படுகின்றன. செயலில் உள்ள திட்டங்கள், முடிக்கப்பட்ட திட்டங்கள், மற்றும் அறியப்பட்ட தொழில்நுட்பக் கடன் ஆகியவை அனைத்தும் பதிப்பிடப்பட்டு ஒரே இடத்தில் வைக்கப்பட்டுள்ளன, இதனால் ஏஜென்ட்கள் வெளிப்புற சூழலை சாராமல் செயல்பட முடிகிறது.

இது படிப்படியான வெளிப்படுத்தலை செயல்படுத்துகிறது: ஏஜென்ட்கள் ஒரு சிறிய, நிலையான தொடக்கப் புள்ளியுடன் தொடங்கி, ஆரம்பத்திலேயே அதிகமாக சுமத்தப்படுவதற்குப் பதிலாக, அடுத்ததாக எங்கு பார்க்க வேண்டும் என்று கற்றுக்கொடுக்கப்படுகிறார்கள்.

நாங்கள் இதை இயந்திரமாக அமல்படுத்துகிறோம். அர்ப்பணிக்கப்பட்ட லின்டர்கள் மற்றும் CI வேலைகள் அறிவுத் தளம் புதுப்பிக்கப்பட்டது, குறுக்கு இணைக்கப்பட்டது மற்றும் சரியாக அமைக்கப்பட்டது என்பதை உறுதிப்படுத்துகின்றன. மீண்டும் மீண்டும் இயங்கும் “doc-gardening” ஏஜென்ட், உண்மையான குறியீட்டு நடத்தையை பிரதிபலிக்காத பழைய அல்லது காலாவதியான ஆவணங்களை ஸ்கேன் செய்து, சரிசெய்தல் pull request ஐ திறக்கிறது.

கோட்பேஸ் வளர்ந்தபோது, வடிவமைப்பு முடிவுகளுக்கான Codex இன் கட்டமைப்பும் வளர வேண்டும்.

ரிபாசிட்டரி முழுவதும் ஏஜென்ட் மூலம் உருவாக்கப்பட்டதால், முதலில் Codex legibility க்கு இது மேம்படுத்தப்பட்டுள்ளது. புதிய பொறியியல் நியமனங்களுக்கு தங்கள் குறியீட்டின் வழிசெலுத்தல் திறனை மேம்படுத்த அணிகள் முயல்வதைப் போலவே, எங்கள் மனித பொறியாளர்களின் இலக்கு, ஒரு ஏஜென்ட் முழு வணிக டொமைனை ரிபாசிட்டரியிலிருந்தே நேரடியாகபகுத்தறிய முடியும் வகையில் செய்வதாக இருந்தது.

ஏஜென்டின் பார்வையில், அது இயங்கும் போது சூழலுக்குள் அணுக முடியாத எதுவும் நடைமுறையில் இல்லை என்று கருதப்படுகிறது. Google Docs, சாட் த்ரெட்கள் அல்லது மக்களின் மனதில் இருக்கும் அறிவு அமைப்பால் அணுக முடியாது. ரிபாசிட்டரி-உள், பதிப்பிடப்பட்ட கலைப்பொருட்கள் (எ.கா., code, markdown, ஸ்கீமா, executable plans) மட்டுமே அதனால் காண முடியும்.

நேரத்தின்போது, மேலும் மேலும் சூழலை repo க்குள் சேர்க்க வேண்டியிருந்ததை நாங்கள் கற்றுக்கொண்டோம். அந்த Slack விவாதம் குழுவை ஒரு கட்டமைப்பு முறைமையில் ஒத்திசைத்ததா? அது ஏஜென்டால் கண்டுபிடிக்க முடியாவிட்டால், மூன்று மாதங்கள் கழித்து சேரும் புதிய நியமனத்திற்கு தெரியாதது போலவே, அது வாசிக்க முடியாததாக இருக்கும்.

Codex க்கு மேலும் சூழலை வழங்குவது என்பது, தற்காலிக வழிமுறைகளால் அதை மூழ்கடிப்பதற்குப் பதிலாக, ஏஜென்ட் அதன்மீது காரணமறியக்கூடிய வகையில் சரியான தகவலை ஒழுங்கமைத்து வெளிப்படுத்துவதாகும். புதிய குழு உறுப்பினரை தயாரிப்பு கொள்கைகள், பொறியியல் நெறிமுறைகள், மற்றும் குழு கலாச்சாரம் (எமோஜி விருப்பங்களும் உட்பட) குறித்து நீங்கள் அறிமுகப்படுத்துவது போலவே, இந்த தகவலை ஏஜென்ட் க்கு வழங்குவது மேலும் சிறப்பாக ஒத்திசைந்த வெளியீட்டிற்கு வழிவகுக்கும்.

இந்த அமைப்பு பல சமரசங்களைத் தெளிவுபடுத்தியது. ரெப்போக்குள் முழுமையாக உள்வாங்கி, அதைப் பற்றி பகுத்தறியக்கூடிய சார்புகள் மற்றும் அப்ஸ்ட்ராக்ஷன்களையே நாங்கள் விரும்பினோம். “சலிப்பானவை” என்று அடிக்கடி விவரிக்கப்படும் தொழில்நுட்பங்கள், இணைக்கக்கூடிய தன்மை, API நிலைத்தன்மை, மற்றும் பயிற்சி தொகுப்பில் உள்ள பிரதிநிதித்துவம் காரணமாக ஏஜென்ட்களுக்கு மாடல் செய்ய எளிதாக இருக்கும். சில சந்தர்ப்பங்களில், பொது நூலகங்களின் தெளிவற்ற மேல்நிலை நடத்தையைச் சமாளிப்பதற்குப் பதிலாக, செயல்பாடுகளின் துணைத்தொகுதிகளை ஏஜென்ட் மீண்டும் செயல்படுத்துவது மலிவாக இருந்தது. உதாரணமாக, பொதுவான p-limit பாணி பாக்கேஜை பயன்படுத்துவதற்குப் பதிலாக, நாங்கள் எங்களுக்கென map-with-concurrency உதவியாளரை உருவாக்கினோம்: அது எங்கள் OpenTelemetry கருவிகளுடன் நெருக்கமாக ஒருங்கிணைக்கப்பட்டுள்ளது, 100% சோதனை கவரேஜை கொண்டுள்ளது, மேலும் எங்கள் runtime எதிர்பார்ப்பதுபோலவே துல்லியமாக செயல்படுகிறது.

அமைப்பின் மேலும் பல பகுதிகளை ஏஜென்ட் ஆய்வு செய்ய, சரிபார்க்க, மற்றும் நேரடியாக மாற்றக்கூடிய ஒரு வடிவத்திற்குள் கொண்டு வருவது தாக்கத்தை அதிகரிக்கிறது—Codex மட்டுமல்ல, பிற ஏஜென்ட்களுக்கும் (எ.கா. Aardvark) குறியீட்டு தளத்திலும் பணியாற்றி வருகின்றது.

ஆவணங்கள் மட்டும் முழுமையாக ஏஜென்ட் உருவாக்கிய குறியீட்டுத்தளத்தை ஒற்றுமையாக வைத்திருக்க முடியாது. மாறாத விதிகளை அமல்படுத்தி, செயலாக்கங்களை மிக நுணுக்கமாகக் கட்டுப்படுத்தாமல், அடித்தளத்தை பாதிக்காமல் ஏஜென்ட்கள் வேகமாக வெளியிட அனுமதிக்கிறோம். எடுத்துக்காட்டாக, எல்லையில் தரவு வடிவங்களை பாகுபடுத்த⁠(புதிய சாளரத்தில் திறக்கும்) Codex ஐ நாங்கள் கோருகிறோம், ஆனால் அது எவ்வாறு நிகழ்கிறது என்பது குறித்து அவை பரிந்துரைக்கப்படவில்லை (மாடல் Zod ஐ விரும்புவதாகத் தெரிகிறது, ஆனால் அந்த குறிப்பிட்ட நூலகத்தை நாங்கள் குறிப்பிடவில்லை).

ஏஜென்ட்கள் கடுமையான எல்லைகள் மற்றும் முன்கணிக்கக்கூடிய அமைப்பு⁠(புதிய சாளரத்தில் திறக்கும்) கொண்ட சூழல்களில் மிகச் சிறப்பாக செயல்படுகின்றன, எனவே நாங்கள் பயன்பாட்டை ஒரு உறுதியான கட்டமைப்பு மாடலைச் சுற்றி உருவாக்கினோம். ஒவ்வொரு வணிக துறையும் நிரந்தர அடுக்குகளின் ஒரு தொகுப்பாகப் பிரிக்கப்படுகிறது, கடுமையாக சரிபார்க்கப்பட்ட சார்பு திசைகளும், அனுமதிக்கப்படும் விளிம்புகளின் வரையறுக்கப்பட்ட தொகுப்பும் கொண்டது. இந்த கட்டுப்பாடுகள் தனிப்பயன் லிண்டர்கள் (Codex-உருவாக்கியது, நிச்சயமாக!) மற்றும் கட்டமைப்பு சோதனைகள் மூலம் தானியங்கி முறையில் அமல்படுத்தப்படுகின்றன.

கீழே உள்ள வரைபடம் விதியைக் காட்டுகிறது: ஒவ்வொரு வணிக டொமைனுக்குள்ளும் (எ.கா. செயலி அமைப்புகள்), குறியீடு ஒரு நிர்ணயிக்கப்பட்ட அடுக்குகளின் தொகுப்பின் வழியாக மட்டுமே “முன்னோக்கி” சார்ந்திருக்க முடியும் (Types → Config → Repo → Service → Runtime → UI). குறுக்கு-வெட்டு கவலைகள் (auth, connectors, தொலைநோக்கி, அம்சக் கொடிகள்) ஒரே வெளிப்படையான இடைமுகத்தின் மூலம் நுழைகின்றன: வழங்குநர்கள். வேறு எதுவும் அனுமதிக்கப்படாது, மேலும் இது இயந்திரமாக அமல்படுத்தப்படும்.

நூற்றுக்கணக்கான பொறியாளர்கள் இருக்கும் வரை நீங்கள் வழக்கமாக ஒத்திவைக்கும் கட்டிடக்கலை இதுதான். கோடிங் ஏஜென்ட்களுடன், இது ஒரு ஆரம்பகால முன்நிபந்தனை: கட்டுப்பாடுகள் தான் சிதைவு அல்லது கட்டமைப்பு விலகல் இல்லாமல் வேகத்தை அனுமதிக்கின்றன.

நடைமுறையில், இந்த விதிகளை நாங்கள் தனிப்பயன் லிண்டர்கள் மற்றும் கட்டமைப்பு சோதனைகள் மற்றும் "சுவை மாறாதவைகளின்" ஒரு சிறிய தொகுப்பு மூலம் செயல்படுத்துகிறோம். எடுத்துக்காட்டாக, தனிப்பயன் லிண்ட்களைப் பயன்படுத்தி, கட்டமைக்கப்பட்ட பதிவு செய்தல், ஸ்கீமாக்கள் மற்றும் வகைகளுக்கான பெயரிடும் மரபுகள், கோப்பு அளவு வரம்புகள் மற்றும் தளம் சார்ந்த நம்பகத்தன்மை தேவைகளை நாங்கள் நிலையான முறையில் செயல்படுத்துகிறோம். லின்ட்கள் தனிப்பயனாக்கப்பட்டவை என்பதால், ஏஜென்ட் சூழலில் திருத்த வழிமுறைகளைச் சேர்க்க பிழைச் செய்திகளை நாங்கள் எழுதுகிறோம்.

மனிதர்கள் முதன்மையாகச் செய்யும் பணிப்பாய்வில், இந்த விதிகள் பகுத்தறிவற்றதாகவோ அல்லது கட்டுப்படுத்துவதாகவோ தோன்றலாம். ஏஜென்ட்களுடன், அவை பெருக்கிகளாக மாறுகின்றன: ஒருமுறை குறியாக்கம் செய்யப்பட்டவுடன், அவை ஒரே நேரத்தில் எல்லா இடங்களிலும் செயல்படும்.

அதே நேரத்தில், கட்டுப்பாடுகள் எங்கு முக்கியம் மற்றும் எங்கு அவை முக்கியமல்ல என்பதைக் குறித்து நாங்கள் தெளிவாக இருக்கிறோம். இது ஒரு பெரிய பொறியியல் பிளாட்ஃபார்ம் அமைப்பை வழிநடத்துவது போன்றது: மையத்தில் எல்லைகளை அமல்படுத்துங்கள், உள்ளூரில் சுயாட்சியை அனுமதியுங்கள். நீங்கள் எல்லைகள், சரியான தன்மை, மற்றும் மீண்டும் உருவாக்கத்தன்மை ஆகியவற்றைப் பற்றி ஆழமாக அக்கறை கொள்கிறீர்கள். அந்த எல்லைகளுக்குள், தீர்வுகள் எவ்வாறு வெளிப்படுத்தப்படுகின்றன என்பதில் குழுக்களுக்கும் அல்லது ஏஜென்ட்களுக்கும் கணிசமான சுதந்திரத்தை நீங்கள் வழங்குகிறீர்கள்.

முடிவாக வரும் குறியீடு எப்போதும் மனித ஸ்டைலிஸ்டிக் விருப்பங்களுடன் பொருந்தாது, அது சரி. வெளியீடு சரியாகவும், பராமரிக்கக்கூடியதாகவும், எதிர்கால ஏஜென்ட் இயக்கங்களுக்கு வாசிக்கத் தெளிவாகவும் இருந்தால், அது தேவையான தரநிலையை பூர்த்தி செய்கிறது.

மனிதர்களின் சுவை தொடர்ந்து முறைமைக்குத் திரும்ப வழங்கப்படுகிறது. மதிப்பீட்டு கருத்துகள், மறுசீரமைப்பு pull requests, மற்றும் பயனர்-முன்னோக்கிய பிழைகள் ஆவணப்பதிவுகளாகப் பதிவு செய்யப்படுகின்றன அல்லது நேரடியாக கருவிகளில் குறியாக்கப்படுகின்றன. ஆவணமாக்கல் குறைவாக இருக்கும்போது, அந்த விதியை குறியீடாக மாற்றுகிறோம்

Codex-இன் த்ரூபுட் அதிகரித்தபோது, பல பாரம்பரிய பொறியியல் நெறிமுறைகள் பயனற்றவையாக மாறின.

ரிபாசிட்டரி குறைந்த அளவிலான தடுப்பு இணைப்பு வாயில்களுடன் செயல்படுகிறது. Pull request கள் குறுகிய காலத்திற்கு மட்டுமே இருக்கும். சோதனை பிழைகள் பெரும்பாலும் முன்னேற்றத்தை முடிவில்லாமல் தடுக்காமல், பின்தொடர்வு செயல்முறைகள் மூலம் கையாளப்படுகின்றன. மனித கவனத்தை விட ஏஜென்ட் த்ரூபுட் மிக அதிகமாக இருக்கும் ஒரு அமைப்பில், திருத்தங்கள் மலிவானவை, ஆனால் காத்திருப்பது விலையுயர்ந்தது.

குறைந்த த்ரூபுட் சூழலில் இது பொறுப்பற்றதாக இருக்கும். இங்கே, பெரும்பாலும் இது சரியான சமநிலையாகும்.

நாம் Codex ஏஜெண்ட்களால் குறியீட்டுத் தொகுப்பு உருவாக்கப்பட்டது என்று சொல்வது, குறியீட்டுத் தொகுப்பில் உள்ள அனைத்தையும் குறிக்கிறது.

ஏஜென்ட்கள் உருவாக்குகின்றன:

• தயாரிப்பு குறியீடு மற்றும் சோதனைகள்
• CI கட்டமைப்பு மற்றும் வெளியீட்டு கருவிகள்
• உள்ளக டெவலப்பர் கருவிகள்
• ஆவணங்கள் மற்றும் வடிவமைப்பு வரலாறு
• மதிப்பீட்டு கருவிகள்
• மதிப்பீடு கருத்துகள் மற்றும் பதில்கள்
• ரிபாசிட்டரியைத் தானே நிர்வகிக்கும் ஸ்கிரிப்டுகள்
• உற்பத்தி டாஷ்போர்டு வரையறை கோப்புகள்

மனிதர்கள் எப்போதும் செயல்பாட்டில் உள்ளனர், ஆனால் நாம் பழகியதை விட வேறொரு சுருக்க நிலை அடுக்கில் பணியாற்றுகிறார்கள். நாங்கள் பணிக்கு முன்னுரிமை அளிக்கிறோம், பயனர் கருத்துக்களை ஏற்றுக்கொள்ளும் அளவுகோல்களாக மாற்றுகிறோம், மற்றும் முடிவுகளைச் சரிபார்க்கிறோம். ஏஜென்ட் சிரமப்படும்போது, அதை ஒரு சிக்னலாகக் கருதுகிறோம்: என்ன குறைகிறது—கருவிகள், பாதுகாப்பு தடுப்புகள், ஆவணங்கள்—என்பதை அடையாளம் கண்டு, அதை ரிபாசிட்டரியில் மீண்டும் சேர்க்கிறோம், எப்போதும் Codex தானே திருத்தத்தை எழுதச் செய்வதன் மூலம்.

ஏஜென்ட்கள் எங்கள் நிலையான மேம்பாட்டு கருவிகளை நேரடியாகப் பயன்படுத்துகின்றனர். அவர்கள் மதிப்பீட்டு கருத்துக்களைப் பெறுகிறார்கள், நேரடியாக பதிலளிக்கிறார்கள், புதுப்பிப்புகளைப் புதுப்பிக்கிறார்கள், மேலும் அடிக்கடி தங்களுடைய pull request களை சுருக்கி இணைக்கிறார்கள்.

மேம்பாட்டு வளையத்தின் பெரும்பகுதி நேரடியாக அமைப்பில் - சோதனை, சரிபார்ப்பு, மதிப்பாய்வு, பின்னூட்ட கையாளுதல் மற்றும் மீட்பு - குறியாக்கம் செய்யப்பட்டதால், ரிபாசிட்டரி சமீபத்தில் ஒரு அர்த்தமுள்ள வரம்பைக் கடந்தது, அங்கு Codex ஒரு புதிய அம்சத்தை முழுமையாக இயக்க முடியும்.

ஒரே ஒரு ப்ராம்ப்ட் கொடுத்தால், ஏஜென்ட் இப்போது செய்ய முடியும்:

• கோட்பேஸின் தற்போதைய நிலையை சரிபார்க்கவும்
• புகாரளிக்கப்பட்ட பிழையை மீண்டும் உருவாக்கவும்
• தோல்வியை விளக்கும் வீடியோவை பதிவு செய்யவும்
• சரிசெய்தலை செயல்படுத்தவும்
• பயன்பாட்டை இயக்கி திருத்தத்தைச் சரிபார்க்கவும்
• தீர்வை விளக்கும் இரண்டாவது வீடியோவை பதிவு செய்யவும்
• Pull request திறக்கவும்
• ஏஜென்ட் மற்றும் மனிதர்களின் பின்னூட்டத்திற்கு பதிலளிக்கவும்
• கட்டுமான தோல்விகளை கண்டறிந்து சரிசெய்யவும்
• தீர்மானம் தேவைப்படும் போது மட்டுமே மனிதரிடம் உயர்த்த வேண்டும்
• மாற்றத்தை இணைக்கவும்

இந்த நடத்தை இந்த ரிபாசிட்டரியின் குறிப்பிட்ட அமைப்பு மற்றும் கருவிகளின் மீது பெரிதும் சார்ந்துள்ளது, மேலும் இதே போன்ற முதலீடு இல்லாமல் பொதுவாகப் பொருந்தும் என்று கருதக்கூடாது—குறைந்தபட்சம், இன்னும் இல்லை.

முழு ஏஜென்ட் தன்னாட்சி புதிய சிக்கல்களை அறிமுகப்படுத்துகிறது. Codex ஏற்கனவே ரிபாசிட்டரியில் உள்ள வடிவங்களை—சீரற்ற அல்லது சிறப்பற்றவற்றையும்—மீண்டும் உருவாக்குகிறது. காலப்போக்கில், இது தவிர்க்க முடியாத வகையில் மாறுதலுக்கு வழிவகுக்கிறது.

ஆரம்பத்தில், மனிதர்கள் இதை கையால் செய்தனர். எங்கள் குழு ஒவ்வொரு வெள்ளிக்கிழமையும் (வாரத்தின் 20%) “AI slop” ஐ சுத்தம் செய்வதில் செலவழித்து வந்தது. எதிர்பார்த்ததுபோல, அது அளவுபடுத்தப்படவில்லை.

அதற்குப் பதிலாக, நாங்கள் “பொற்கொள்கைகள்” என்று அழைப்பவற்றை நேரடியாக ரிபாசிட்டரிக்குள் குறியாக்கத் தொடங்கி, மீண்டும் மீண்டும் நடைபெறும் சுத்தம் செய்யும் செயல்முறையையும் உருவாக்கினோம். இந்தக் கோட்பாடுகள் கருத்து சார்ந்த, இயந்திர விதிகளாகும், அவை குறியீட்டுத்தளத்தை வாசிக்க எளிதாகவும் ஒரே மாதிரியாகவும் வைத்திருப்பதன் மூலம் எதிர்கால ஏஜென்ட் இயக்கங்களுக்கு உதவுகின்றன. உதாரணமாக: (1) மாற்றத்தை மையப்படுத்தியதாக வைத்திருக்க கையால் உருட்டப்பட்ட உதவியாளர்களை விட பகிரப்பட்ட பயன்பாட்டு தொகுப்புகளை நாங்கள் விரும்புகிறோம், மேலும் (2) “YOLO-style” தரவை நாங்கள் ஆய்வு செய்வதில்லை - நாங்கள் எல்லைகளை சரிபார்க்கிறோம் அல்லது தட்டச்சு செய்யப்பட்ட SDKகளை நம்பியிருக்கிறோம், இதனால் ஏஜென்ட் தற்செயலாக யூகிக்கப்பட்ட வடிவங்களில் உருவாக்க முடியாது. வழக்கமான இடைவெளியில், விலகல்களை ஸ்கேன் செய்யும், தர மதிப்பீடுகளைப் புதுப்பிக்கும், மற்றும் இலக்கிடப்பட்ட மறுசீரமைப்பு pull request களைத் திறக்கும் பின்னணியில் இயங்கும் Codex பணிகளின் ஒரு தொகுப்பு எங்களிடம் உள்ளது. இவற்றில் பெரும்பாலானவற்றை ஒரு நிமிடத்திற்குள் மதிப்பாய்வு செய்து தானாகவே இணைக்கப்படலாம்.

இது குப்பை சேகரிப்பு போல செயல்படுகிறது. தொழில்நுட்பக் கடன் என்பது அதிக வட்டி கொண்ட கடனைப் போன்றது: அதை கூட்டாக பெருக விடாமல், சிறு சிறு அளவுகளில் தொடர்ந்து செலுத்துவது, வலியூட்டும் திடீர் கட்டங்களாக சமாளிப்பதைவிட பெரும்பாலும் சிறந்தது. மனித ரசனை ஒருமுறை பிடிக்கப்பட்டு, பின்னர் ஒவ்வொரு குறியீட்டு வரியிலும் தொடர்ந்து அமல்படுத்தப்படுகிறது. இது மேலும், அவை நாட்கள் அல்லது வாரங்கள் முழுவதும் குறியீட்டு அடிப்படையில் பரவ விடாமல், தினசரி அடிப்படையில் மோசமான வடிவங்களைப் பிடித்து தீர்க்க எங்களுக்கு உதவுகிறது.

இந்த மூலோபாயம் இதுவரை OpenAI இல் உள்ளக வெளியீடு மற்றும் தத்தெடுப்பில் நன்றாக செயல்பட்டுள்ளது. உண்மையான பயனர்களுக்காக ஒரு உண்மையான தயாரிப்பை உருவாக்குவதன் மூலம் எங்கள் முதலீடுகளை நிஜத்துடன் இணைத்து, நீண்டகால பராமரிப்புத் திறனை நோக்கி எங்களை வழிநடத்த உதவியது.

முழுமையாக ஏஜென்ட் உருவாக்கப்பட்ட அமைப்பில், கட்டமைப்பு ஒத்திசைவு பல ஆண்டுகளாக எவ்வாறு வளர்கிறது என்பதை நாம் இன்னும் அறியவில்லை. மனித தீர்ப்பு எங்கு அதிக தாக்கத்தை அளிக்கிறது என்பதையும், அந்த தீர்ப்பை எவ்வாறு குறியாக்கம் செய்தால் அது சேர்ந்து பெருகும் என்பதையும் நாங்கள் இன்னும் கற்றுக்கொண்டிருக்கிறோம். மாடல்கள் மேலும் திறனுள்ளவையாக மாறிக்கொண்டிருக்கும் போது, இந்த அமைப்பு எவ்வாறு வளர்ச்சியடையும் என்பதையும் நாங்கள் இன்னும் அறியவில்லை.

தெளிவாகியிருப்பது இதுதான்: மென்பொருள் உருவாக்கம் இன்னும் ஒழுக்கத்தைத் தேவைப்படுத்துகிறது, ஆனால் அந்த ஒழுக்கம் குறியீட்டில் அல்ல, மாறாக ஆதரவு கட்டமைப்பில் அதிகமாக வெளிப்படுகிறது. குறியீட்டுத் தளத்தை ஒத்திசைவாக வைத்திருக்கும் கருவிகள், சுருக்கங்கள் மற்றும் பின்னூட்ட சுழல்கள் பெருகிய முறையில் முக்கியமானவை.

எங்களின் மிகக் கடினமான சவால்கள் இப்போது சூழல்கள், பின்னூட்டச் சுழற்சிகள், மற்றும் கட்டுப்பாட்டு அமைப்புகளை வடிவமைப்பதில் மையமாகின்றன — அவை ஏஜென்ட்கள் எங்கள் இலக்கை நிறைவேற்ற உதவுகின்றன: அளவளாவிய அளவில் சிக்கலான, நம்பகமான மென்பொருளை உருவாக்கவும் பராமரிக்கவும்.

Codex போன்ற ஏஜென்ட்கள் மென்பொருள் வாழ்க்கைச் சுழற்சியின் பெரிய பகுதிகளை ஏற்றுக்கொள்ளும் போது, இந்த கேள்விகள் மேலும் முக்கியத்துவம் பெறும். சில ஆரம்பப் பாடங்களைப் பகிர்வது, உங்கள் முயற்சியை எங்கு முதலீடு செய்ய வேண்டும் என்பதைப் பற்றி நீங்கள் சிந்திக்க உதவும் என்று நாங்கள் நம்புகிறோம், அதனால் நீங்கள் எளிதாகவே விஷயங்களை உருவாக்க முடியும்.