ਟੈਸਟ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
AI-ਅਧਾਰਿਤ ਕੋਡ ਅਸਿਸਟੈਂਟ ਅਕਸਰ ਟੀਮਾਂ ਨੂੰ ਰੈਪੋ (repo) ਵਿੱਚ ਇੱਕ "ਨਿਯਮਾਂ" (rules) ਵਾਲੀ ਫਾਈਲ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਅਤੇ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਮਾਡਲ ਹਰ ਰਿਕਵੈਸਟ 'ਤੇ ਇਸਦੇ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਪਾਲਣਾ ਕਰੇਗਾ। ਅਸਲ ਵਿੱਚ, ਮਾਡਲ ਸ਼ਾਇਦ ਕਦੇ ਵੀ ਉਸ ਫਾਈਲ ਨੂੰ ਦੇਖੇ ਹੀ ਨਾ, ਜਾਂ ਉਹ ਇਸਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ ਪਰ ਇਸਦੀ ਸਮੱਗਰੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦਾ ਹੈ। Claude Code ਦੇ ਇੱਕ ਤਾਜ਼ਾ ਪ੍ਰਯੋਗ ਨੇ ਦੋਵੇਂ ਸਮੱਸਿਆਵਾਂ ਦਿਖਾਈਆਂ। ਟੂਲ ਨੇ ਚੁੱਪਚਾਪ 72 KB ਦੀ AGENTS.md ਫਾਈਲ ਨੂੰ ਛੱਡ ਦਿੱਤਾ; ਜਦੋਂ ਉਸੇ ਫਾਈਲ ਦਾ ਨਾਮ ਬਦਲ ਕੇ CLAUDE.md ਕਰ ਦਿੱਤਾ ਗਿਆ, ਤਾਂ ਅਸਿਸਟੈਂਟ ਨੇ ਇਸਨੂੰ ਲੋਡ ਕਰ ਲਿਆ ਅਤੇ ਹਰ ਰਿਕਵੈਸਟ ਲਈ ਟੋਕਨ ਕਾਊਂਟ ਵਧਾ ਦਿੱਤਾ। ਉਹ ਵਾਧੂ ਟੋਕਨ ਬਜਟ ਲੇਟੈਂਸੀ (latency) ਅਤੇ ਲਾਗਤ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਰਿਕਵੈਸਟ ਨੂੰ ਮਾਡਲ ਦੀ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਧੱਕ ਸਕਦਾ ਹੈ।
ਉਹ ਡਿਵੈਲਪਰ ਜੋ ਇਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ "ਫਾਈਲ ਦਾ ਹੋਣਾ" ਬਰਾਬਰ ਹੈ "ਮਾਡਲ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ", ਉਹ ਲੁਕੀਆਂ ਹੋਈਆਂ ਅਕੁਸ਼ਲਤਾਵਾਂ ਅਤੇ ਅਨਿਸ਼ਚਿਤ ਆਉਟਪੁੱਟ ਦਾ ਖ਼ਤਰਾ ਲੈਂਦੇ ਹਨ। ਤਿੰਨ-ਪੜਾਵੀ ਟੈਸਟ ਹਰੇਕ ਪੜਾਅ 'ਤੇ ਸਬੂਤ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ: ਕੌਂਫਿਗਰੇਸ਼ਨ, ਲੋਡਿੰਗ, ਅਤੇ ਉਪਯੋਗਤਾ।
ਪੁੱਛਣ ਲਈ ਤਿੰਨ ਸਵਾਲ
- ਕੌਂਫਿਗਰਡ (Configured) – ਕੀ ਫਾਈਲ ਉੱਥੇ ਰੱਖੀ ਗਈ ਹੈ ਜਿੱਥੇ ਅਸਿਸਟੈਂਟ ਇਸਨੂੰ ਲੱਭਦਾ ਹੈ? ਵੱਖ-ਵੱਖ ਟੂਲ ਪਾਥ (paths) ਜਾਂ ਫਾਈਲਨਾਮ ਦੇ ਰਵਾਇਤੀ ਤਰੀਕਿਆਂ ਨੂੰ ਹਾਰਡ-ਕੋਡ ਕਰਦੇ ਹਨ; ਮੇਲ ਨਾ ਖਾਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫਾਈਲ ਕਦੇ ਵੀ ਪ੍ਰੋਂਪਟ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਨਹੀਂ ਆਵੇਗੀ।
- ਲੋਡਡ (Loaded) – ਕੀ ਅਸਿਸਟੈਂਟ ਕੋਈ ਸਬੂਤ ਦਿੰਦਾ ਹੈ ਕਿ ਉਸਨੇ ਫਾਈਲ ਪ੍ਰਾਪਤ ਕੀਤੀ ਹੈ? ਇੱਕ ਹੈਸ਼ (hash) ਡਿਸਕ 'ਤੇ ਫਾਈਲ ਦੀ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਇੱਕ ਡਿਲੀਵਰੀ ਟ੍ਰੇਸ (ਜਿਵੇਂ ਕਿ ਇੱਕ ਲੌਗ ਲਾਈਨ ਜਾਂ ਟੋਕਨ ਕਾਊਂਟ) ਹੀ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਮਾਡਲ ਨੇ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਦੇਖਿਆ ਹੈ।
- ਉਪਯੋਗੀ (Useful) – ਕੀ ਫਾਈਲ ਦੀ ਮੌਜੂਦਗੀ ਕੰਮ ਦੇ ਨਤੀਜੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦੀ ਹੈ? ਇੱਕ ਲੋਡ ਕੀਤੀ ਫਾਈਲ ਜੋ ਟੋਕਨ ਵਧਾਉਂਦੀ ਹੈ ਪਰ ਨਤੀਜੇ ਨੂੰ ਬਦਲਦੀ ਨਹੀਂ ਹੈ, ਉਹ ਇੱਕ ਨੁਕਸਾਨ ਹੈ।
ਟੈਸਟ ਚਲਾਉਣਾ
ਪ੍ਰਕਿਰਿਆ ਜਾਣਬੁੱਝ ਕੇ ਬਹੁਤ ਸਰਲ ਰੱਖੀ ਗਈ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਪਲੇਟਫਾਰਮ 'ਤੇ ਦੁਹਰਾਇਆ ਜਾ ਸਕੇ।
ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਬਣਾਓ – ਇੱਕ ਸਧਾਰਨ, ਦੇਖਣਯੋਗ ਨਿਰਦੇਸ਼ ਲਿਖੋ। ਉਦਾਹਰਨ ਲਈ: “ਐਡਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਿਲਕੁਲ ਦੋ ਫਾਈਲਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ।” ਨਿਯਮ ਦੇ ਪ੍ਰਭਾਵ ਦੀ ਜਾਂਚ ਅਸਿਸਟੈਂਟ ਦੇ ਜਵਾਬ ਵਿੱਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਟੂਲ ਦਾ ਵਰਜ਼ਨ ਅਤੇ ਮਾਡਲ ਚੈੱਕ ਕਰੋ – ਇੱਕ ਨਵਾਂ ਸੈਸ਼ਨ ਖੋਲ੍ਹੋ, ਵਰਜ਼ਨ ਸਟ੍ਰਿੰਗ ਅਤੇ ਮਾਡਲ ਆਈਡੈਂਟੀਫਾਇਰ ਨੂੰ ਨੋਟ ਕਰੋ। ਵੱਖ-ਵੱਖ ਵਰਜ਼ਨ ਉਹ ਫਾਈਲਨਾਮ ਬਦਲ ਸਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਪਛਾਣਦੇ ਹਨ।
ਦੋ ਰਨ (runs) ਚਲਾਓ ਰਨ A: ਇੱਕ ਅਜਿਹਾ ਫਾਈਲਨਾਮ ਵਰਤੋ ਜਿਸਨੂੰ ਟੂਲ ਨਹੀਂ ਪਛਾਣਦਾ (ਜਿਵੇਂ ਕਿ AGENTS.md)। ਰਨ B: ਟੂਲ ਦਾ ਕੁਦਰਤੀ (native) ਫਾਈਲਨਾਮ ਵਰਤੋ (ਜਿਵੇਂ ਕਿ CLAUDE.md)।
ਇਹਨਾਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ:
- ਫਾਈਲ ਦਾ ਸੋਰਸ ਹੈਸ਼ (ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕਿ ਡਿਸਕ 'ਤੇ ਸਮੱਗਰੀ ਨਹੀਂ ਬਦਲੀ)।
- ਵਰਤਿਆ ਗਿਆ ਸਹੀ ਪਾਥ (path)।
- ਫਾਈਲ ਲੋਡ ਕਰਨ ਬਾਰੇ ਅਸਿਸਟੈਂਟ ਦੁਆਰਾ ਲੌਗ ਕੀਤਾ ਗਿਆ ਕੋਈ ਵੀ ਸਬੂਤ (ਟੋਕਨ ਕਾਊਂਟ ਵਿੱਚ ਵਾਧਾ, ਸਪੱਸ਼ਟ “loaded X.md” ਸੁਨੇਹਾ, ਆਦਿ)।
- ਹਰ ਰਿਕਵੈਸਟ ਲਈ ਟੋਕਨ ਕਾਊਂਟ।
- ਕੰਮ ਦਾ ਨਤੀਜਾ (ਕੀ ਅਸਿਸਟੈਂਟ ਨੇ ਬਿਲਕੁਲ ਦੋ ਫਾਈਲਾਂ ਦੀ ਸੂਚੀ ਬਣਾਈ?)।
ਜੇਕਰ ਰਨ B ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ ਅਤੇ ਟੋਕਨ ਕਾਊਂਟ ਉਮੀਦ ਮੁਤਾਬਕ ਵਧਦਾ ਹੈ, ਤਾਂ ਫਾਈਲ ਲੋਡ ਵੀ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਉਪਯੋਗੀ ਵੀ ਹੈ। ਜੇਕਰ ਟੋਕਨ ਵਾਧੇ ਦੇ ਬਾਵਜੂਦ ਨਿਯਮ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਫਾਈਲ ਪੜ੍ਹੀ ਤਾਂ ਜਾ ਰਹੀ ਹੈ ਪਰ ਮਾਡਲ ਦਾ ਪ੍ਰੋਂਪਟ ਪਾਰਸਿੰਗ ਨਿਰਦੇਸ਼ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਅਜਿਹੇ ਮਾਮਲੇ ਵਿੱਚ, ਫਾਈਲ ਵਿੱਚ ਹੋਰ ਟੈਕਸਟ ਜੋੜਨਾ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ; ਇਸ ਦੀ ਬਜਾਏ ਨਿਯਮ ਨੂੰ ਕਿਸੇ ਹਾਰਡ-ਕੋਡਡ ਪਾਲਿਸੀ ਗੇਟ ਜਾਂ ਟੈਸਟ ਹਾਰਨੈਸ (test harness) ਵਿੱਚ ਬਦਲ ਦਿਓ।
ਡੇਟਾ ਕੀ ਦੱਸਦਾ ਹੈ
Claude Code ਦੇ ਮਾਮਲੇ ਨੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਅਤੇ ਲੋਡਿੰਗ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਵੱਡਾ ਅੰਤਰ ਦਿਖਾਇਆ। 72 KB ਦੀ ਫਾਈਲ ਮੌਜੂਦ ਸੀ, ਉਸਦਾ ਹੈਸ਼ ਸਹੀ ਸੀ, ਅਤੇ ਉਹ ਰੈਪੋ ਦੇ ਨਾਲ ਸਿੰਕ ਸੀ, ਫਿਰ ਵੀ ਅਸਿਸਟੈਂਟ ਨੇ ਕਦੇ ਵੀ ਇਸਦਾ ਹਵਾਲਾ ਨਹੀਂ ਦਿੱਤਾ। ਫਾਈਲ ਨੂੰ ਕੁਦਰਤੀ CLAUDE.md ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਲੋਡਿੰਗ ਸ਼ੁਰੂ ਹੋ ਗਈ, ਪਰ ਇਸ ਨਾਲ ਇੱਕ ਵੱਡਾ ਟੋਕਨ ਓਵਰਹੈੱਡ ਵੀ ਵਧ ਗਿਆ। ਹਰ ਵਾਧੂ ਟੋਕਨ ਕੰਪਿਊਟ ਸਾਈਕਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਰਿਕਵੈਸਟ ਨੂੰ ਰੇਟ ਲਿਮਿਟਸ (rate limits) ਤੋਂ ਬਾਹਰ ਧੱਕ ਸਕਦਾ ਹੈ।
ਤਿੰਨ-ਪੜਾਵੀ ਟੈਸਟ ਅਜਿਹੇ ਲੁਕੇ ਹੋਏ ਖਰਚਿਆਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਬਲਾਕਰ (production blockers) ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ। ਟੋਕਨ ਡੈਲਟਾ (token delta) ਨੂੰ ਕੈਪਚਰ ਕਰਕੇ, ਟੀਮਾਂ ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿ ਕੀ ਨਿਯਮ ਦਾ ਲਾਭ ਉਸਦੀ ਕੀਮਤ ਤੋਂ ਵੱਧ ਹੈ।
ਸਿੱਖਿਆ (Takeaway)
ਕਦੇ ਵੀ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਕੋਈ ਨਿਯਮ ਫਾਈਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿਉਂਕਿ ਇਹ ਰੈਪੋ ਵਿੱਚ ਹੈ। ਉਸ ਅਨੁਮਾਨ ਨੂੰ ਮਾਪਣਯੋਗ ਸਬੂਤ ਵਿੱਚ ਬਦਲਣ ਲਈ ਤਿੰਨ-ਪੜਾਵੀ ਟੈਸਟ—ਕੌਂਫਿਗਰ, ਲੋਡ, ਉਪਯੋਗਤਾ ਸਾਬਤ ਕਰੋ—ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜਦੋਂ ਸਬੂਤ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਫਾਈਲ ਸਿਰਫ਼ ਇੱਕ ਟ