23 ਸਤੰ 2025·8 ਮਿੰਟ
AI-ਜਨਰੇਟਡ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ, ਕਾਰਗਰਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ
AI-ਜਨਰੇਟਡ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ, ਕਾਰਗਰਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਪ੍ਰਯੋਗਿਕ ਮਾਰਗਦਰਸ਼ਨ—ਰੀਵਿਊ, ਟੈਸਟ ਅਤੇ ਮਾਨੀਟਰਨਿੰਗ ਲਈ ਸਪਸ਼ਟ ਚੈੱਕਲਿਸਟਾਂ ਸਮੇਤ।
AI-ਜਨਰੇਟਡ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ, ਕਾਰਗਰਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਪ੍ਰਯੋਗਿਕ ਮਾਰਗਦਰਸ਼ਨ—ਰੀਵਿਊ, ਟੈਸਟ ਅਤੇ ਮਾਨੀਟਰਨਿੰਗ ਲਈ ਸਪਸ਼ਟ ਚੈੱਕਲਿਸਟਾਂ ਸਮੇਤ।
“AI-ਜਨਰੇਟਡ ਕੋਡ” ਦਾ ਮਤਲਬ ਤੁਹਾਡੇ ਟੀਮ ਅਤੇ ਟੂਲਿੰਗ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ। ਕਿਸੇ ਲਈ ਇਹ ਮੌਜੂਦਾ ਮੋਡੀਊਲ ਵਿੱਚ ਕੁਝ ਆਟੋਕੰਪਲੀਟ ਲਾਈਨਾਂ ਹਨ। ਕਿਸੇ ਲਈ ਇਹ ਪੂਰੇ ਐਂਡਪਆਇੰਟ, ਡਾਟਾ ਮਾਡਲ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਟੈਸਟ ਸਟਬ ਜਾਂ ਇੱਕ ਵੱਡਾ ਰੀਫੈਕਟਰ ਇੱਕ ਪ੍ਰਾਂਪਟ ਤੋਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਗੁਣਵੱਤਾ ਦਾ ਮੂਲਿਆੰਕਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਤੁਹਾਡੇ ਰੇਪੋ ਵਿੱਚ ਕਿੰਨੇ ਤੱਥ AI-ਜਨਰੇਟਡ ਮੰਨੇ ਜਾਣਗੇ: ਸਨਿੱਪੇਟ, ਪੂਰੇ ਫੰਕਸ਼ਨ, ਨਵੀਂ ਸਰਵਿਸ, ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਕੋਡ, ਜਾਂ “AI-ਸਹਾਇਤ” ਰੀਰਾਈਟ।
ਮੁੱਖ ਉਮੀਦ: AI ਆਉਟਪੁੱਟ ਇੱਕ ਡ੍ਰਾਫਟ ਹੈ, ਗਾਰੰਟੀ ਨਹੀਂ। ਇਹ ਮਨਮੋਹਕ ਤਰੀਕੇ ਨਾਲ ਪੜਨਯੋਗ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਐਜ ਕੇਸਾਂ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ, ਕਿਸੇ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਗਲਤ ਵਰਤ ਸਕਦਾ ਹੈ, authentication ਚੈਕ ਛੱਡ ਸਕਦਾ ਹੈ, ਜਾਂ ਸੁੱਕੜੇ ਪਰਫਾਰਮੈਂਸ ਬੋਤਲਨੇਕ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਤੇਜ਼ ਜੂਨੀਅਰ ਟੀਮ ਮੈਂਬਰ ਦੇ ਕੋਡ ਵਾਂਗ ਸਮਝੋ: ਮਦਦਗਾਰ ਤੇਜ਼ੀ, ਪਰ ਇਸਨੂੰ ਰਿਵਿਊ, ਟੈਸਟ ਅਤੇ ਸਪਸ਼ਟ ਐਕਸੈਪਟੈਂਸ ਕ੍ਰਾਈਟੀਰੀਆ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਜੇ ਤੁਸੀਂ “vibe-coding” ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ ਚੈਟ ਪ੍ਰਾਂਪਟ ਤੋਂ ਪੂਰਾ ਫੀਚਰ ਜਨਰੇਟ ਕਰਨਾ ਜਿਵੇਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਵਿੱਚ—ਫਰੰਟਐਂਡ React, ਬੈਕਐਂਡ Go ਨਾਲ PostgreSQL, ਜਾਂ ਇੱਕ Flutter ਮੋਬਾਈਲ ਐਪ), ਤਾਂ ਇਹ ਮਨੋਭਾਵ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਣ ਬਣ ਜਾਂਦਾ ਹੈ। ਜਿੰਨੀ ਵੱਧ ਜਨਰੇਟ ਕੀਤੀ ਸਤਹ ਹੁੰਦੀ ਹੈ, ਓਨਾ ਜ਼ਿਆਦਾ ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ “ਡਨ” ਦਾ ਮਤਲਬ "ਇਹ ਕੰਪਾਇਲ ਹੋ ਜਾਂਦਾ ਹੈ" ਤੋਂ ਅੱਗੇ ਕੀ ਹੈ, ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਵੇ।
ਸੁਰੱਖਿਆ, ਕਾਰਗਰਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਜਨਰੇਟਡ ਕੋਡ ਵਿੱਚ ਆਪਣੀ-ਆਪ ਹੀ ਨਹੀਂ ਆਉਂਦੀਆਂ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰੋਗੇ ਅਤੇ ਜਾਂਚ ਨਹੀਂ ਕਰੋਗੇ। AI ਆਮ ਤੌਰ 'ਤੇ ਪਲੇਜ਼ੀਬਿਲਟੀ ਅਤੇ ਆਮ ਪੈਟਰਨਾਂ ਲਈ optimize ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਥ੍ਰੇਟ ਮਾਡਲ, ਟ੍ਰੈਫਿਕ ਆਕਾਰ, ਫੇਲਿਯਰ ਮੋਡ ਜਾਂ ਕੰਪਲਾਇਅੰਸ ਲੋੜਾਂ ਲਈ। ਬਿਨਾਂ ਸਪਸ਼ਟ ਕ੍ਰাইটੇਰੀਆ ਦੇ, ਟੀਮਾਂ ਅਕਸਰ ਉਹ ਕੋਡ ਮਰਜ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਖੁਸ਼-ਮਾਰਗ ਡੈਮੋ 'ਚ ਚੱਲਦਾ ਹੈ ਪਰ ਅਸਲ ਲੋਡ ਜਾਂ ਵਿਰੋਧੀ ਇਨਪੁੱਟ ਹੇਠਾਂ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਅਮਲ ਵਿੱਚ ਇਹ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਓਵਰਲੈਪ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, rate limiting ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦੋਹਾਂ ਨੂੰ ਬਿਹਤਰ ਕਰਦੀ ਹੈ; caching ਕਾਰਗਰਤਾ ਵਧਾਉਂਦੀ ਹੈ ਪਰ ਜੇ ਇਹ ਯੂਜ਼ਰਾਂ ਵਿਚਕਾਰ ਡੇਟਾ ਲੀਕ ਕਰੇ ਤਾਂ ਸੁਰੱਖਿਆ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੈ; ਸਖਤ timeouts ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ ਪਰ ਨਵੇਂ error-handling ਰਾਹ ਖੋਲ ਸਕਦੇ ਹਨ ਜਿਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ ਜੋੜਨਾ ਪਏਗਾ।
ਇਹ ਸੈਕਸ਼ਨ ਮੂਲ ਮਨੋਭਾਵ ਸੈੱਟ ਕਰਦਾ ਹੈ: AI ਕੋਡ ਲਿਖਣ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਪਰ “ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ” ਉਹ ਗੁਣਵੱਤਾ ਮਾਪਦੰਡ ਹੈ ਜੋ ਤੁਸੀਂ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਲਗਾਤਾਰ ਜਾਂਚ ਕਰਦੇ ਹੋ।
AI-ਜਨਰੇਟਡ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਸੁਤੰਤਰ ਅਤੇ ਆਤਮਵਿਸ਼ਵਾਸੀ ਲਗਦਾ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਵੱਧ ਮੁਸ਼ਕਲੀਆਂ ਸਟਾਇਲ ਦੀਆਂ ਨਹੀਂ—ਉਹ ਫੈਸਲੇ ਦੀਆਂ ਖਾਮੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਮਾਡਲਸ ਪਲੇਜ਼ੀਬਲ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਉਤਪੱਨ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਕੰਪਾਇਲ ਵੀ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਬੇਸਿਕ ਟੈਸਟ ਵੀ ਪਾਸ ਕਰ ਲੈਂਦੇ ਹਨ, ਪਰ ਨਰਮੀ ਨਾਲ ਉਹ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੀ ਸੰਦਰਭ ਜਾਣਕਾਰੀ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਕੁਝ ਵਰਗ ਮੁੜ-ਮੁੜ ਸਮੀਖਿਆ ਦੇ ਦੌਰਾਨ ਆਉਂਦੇ ਹਨ:
catch ਬਲਾਕ ਜਿਹੜੇ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਛੁਪਾ ਦਿੰਦੇ ਹਨ।ਜਨਰੇਟਡ ਕੋਡ ਛੁਪੇ ਹੋਏ ਧਾਰਣਾਵਾਂ ਰੱਖ ਸਕਦਾ ਹੈ: ਸਮਾਂ ਖੇਤਰ ਹਮੇਸ਼ਾ UTC, IDs ਹਮੇਸ਼ਾ ਨੰਬਰਿਕ, ਬੇਨਤੀ ਸਦਾ ਠੀਕ-ਤਰ੍ਹਾਂ ਬਣੀ ਹੋਈ, ਨੈੱਟਵਰਕ ਕਾਲ ਸਦਾ ਤੇਜ਼—ਇਹ ਸਾਰੀਆਂ ਧਾਰਣਾਵਾਂ ਖਤਰਨਾਕ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਅਧੂਰੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ—ਕੁਝ ਸੁਰੱਖਿਆ ਚੈੱਕ ਸਟਬ ਕੀਤੇ ਹੋਏ, TODO ਪਾਥ, ਜਾਂ fallback ਬ੍ਰਾਂਚ ਜੋ ਡਾਟਾ ਵਾਪਸ ਕਰਨ ਦੀ ਬਜਾਏ ਡਿਫਾਲਟ ਡੇਟਾ ਰਿਟਰਨ ਕਰਦਾ ਹੈ।
ਆਮ ਫੇਲ੍ਹ ਮੋਡ ਇਹ ਹੈ ਕਿ ਕਿਤੇ ਹੋਰ ਸਹੀ ਪੈਟਰਨ ਨੂੰ ਇੱਥੇ ਬਿਨਾਂ ਸੰਦਰਭ ਦੇ ਗਲਤ ਢੰਗ ਨਾਲ ਲਗਾ ਲਿਆ ਜਾਵੇ: hashing ਹੇਲਪਰ ਨੂੰ ਸਹੀ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਬਿਨਾਂ ਦੁਹਰਾਉਣਾ, GENERIC sanitizer ਜੋ ਤੁਹਾਡੇ ਆਟਪੁੱਟ ਸੰਦਰਭ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਜਾਂ ਇੱਕ retry ਲੂਪ ਜੋ ਗੈਰ-ਇਰਾਦੇ ਨਾਲ ਲੋਡ (ਅਤੇ ਲਾਗਤ) ਨੂੰ ਵਧਾ ਦੇਵੇ।
ਭਾਵੇਂ ਕੋਡ ਜਨਰੇਟ ਹੋਵੇ, ਇਨਸਾਨ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਉਸ ਦੇ ਵਿਹਾਰ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਰਹਿੰਦੇ ਹਨ। AI ਆਉਟਪੁੱਟ ਨੂੰ ਇੱਕ ਡ੍ਰਾਫਟ ਸਮਝੋ: ਤੁਸੀਂ ਥ੍ਰੇਟ ਮਾਡਲ, ਐਜ ਕੇਸ ਅਤੇ ਨਤੀਜੇ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ।
AI-ਜਨਰੇਟਡ ਕੋਡ ਅਕਸਰ ਨਿਰਣਾਇਕ ਅਤੇ ਪੂਰਾ ਲਗਦਾ ਹੈ—ਇਸ ਲਈ ਆਸਾਨੀ ਨਾਲ ਮੂਲ ਸਵਾਲ ਛੱਡ ਦੇਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ: "ਅਸੀਂ ਕੀ ਦੀ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹਾਂ ਅਤੇ ਕਿਸ ਤੋਂ?" ਇੱਕ ਸਧਾਰਨ ਥ੍ਰੇਟ ਮਾਡਲ ਇੱਕ ਛੋਟਾ, ਸਾਫ਼-ਭਾਸ਼ਾ ਆਦਤ ਹੈ ਜੋ ਸੁਰੱਖਿਆ ਫੈਸਲਿਆਂ ਨੂੰ ਕੋਡ ਫਾਇਨਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਪਸ਼ਟ ਰੱਖਦੀ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਉਹਨਾਂ ਐਸੈਟਸ ਦਾ ਨਾਮ ਲੈ ਕੇ ਜੇਹਨਾਂ ਦੇ ਖ਼ਰਾਬ ਹੋਣ ਨਾਲ ਨੁਕਸਾਨ ਹੋਵੇਗਾ:
ਫਿਰ ਐਕਟਰਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ: ਆਮ ਯੂਜ਼ਰ, ਐਡਮਿੰਸ, ਸਪੋਰਟ ਸਟਾਫ, ਬਾਹਰੀ ਸਰਵਿਸਾਂ ਅਤੇ ਅਟੈਕਰ (ਕ੍ਰੈਡੈਂਸ਼ਲ ਸਟੱਫਿੰਗ, ਧੋਖਾਧੜੀ ਕਰਨ ਵਾਲੇ, ਬੋਟ)।
ਆਖਰ ਵਿੱਚ, ਟਰਸਟ ਬਾਊਂਡਰੀਜ਼ ਦਾ ਰੇਖਾ ਖਿੱਚੋ (ਜਾਂ ਵਰਣਨ ਕਰੋ): browser ↔ backend, backend ↔ database, backend ↔ third-party APIs, ਅੰਦਰੂਨੀ ਸਰਵਿਸਾਂ ↔ ਪਬਲਿਕ ਇੰਟਰਨੈਟ। ਜੇ AI "ਤੇਜ਼" ਛੇਤੀ-ਦੀ-ਰਾਹ ਕੰਮ ਨੂੰ ਇਹ ਬਾਊਂਡਰੀਜ਼ ਪਾਰ ਕਰਨ ਦੀ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਪਬਲਿਕ ਐਂਡਪਾਇੰਟ ਤੋਂ ਡਾਇਰੈਕਟ ਡੇਟਾਬੇਸ ਐਕਸੈਸ), ਤਾਂ ਤੁਰੰਤ ਝੰਡਾ ਲਾਇਆ ਜਾਵੇ।
ਇਸਨੂੰ ਅਜਿਹਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ ਜਾਵੇ:
PR ਵੇਰਣ ਵਿੱਚ ਉੱਤਰਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰੋ, ਜਾਂ ਜੇ ਚੋਣ ਲੰਬੇ ਸਮੇਂ ਲਈ ਹੈ (ਜਿਵੇਂ ਟੋਕਨ ਫਾਰਮੈਟ, webhook ਵੈਰੀਫਿਕੇਸ਼ਨ ਤਰੀਕਾ) ਤਾਂ ਇੱਕ ਛੋਟਾ ADR (Architecture Decision Record) ਬਣਾਓ। ਭਵਿੱਖ ਦੇ ਰਿਵਿਊਅਰ ਫਿਰ ਦੇਖ ਸਕਦੇ ਹਨ ਕਿ AI-ਜਨਰੇਟਡ ਬਦਲਾਅ ਅਜੇ ਵੀ ਮੂਲ ਮਨਸ਼ਾ ਨਾਲ ਮਿਲਦੇ ਹਨ ਜਾਂ ਨਹੀਂ—ਅਤੇ ਕਿਹੜੇ ਖਤਰੇ ਜ਼ਰੀਏ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ ਸਨ।
AI-ਜਨਰੇਟਡ ਕੋਡ ਸੁੰਦਰ ਅਤੇ ਸੁਨਿਰਮਿਤ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਲੁਕਾਈ ਹੋਈਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ—ਖਾਸ ਕਰਕੇ ਡਿਫਾਲਟ, ਗਲਤੀ ਹੈਂਡਲਿੰਗ ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਚਾਰਪੈਟੀਆਂ। ਸਮੀਖਿਆ ਦੌਰਾਨ, ਅੰਦਾਜ਼ੇ ਤੋਂ ਵੱਧ "ਇੱਕ ਅਟੈਕਰ ਇਸ ਨਾਲ ਕੀ ਕਰ ਸਕਦਾ ਹੈ?" ਉੱਤੇ ਧਿਆਨ ਦਿਓ।
Trust boundaries. ਜਿਥੇ ਡੇਟਾ ਸਿਸਟਮ ਵਿੱਚ ਆਉਂਦਾ ਹੈ (HTTP requests, webhooks, queues, files) ਨੂੰ ਪਛਾਣੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਵੈਧਤਾ ਬਾਊਂਡਰੀ 'ਤੇ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ "ਕਿਤੇ ਬਾਅਦ"। ਆਉਟਪੁੱਟ ਲਈ, ਜाँचੋ ਕਿ ਐਨਕੋਡਿੰਗ ਸੰਦਰਭ-ਉਪਯੁਕਤ ਹੈ (HTML, SQL, shell, logs)।
Authentication vs. authorization. AI ਕੋਡ ਅਕਸਰ isLoggedIn ਵਰਗੀਆਂ ਜਾਂਚਾਂ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ ਪਰ resource-ਨਿਰਧਾਰਕ ਨਿਯੰਤਰਣ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਹਰ ਸੰਵੇਦਨਸ਼ੀਲ ਐਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ ਕਿ ਕੌਣ ਕਿਸ ਉਪਰ ਕਰ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, userId URL ਵਿੱਚ ਮੌਜੂਦ ਹੋਣਾ ਹੀ ਪਰਮੀਸ਼ਨ ਨਹੀਂ ਦਿੰਦਾ)।
Secrets ਅਤੇ config. ਯਕੀਨੀ ਬਣਾਓ ਕਿ API keys, tokens, ਅਤੇ connection strings ਸੋਰਸ ਵਿੱਚ, ਨਮੂਨਾ configs ਵਿੱਚ, ਲੋਗਾਂ ਵਿੱਚ ਜਾਂ ਟੈਸਟਾਂ ਵਿੱਚ ਨਹੀਂ ਹਨ। ਇਹ ਵੀ ਚੈੱਕ ਕਰੋ ਕਿ "debug mode" ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਵਰਤੋਂ ਵਿੱਚ ਨਹੀਂ।
Error handling ਅਤੇ logging. ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਫੇਲਿਊਰ ਰਾਹਤਕਾਿਰ raw exceptions, stack traces, SQL errors ਜਾਂ ਅੰਦਰੂਨੀ IDs ਨੂੰ ਵਾਪਸ ਨਾ ਕਰਦੇ ਹੋਣ। ਲੌਗਸ ਸਹਾਇਕ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਪਰ ਸੀਕ੍ਰੇਟਸ, ਐਕਸੈਸ ਟੋਕਨ ਜਾਂ ਨਿੱਜੀ ਡੇਟਾ ਨੂੰ ਲੀਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।
ਖਤਰੇ ਵਾਲੇ ਰਸਤੇ ਲਈ ਇੱਕ ਨੈਗੇਟਿਵ ਟੈਸਟ ਮੰਗੋ (unauthorized access, invalid input, expired token)। ਜੇ ਕੋਡ ਨੂੰ ਇਨ੍ਹਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਇਹ ਅਕਸਰ ਇਸ ਗੱਲ ਦੀ ਨਿਸ਼ਾਨੀ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਬਾਊਂਡਰੀ ਸਪਸ਼ਟ ਨਹੀਂ ਹੈ।
AI-ਜਨਰੇਟਡ ਕੋਡ ਅਕਸਰ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਲਈ ਪੈਕੇਜ ਜੋੜ ਦਿੰਦਾ ਹੈ। ਇਹ ਚੁਪਚਾਪ ਤੌਰ 'ਤੇ ਤੁਹਾਡਾ ਐਟੈਕ ਸਰਫੇਸ ਵਧਾ ਸਕਦਾ ਹੈ: ਹੋਰ ਰੱਖੜੀਦਾਰ, ਜ਼ਿਆਦਾ ਅਪਡੇਟ ਚਾਰਚਾ, ਅਤੇ ਬਿਨਾਂ ਪ੍ਰਤੀਖਿਆ ਦੇ ਟ੍ਰਾਂਜ਼ਿਟਿਵ ਡਿਪੈਂਡੈਂਸੀਜ਼।
ਡਿਪੈਂਡੈਂਸੀ ਚੋਣਾਂ ਨੂੰ ਇਰਾਦਤਸਹਿਤ ਸ਼ੁਰੂ ਕਰੋ:
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: PR ਦੱਸਣ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਨਵੀਂ ਡਿਪੈਂਡੈਂਸੀ ਨਹੀਂ। ਜੇ AI ਕਿਸੇ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ, ਪੁੱਛੋ ਕਿ ਕੀ standard library ਕੋਡ ਜਾਂ ਮੌਜੂਦਾ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪੈਕੇਜ ਪਹਿਲਾਂ ਹੀ ਲੋੜ ਪੂਰੀ ਕਰਦਾ ਹੈ।
ਆਟੋਮੈਟਿਕ ਸਕੈਨ ਕੇਵਲ ਲਾਭਕਾਰੀ ਹਨ ਜੇ ਫਾਈਂਡਿੰਗਸ ਤੋਂ ਕਾਰਵਾਈ ਹੁੰਦੀ ਹੈ। ਜੋੜੋ:
ਫਿਰ ਹੈਂਡਲਿੰਗ ਨਿਯਮ ਤਯਾਰ ਕਰੋ: ਕਿਹੜੀ severity merges ਬਲੌਕ ਕਰਦੀ ਹੈ, ਕਿਹੜੀ time-box ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਕੌਣ exception ਅਨੁਮੋਦਨ ਕਰਦਾ ਹੈ। ਇਹ ਨਿਯਮ ਦਸਤਾਵੇਜ਼ਿਤ ਰੱਖੋ ਅਤੇ contribution guide ਤੋਂ ਲਿੰਕ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, /docs/contributing)।
ਕਈ ਘਟਨਾਵਾਂ ਟ੍ਰਾਂਜ਼ਿਟਿਵ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਅਪਰੋਕਸ਼ ਤੌਰ 'ਤੇ ਖਿੱਚੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। PRs ਵਿੱਚ lockfile diffs ਰਿਵਿਊ ਕਰੋ, ਅਤੇ ਅਣਵਰਤ ਸ਼ਾਮਲ ਪੈਕੇਜਾਂ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ prune ਕਰੋ—AI ਕੋਡ ਕਈ ਵਾਰੀ 'ਜਰੂਰਤ ਹੋ ਸਕਦੀ ਹੈ' ਦੇ ਤੌਰ 'ਤੇ ਹੇਲਪਰ ਇੰਪੋਰਟ ਕਰਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਹੀ ਨਹੀਂ ਜਾਂਦੇ।
ਲਿਖੋ ਕਿ ਅਪਡੇਟ ਕਿਵੇਂ ਹੁੰਦੇ ਹਨ (ਸ਼ੈਡਿਊਲਡ bump PRs, automated tooling, ਜਾਂ manual), ਅਤੇ ਕੌਣ ਡਿਪੈਂਡੈਂਸੀ ਬਦਲਾਅਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ। ਸਾਫ਼ ownership stale, vulnerable packages ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਲਈ ਰਹਿਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਕਾਰਗਰਤਾ "ਐਪ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ" ਨਾਲ ਸੀਮਿਤ ਨਹੀਂ। ਇਹ ਮਾਪਣਯੋਗ ਟਾਰਗੇਟਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੀ ਅਸਲ ਵਰਤੋਂ ਅਤੇ તમે ਚੱਲਾਉਣ ਦੀ ਲਾਗਤ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ। AI-ਜਨਰੇਟਡ ਕੋਡ ਅਕਸਰ ਟੈਸਟ ਪਾਸ ਕਰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸੁਤਰੰਮੀ ਲੱਗਦਾ ਹੈ, ਪਰ ਫਿਰ ਵੀ CPU ਬਰਬਾਦ ਕਰ ਸਕਦਾ ਹੈ, ਡੇਟਾਬੇਸ ਨੂੰ ਬਹੁਤ ਵਾਰ ਹਿਟ ਕਰਦਾ ਹੈ, ਜਾਂ ਬੇਕਾਰ ਮੈਮੋਰੀ allocate ਕਰਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ "ਚੰਗਾ" ਨੂੰ ਨੰਬਰਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਆਮ ਲਕੜੀਆਂ ਸ਼ਾਮਲ ਹਨ:
ਇਹ ਟਾਰਗੇਟਾਂ ਇਕ ਹਕੀਕਤਪਸੰਦ ਵਰਕਲੋਡ ਨਾਲ ਜੁੜੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (ਤੁਹਾਡਾ "happy path" ਅਤੇ ਆਮ spike), ਨਾ ਕਿ ਇੱਕ ਇਕੱਲਾ synthetic benchmark।
AI-ਜਨਰੇਟਡ ਕੋਡ ਬੇਰੁੱਖੀ ਥਾਵਾਂ 'ਤੇ ਅਕਸਰ ਅਸਰ ਦਿਖਾਂਦਾ ਹੈ:
ਜਨਰੇਟਡ ਕੋਡ ਅਕਸਰ "correct by construction" ਹੁੰਦਾ ਹੈ ਪਰ "efficient by default" ਨਹੀਂ। ਮਾਡਲ ਪਾਠਨਯੋਗ, ਜਨਰਿਕ ਤਰੀਕੇ ਠਾਹਰਾਉਂਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਦੱਸਦੇ।
ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਉਤਪਾਦ-ਨੁਕਸ਼ਾਨ ਵਾਲੇ ਮਾਹੌਲ ਦੇ ਸਮੀਪਤ ਪਰਿਬੇਸ਼ ਵਿੱਚ ਪ੍ਰੋਫਾਈਲਿੰਗ ਅਤੇ ਮਾਪ ਲਓ:
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਟਾਰਗੇਟਾਂ विरੁੱਧ ਬੀਫੋਰ/ਆਫਟਰ ਸੁਧਾਰ ਨਹੀਂ ਦਿਖਾ ਸਕਦੇ ਤਾਂ ਇਹ optimization ਨਹੀਂ, ਬਦਲਾਅ ਹੈ।
AI-ਜਨਰੇਟਡ ਕੋਡ ਅਕਸਰ "ਚੱਲਦਾ ਹੈ" ਪਰ ਧੀਮਾ ਰੇਤਾਂ ਤੇ ਖਰਚ ਕਰਦਾ ਹੈ: ਵਾਧੂ ਡੇਟਾਬੇਸ ਰਾਊਂਡ ਟ੍ਰਿਪ, ਅਣਬੱਧ N+1 queries, ਵੱਡੇ ਡੇਟਾਸੈੱਟ ਉੱਤੇ ਅਨਬੰਧ ਲੂਪ, ਜਾਂ ਰੀਟ੍ਰਾਈ ਜੋ ਕਦੇ ਰੁਕਦੇ ਨਹੀਂ। ਗਾਰਡਰੇਲ ਕਾਰਗਰਤਾ ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਉਂਦੇ ਹਨ।
ਕੈਸ਼ਿੰਗ ਧੀਮਾ ਰਸਤੇ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ ਪਰ ਇਹ ਵੀ ਸਦਾ ਆਊਟ-ਟੂ-ਡੇਟ ਡੇਟਾ ਪਰੋਵਾਈਡ ਕਰ ਸਕਦੀ ਹੈ। ਕੈਸ਼ ਸਿਰਫ਼ ਤਾਂ ਵਰਤੋ ਜਦੋਂ ਇੱਕ ਸਪਸ਼ਟ invalidation ਰਣਨੀਤੀ ਹੋਵੇ (TTL, ਘਟਨਾ-ਅਧਾਰਤ invalidation, ਜਾਂ ਵਰਜ਼ਨ ਕੀ)। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਕਿ ਕੈਸ਼ ਕੀਮਤ ਕਿਵੇਂ ਤਾਜ਼ਾਕਰਦੀ ਹੈ, ਤਾਂ ਕੈਸ਼ ਨਾ ਕਰੋ।
ਯਕੀਨੀ ਬਣਾਓ ਕਿ timeouts, retries, ਅਤੇ backoff ਇਰਾਦਤ ਨਾਲ ਸੈਟ ਕੀਤੇ ਗਏ ਹਨ (ਅਣੰਤ ਉਡੀਕ ਨਹੀਂ)। ਹਰ ਬਾਹਰੀ ਕਾਲ—HTTP, ਡੇਟਾਬੇਸ, কਿਊ, ਜਾਂ ਤੀਜੀ-ਪੱਖ APIs—ਦੇ ਲਈ:
ਇਹ "ਧੀਮੇ ਫੇਲਿਯਰ" ਨੂੰ ਰੋਕਦੇ ਹਨ ਜੋ ਲੋਡ ਹੇਠ ਰਿਸੋਰਸਾਂ ਨੂੰ ਬਲੌਕ ਕਰ ਦਿੰਦੇ ਹਨ।
async ਕੋਡ ਪaths ਵਿੱਚ blocking calls ਤੋਂ ਬਚੋ; thread ਵਰਤੋਂ ਚੈੱਕ ਕਰੋ। ਆਮ offenders ਸਿੰਕ੍ਰੋਨਸ ਫਾਇਲ ਰੀਡ, event loop 'ਤੇ CPU-ਭਾਰੀ ਕੰਮ, ਜਾਂ async ਹੈਂਡਲਰ ਵਿੱਚ blocking ਲਾਇਬ੍ਰੇਰੀਜ਼ ਦਾ ਵਰਤੋਂ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਭਾਰੀ ਹਿਸਾਬ-ਕਿਤਾਬ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸਨੂੰ offload ਕਰੋ (worker pool, background job, ਜਾਂ ਵੱਖ-ਵੱਖ ਸਰਵਿਸ)।
ਬੈਚ ਆਪਰੇਸ਼ਨ ਅਤੇ pagination ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਕੋਈ ਵੀ ਐਂਡਪੋਇੰਟ ਜੋ ਕलेकਸ਼ਨ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਉਸਨੂੰ limits ਅਤੇ cursors ਦੇ ਨਾਲ support ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ background jobs ਨੇ chunk ਵਿੱਚ ਪ੍ਰੋਸੇਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਕੋਈ query ਯੂਜ਼ਰ ਡੇਟਾ ਦੇ ਨਾਲ ਵਧ ਸਕਦੀ ਹੈ, ਤਾਂ ਮੰਨ ਲਓ ਕਿ ਇਹ ਵਧੇਗੀ।
CI ਵਿੱਚ performance tests ਜੋੜੋ ਤਾਂ ਕਿ ਰਿਗਰੇਸ਼ਨਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਫੜਿਆ ਜਾ ਸਕੇ। ਉਹਨਾਂ ਨੂੰ ਛੋਟੇ ਪਰ ਅਰਥਪੂਰਨ ਰੱਖੋ: ਕੁਝ hot endpoints, ਇੱਕ ਪ੍ਰਤਿੰਦਤ ਡੇਟਾਸੈੱਟ, ਅਤੇ thresholds (ਲੇਟੰਸੀ ਪਰਸੈਂਟਾਈਲ, ਮੈਮੋਰੀ, ਅਤੇ query ਗਿਣਤੀ)। ਫੇਲ੍ਹਾਂ ਨੂੰ ਟੈਸਟ ਫੇਲ੍ਹ ਵਾਂਗ ਹੀ ਮਨੋ—ਦੋਬਾਰਾ ਚਲਾਕਰ ਠੀਕ ਨਾ ਕਰਨਾ।
ਭਰੋਸੇਯੋਗਤਾ ਸਿਰਫ਼ "ਕ੍ਰੈਸ਼ ਨਾ ਹੋਣਾ" ਨਹੀਂ। AI-ਜਨਰੇਟਡ ਕੋਡ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਿਸਟਮ ਘਟੀਆ ਇਨਪੁੱਟ, ਅੰਤਰੰਗ ਆਊਟੇਜ, ਅਤੇ ਵਿਉਜ਼ਰ ਵਿਹਾਰ ਹੇਠ ਸਹੀ ਨਤੀਜੇ ਦੇਵੇ—ਅਤੇ ਜਦੋਂ ਨਹੀਂ ਦੇ ਸਕਦਾ ਤਾਂ ਨਿਯੰਤਰਿਤ ਢੰਗ ਨਾਲ ਫੇਲ ਹੋਵੇ।
ਹਰ ਮੁੱਖ ਰਸਤੇ ਲਈ "ਸਹੀ" ਕਿਹੜਾ ਹੈ, ਇਹ ਪਹਿਲਾਂ ਸਹਿਮਤ ਕਰੋ:
ਇਹ ਨਤੀਜੇ ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਇੱਕ ਮਾਪਦੰਡ ਦਿੰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ AI-ਲਿਖੀ ਲੋਜਿਕ ਜੋ ਕਿ ਪਲੇਜ਼ੀਬਲ ਲੱਗਦੀ ਹੈ ਪਰ ਐਜ ਕੇਸ ਲੁਕਾਉਂਦੀ ਹੈ, ਉਸ ਦੀ ਬੇਈਮਾਨੀ ਜਾਚੀ ਜਾ ਸਕੇ।
AI-ਜਨਰੇਟਡ ਹੈਂਡਲਰ ਅਕਸਰ "ਸਿਰਫ਼ ਕੰਮ ਕਰੋ" ਅਤੇ 200 ਵਾਪਸ ਕਰ ਦਿੰਦੇ ਹਨ। ਭੁਗਤਾਨ, job processing, ਅਤੇ webhook ingestion ਲਈ ਇਹ ਖਤਰनाक ਹੈ ਕਿਉਂਕਿ retries ਸਧਾਰਨ ਹਨ।
ਕੋਡ ਵਿੱਚ idempotency ਹੋਣ ਦੀ ਜਾਂਚ ਕਰੋ:
ਜੇ ਫਲੋ ਡੇਟਾਬੇਸ, ਕਿਊ, ਅਤੇ ਕੈਸ਼ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ consistency ਨੀਤੀਆਂ ਕੋਡ ਵਿੱਚ ਲਿਖੀਆਂ ਹੋਣ—ਅਨੁਮਾਨ ਤੇ ਨਹੀਂ।
ਖੋਜੋ:
ਡਿਸਟ੍ਰਿਬਿਊਟਡ ਸਿਸਟਮ ਹਿੱਸਿਆਂ ਵਿੱਚ ਨਾਕਾਮ ਹੁੰਦੇ ਹਨ। ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੋਡ ਇਨ੍ਹਾਂ ਦੇ ਕੇਸਾਂ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ ਜਿਵੇਂ "DB ਲਿਖਾਈ ਸਫਲ ਹੋਈ, ਪਰ ਇਵੈਂਟ ਪਬਲਿਸ਼ ਫੇਲ" ਜਾਂ "HTTP ਕਾਲ timeout ਹੋ ਗਿਆ ਪਰ ਰਿਮੋਟ ਸਾਈਡ ਸਫਲ ਹੋ ਗਿਆ"।
ਅਣੰਤ retries ਜਾਂ ਨਿਗਰਾਨੀ ਬਿਨਾਂ ਚੋਣਾਂ ਵਾਲੀ ਰੀਟ੍ਰਾਈ ਨੂੰ ਛੱਡ ਕੇ, timeouts, ਬਾਊਂਡਡ retries ਅਤੇ compensating actions ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜਾਣ-ਪਛਾਣ ਲਈ ਇਨ੍ਹਾਂ ਕੇਸਾਂ ਨੂੰ ਟੈਸਟ ਵਿੱਚ ਕਵਰ ਕਰਨ ਦਾ ਨੋਟ ਜੋੜੋ (covered later in /blog/testing-strategy-that-catches-ai-mistakes)।
AI-ਜਨਰੇਟਡ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ "ਪੂਰਾ" ਲੱਗਦਾ ਹੈ ਪਰ ਅਕਸਰ ਏਜ ਕੇਸ, ਇਨਪੁੱਟ ਬਾਰੇ optimistic assumptions, ਅਤੇ error path ਜੋ ਕਦੇ ਨਹੀਂ ਵਰਤੀਆਂ ਗਈਆਂ—ਇੰਨ੍ਹਾਂ ਨੂੰ ਛੁਪਾ ਲੈਂਦਾ ਹੈ। ਚੰਗੀ ਟੈਸਟ ਰਣਨੀਤੀ ਹਰ ਚੀਜ਼ ਟੈਸਟ ਕਰਨ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨ ਬਾਰੇ ਹੈ ਜੋ ਹੈਰਾਨੀਜਨਕ ਤਰੀਕੇ ਨਾਲ ਟੁੱਟ ਸਕਦੀਆਂ ਹਨ।
ਲੋਜਿਕ ਲਈ unit tests ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉਹਨਾਂ ਸਥਾਨਾਂ ਲਈ integration tests ਜੋ ਅਸਲ ਸਿਸਟਮ mocks ਤੋਂ ਵੱਖ-ਵੱਖ ਵਰਤੋਂ ਦਿਖਾਉਂਦੇ ਹਨ:
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ AI-ਲਿਖੀ glue code ਅਕਸਰ ਫੇਲ ਹੁੰਦੀ ਹੈ: ਗਲਤ SQL assumptions, ਗਲਤ retry ਵਿਵਹਾਰ, ਜਾਂ ਮਿਸ-ਮਾਡਲਡ API responses।
AI ਕੋਡ ਅਕਸਰ ਅਣ-ਵਿਰੋਧੀ ਫੇਲਿਯਰ ਹੈਂਡਲਿੰਗ ਨੂੰ ਘਟਾ ਦਿੰਦਾ ਹੈ। ਨੈਗੇਟਿਵ ਟੈਸਟ ਜੋੜੋ ਜੋ ਸਿਸਟਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪੇਸ਼ਗੀ-ਯੋਗ ਤਰੀਕੇ ਨਾਲ ਜਵਾਬ ਦੇਣ ਦੀ ਪਕੜ ਕਰਨ:
ਇਹ ਟੈਸਟ ਉਹ ਨਤੀਜੇ assert ਕਰਨ: ਸਹੀ HTTP status, error messages ਵਿੱਚ ਕੋਈ ਡੇਟਾ ਲੀਕ ਨਾ, idempotent retries, ਅਤੇ graceful fallbacks।
ਜਦੋਂ ਕੋਈ ਕੰਪੋਨੈਂਟ ਇਨਪੁੱਟ ਨੂੰ ਪਾਰਸ ਕਰਦਾ, queries ਬਣਾਂਦਾ, ਜਾਂ ਯੂਜ਼ਰ ਡੇਟਾ ਨੂੰ ਤਬਦੀਲ ਕਰਦਾ, ਤਾਂ ਪਰੰਪਰਾਤਮਕ ਉਦਾਹਰਨ ਅਜਿਹਾ ਨਹੀਂ ਸੰਭਾਲਦੇ।
Property-based tests ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ boundary ਬੱਗ ਫੜਨ 'ਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ (ਲੰਬਾਈ ਸੀਮਾਵਾਂ, ਐਨਕੋਡਿੰਗ ਮੁੱਦੇ, ਅਣ-ਉਮੀਦਿਤ nulls) ਜਿਹਨੂੰ AI ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਅਕਸਰ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਕਵਰੇਜ ਨੰਬਰ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਬਾਰ ਵਜੋਂ ਲਾਭਕਾਰੀ ਹਨ, ਨਹੀਂ ਤਾਂ ਅੰਤ:
ਆਥਾਰਟੀ/ਅਧਿਕਾਰ, ਡੇਟਾ ਵੈਧਤਾ, ਪੈਸੇ/ਕ੍ਰੈਡਿਟ, ਮਿਟਾਉਣ ਵਾਲੇ ਰਸਤੇ, ਅਤੇ retry/timeout ਲੋਜਿਕ 'ਤੇ ਟੈਸਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕੀ "ਉੱਚ-ਜੋਖਮ" ਹੈ, ਤਾਂ ਪبلਿਕ ਐਂਡਪੋਇੰਟ ਤੋਂ ਡੇਟਾਬੇਸ ਲਿਖਾਈ ਤੱਕ ਦੀ ਬੇਨਤੀ ਮਾਰਗ ਦੀ ਪਟਰੀ ਖਿੱਚੋ ਅਤੇ ਰਾਹਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ।
AI-ਜਨਰੇਟਡ ਕੋਡ "ਤਿਆਰ" ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਚਲਾਉਣਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਟੀਮਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸੁੱਟੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਵਿਜ਼ੀਬਿਲਟੀ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦੀ। Observability ਉਸ ਚੀਜ਼ ਨੂੰ routine fix ਬਣਾਉਂਦੀ ਜੋ ਹੈਰਾਨਗੀ ਵਾਲੀ ਘਟਨਾ ਹੋ ਸਕਦੀ ਹੈ।
ਸਟਰੱਕਚਰਡ ਲੌਗਿੰਗ ਨਿਅਤਕ ਕਰਨ ਲਾਜ਼ਮੀ ਕਰੋ। ਸਧਾਰਣ ਟੈਕਸਟ ਲੋਕਲ ਡੈਵ ਲਈ ਠੀਕ ਹੈ, ਪਰ ਜਦੋਂ ਕਈ ਸਰਵਿਸਾਂ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟਸ ਸ਼ਾਮਲ ਹੋਣ ਤਾਂ ਉਹ scale ਨਹੀਂ ਕਰਦੇ।
ਲਾਜ਼ਮੀ:
ਲਕੜੀ ਇਹ ਹੈ ਕਿ ਇੱਕ request ID ਇਕੱਲੇ ਇਹ ਪੁੱਛਣ ਦੇ ਯੋਗ ਹੋਵੇ: "ਕੀ ਹੋਇਆ, ਕਿੱਥੇ, ਅਤੇ ਕਿਉਂ?" bina guess ਕਰੇ।
ਲੌਗਸ ਇਹ ਸਮਝਾਉਂਦੀਆਂ ਹਨ ਕਿ ਕਿਉਂ; ਮੈਟ੍ਰਿਕਸ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕਦੋਂ ਚੀਜ਼ਾਂ ਘਟਣ ਲੱਗਦੀਆਂ ਹਨ।
ਜੋੜੋ ਮੈਟ੍ਰਿਕਸ:
AI-ਜਨਰੇਟਡ ਕੋਡ ਅਕਸਰ ਗੁਪਤ ਅਸਰਸ਼ੀਲਤਾਵਾਂ ਲਿਆਉਂਦਾ ਹੈ (ਵਾਧੂ queries, ਅਣਬੱਧ loops, chatty network calls)। saturation ਅਤੇ queue depth ਇਨ੍ਹਾਂ ਨੂੰ ਜਲਦੀ ਫੜ ਲੈਂਦੇ ਹਨ।
ਇੱਕ ਅਲਰਟ ਨੂੰ ਇੱਕ ਫੈਸਲਾ ਲਈ ਲੈ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਇੱਕ ਗ੍ਰਾਫ ਨਹੀਂ। noisy thresholds ("CPU > 70%") ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਉਹ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਨਾਲ ਗੱਥੇ ਨਾ ਹੋਣ।
ਚੰਗੀ ਅਲਰਟ ਡਿਜ਼ਾਈਨ:
ਸਟੇਜਿੰਗ ਜਾਂ ਯੋਜਨਾਬੱਧ ਅਭਿਆਸ ਦੌਰਾਨ ਅਲਰਟਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਜਾਣਚ ਨਹੀਂ ਸਕਦੇ ਕਿ ਅਲਰਟ ਫਾਇਰ ਕਰਦੀ ਹੈ ਅਤੇ ਕਾਰਵਾਈਯੋਗ ਹੈ, ਤਾਂ ਇਹ ਅਲਰਟ ਨਹੀਂ—ਸਿਰਫ ਇੱਕ ਆਸ ਹੈ।
ਆਪਣੇ ਮੁੱਖ ਰਸਤੇ ਲਈ ਹਲਕੇ-ਭਾਰ ਰਨਬੁੱਕ ਲਿਖੋ:
ਰਨਬੁੱਕ ਕੋਡ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨੇੜੇ ਰੱਖੋ—ਉਦਾਹਰਨ ਲਈ ਰੇਪੋ ਵਿੱਚ ਜਾਂ ਅੰਦਰੂਨੀ ਡੌਕਸ ਵਿੱਚ—ਤਾਂ ਜੋ ਜਦ ਸਿਸਟਮ ਬਦਲੇ ਤਾਂ ਉਹ ਅਪਡੇਟ ਹੋ ਸਕਣ।
AI-ਜਨਰੇਟਡ ਕੋਡ throughput ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਨਾਲ variance ਵੀ ਵੱਧ ਜਾਂਦਾ ਹੈ: ਛੋਟੇ ਬਦਲਾਅ ਸੁਰੱਖਿਆ ਮੁੱਦੇ, ਧੀਮੇ ਰਸਤੇ, ਜਾਂ ਨਾਜੁਕ ਸਹੀਤਾ ਬੱਗ ਲਿਆ ਸਕਦੇ ਹਨ। ਇੱਕ ਅਨੁਪਾਲਿਤ CI/CD ਪਾਈਪਲਾਈਨ ਉਸ variance ਨੂੰ ਸੰਭਾਲਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਇਹੋ ਥਾਂ ਹੈ ਜਿਥੇ end-to-end generation ਵਰਕਫਲੋ ਨੂੰ ਵੱਧ ਅਨੁਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਜੇ ਕੋਈ ਟੂਲ ਜਲਦੀ generate ਅਤੇ deploy ਕਰ ਸਕਦਾ ਹੈ (ਜਿਵੇਂ Koder.ai ਬਿਲਟ-ਇਨ deployment/hosting, custom domains, ਅਤੇ snapshots/rollback ਨਾਲ), ਤੁਹਾਡੇ CI/CD gates ਅਤੇ rollback ਪ੍ਰਕਿਰਿਆਵਾਂ ਵੀ ਉਸੇ ਰਫ਼ਤਾਰ ਅਤੇ ਮਿਆਰ ਵਾਲੀਆਂ ਹੋਣਾ ਚਾਹੀਦੀਆਂ ਹਨ—ਤਾਂ ਜੋ ਗਤੀ ਸੁਰੱਖਿਆ ਦੀ ਕੀਮਤ ਨਾ ਬਣ ਜਾਵੇ।
Pipeline ਨੂੰ merge ਅਤੇ release ਲਈ ਘੱਟੋ-ਘੱਟ ਮਾਪਦੰਡ ਮੱਨੋ—"quick fixes" ਲਈ ਕੋਈ ਛੂਟ ਨਹੀਂ। ਆਮ ਗੇਟ ਹਨ:
ਜੇ ਕੋਈ ਚੈੱਕ ਮਹੱਤਵਪੂਰਣ ਹੈ, ਉਸਨੂੰ blocking ਬਣਾਓ। ਜੇ ਇਹ noisy ਹੈ, ਤਦ ਉਸਨੂੰ tune ਕਰੋ—ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰੋ।
"ਸਾਰੇ-ਇਕੱਠੇ" ਡਿਪਲੋਯਮੈਂਟ ਦੀ ਥਾਂ ਕੰਟਰੋਲਡ ਰੋਲਆਊਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ:
ਆਟੋਮੈਟਿਕ rollback triggers (error rate, latency, saturation) define ਕਰੋ ਤਾਂ ਜੋ ਰੋਲਆਊਟ ਉਹਨਾਂ ਤੱਕ ਰੁਕ ਜਾਵੇ ਜਦੋਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਸਰ ਪੈਂਦਾ।
ਰੋਲਬੈਕ ਯੋਜਨਾ ਤਬ ਹੀ ਹਕੀਕਤ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਤੇਜ਼ ਹੋਵੇ। ਡੇਟਾਬੇਸ ਮਾਈਗਰੇਸ਼ਨ ਨੂੰ ਜਿੱਥੇ ਸੰਭਵ ਉਲਟਯੋਗ ਰੱਖੋ, ਅਤੇ ਇਕ-ਤਰੀਕਾ schema changes ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਜਾਂਚਿਆ ਹੋਇਆ forward-fix ਯੋਜਨਾ ਨਾ ਹੋਵੇ। ਨਿਰਪੱਖ ਮਾਹੌਲ ਵਿੱਚ ਕਾਲਾਂ ਰੋਲਬੈਕ ਡ੍ਰਿਲ ਚਲਾਓ।
PR templates ਜੋ ਇਰਾਦਾ, ਜੋਖਮ, ਅਤੇ ਟੈਸਟ ਨੋਟਸ ਕੈਪਚਰ ਕਰਦੇ ਹਨ ਲਾਜ਼ਮੀ ਕਰੋ। ਰਿਲੀਜ਼ ਲਈ ਇੱਕ ਹਲਕੀ-ਭਾਰ changelog ਰੱਖੋ, ਅਤੇ ਸਾਫ਼ approval ਨਿਯਮ (ਉਦਾਹਰਨ ਲਈ, routine changes ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਰਿਵਿਊਅਰ, security-sensitive ਲਈ ਦੋ)। ਹੋਰ ਡੂੰਘੀ ਸਮੀਖਿਆ workflow ਲਈ ਦੇਖੋ /blog/code-review-checklist।
AI-ਜਨਰੇਟਡ ਕੋਡ ਲਈ "ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ" ਦਾ ਮਤਲਬ "ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਕੋਡ ਟੀਮ ਦੁਆਰਾ ਸੁਰੱਖਿਅਤ, ਬਦਲੇ ਜਾਣ ਯੋਗ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ—ਅਸਲ ਟਰੈਫਿਕ, ਅਸਲ ਫੇਲਿਯਰ, ਅਤੇ ਅਸਲ ਡੇਡਲਾਈਨਾਂ ਹੇਠ।
ਕਿਸੇ ਵੀ AI-ਜਨਰੇਟਡ ਫੀਚਰ ਦੇ ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਚਾਰ ਚੀਜ਼ਾਂ ਸੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
AI ਕੋਡ ਲਿਖ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਸ ਦੀ ਮਾਲਕੀ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਹਰ ਜਨਰੇਟ ਕੀਤੀ ਕਮਪੋਨੈਂਟ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਮਲਕੀਅਤ ਨਿਰਧਾਰਤ ਕਰੋ:
ਜੇ ਮਲਕੀਅਤ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ ਉਹ ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ ਨਹੀਂ ਹੈ।
ਇਸਨੂੰ ਐਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਵਾਸਤਵ ਵਿੱਚ ਰਿਵਿਊ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕੇ:
ਇਹ ਪਰਿਭਾਸ਼ਾ "ਪ੍ਰੋਡਕਸ਼ਨ-ਤਿਆਰ" ਨੂੰ ਵਿਆਖਿਆਤਮਕ ਅਤੇ ਕਾਰਗਰ ਬਣਾਉਂਦੀ ਹੈ—ਘੱਟ ਬਹਿਸ, ਘੱਟ ਹੈਰਾਨੀਆਂ।
AI-ਦੁਆਰਾ ਬਣਾਇਆ ਕੋਡ ਉਹ ਕੋਈ ਵੀ ਬਦਲਾਅ ਹੈ ਜਿਸ ਦੀ ਢਾਂਚਾ ਜਾਂ ਲੋਜਿਕ ਮੂਡਲ ਤੋਂ ਪ੍ਰਾਂਪਟ ਰਾਹੀਂ ਮੁੱਖਤਿਆਰ ਕੀਤੀ ਗਈ ਹੋਵੇ—ਚਾਹੇ ਉਹ ਕੁਝ ਲਾਈਨਾਂ ਆਟੋਕੰਪਲੀਟ ਹੋਣ, ਇੱਕ ਫੰਕਸ਼ਨ ਹੋਣ ਜਾਂ ਇਕ ਪੂਰਾ ਸਰਵਿਸ ਸਕੈਫੋਲਡ ਹੋਵੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਉਸ ਤਰੀਕੇ ਨਾਲ ਖੁਦ ਨਹੀਂ ਲਿਖਦੇ ਤਾਂ ਉਸਨੂੰ AI-ਜਨਰੇਟਡ ਮੰਨੋ ਅਤੇ ਉਸੇ ਰਿਵਿਊ/ਟੈਸਟ ਮਾਪਦੰਡ ਲਾਗੂ ਕਰੋ।
AI ਆਊਟਪੁੱਟ ਨੂੰ ਇੱਕ ਡ੍ਰਾਫਟ ਵਜੋਂ ਵੇਖੋ—ਇਹ ਪੜਨਯੋਗ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸਨੂੰ ਇੱਕ ਤੇਜ਼ ਜੂਨੀਅਰ ਟੀਮ ਮੈਂਬਰ ਦੇ ਕੋਡ ਵਾਂਗ ਵਰਤੋ:
ਕਿਉਂਕਿ ਸੁਰੱਖਿਆ, ਕਾਰਗਰਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਅਕਸਰ ਜਨਰੇਟਡ ਕੋਡ ਵਿੱਚ "ਇੱਕਸਪੈਕਟ" ਤੌਰ ਤੇ ਨਹੀਂ ਆਉਂਦੇ।
ਜੇ ਤੁਸੀਂ ਟਾਰਗੇਟ (ਥ੍ਰੇਟ ਮਾਡਲ, ਲੇਟੰਸੀ ਬਜਟ, ਫੇਲਿਯਰ ਬਿਹੇਵਿਯਰ) ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਮਾਡਲ ਮੰਨਤਾ ਪੱਧਰ ਤੇ ਅਤੇ ਆਮ ਪੈਟਰਨਾਂ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕਰੇਗਾ—ਤੁਹਾਡੇ ਟ੍ਰੈਫਿਕ, ਅਨੁਕੂਲਤਾ ਜਾਂ ਫੇਲਿਯਰ ਮੋਡ ਲਈ ਨਹੀਂ।
ਨਿਮਨਲਿਖਤ ਮੁੜ-ਆਉਣ ਵਾਲੇ ਖ਼ਤਰੇ ਵੇਖੋ:
ਨਾਲ ਹੀ TODO ਬ੍ਰਾਂਚਾਂ ਜਾਂ fail-open ਡਿਫਾਲਟਾਂ ਲਈ ਸਕੈਨ ਕਰੋ।
ਛੋਟਾ ਅਤੇ ਕਾਰਗਰ ਰੱਖੋ:
ਫਿਰ ਪੁੱਛੋ: "ਇਸ ਫੀਚਰ ਨਾਲ ਖ਼ਰਾਬ ਮਨੁੱਖ ਸਭ ਤੋਂ ਵੱਡਾ ਕੀ ਕਰ ਸਕਦਾ ਹੈ?"
ਕੁਝ ਉੱਚ-ਸਿਗਨਲ ਚੈੱਕ:
ਖਤਰੇ ਵਾਲੇ ਰਸਤੇ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਨੈਗੇਟਿਵ ਟੈਸਟ ਮੰਗੋ (unauthorized, invalid input, expired token)।
ਕਿਉਂਕਿ ਮਾਡਲ ਮੁਮੀਲਾਂ ਹੱਲ ਕਰਨ ਲਈ ਪੈਕੇਜ ਜੋੜ ਸਕਦਾ ਹੈ, ਜੋ ਤੁਹਾਡਾ ਐਟੈਕ ਸਤਹ ਅਤੇ ਰਖ-ਰਖਾਵ ਵਧਾ ਦਿੰਦੇ ਹਨ।
ਰੋਕ-ਟੋਕ:
PR ਵਿੱਚ lockfile diffs ਰਿਵਿਊ ਕਰੋ ਤਾਂ ਜੋ ਟ੍ਰਾਂਜ਼ਿਟਿਵ ਜੋੜਾਂ ਪਕੜੇ ਜਾ ਸਕਣ।
ਮਾਪਿਆਂ ਨਾਲ "ਚੰਗਾ" ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਅਸਲ ਵਰਕਲੋਡ ਨਾਲ ਜੁੜੇ ਹੋਣ:
ਫਿਰ ਪ੍ਰੋਫਾਇਲ ਕਰੋ ਅਤੇ ਅਨੁਪਾਤਿਤ ਅਨੁਵੀਕਰਨ ਦੀਆਂ ਬਿਨਾਂ ਮਾਪ-ਮੁਲਾਂਕਣ ਦੇ ਇਸ਼ੀਐੱਨ ਨਾ ਕਰੋ।
ਪ੍ਰਯੋਗਿਕ ਗਾਰਡਰੇਲ ਜੋ "ਚਲਦਾ ਹੈ ਪਰ ਢਿੱਲਾ" ਕੋਡ ਰੋਕਦੇ ਹਨ:
ਇਹ ਗਾਰਡਰੇਲ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕਾਰਗਰਤਾ ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਉਂਦੇ ਹਨ।
ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ "ਕਰੇਸ਼ਾਂ ਨਾ ਹੋਣ" ਨਹੀਂ—ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਿਸਟਮ ਗਲਤ ਇਨਪੁੱਟ, ਅੰਤਰਾਲਿਕ ਆਊਟੇਜ ਅਤੇ ਵਾਸਤਵਿਕ ਯੂਜ਼ਰ ਵਿਵਹਾਰ ਹੇਠਾਂ ਸਹੀ ਨਤੀਜੇ ਦੇਵੇ, ਅਤੇ ਜਦੋਂ ਨਹੀਂ ਦਿੰਦਾ ਤਾਂ ਨਿਯੰਤਰਿਤ ਢੰਗ ਨਾਲ ਫੇਲ ਹੋਵੇ।
ਮੁੱਖ ਚੀਜ਼ਾਂ:
ਯੂਨਿਟ ਟੈਸਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ integration tests ਜੋ ਅਸਲੀ ਸਿਸਟਮ ਅਨੁਭਵ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:
ਨੈਗੇਟਿਵ ਮਾਰਗਾਂ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਟੈਸਟ ਕਰੋ (invalid inputs, auth failures, timeouts)
ਜਿੱਥੇ ਇਨਪੁੱਟ ਭਾਰੀ ਹੋ,(property-based) ਜਾਂ fuzz ਟੈਸਟ ਜੋੜੋ—ਇਹ ਬਾਉਂਡਰੀ ਬੱਗ ਫੜਨ ਵਿੱਚ ਖਾਸ ਤੌਰ ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ।
ਕਵਰੇਜ ਨੂੰ ਇੱਕ ਮਿਨੀਮਮ ਬਾਰ ਮੰਨੋ ਪਰ ਜੋਖਮ ਵਾਲੇ ਰਸਤੇ 'ਤੇ ਧਿਆਨ ਦਿਓ।