ਚੈਟ ਤੋਂ ਬੈਕਲੌਗ ਤੱਕ ਦਾ ਬਦਲਾਅ
ਤਿੰਨ ਮਹੀਨੇ ਪਹਿਲਾਂ, ਮੇਰਾ ਟਾਸਕ ਮੈਨੇਜਮੈਂਟ ਸਿਰਫ਼ ਇੱਕ ਚੈਟ ਵਿੰਡੋ ਸੀ। ਜੇਕਰ ਮੈਂ ਟੈਬ ਬੰਦ ਕਰ ਦਿੰਦਾ, ਤਾਂ ਯੋਜਨਾ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਸੀ।
ਅੱਜ, ਇਹ ਇੱਕ Postgres backlog ਹੈ। ਤਿੰਨ ਵੱਖ-ਵੱਖ AI agents—Claude Code, Codex, ਅਤੇ Grok—ਇਸ ਵਿੱਚੋਂ ਕੰਮ ਲੈਂਦੇ ਹਨ। ਉਹ ਇਸ 'ਤੇ attribution ਲਗਾਉਂਦੇ ਹਨ ਅਤੇ git history ਦੇ ਆਧਾਰ 'ਤੇ ਇਸਨੂੰ ਕਲੋਜ਼ (close) ਕਰਦੇ ਹਨ।
ਮੈਂ ਕੋਈ ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਮੈਂਟ ਸਿਸਟਮ ਬਣਾਉਣ ਦੇ ਇਰਾਦੇ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ ਸੀ। ਮੈਂ ਬਸ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਰਿਹਾ। ਹਰ ਵਾਰ ਜਦੋਂ ਮੈਂ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਸੁਲਝਾਇਆ, ਇੱਕ ਨਵੀਂ ਸਮੱਸਿਆ ਸਾਹਮਣੇ ਆ ਗਈ।
ਮੇਰਾ ਕੰਮ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ। ਮੈਂ Nexus ਨਾਮ ਦਾ ਇੱਕ ਪਰਸਨਲ ਡਾਟਾ ਪਲੇਟਫਾਰਮ ਚਲਾਉਂਦਾ ਹਾਂ। ਮੈਂ ਲਗਭਗ 100 repositories ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹਾਂ। ਇੱਕ ਸਮੇਂ ਦੌਰਾਨ, ਮੈਂ 35 ਦਿਨਾਂ ਵਿੱਚ 557,000 ਲਾਈਨਾਂ ਦਾ ਕੋਡ ਸ਼ਿਪ ਕੀਤਾ। ਉਸ ਮਾਤਰਾ ਨੇ ਮੇਰੇ ਦੁਆਰਾ ਅਜ਼ਮਾਇਆ ਗਿਆ ਹਰ ਪਲੈਨਿੰਗ ਤਰੀਕਾ ਤਬਾਹ ਕਰ ਦਿੱਤਾ।
ਮੇਰਾ ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਵਿਕਸਿਤ ਹੋਇਆ:
Phase 1: Conversational Planning ਯੋਜਨਾ ਚੈਟ ਹਿਸਟਰੀ ਵਿੱਚ ਹੁੰਦੀ ਸੀ। ਮੈਂ ਉੱਚੀ-ਉੱਚੀ ਸੋਚਦਾ ਸੀ, ਇੱਕ ਵਧੀਆ ਵਿਚਾਰ ਮਿਲਦਾ ਸੀ, ਅਤੇ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਸੀ।
- ਸਮੱਸਿਆ: ਜਦੋਂ ਚੈਟ ਖਤਮ ਹੁੰਦੀ ਸੀ, ਯੋਜਨਾਵਾਂ ਗਾਇਬ ਹੋ ਜਾਂਦੀਆਂ ਸਨ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲ ਨਹੀਂ ਦੇ ਸਕਦੇ ਸੀ ਜਾਂ ਕਿਸੇ ਹੋਰ ਨੂੰ ਨਹੀਂ ਸੌਂਪ ਸਕਦੇ ਸੀ।
Phase 2: Per-Repo TODO Files ਮੈਂ ਹਰ repository ਵਿੱਚ TODO.md ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ। ਮੈਂ ਸਧਾਰਨ ਚੈੱਕਲਿਸਟਾਂ ਦੀ ਵਰਤੋਂ ਬੰਦ ਕਰ ਦਿੱਤੀ। ਇਸ ਦੀ ਬਜਾਏ, ਮੈਂ ਛੋਟੀਆਂ ਸਪੈਸੀਫਿਕੇਸ਼ਨਾਂ (specs) ਲਿਖੀਆਂ। ਹਰੇਕ ਆਈਟਮ ਵਿੱਚ ਸ਼ਾਮਲ ਸੀ:
- ਸਟੇਟਸ ਅਤੇ ਮਿਤੀ।
- ਇੱਕ ਟ੍ਰਿਗਰ (ਇਹ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੋ ਗਿਆ)।
- ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕੀਤੇ ਗਏ ਕਦਮ (ਯੋਜਨਾ)।
- ਜਾਣੇ-ਪਛਾਣੇ ਜੋਖਮ।
- ਸਮੱਸਿਆ: 100 repos ਦੇ ਨਾਲ, ਮੇਰੇ ਕੋਲ ਕੋਈ ਗਲੋਬਲ ਵਿਊ (global view) ਨਹੀਂ ਸੀ। ਮੈਂ ਇੱਕੋ ਜਗ੍ਹਾ 'ਤੇ ਉਹ ਸਭ ਕੁਝ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਸੀ ਜੋ ਮੈਨੂੰ ਕਰਨ ਦੀ ਲੋੜ ਸੀ।
Phase 3: The Operator Backlog (OB) ਮੈਂ ਟਾਸਕਾਂ ਨੂੰ Postgres ਡਾਟਾਬੇਸ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਇਸ ਨਾਲ ਇੱਕ ਗਲੋਬਲ ਕਿਊ (queue) ਬਣ ਗਈ। ਮੈਂ ਇੱਕ ਅਪਰੂਵਲ ਗੇਟ (approval gate) ਜੋੜਿਆ। ਮੇਰੇ ਰਿਵਿਊ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਕੋਈ ਟਾਸਕ ਅਸਲੀ ਬਣਦਾ ਹੈ। ਇਹ AI ਨੂੰ ਬੈਕਲੌਗ ਵਿੱਚ ਫਾਲਤੂ ਕੰਮ (garbage) ਭਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਮੈਂ ਸਟੇਟਸ ਲੇਨਾਂ (status lanes) ਦੀ ਵਰਤੋਂ ਕੀਤੀ:
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- ਸਮੱਸਿਆ: ਮੈਂ ਰੁਕਾਵਟ (bottleneck) ਬਣ ਗਿਆ। ਮੈਂ ਲੇਨਾਂ ਨੂੰ ਕਾਫ਼ੀ ਤੇਜ਼ੀ ਨਾਲ ਖਾਲੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ।
Phase 4: Multi-Agent Execution ਬੈਕਲੌਗ ਹੁਣ ਕਈ AI agents ਲਈ ਇੱਕ ਸਾਂਝੀ ਕਿਊ (queue) ਹੈ।
- ਉਹ leases ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਉਹ ਇੱਕੋ ਟਾਸਕ 'ਤੇ ਕੰਮ ਨਾ ਕਰਨ।
- ਉਹ attribution ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਮੈਨੂੰ ਪਤਾ ਲੱਗ ਸਕੇ ਕਿ ਕਿਸਨੇ ਕੀ ਕੀਤਾ।
- ਉਹ ਕੰਮ ਇੱਕ ਦੂਜੇ ਨੂੰ ਸੌਂਪ ਸਕਦੇ ਹਨ। ਇੱਕ agent ਨੂੰ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਕੋਈ ਟਾਸਕ ਅਸੰਭਵ ਹੈ ਅਤੇ ਉਹ ਇੱਕ prerequisite ਫਾਈਲ ਕਰ ਸਕਦਾ ਹੈ। ਫਿਰ ਦੂਜਾ agent ਉਸ prerequisite ਨੂੰ ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ ਅਸਲ ਟਾਸਕ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ।
ਸਬਕ ਸਧਾਰਨ ਹੈ: ਸਫਲ ਹੋਣ ਲਈ ਤੁਹਾਨੂੰ Phase 4 ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਚੀਜ਼ ਸਿੱਖਣੀ ਹੈ, ਤਾਂ Phase 2 ਦਾ ਫਾਰਮੈਟ ਅਪਣਾਓ। ਆਪਣੇ ਟਾਸਕਾਂ ਨੂੰ ਸਟੇਟਸ, ਟ੍ਰਿਗਰ, ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕੀਤੇ ਗਏ ਕਦਮਾਂ ਅਤੇ ਜੋਖਮਾਂ ਦੇ ਨਾਲ ਲਿਖੋ। ਇਸ ਵਿੱਚ ਕੁਝ ਖਰਚ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਿਯਮ ਇਹ ਹੈ: ਹਮੇਸ਼ਾ ਸੱਚਾਈ ਦੇ ਅਧਾਰ 'ਤੇ ਯੋਜਨਾ ਬਣਾਓ। ਕਦੇ ਵੀ ਕਿਸੇ ਅੰਦਾਜ਼ੇ ਜਾਂ ਸਾਰ ਦੇ ਅਧਾਰ 'ਤੇ ਯੋਜਨਾ ਨਾ ਬਣਾਓ। ਪੁਰਾਣੇ ਡੇਟਾ 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਸੰਪੂਰਨ ਯੋਜਨਾ ਵੀ ਉਨੀ ਹੀ ਤੇਜ਼ੀ ਨਾਲ ਅਸਫਲ ਹੋਵੇਗੀ ਜਿੰਨੀ ਕਿ ਬਿਨਾਂ ਕਿਸੇ ਯੋਜਨਾ ਦੇ।
ਵਿਕਲਪਿਕ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi