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

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

ಮೂರು ತಿಂಗಳ ಹಿಂದೆ, ನನ್ನ ಕಾರ್ಯ ನಿರ್ವಹಣೆ (task management) ಕೇವಲ ಒಂದು ಚಾಟ್ ವಿಂಡೋ ಆಗಿತ್ತು. ನಾನು ಆ ಟ್ಯಾಬ್ ಅನ್ನು ಮುಚ್ಚಿದರೆ, ಯೋಜನೆಯೇ ಮಾಯವಾಗುತ್ತಿತ್ತು.

ಇಂದು, ಅದು ಒಂದು Postgres ಬ್ಯಾಕ್‌ಲಾಗ್ ಆಗಿದೆ. Claude Code, Codex ಮತ್ತು Grok ಎಂಬ ಮೂರು ವಿಭಿನ್ನ AI ಏಜೆಂಟ್‌ಗಳು ಅದರಿಂದ ಕೆಲಸವನ್ನು ಪಡೆಯುತ್ತವೆ. ಅವು ಕೆಲಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ವಿವರಗಳನ್ನು (attribution) ಸೇರಿಸಿ, git history ಆಧಾರದ ಮೇಲೆ ಅದನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತವೆ.

ನಾನು ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಉದ್ದೇಶಿಸಿರಲಿಲ್ಲ. ನಾನು ಕೇವಲ ಅಡೆತಡೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೆ. ಪ್ರತಿ ಬಾರಿ ನಾನು ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಬಗೆಹರಿಸಿದಾಗ, ಹೊಸ ಸಮಸ್ಯೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿತ್ತು.

ನನ್ನ ಕೆಲಸದ ಒತ್ತಡ ಹೆಚ್ಚಿದೆ. ನಾನು Nexus ಎಂಬ ವೈಯಕ್ತಿಕ ಡೇಟಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ನಡೆಸುತ್ತಿದ್ದೇನೆ. ನಾನು ಸುಮಾರು 100 ರೆಪೊಸಿಟರಿಗಳನ್ನು (repositories) ನಿರ್ವಹಿಸುತ್ತೇನೆ. ಒಂದು ಅವಧಿಯಲ್ಲಿ, ನಾನು 35 ದಿನಗಳಲ್ಲಿ 557,000 ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ವಿತರಿಸಿದೆ (shipped). ಆ ಪ್ರಮಾಣವು ನಾನು ಪ್ರಯತ್ನಿಸಿದ ಪ್ರತಿಯೊಂದು ಯೋಜನಾ ವಿಧಾನವನ್ನೂ ವಿಫಲಗೊಳಿಸಿತು.

ನನ್ನ ವ್ಯವಸ್ಥೆಯು ಈ ರೀತಿ ವಿಕಸನಗೊಂಡಿತು:

ಹಂತ 1: ಸಂಭಾಷಣಾತ್ಮಕ ಯೋಜನೆ (Conversational Planning) ಯೋಜನೆಯು ಚಾಟ್ ಇತಿಹಾಸದಲ್ಲಿ ಇರುತ್ತಿತ್ತು. ನಾನು ಜೋರಾಗಿ ಯೋಚಿಸುತ್ತಿದ್ದೆ, ಒಂದು ಉತ್ತಮ ಕಲ್ಪನೆಯನ್ನು ಪಡೆಯುತ್ತಿದ್ದೆ ಮತ್ತು ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೆ.

• ಸಮಸ್ಯೆ: ಚಾಟ್ ಮುಗಿದ ತಕ್ಷಣ ಯೋಜನೆಗಳು ಮಾಯವಾಗುತ್ತಿದ್ದವು. ಅವುಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಲು ಅಥವಾ ಬೇರೆಯವರಿಗೆ ಹಸ್ತಾಂತರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತಿರಲಿಲ್ಲ.

ಹಂತ 2: ಪ್ರತಿ-ರೆಪೊ (Per-Repo) TODO ಫೈಲ್‌ಗಳು ನಾನು ಪ್ರತಿ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ TODO.md ಫೈಲ್‌ಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ನಾನು ಸರಳವಾದ ಚೆಕ್‌ಲಿಸ್ಟ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ. ಬದಲಾಗಿ, ನಾನು ಸಣ್ಣ ವಿವರಣೆಗಳನ್ನು (specs) ಬರೆಯುತ್ತಿದ್ದೆ. ಪ್ರತಿ ಅಂಶವು ಇವುಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು:

• ಸ್ಥಿತಿ (Status) ಮತ್ತು ದಿನಾಂಕ.
• ಒಂದು ಟ್ರಿಗ್ಗರ್ (ಇದು ಏಕೆ ತುರ್ತು ಎಂಬ ಕಾರಣ).
• ಮೊದಲೇ ನಿರ್ಧರಿಸಿದ ಹಂತಗಳು (ಯೋಜನೆ).
• ತಿಳಿದಿರುವ ಅಪಾಯಗಳು.
• ಸಮಸ್ಯೆ: 100 ರೆಪೊಸಿಟರಿಗಳಿದ್ದಾಗ, ನನಗೆ ಒಟ್ಟಾರೆ ನೋಟ (global view) ಸಿಗುತ್ತಿರಲಿಲ್ಲ. ನಾನು ಮಾಡಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಕಡೆ ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತಿರಲಿಲ್ಲ.

ಹಂತ 3: ಆಪರೇಟರ್ ಬ್ಯಾಕ್‌ಲಾಗ್ (OB) ನಾನು ಕಾರ್ಯಗಳನ್ನು Postgres ಡೇಟಾಬೇಸ್‌ಗೆ ವರ್ಗಾಯಿಸಿದೆ. ಇದು ಒಂದು ಜಾಗತಿಕ ಕ್ಯೂ (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 ರ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಕಲಿಯಿರಿ. ನಿಮ್ಮ ಕಾರ್ಯಗಳನ್ನು ಸ್ಥಿತಿ, ಟ್ರಿಗ್ಗರ್, ಮೊದಲೇ ನಿರ್ಧರಿಸಿದ ಹಂತಗಳು ಮತ್ತು ಅಪಾಯಗಳೊಂದಿಗೆ ಬರೆಯಿರಿ. ಇದಕ್ಕೆ ಯಾವುದೇ ವೆಚ್ಚವಿಲ್ಲ ಮತ್ತು ಇದು ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸುತ್ತದೆ.

ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ ನಿಯಮವೆಂದರೆ ಇದು: ಯಾವಾಗಲೂ ಸತ್ಯದ ಆಧಾರದ ಮೇಲೆ ಯೋಜಿಸಿ. ಎಂದಿಗೂ ಕೇವಲ ಊಹ ಅಥವಾ ಸಾರಾಂಶದ ಆಧಾರದ ಮೇಲೆ ಯೋಜಿಸಬೇಡಿ. ಹಳೆಯ ಅಥವಾ ಅಪ್ರಸ್ತುತ ದತ್ತಾಂಶದ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಪರಿಪೂರ್ಣ ಯೋಜನೆಯು, ಯಾವುದೇ ಯೋಜನೆಯಿಲ್ಲದಷ್ಟೇ ವೇಗವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಮೂಲ: https://dev.to/niclydon/the-drift-from-chat-to-backlog-how-my-ai-task-planning-evolved-over-three-months-2akg

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi