𝗧𝗵𝗲 𝗗𝗿𝗶𝗳𝘁 𝗳𝗿𝗼𝗺 𝗖𝗵𝗮𝘁 𝘁𝗼 𝗕𝗮𝗰𝗸𝗹𝗼𝗴

चॅटपासून बॅकलॉगकडे झालेला प्रवास

तीन महिन्यांपूर्वी, माझे टास्क मॅनेजमेंट फक्त एक चॅट विंडो होती. जर मी टॅब बंद केला, तर प्लॅन गायब व्हायचा.

आज, ते एक Postgres बॅकलॉग आहे. Claude Code, Codex आणि Grok हे तीन वेगवेगळे AI एजंट्स त्यातून काम घेतात. ते कामावर attribution नोंदवतात आणि git history च्या आधारे ते पूर्ण करून बंद करतात.

मला प्रोजेक्ट मॅनेजमेंट सिस्टम बनवायची नव्हती. मी फक्त अडचणींचा सामना करत होतो. प्रत्येक वेळी जेव्हा मी एखादी समस्या सोडवायचा प्रयत्न करायचो, तेव्हा एक नवीन समस्या समोर येत असे.

माझे काम खूप मोठे आहे. मी Nexus नावाचे एक पर्सनल डेटा प्लॅटफॉर्म चालवतो. मी सुमारे १०० रिपॉझिटरीज मॅनेज करतो. एका काळात, मी ३५ दिवसांत ५,५७,००० ओळींचा कोड शिप केला. त्या प्रचंड प्रमाणामुळे मी वापरलेले सर्व प्लॅनिंगचे मार्ग अपयशी ठरले.

माझी सिस्टम कशी विकसित झाली ते खालीलप्रमाणे आहे:

टप्पा १: संवादात्मक नियोजन (Conversational Planning) प्लॅन चॅट हिस्ट्रीमध्ये असायचा. मी मोठ्याने विचार करायचो, एक चांगली कल्पना सुचायची आणि काम सुरू करायचो.

• समस्या: चॅट संपले की प्लॅन गायब व्हायचा. तुम्ही त्यांना प्राधान्य देऊ शकत नसत किंवा ते दुसऱ्या कोणाकडेही सोपवू शकत नसत.

टप्पा २: प्रति-रिपॉझिटरी TODO फाइल्स (Per-Repo TODO Files) मी प्रत्येक रिपॉझिटरीमध्ये TODO.md फाइल्स वापरण्यास सुरुवात केली. मी साध्या चेकलिस्ट वापरणे थांबवले. त्याऐवजी, मी लहान स्पेसिफिकेशन्स (specs) लिहायला सुरुवात केली. प्रत्येक आयटममध्ये खालील गोष्टींचा समावेश असे:

• स्टेटस आणि तारीख.
• ट्रिगर (हे काम तातडीचे का झाले).
• आधीच ठरवलेले टप्पे (प्लॅन).
• ज्ञात धोके (Known risks).
• समस्या: १०० रिपॉझिटरीज असल्यामुळे, मला कोणताही जागतिक दृष्टिकोन (global view) मिळत नव्हता. मला करायच्या सर्व गोष्टी एकाच ठिकाणी पाहता येत नव्हत्या.

टप्पा ३: ऑपरेटर बॅकलॉग (The Operator Backlog - OB) मी टास्क एका Postgres डेटाबेसमध्ये हलवले. यामुळे एक ग्लोबल क्यू (global queue) तयार झाला. मी एक अप्रूव्हल गेट (approval gate) जोडले. मी रिव्ह्यू केल्यानंतरच एखादा टास्क 'रिअल' मानला जातो. यामुळे AI बॅकलॉगमध्ये कचरा भरत नाही. मी स्टेटस लेन (status lanes) वापरले:

• requires_triage
• requires_decision
• requires_investigation
• autonomous_safe
• समस्या: मी स्वतःच अडथळा (bottleneck) ठरलो. मी वेगाने हे स्टेटस लेन रिकामे करू शकत नव्हतो.

टप्पा ४: मल्टी-एजंट एक्झिक्यूशन (Multi-Agent Execution) बॅकलॉग आता अनेक AI एजंट्ससाठी एक सामायिक क्यू (shared queue) आहे.

• ते 'leases' वापरतात जेणेकरून ते एकाच टास्कवर काम करणार नाहीत.
• ते 'attribution' वापरतात जेणेकरून कोणी काय केले हे मला समजेल.
• ते काम एकमेकांकडे सोपवू शकतात. एखादा एजंट एखादा टास्क अशक्य असल्याचे शोधू शकतो आणि त्यासाठी आवश्यक असलेली पूर्वअट (prerequisite) नोंदवू शकतो. त्यानंतर दुसरा एजंट ती पूर्वअट पूर्ण करून मूळ टास्क पूर्ण करू शकतो.

धडा साधा आहे: यशस्वी होण्यासाठी तुम्हाला टप्पा ४ ची गरज नाही.

जर तुम्ही एक गोष्ट अमलात आणणार असाल, तर टप्पा २ चे फॉरमॅट नक्की वापरा. तुमचे टास्क स्टेटस, ट्रिगर, आधी ठरवलेले टप्पे आणि धोके यांसह लिहा. यासाठी काहीही खर्च येत नाही आणि यामुळे सर्व काही बदलू शकते.

सर्वात महत्त्वाचा नियम हा आहे: नेहमी सत्याच्या आधारे नियोजन करा. कधीही केवळ अंदाज किंवा सारांशावर आधारित नियोजन करू नका. कालबाह्य माहितीवर आधारित केलेले उत्तम नियोजन देखील, नियोजन न करण्याइतकेच लवकर अपयशी ठरेल.

स्रोत: https://dev.to/niclydon/the-drift-from-chat-to-backlog-how-my-ai-task-planning-evolved-over-three-months-2akg

ऐच्छिक शिक्षण समुदाय: https://t.me/GyaanSetuAi