சாட்டிலிருந்து பேக்லாக் வரையிலான மாற்றம்
மூன்று மாதங்களுக்கு முன்பு, எனது பணி மேலாண்மை (task management) என்பது ஒரு சாட் விண்டோ (chat window) மட்டுமே. நான் அந்த டேப்பை (tab) மூடிவிட்டால், திட்டம் காணாமல் போய்விடும்.
இன்று, அது ஒரு Postgres பேக்லாக் (backlog). Claude Code, Codex மற்றும் Grok ஆகிய மூன்று வெவ்வேறு AI ஏஜெண்டுகள் (agents) அதிலிருந்து பணிகளை எடுக்கின்றன. அவை அந்தப் பணியை யாருடையது (attribution) என்று அடையாளப்படுத்தி, git history-யுடன் இணைத்து முடிக்கின்றன.
நான் ஒரு திட்ட மேலாண்மை அமைப்பை (project management system) உருவாக்கத் தொடங்கவில்லை. நான் தொடர்ந்து தடைகளைத் தான் சந்தித்தேன். ஒவ்வொரு முறை ஒரு சிக்கலைத் தீர்க்க முயலும்போதும், ஒரு புதிய சிக்கல் உருவானது.
எனது வேலைப்பளு அதிகம். நான் Nexus எனப்படும் ஒரு தனிப்பட்ட தரவுத் தளத்தை (personal data platform) இயக்குகிறேன். நான் சுமார் 100 ரெப்போசிட்டரிகளை (repositories) நிர்வகிக்கிறேன். ஒரு குறிப்பிட்ட காலத்தில், நான் 35 நாட்களில் 557,000 வரிகள் கொண்ட குறியீடுகளை (lines of code) வெளியிட்டேன். அந்த அளவு, நான் முயன்ற அனைத்துத் திட்டமிடல் முறைகளையும் முறியடித்தது.
எனது அமைப்பு எவ்வாறு பரிணாமம் அடைந்தது என்பது இதோ:
நிலை 1: உரையாடல் சார்ந்த திட்டமிடல் (Conversational Planning) திட்டம் சாட் வரலாற்றிலேயே (chat history) இருந்தது. நான் சத்தமாகச் சிந்திப்பேன், ஒரு நல்ல யோசனையைப் பெறுவேன், பிறகு அதை உருவாக்கத் தொடங்குவேன்.
- சிக்கல்: சாட் முடிந்தவுடன் திட்டங்கள் காணாமல் போயின. அவற்றை முன்னுரிமைப்படுத்தவோ அல்லது வேறு யாருக்காவது ஒப்படைக்கவோ முடியாது.
நிலை 2: ஒவ்வொரு ரெப்போவிற்கும் TODO கோப்புகள் (Per-Repo TODO Files) ஒவ்வொரு ரெப்போசிட்டரியிலும் TODO.md கோப்புகளைப் பயன்படுத்தத் தொடங்கினேன். சாதாரண சரிபார்ப்புப் பட்டியல்களை (checklists) பயன்படுத்துவதை நிறுத்திவிட்டு, அதற்குப் பதிலாகச் சிறிய விவரக்குறிப்புகளை (specs) எழுதினேன். ஒவ்வொரு அம்சத்திலும் பின்வருவன அடங்கும்:
- நிலை (Status) மற்றும் தேதி.
- ஒரு தூண்டுதல் (trigger) (இது ஏன் அவசரமாகிறது).
- முன்கூட்டியே தீர்மானிக்கப்பட்ட படிகள் (திட்டம்).
- தெரிந்த அபாயங்கள் (risks).
- சிக்கல்: 100 ரெப்போக்கள் இருந்ததால், எனக்கு ஒரு ஒட்டுமொத்தப் பார்வை (global view) இல்லை. நான் செய்ய வேண்டிய அனைத்தையும் ஒரே இடத்தில் பார்க்க முடியவில்லை.
நிலை 3: ஆபரேட்டர் பேக்லாக் (The Operator Backlog - OB) நான் பணிகளை ஒரு Postgres தரவுத்தளத்திற்கு (database) மாற்றினேன். இது ஒரு உலகளாவிய வரிசையை (global queue) உருவாக்கியது. நான் ஒரு ஒப்புதல் நுழைவாயிலை (approval gate) சேர்த்தேன். நான் ஆய்வு செய்த பின்னரே ஒரு பணி உண்மையானதாக மாறும். இது AI தேவையற்ற குப்பைகளை (garbage) பேக்லாக்கில் சேர்ப்பதைத் தடுக்கிறது. நான் நிலை வரிசைகளைப் (status lanes) பயன்படுத்தினேன்:
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- சிக்கல்: நானே ஒரு தடையாகி (bottleneck)னேன். அந்த வரிசைகளை என்னால் போதுமான வேகத்தில் காலியாக்க முடியவில்லை.
நிலை 4: பல ஏஜெண்டுகள் மூலம் செயல்படுத்துதல் (Multi-Agent Execution) பேக்லாக் இப்போது பல AI ஏஜெண்டுகளுக்கான ஒரு பகிரப்பட்ட வரிசையாக உள்ளது.
- அவை ஒரே பணியில் வேலை செய்யாமல் இருக்க 'leases' பயன்படுத்துகின்றன.
- யார் என்ன செய்தார்கள் என்பதை நான் அறிய அவை 'attribution' பயன்படுத்துகின்றன.
- அவை பணிகளை ஒப்படைக்க முடியும். ஒரு ஏஜெண்ட் ஒரு பணி சாத்தியமற்றது என்பதைக் கண்டறிந்து, அதற்குத் தேவையான முன்நிபந்தனையை (prerequisite) கோரலாம். பின்னர் இரண்டாவது ஏஜெண்ட் அந்த முன்நிபந்தனையை எடுத்துக்கொண்டு, அசல் பணியை முடிக்கலாம்.
பாடம் எளிமையானது: நீங்கள் வெற்றி பெற நிலை 4 தேவையில்லை.
நீங்கள் ஒன்றை மட்டும் கற்றுக்கொள்ள விரும்பினால், நிலை 2-ன் முறையை மட்டும் கற்றுக்கொள்ளுங்கள். உங்கள் பணிகளை ஒரு நிலை (status), ஒரு தூண்டுதல் (trigger), முன்கூட்டியே தீர்மானிக்கப்பட்ட படிகள் மற்றும் அபாயங்களுடன் (risks) எழுதுங்கள். இதற்கு எந்தச் செலவும் இல்லை, ஆனால் இது அனைத்தையும் மாற்றும்.
மிக முக்கியமான விதி இதுதான்: எப்போதும் உண்மையை அடிப்படையாகக் கொண்டே திட்டமிடுங்கள். ஒரு யூகத்தின் அடிப்படையிலோ அல்லது ஒரு சுருக்கத்தின் அடிப்படையிலோ ஒருபோதும் திட்டமிடாதீர்கள். காலாவதியான தரவுகளைக் கொண்டு உருவாக்கப்பட்ட ஒரு சிறந்த திட்டம், திட்டமே இல்லாததைப் போலவே மிக விரைவாகத் தோல்வியடையும்.
விருப்பத்தேர்வு கற்றல் சமூகம்: https://t.me/GyaanSetuAi