𝗧𝗵𝗲 𝗗𝗿𝗶𝗳𝘁 𝗳𝗿𝗼𝗺 𝗖𝗵𝗮𝘁 𝘁𝗼 𝗕𝗮𝗰𝗸𝗹𝗼𝗴
మూడు నెలల క్రితం, నా టాస్క్ మేనేజ్మెంట్ కేవలం ఒక చాట్ విండో మాత్రమే. నేను ఆ ట్యాబ్ను మూసివేస్తే, ప్లాన్ కూడా పోయేది.
ఈరోజు, అది ఒక Postgres బ్యాక్లాగ్. Claude Code, Codex మరియు Grok అనే మూడు వేర్వేరు AI ఏజెంట్లు దాని నుండి పనిని తీసుకుంటాయి. అవి ఆ పనిని ఎవరు చేశారో (attribution) నమోదు చేస్తాయి మరియు git హిస్టరీ ఆధారంగా దానిని క్లోజ్ చేస్తాయి.
నేను ప్రాజెక్ట్ మేనేజ్మెంట్ సిస్టమ్ను నిర్మించాలని అనుకోలేదు. కానీ నేను ఎదుర్కొంటున్న అడ్డంకుల వల్ల ఇది తప్పనిసరి అయింది. ప్రతిసారి ఒక సమస్యను పరిష్కరించినప్పుడల్లా, మరొక కొత్త సమస్య ఎదురవుతోంది.
నా పని చాలా భారంగా ఉంటుంది. నేను Nexus అనే పర్సనల్ డేటా ప్లాట్ఫారమ్ను నడుపుతున్నాను. నేను సుమారు 100 రిపోజిటరీలను నిర్వహిస్తున్నాను. ఒకానొక సమయంలో, నేను 35 రోజుల్లో 557,000 లైన్ల కోడ్ను షిప్ చేశాను. ఆ స్థాయిలో పని ఉండటం వల్ల నేను ప్రయత్నించిన ప్రతి ప్లానింగ్ పద్ధతి విఫలమైంది.
నా సిస్టమ్ ఎలా పరిణామం చెందిందో ఇక్కడ ఉంది:
Phase 1: Conversational Planning ప్లాన్ చాట్ హిస్టరీలోనే ఉండేది. నేను ఆలోచనలను బయటపెడుతూ, ఒక మంచి ఐడియా వచ్చిన వెంటనే బిల్డింగ్ మొదలుపెట్టేవాడిని.
- సమస్య: చాట్ ముగియగానే ప్లాన్లు మాయమైపోయేవి. వాటికి ప్రాధాన్యత ఇవ్వడం లేదా వేరొకరికి అప్పగించడం సాధ్యమయ్యేది కాదు.
Phase 2: Per-Repo TODO Files నేను ప్రతి రిపోజిటరీలో TODO.md ఫైల్లను ఉపయోగించడం ప్రారంభించాను. సాధారణ చెక్లిస్ట్లను వాడటం మానేసి, వాటికి బదులుగా చిన్న స్పెసిఫికేషన్లు (specs) రాయడం మొదలుపెట్టాను. ప్రతి అంశంలో ఇవి ఉండేవి:
- స్థితి (Status) మరియు తేదీ.
- ఒక ట్రిగ్గర్ (ఇది ఎందుకు అత్యవసరమైంది).
- ముందుగా నిర్ణయించిన దశలు (ప్లాన్).
- తెలిసిన రిస్క్లు.
- సమస్య: 100 రిపోజిటరీలతో, నాకు గ్లోబల్ వ్యూ (global view) ఉండేది కాదు. నేను చేయాల్సిన పనులన్నీ ఒకే చోట చూడలేకపోయాను.
Phase 3: The Operator Backlog (OB) నేను టాస్క్లను Postgres డేటాబేస్లోకి మార్చాను. దీనివల్ల ఒక గ్లోబల్ క్యూ (global queue) ఏర్పడింది. నేను ఒక అప్రూవల్ గేట్ను (approval gate) జోడించాను. నేను రివ్యూ చేసిన తర్వాతే ఒక టాస్క్ నిజమైనదిగా మారుతుంది. దీనివల్ల AI అనవసరమైన డేటాను బ్యాక్లాగ్లోకి చేర్చకుండా నిరోధించవచ్చు. నేను స్టేటస్ లేన్లను (status lanes) ఉపయోగించాను:
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- సమస్య: నేను ఒక అడ్డంకిగా (bottleneck) మారాను. నేను ఆ లేన్లను తగినంత వేగంగా ఖాళీ చేయలేకపోయాను.
Phase 4: Multi-Agent Execution బ్యాక్లాగ్ ఇప్పుడు బహుళ AI ఏజెంట్ల కోసం ఒక షేర్డ్ క్యూ (shared queue).
- అవి ఒకే టాస్క్పై పని చేయకుండా ఉండటానికి లీజులు (leases) ఉపయోగిస్తాయి.
- ఎవరు ఏమి చేశారో నాకు తెలియడానికి అవి అట్రిబ్యూషన్ (attribution) ఉపయోగిస్తాయి.
- అవి పనిని ఒకరి నుండి ఒకరికి అప్పగించగలవు (hand off). ఒక ఏజెంట్ ఒక టాస్క్ అసాధ్యమని భావిస్తే, దానికి కావాల్సిన ముందస్తు అవసరాన్ని (prerequisite) ఫైల్ చేయవచ్చు. అప్పుడు రెండవ ఏజెంట్ ఆ ముందస్తు అవసరాన్ని పూర్తి చేసి, అసలు టాస్క్ను ముగించగలదు.
పాఠం చాలా సరళమైనది: మీరు విజయం సాధించడానికి ఫేజ్ 4 అవసరం లేదు.
మీరు ఏదైనా ఒకటి నేర్చుకోవాలనుకుంటే, ఫేజ్ 2 ఫార్మాట్ను అనుసరించండి. మీ టాస్క్లను స్థితి (status), ట్రిగ్గర్ (trigger), ముందుగా నిర్ణయించిన దశలు (pre-decided steps) మరియు రిస్క్లతో (risks) రాయండి. దీనికి ఖర్చు ఏమీ ఉండదు, కానీ ఇది అన్నింటినీ మార్చేస్తుంది.
అత్యంత ముఖ్యమైన నియమం ఇది: ఎల్లప్పుడూ వాస్తవాల ఆధారంగానే ప్రణాళికలు సిద్ధం చేసుకోండి. ఊహలు లేదా సారాంశాల ఆధారంగా ఎప్పుడూ ప్రణాళికలు వేయకండి. పాత డేటా ఆధారంగా రూపొందించిన పరిపూర్ణ ప్రణాళిక కూడా, అసలు ప్రణాళిక లేకపోవడం వల్ల కలిగే నష్టంతో సమానంగా వేగంగా విఫలమవుతుంది.
ఐచ్ఛిక అభ్యాస సమూహం: https://t.me/GyaanSetuAi