ਵਾਈਬ ਕੋਡਿੰਗ: ਜਦ ਮੁਸ਼ਕਲ ਹਿੱਸਾ ਇਹ ਹੈ ਕਿ ਕੀ ਬਣਾਇਆ ਜਾਵੇ

ਬੋਤਲਨੈਕ ਹਿਲ ਗਿਆ—ਇਸ ਨਾਲ ਕੀ ਬਦਲਦਾ ਹੈ

ਪਹਿਲੀ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ AI ਨੂੰ Minutes ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸਕਰੀਨ, API ਕਾਲ, ਜਾਂ ਆਟੋਮੇਸ਼ਨ ਬਣਾਉਂਦੇ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਇਹ ਇੱਕ ਚੀਟ ਕੋਡ ਜਿਹੇ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਜੋ ਕੁਝ ਦਿਨ ਲੈਂਦਾ ਸੀ—ਟਿਕਟਾਂ, ਉਡੀਕ, ਅਤੇ ਬਹੁ-ਵਾਰ ਗੱਲਬਾਤ—ਹੁਣ ਅਚਾਨਕ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਆ ਜਾਂਦਾ ਹੈ: “ਇਹਾਂ ਫੀਚਰ ਹੈ।”

ਅਤੇ ਫਿਰ ਇੱਕ ਵੱਖਰੀ ਚੋਪ ਪ੍ਰਵੇਸ਼ ਕਰਦੀ ਹੈ।

ਕੀ ਇਹ ਸਹੀ ਫੀਚਰ ਹੈ? ਕੀ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ? “ਕੰਮ ਕਰ ਰਿਹਾ” ਦਾ ਮਤਲਬ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ, ਡੇਟਾ, ਨੀਤੀਆਂ, ਅਤੇ ਕਾਰੋਬਾਰ ਲਈ ਕੀ ਹੈ?

ਮੁੱਖ ਬਦਲਾਅ: ਟਾਈਪ ਕਰਨ ਤੋਂ ਫੈਸਲਾ ਕਰਨ ਵੱਲ

ਵਾਈਬ ਕੋਡਿੰਗ ਮਿਹਨਤ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੀ—ਇਸ ਨੂੰ ਇਕ ਹੋਰ ਥਾਂ ਵੱਲ ਟਹਿਲਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਕੋਡ ਤੇਜ਼ ਤੇ ਸਸਤਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰੁਕਾਵਟ ਹੁਣ ਟੀਮ ਦੀ импਲਿਮੈਂਟੇਸ਼ਨ ਖ਼ਿਆਲ ਨਹੀਂ ਰਹਿੰਦੀ। ਰੁਕਾਵਟ ਬਣਦੀ ਹੈ ਤੁਹਾਡੀ ਚੰਗੀ ਫੈਸਲੇ ਲੈਣ ਦੀ ਸਮਰੱਥਾ:

• ਅਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਕਿਸ ਲਈ?
• ਅਸੀਂ ਕੀ ਤਿਅੱਗ ਕਰਨ ਨੂੰ ਤੈਅ ਹਾਂ (ਸਹੀਪਨ, ਸਮਾਂ, ਸੁਰੱਖਿਆ, ਸਕੋਪ)?
• ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ “ਮੁਕੰਮਲ” ਮੰਨਿਆ ਜਾਵੇ?

ਜੇ ਇਹਨਾਂ ਦੇ ਜਵਾਬ ਅਸਪਸ਼ਟ ਹਨ, ਤਾਂ ਤੇਜ਼ੀ ਸ਼ੋਰ ਬਣਾਉਂਦੀ ਹੈ: ਹੋਰ ਪ੍ਰੋਟੋਟਾਈਪ, ਅਧ-ਫੀਚਰ, ਅਤੇ “ਲਗਭਗ ਠੀਕ” ਨਤੀਜੇ।

ਇਹ ਲੇਖ ਕਿਸ ਲਈ ਹੈ (ਅਤੇ ਕੌਣ ਲਈ)

ਇਹ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਲਈ ਇਕ ਪ੍ਰਯੋਗਿਕ ਮਾਰਗਦਰਸ਼ਨ ਹੈ ਜੋ ਤੇਜ਼ ਆਉਟਪੁੱਟ ਨੂੰ ਅਸਲੀ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹਨ—ਪ੍ਰੋਡਕਟ ਮੈਨੇਜਰ, ਫਾਉਂਡਰ, ਡਿਜ਼ਾਈਨਰ, ਟੀਮ ਲੀਡ, ਅਤੇ ਗੈਰ-ਟੈਕਨੀਕਲ ਹਿੱਸੇਦਾਰ ਜੋ ਹੁਣ ਪ੍ਰੰਪਟ ਕਰਕੇ “ਬਿਲਡ” ਕਰ ਰਹੇ ਹਨ।

ਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਕਿਵੇਂ ਅਸਪਸ਼ਟ ਵਾਈਬਸ ਤੋਂ ਸਾਫ਼ ਨਿਰਦੇਸ਼ ਤੱਕ ਜਾਇਆ ਜਾਵੇ, ਜਦੋਂ ਹਰ ਚੀਜ਼ ਸੌਖੀ ਲੱਗੇ ਤਾਂ ਕਿਵੇਂ ਪ੍ਰਾਥਮਿਕਤਾ ਰੱਖਣੀ ਹੈ, ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਪ੍ਰੋਡਕਟ ਤੱਕ ਕਿਹੜੀ ਚੀਜ਼ ਗ੍ਰੈਜੂਏਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਫੀਡਬੈਕ ਲੂਪ ਸੈਟ ਕਰਕੇ AI-ਸਹਾਇਤ ਕੋਡਿੰਗ ਮਾਪਯੋਗ ਮੁੱਲ ਪੈਦਾ ਕਰੇ—ਸਿਰਫ਼ ਹੋਰ ਕੋਡ ਨਹੀਂ।

ਵਾਈਬ ਕੋਡਿੰਗ ਅਮਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਰਖਦੀ ਹੈ

“ਵਾਈਬ ਕੋਡਿੰਗ” ਇੱਕ ਆਮ ਨਾਂ ਹੈ ਜਿਸਦਾ ਮਤਲਬ ਹੈ AI ਨੂੰ ਨਿਰਦੇਸ਼ ਦੇ ਕੇ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣਾ ਨਾ ਕਿ ਹਰ ਲਾਈਨ ਖੁਦ ਲਿਖਣਾ। ਤੁਸੀਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਆਪਣੀ ਇੱਛਾ ਵਰਣਨ ਕਰਦੇ ਹੋ, AI ਕੋਡ ਦਾ ਪ੍ਰਸਤਾਵ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇਤਰੇਟ ਕਰਦੇ ਹੋ—ਛੋਟੇ-ਵੇਲੇ ਦੀ ਜੋੜੀਵਾਰ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਵਾਂਗ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਡਰਾਫਟ ਕਰ ਸਕਦਾ, ਰੀਫੈਕਟਰ ਕਰ ਸਕਦਾ, ਅਤੇ ਚੋਣਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹੈ।

Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ, ਇਹ ਚੈਟ-ਟੂ-ਬਿਲਡ ਵਰਕਫਲੋ ਪ੍ਰੋਡਕਟ ਹੈ: ਤੁਸੀਂ ਜਿਹੜੀ ਐਪ ਚਾਹੁੰਦੇ ਹੋ ਉਸਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਸਿਸਟਮ ਇਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਵੈੱਬ/ਸਰਵਰ/ਮੋਬਾਈਲ ਨਿਰਮਾਣ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਗੱਲਬਾਤ ਵਿੱਚ ਦੁਹਰਾਓ—ਬਿਨਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਚਲਾਉਣ ਲਈ ਪੰਜ ਵੱਖ-ਵੱਖ ਟੂਲ ਜੋੜਨ ਦੀ ਲੋੜ ਦੇ।

ਰੋਜ਼ਾਨਾ ਦਿਨਚਰਿਆ ਵਿੱਚ ਇਹ ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਵਾਈਬ ਕੋਡਿੰਗ ਚੱਕਰ ਇੱਕੋ ਹੀ ਰਿਦਮ ਫਾਲੋ ਕਰਦੇ ਹਨ:

1. ਪ੍ਰੰਪਟ: ਤੁਸੀਂ ਲਕਸ਼, ਪਾਬੰਦੀਆਂ ਤੇ ਸੰਦਰਭ ਦੱਸਦੇ ਹੋ ("ਚੈਕਆਉਟ ਫਾਰਮ ਜੋੜੋ, ਵੈਧਤਾ ਹੋਵੇ, ਮੌਜੂਦਾ ਡਿਜ਼ਾਈਨ ਰੱਖੋ, Stripe ਵਰਤੋ").
2. ਜਨਰੇਟ: AI ਕੋਡ, ਟੈਸਟ ਜਾਂ ਯੋਜਨਾ ਤਿਆਰ ਕਰਦਾ ਹੈ।
3. ਰਿਵਿਊ: ਤੁਸੀਂ ਇਸਨੂੰ ਕੋਡ ਰਿਵਿਊਅਰ ਵਾਂਗ ਪੜ੍ਹਦੇ ਹੋ—ਸਹੀਪਨ, ਏਜ ਕੇਸ, ਸੁਰੱਖਿਆ, ਅਤੇ ਪ੍ਰੋਡਕਟ ਨਾਲ ਫਿਟ ਦੀ ਜਾਂਚ।
4. ਇਤਰੇਟ: ਤੁਸੀਂ ਪ੍ਰੰਪਟ ਸੰਕੋਚ ਕਰਦੇ ਹੋ ("ਕਾਰਡ ਡੇਟਾ ਸਟੋਰ ਨਾ ਕਰੋ; ਫੇਲ ਹੋਏ ਭੁਗਤਾਨ ਸੰਭਾਲੋ; ਐਨਾਲਿਟਿਕਸ ਇਵੈਂਟ ਨਾਮ ਜੋੜੋ").

ਇਹ ਕੀ ਨਹੀਂ ਹੈ

ਇਹ ਜਾਦੂ ਨਹੀਂ ਹੈ ਤੇ ਨਾ ਹੀ "ਤੁਰੰਤ ਕੁਝ ਵੀ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ"। AI ਭਰੋਸੇਮੰਦ ਤੌਰ 'ਤੇ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੇ ਡੋਮੇਨ ਨੂੰ ਗਲਤ ਸਮਝ ਸਕਦਾ ਹੈ ਜਾਂ ਨੁਕਸਾਨਭਰੇ ਬੱਗ ਲਿਆ ਸਕਦਾ ਹੈ। ਫੈਸਲਾ, ਟੈਸਟਿੰਗ, ਅਤੇ ਜਵਾਬਦੇਹੀ ਅਜੇ ਵੀ ਮਨੁੱਖਾਂ 'ਤੇ ਹੀ ਰਹਿੰਦੀ ਹੈ। ਵਾਈਬ ਕੋਡਿੰਗ ਕੇਵਲ ਇਸ ਗੱਲ ਨੂੰ ਬਦਲਦੀ ਹੈ ਕਿ ਕੋਡ ਕਿਵੇਂ ਤਿਆਰ ਹੁੰਦਾ ਹੈ—ਸੁਰੱਖਿਆ, ਮੇਨਟੇਨੇਬਿਲਟੀ, ਅਤੇ ਕਾਰੋਬਾਰੀ ਲਕੜੇ ਦੀ ਲੋੜ ਨਹੀਂ ਭੁਲਾਈ ਜਾ ਸਕਦੀ।

ਆਮ ਵਰਕਫਲੋਜ਼ ਜੋ ਤੁਸੀਂ ਦੇਖੋਗੇ

• ਚੈਟ-ਟੂ-ਕੋਡ: ਚੈਟ ਵਿੱਚ ਫੀਚਰ ਵਰਣਨ, ਫਿਰ ਸੁਝਾਏ ਗਏ ਬਦਲਾਵ ਲੱਗੂ ਕਰਨਾ।
• IDE ਵਿਚ ਕੋਡਜੈੱਨ: ਇਨਲਾਈਨ ਸੁਝਾਵ, ਰੀਫੈਕਟਰ, ਟੈਸਟ ਜਨਰੇਸ਼ਨ, ਅਤੇ "ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਸਾਫ਼ ਕਰੋ" ਸੰਪਾਦਨ।
• ਏਜੰਟ-ਸਟਾਈਲ ਟਾਸਕ: ਇੱਕ ਲਕਸ਼ ਦਿੱਤਾ ("CSV 'ਚ ਐਕਸਪੋਰਟ ਜੋੜੋ") ਅਤੇ ਟੂਲ ਫਾਈਲਾਂ 'ਚ ਕਈ-ਕਦਮੀ ਬਦਲਾਅ ਚਲਾਉਂਦਾ, ਫਿਰ ਇੱਕ ਪ੍ਰਸਤਾਵਿਤ ਡਿਫ਼ ਦਿਖਾਇਆ ਜਾਂਦਾ।

ਨਵੀਂ ਰੁਕਾਵਟ: ਇਰਾਦੇ ਦੀ ਸਪੱਸ਼ਟਤਾ

ਜਦੋਂ ਕੋਡ ਜਨਰੇਟ ਕਰਨਾ ਸਸਤਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਦੁਕਾਨੀ ਸਰੋਤ ਬਣ ਜਾਂਦਾ ਹੈ ਸਪੱਸ਼ਟ ਫੈਸਲੇ: ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, "ਡਨ" ਕੀ ਮਤਲਬ ਹੈ, ਕੀ ਬਾਹਰ ਰੱਖਣਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਜੋਖਮ ਮਨਜ਼ੂਰ ਹਨ। ਜਿੰਨੀ ਬਿਹਤਰ ਤੁਹਾਡੀ ਮਨਸ਼ਾ, ਉਥੇ ਹੀ ਬਿਹਤਰ ਆਉਟਪੁੱਟ—and ਬਾਅਦ ਦੇ ਮਹਿੰਗੇ ਸਪੁਰਦਾਓ ਘੱਟ।

ਘੱਟ ਕੋਡ ਲਿਖਣ ਨਾਲ ਚੰਗੇ ਫੈਸਲੇ ਲੈਣ ਦੀ ਲੋੜ ਕਿਉਂ ਵੱਧਦੀ ਹੈ

ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਮੁੱਖ ਰੁਕਾਵਟ ਡਿਵੈਲਪਰ ਸਮਾਂ ਸੀ: ਸਿੰਟੈਕਸ, ਬੋਇਲਰਪਲੇਟ, ਸਰਵਿਸਾਂ ਨੂੰ ਜੋੜਨਾ, ਅਤੇ "ਸਿਰਫ਼ ਚਲਾ ਦੇਖਨਾ"। ਉਹ ਤੇਜ਼ੀਆਂ ਟੀਮਾਂ ਨੂੰ ਚੁਣਨਬੱਧ ਬਣਾਉਂਦੀਆਂ। ਜੇ ਇੱਕ ਫੀਚਰ ਨੂੰ ਤਿੰਨ ਹਫ਼ਤੇ ਲੱਗਦੇ, ਤਾਂ ਤੁਸੀਂ ਸੋਚ-ਵਿਚਾਰ ਕਰਦੇ ਕਿ ਕੀ ਇਹ ਲਾਇਕ ਹੈ।

AI-ਸਹਾਇਤ ਕੋਡਿੰਗ ਨਾਲ ਉਹ ਫਿੱਕਰ ਘੱਟ ਹੋ ਗਿਆ। ਤੁਸੀਂ UI ਵੈਰੀਐਂਟ, ਵੱਖ-ਵੱਖ ਡੇਟਾ ਮਾਡਲ, ਜਾਂ ਇੱਕ ਪ੍ਰੂਫ-ਆਫ-ਕਾਂਸੈਪਟ ਘੰਟਿਆਂ ਵਿੱਚ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਰੁਕਾਵਟ "ਉਤਪਾਦਨ" ਤੋਂ "ਦਿਸ਼ਾ" ਵੱਲ ਸਵਿੱਚ ਹੋ ਜਾਂਦੀ ਹੈ: ਸੁਆਦ, ਟਰੇਡਆਫ, ਅਤੇ ਦੱਸਣਾ ਕੀ ਸੱਚਮੁੱਚ ਕੀਮਤੀ ਹੈ।

ਸਸਤਾ ਐਕਸਪਲੋਰੇਸ਼ਨ ਜ਼ਿਆਦਾ ਫੈਸਲੇ ਲਿਆਉਂਦੀ ਹੈ

ਜਦੋਂ ਚੋਣਾਂ ਮਹਿੰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਸੀਮਤ ਰੱਖਦੇ ਹੋ। ਜਦੋਂ ਚੋਣਾਂ ਸਸਤੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਜਿਆਦਾ ਬਣਾਉਂਦੇ ਹੋ—ਇਰਾਦੇ ਨਾਲ ਜਾਂ ਬਿਨਾਂ। ਹਰ "ਤੇਜ਼ ਪ੍ਰਯੋਗ" ਨਵੇਂ ਵਿਕਲਪ ਬਣਾਉਂਦਾ:

• ਕਿਹੜਾ ਵਰਜਨ ਲਕਸ਼ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ?
• ਕੀ ਰੱਖਣਾ, ਹਟਾਉਣਾ, ਜਾਂ ਮਿਲਾਣਾ ਚਾਹੀਦਾ?
• ਕਿਹੜੇ ਏਜ ਕੇਸ ਇਸ ਸਮੇਂ ਮਨਜ਼ੂਰ ਹਨ?

ਇਸ ਲਈ ਜਦ ਕੋਡ ਆਉਟਪੁੱਟ ਵੱਧਦਾ ਹੈ, ਫੈਸਲਿਆਂ ਦੀ ਮਾਤਰਾ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦੀ ਹੈ।

ਫੈਸਲਾ-ਬਕਾਇਆ: ਨਵਾਂ ਵੈਸਟ

"ਫੈਸਲਾ-ਬਕਾਇਆ" ਉੱਠਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਮੁਸ਼ਕਲ ਚੋਣਾਂ ਤੋ ਕੱਦਰ ਨਹੀਂ ਕਰਦੇ: ਅਸਪਸ਼ਟ ਸਫਲਤਾ ਮਾਪਦੰਡ, ਫੱਜੀ ਮਾਲਕੀ, ਜਾਂ ਅਣਸੁਲਝੇ ਟਰੇਡਆਫ (ਗਤੀ ਵਿਰੁੱਧ ਗੁਣਵੱਤਾ, ਲਚਕੀਲਾਪਣ ਵਿਰੁੱਧ ਸਾਦਗੀ)। ਕੋਡ ਉਤਪਾਦਨ ਦੇ ਲਈ ਆਸਾਨ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਉਤਪਾਦ ਨਿਯੰਤ੍ਰਣ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਆਮ ਨਿਸ਼ਾਨਾਂ ਵਿੱਚ ਕਈ ਅਧ-ਪੂਰਨ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ, ਓਵਰਲੈਪ ਫੀਚਰ, ਅਤੇ ਦੁਹਰਾਈਆਂ ਰੀਰਾਈਟ ਸ਼ਾਮਲ ਹਨ ਕਿਉਂਕਿ "ਇਹ ਠੀਕ ਮਹਿਸੂਸ ਨਹੀਂ ਹੋਇਆ।"

ਅਸਪਸ਼ਟ ਲਕਸ਼ immer churn ਪੈਦਾ ਕਰਦੇ ਹਨ

ਜੇ ਲਕਸ਼ ਧੁੰਦਲਾ ਹੈ ("ਆਨਬੋਰਡਿੰਗ ਸੁਧਾਰੋ"), AI ਤੁਹਾਡੀ ਮਦਦ ਕਰਕੇ ਕੁਝ ਬਣਾ ਸਕਦਾ, ਪਰ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਇਸ ਨਾਲ ਐਕਟੀਵੇਸ਼ਨ ਵਧੀ, ਸਹਾਇਤਾ ਟਿਕਟ ਘਟੇ, ਜਾਂ ਟਾਈਮ-ਟੂ-ਵੈਲਯੂ ਘਟਿਆ। ਬਿਨਾਂ ਸਪੱਸ਼ਟ ਲਕਸ਼ ਦੇ, ਟੀਮਾਂ ਐਸੇ ਇਟਰੈਸ਼ਨਾਂ ਵਿੱਚ ਘੁੰਮੰਦੀਆਂ ਹਨ ਜੋ ਉਤਪਾਦਕ ਦੌਰ ਤੇ ਲਾਭਦਾਇਕ ਨਹੀਂ—ਅੰਤ ਵਿੱਚ ਪਤਾ ਲਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਮੋਸ਼ਨ ਭੇਜਿਆ ਹੈ, ਪ੍ਰਗਟੀ ਨਹੀਂ।

ਨਵੀਂ ਰੁਕਾਵਟ: ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ

ਜਦੋਂ ਕੋਡ ਬਣਾਉਣਾ ਸਸਤਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ "ਇਸ ਲਈ ਫੀਚਰ ਬਣਾਓ" ਨੂੰ ਇਕ ਨਿਰਦੇਸ਼ ਦੀ ਬਜਾਏ ਇਕ ਜੱਜਮੈਂਟ ਦੀ ਮੰਗ ਬਣ ਜਾਂਦੀ ਹੈ: ਕੀ ਬਣਨਾ ਚਾਹੀਦਾ, ਕਿਸ ਲਈ, ਅਤੇ ਕਿਸ ਮਿਆਰ ਤੱਕ।

ਉਹ ਮੁੱਖ ਫੈਸਲੇ ਜੋ ਤੁਸੀਂ ਐਔਟਸੋਰਸ ਨਹੀਂ ਕਰ ਸਕਦੇ

AI ਜਾਂ ਕਿਸੇ ਟੀਮਮੈਟ ਨੂੰ ਪ੍ਰੰਪਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕੁਝ ਛੋਟੇ ਉਤਪਾਦ ਫੈਸਲੇ ਲਓ ਜੋ ਕੰਮ ਦੀ ਸ਼ਕਲ ਨੂੰ ਪਿੱਛਾਣਦੇ ਹਨ:

• ਸਮੱਸਿਆ: ਅਸੀਂ ਕਿਹੜਾ ਦਰਦ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਇਸ ਬੇਨਤੀ ਨੂੰ ਕੀ ਚਲਾਇਆ?
• ਯੂਜ਼ਰ: ਇਹ ਕਿਸ ਲਈ ਹੈ (ਪ੍ਰਾਇਮਰੀ ਯੂਜ਼ਰ), ਅਤੇ ਕੌਣ ਅਪ੍ਰਤੀਕਸ਼ਿਤ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਤ ਹੋ ਸਕਦਾ ਹੈ?
• ਨਤੀਜਾ: ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ (ਵਰਤਾਰ, ਸਮਾਂ ਬਚਾਉਣਾ, ਘੱਟ ਤਰੁੱਟੀਆਂ)?
• ਪਾਬੰਦੀਆਂ: ਸਮਾਂ, ਬਜਟ, ਕਾਨੂੰਨੀ/ਕੰਪਲਾਇੰਸ, ਪਲੇਟਫਾਰਮ, ਇੰਟੀਗਰੇਸ਼ਨ, ਪਹੁੰਚਯੋਗਤਾ।
• ਸਫਲਤਾ ਮੈਟਰਿਕਸ: ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਗੇ ਕਿ ਇਹ ਕੰਮ ਕਰ ਗਿਆ (ਅਡਾਪਸ਼ਨ, ਕਨਵਰਜ਼ਨ, ਰੀਟੈਨਸ਼ਨ, ਸਪੋਰਟ ਟਿਕਟਾਂ, ਲੇਟਨਸੀ)।

ਬਿਨਾਂ ਇਹਨਾਂ ਦੇ, ਤੁਸੀਂ "ਇੱਕ ਹੱਲ" ਤਾਂ ਪਾ ਲਵੋਗੇ—ਪਰ ਇਹ ਨਹੀਂ ਜਾਣੋਗੇ ਕਿ ਇਹ ਸਹੀ ਹੈ ਜਾਂ ਨਹੀਂ।

“ਕੀ” ਨੂੰ “ਕਿਵੇਂ” ਤੋਂ ਵੱਖਰਾ ਕਰੋ

ਇੱਕ ਲਾਭਦਾਇਕ ਨਿਯਮ: “ਕੀ” ਨੂੰ ਮਨੁੱਖੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰੋ; AI ਨੂੰ “ਕਿਵੇਂ” ਸੁਝਾਉਣ ਦਿਓ।

• ਕੀ ਫੈਸਲੇ: ਯੂਜ਼ਰ ਫਲੋ, ਪਰਮੀਸ਼ਨ, ਲੋੜੀਂਦਾ ਡੇਟਾ, ਸਵੀਕਾਰੋਤੀ ਮਾਪਦੰਡ, ਐਰਰ ਸਥਿਤੀਆਂ।
• ਕਿਵੇਂ ਫੈਸਲੇ: ਫ੍ਰੇਮਵਰਕ, ਕੋਡ ਸੰਰਚਨਾ, ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੇਰਵੇ, ਰੀਫੈਕਟਰਿੰਗ।

ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਮਿਕਸ ਕਰ ਦਿੰਦੇ ("ਇਸਨੂੰ React ਵਿੱਚ X ਲਾਈਬ੍ਰੇਰੀ ਨਾਲ ਬਣਾਓ"), ਤੁਸੀਂ ਗਲਤ ਉਤਪਾਦ ਬਿਹੇਵਿਅਰ ਨੂੰ ਅੱਕਸਮਾਤੀ ਤੌਰ 'ਤੇ ਲਾਕ ਕਰ ਸਕਦੇ ਹੋ।

ਛੁਪੇ ਫੈਸਲੇ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕੱਟਦੇ ਹਨ

ਵਾਈਬ ਕੋਡਿੰਗ ਅਕਸਰ ਉਹ ਡੀਫਾਲਟ ਸ਼ਿਪ ਕਰ ਦਿੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਸਚਮੁਚ ਚੁਣਿਆ ਨਹੀਂ। ਇਨ੍ਹਾਂ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਦੱਸੋ:

• ਡਿਫਾਲਟਸ: ਸ਼ੁਰੂਆਤੀ ਸੈਟਿੰਗਾਂ, ਖਾਲੀ ਸਥਿਤੀਆਂ, ਪਹਿਲਾਂ ਭਰੀਆਂ ਫੀਲਡਾਂ।
• ਏਜ ਕੇਸ: ਡੁਪਲਿਕੇਟ, ਰੀਟ੍ਰਾਈ, ਅਧੂਰੇ ਫੇਲ, ਆਫਲਾਈਨ ਬਿਹੇਵਿਅਰ।
• ਡੇਟਾ ਹੈਂਡਲਿੰਗ: ਕੀ ਸਟੋਰ ਹੁੰਦਾ, ਕਿੱਥੇ ਅਤੇ ਕਿੰਨਾ ਸਮੇਂ; ਐਕਸਪੋਰਟ/ਡਿਲੀਟ ਦੀ ਲੋੜ।
• ਪਰਮੀਸ਼ਨ: ਕੌਣ ਵੇਖ/ਸੋਧ/ਹਟਾ ਸਕਦਾ, ਆਡਿਟ ਲੌਗ, ਐਡਮਿਨ ਓਵਰਰਾਈਡ।

ਇੱਕ ਛੋਟੀ ਪ੍ਰੀ-ਪ੍ਰੰਪਟ ਚੈੱਕਲਿਸਟ

ਪ੍ਰੰਪਟ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਦਿਓ:

1. ਯੂਜ਼ਰ ਕੌਣ ਹੈ ਅਤੇ ਉਹ ਕਿ ਕਰਨਾ ਚਾਹੁੰਦਾ?
2. ਸਭ ਤੋਂ ਛੋਟਾ ਮਨਜ਼ੂਰਯੋਗ ਨਤੀਜਾ ਕੀ ਹੈ?
3. ਕੀ ਨਾ ਹੋਵੇ (ਜੋਖਮ, ਕੰਪਲਾਇੰਸ, ਸੁਰੱਖਿਆ)?
4. ਕੀ ਇਨਪੁਟ/ਆਊਟਪੁਟ ਮੌਜੂਦ ਹਨ (ਡੇਟਾ, ਸਿਸਟਮ, ਭੂਮਿਕਾਵਾਂ)?
5. ਉਹ 3 ਸਵੀਕਾਰੋਤੀ ਟੈਸਟ ਕੀ ਹਨ ਜੋ ਦਿਖਾਉਂਦੇ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ?

ਇਹ ਫੈਸਲੇ "ਕੋਡ ਜਨਰੇਟ ਕਰੋ" ਨੂੰ "ਨਤੀਜਾ ਪਹੁੰਚਾਓ" ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।

ਅਸਪਸ਼ਟ ਵਾਈਬਸ ਤੋਂ ਸਪਸ਼ਟ ਲੋੜਾਂ ਤੱਕ

AI ਇੱਕ ਧੁੰਦਲੀ ਵਿਚਾਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕੋਡ ਵਿੱਚ ਬਦਲ ਸਕਦਾ—ਪਰ ਇਹ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਲਈ "ਚੰਗਾ" ਕੀ ਹੈ, ਦਾ ਅਨੁਮਾਨ ਨਹੀਂ ਲਾ ਸਕਦਾ। ਜਿਹੇ ਪ੍ਰੰਪਟ "ਬਿਹਤਰ ਬਣਾ ਦਿਓ" ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਟਾਰਗੇਟ ਨਤੀਜਾ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ: ਕਿਸ ਲਈ ਬਿਹਤਰ, ਕਿਸ ਸਥਿਤੀ ਵਿੱਚ, ਕਿਸ ਤਰੀਕੇ ਨਾਲ ਅੰਕੜਾ ਕਰਕੇ, ਅਤੇ ਕਿਹੜੇ ਟਰੇਡਆਫ ਮਨਜ਼ੂਰ ਹਨ।

ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੇ ਬਜਾਏ ਨਤੀਜੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਬਦਲਾਅ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਪ੍ਰਿੱਠਕ ਨਤੀਜਾ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ। "ਯੂਜ਼ਰ ਚੈਕਆਉਟ ਤੇਜ਼ੀ ਨਾਲ ਪੂਰਾ ਕਰਦੇ ਹਨ" ਕਾਰਗਰ ਹੈ। "ਚੈਕਆਉਟ ਨੂੰ ਸੁਧਾਰੋ" ਨਹੀਂ। ਸਪਸ਼ਟ ਨਤੀਜਾ ਮਾਡਲ (ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ) ਨੂੰ ਨਿਰਦੇਸ਼ ਦਿੰਦਾ ਹੈ ਕਿ ਕੀ ਰੱਖਣਾ, ਕੀ ਹਟਾਉਣਾ ਅਤੇ ਕੀ ਮਾਪਣਾ ਹੈ।

ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ—ਲਾਈਟਵੇਟ ਆਰਟੀਫੈਕਟ

ਤੁਹਾਨੂੰ 30 ਸਫ਼ਿਆਂ ਦੀ ਸਪੈੱਕ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਨ੍ਹਾਂ ਛੋਟੇ ਫਾਰਮੈਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੁਣੋ ਅਤੇ ਇੱਕ ਪੰਨਾ ਰੱਖੋ:

• ਇੱਕ-ਪੰਨਾ PRD: ਸਮੱਸਿਆ, ਲਕਸ਼, ਨਾਨ-ਗੋਲ, ਸਫਲਤਾ ਮੈਟਰਿਕ, ਪਾਬੰਦੀਆਂ, ਖੁੱਲ੍ਹੇ ਸਵਾਲ
• ਯੂਜ਼ਰ ਸਟੋਰੀ: "As a ___, I want ___, so that ___" (ਅਨੁਵਾਦਿਤ ਸ਼ੈਲੀ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋ)
• ਸਵੀਕਾਰੋਤੀ ਮਾਪਦੰਡ: ਇਹਨਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਮਪਤਾ ਹੈ ਜੋ "ਡਨ" ਲਈ ਲਾਜ਼ਮੀ ਹਨ

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਚੈਟ-ਫਸਟ ਬਿਲਡਰ ਵਰਤ ਰਹੇ ਹੋ, ਇਹ ਆਰਟੀਫੈਕਟ ਪ੍ਰੰਪਟਸ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਂਦੇ ਹਨ—ਖ਼ਾਸ ਕਰ ਕੇ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਥਿਰ ਟੈਂਪਲੇਟ ਵਰਤਦੇ ਹੋ: “ਸੰਦਰਭ → ਲਕਸ਼ → ਪਾਬੰਦੀਆਂ → ਸਵੀਕਾਰੋਤੀ ਮਾਪਦੰਡ → ਨਾਨ-ਗੋਲ।” ਇਹ ਢਾਂਚਾ ਅਕਸਰ ਇੱਕ ਚਮਕਦਾਰ ਡੈਮੋ ਅਤੇ ਕੁਝ ਇਕੱਠਾ ਕਰਨ ਯੋਗ ਚੀਜ਼ ਵਿਚਕਾਰ ਫਰਕ ਬਣਾਂਦਾ ਹੈ।

ਤਿੱਖੇ ਬਨਾਮ ਧੁੰਦਲੇ ਲੋੜਾਂ (ਉਦਾਹਰਨ)

• ਧੁੰਦਲਾ: "ਆਨਬੋਰਡਿੰਗ ਸੁਧਾਰੋ"।

• ਤਿੱਖਾ: "ਆਨਬੋਰਡਿੰਗ ਡਰੌਪ-ਆਫ 45% ਤੋਂ 30% ਕਰਨ—'ਕੰਪਨੀ ਸਾਈਜ਼' ਵੱਲੋਂ ਸਟੈਪ ਹਟਾ ਕੇ; ਯੂਜ਼ਰ ਛੱਡ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਡੈਸ਼ਬੋਰਡ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ।"

• ਧੁੰਦਲਾ: "ਬਿਹਤਰ ਸਰਚ ਜੋੜੋ"।

• ਤਿੱਖਾ: "ਸਰਚ 95% ਕਵੈਰੀਜ਼ ਲਈ <300ms ਵਿੱਚ ਨਤੀਜੇ ਦਿੱਤੇ; exact match + typo tolerance ਲਈ ਰੱਖੋ।"

• ਧੁੰਦਲਾ: "ਸੁਰੱਖਿਆ ਸੁਧਾਰੋ"।

• ਤਿੱਖਾ: "ਐਡਮਿਨ ਰੋਲ ਲਈ MFA ਲਾਜ਼ਮੀ; ਸਾਰੇ ਪਰਮੀਸ਼ਨ ਚੇਂਜ ਲੌਗ ਹੋਣ; ਆਡਿਟ ਲੌਗ 365 ਦਿਨ ਰੱਖੋ।"

ਪਾਬੰਦੀਆਂ ਸਪਸ਼ਟ ਲਿਖੋ

ਤੇਜ਼ੀ ਪਾਬੰਦੀ ਨੂੰ ਹੱਦਾਂ ਨੂੰ ਮੋਹਰਾ ਦੇ ਸਕਦੀ ਹੈ। ਪ੍ਰੰਪਟ ਅਤੇ ਸਪੈਕ ਵਿੱਚ ਪਾਬੰਦੀਆਂ ਰੱਖੋ:

• ਸਮਾਂ/ਬਜਟ: "2 ਦਿਨ ਵਿੱਚ ਸ਼ਿਪ ਹੋਵੇ; ਕੋਈ ਨਵੀਂ ਪੇਡ ਸਰਵਿਸ ਨਾ ਲਿਆਵੋ।"
• ਟੈਕਨੀਕ ਲਿਮਿਟਸ: "ਸਿਰਫ PostgreSQL; Kafka ਨਾ ਲਿਆਓ।"
• ਕੰਪਲਾਇੰਸ: "ਲੌਗਾਂ ਵਿੱਚ ਕੋਈ PII ਨਾ ਹੋਵੇ; GDPR ਡਿਲੀਟ 30 ਦਿਨ ਵਿੱਚ।"

ਸਪਸ਼ਟ ਲੋੜਾਂ ਵਾਈਬ ਕੋਡਿੰਗ ਨੂੰ "ਚੀਜ਼اں ਜਨਰੇਟ ਕਰੋ" ਤੋਂ "ਸਹੀ ਚੀਜ਼ ਬਣਾਓ" ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।

ਜਦ ਹਰ ਚੀਜ਼ ਬਣਾਉਣਾ ਸਸਤਾ ਲੱਗੇ—ਤਬ ਪ੍ਰਾਥਮਿਕਤਾ

AI-ਸਹਾਇਤ ਕੋਡਿੰਗ ਨਾਲ “ਸ਼੍ਰਮ” ਘਟ ਗਿਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਹ ਗਤੀ ਲਈ ਵਧੀਆ ਹੈ—ਪਰ ਇਹ ਵੀ ਢੀਠੀ ਚੀਜ਼ਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਨੂੰ ਸੌਖਾ ਕਰਦਾ ਹੈ।

ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਸਕੋਰਿੰਗ ਢਾਂਚਾ ਵਰਤੋ

ਸਧਾਰਨ ਇੰਪੈਕਟ/ਏਫਰਟ ਮੈਟਰਿਕਸ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ RICE ਨਾਲ ਜਿਆਦਾ ਸਪੱਸ਼ਟਤਾ ਮਿਲੇਗੀ:

• Reach (ਪहुੰਚ): ਕਿਸੇ ਨਿਰਧਾਰਤ ਸਮੇਂ ਵਿੱਚ ਕਿੰਨੇ ਲੋਕ ਇਸ ਨੂੰ ਵਰਤਣਗੇ?
• Impact (ਅਸਰ): ਇਹ ਮੁੱਖ ਮੈਟਰਿਕ ਨੂੰ ਕਿੰਨਾ ਹਿਲਾਊਂਦਾ ਹੈ (ਛੋਟਾ/ਦਰਮਿਆਨਾ/ਵੱਡਾ)?
• Confidence (ਭਰੋਸਾ): ਤੁਸੀਂ reach ਅਤੇ impact ਬਾਰੇ ਕਿੰਨੇ ਯਕੀਨੀ ਹੋ?
• Effort (ਪਰਸ਼ਰ): ਆਈਡਿਆ ਤੋਂ ਡਨ ਤਕ ਸਮਾਂ (ਪਹਿਲਾ ਡੈਮੋ ਨਹੀਂ)

ਚਾਹੇ AI ਕੋਡਿੰਗ ਸਮਾਂ ਘਟਾ ਦੇਵੇ, effort ਵਿੱਚ ਪ੍ਰੋਡਕਟ ਸੋਚ, QA, ਡਾਕਸ, ਸਹਾਇਤਾ, ਅਤੇ ਭਵਿੱਖੀ ਮੇਨਟੇਨੈਂਸ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਇਹ ਓਥੇ ਹੈ ਜਿੱਥੇ "ਸਸਟੇਨਬਲ ਬਣਾਉਣਾ" ਸਸਤਾ ਰਹਿਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ।

ਤੇਜ਼ੀ ਮੌਕੇ ਦੀ ਲਾਗਤ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ

ਜਦੋਂ ਹਰ ਚੀਜ਼ ਬਣਾਉਣਯੋਗ ਦਿਸਦੀ ਹੈ, ਅਸਲ ਲਾਗਤ ਬਣਦੀ ਹੈ ਉਹ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਬਣਾਉਂਦੇ: ਜਿਸ ਬੱਗ ਨੂੰ ਤੁਸੀਂ ਠੀਕ ਨਹੀਂ ਕੀਤਾ, ਉਹ ਆਨਬੋਰਡਿੰਗ ਫਲੋ ਜੋ ਤੁਹਾਂ ਨਹੀਂ ਸੁਧਾਰਿਆ, ਗਾਹਕ ਦੀ ਬੇਨਤੀ ਜੋ ਅਣਦੇਖੀ ਰਹਿ ਗਈ।

ਇੱਕ ਅਮਲੀ ਗਾਰਡਰੈਲ: ਇੱਕ ਛੋਟੀ "Now / Next / Later" ਲਿਸਟ ਰੱਖੋ ਅਤੇ Now ਨੂੰ 1–2 ਸਟੇਟਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਜਦ ਨਵਾਂ ਆਈਡੀਆ ਆਉਂਦਾ ਹੈ, ਇਹ ਕੁਝ ਰਪਲੇਸ ਕਰਨਾ ਚਾਹੀਦਾ—ਨਾਲ ਹੀ ਨਹੀਂ ਜੁੜਨਾ।

WIP ਘਟਾਓ ਅਤੇ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ "ਡਨ" ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਡਨ ਦੀ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ: ਸਫਲਤਾ ਮਾਪਦੰਡ, ਬੇਸਿਕ QA ਚੈੱਕ, ਐਨਾਲਿਟਿਕਸ ਇਵੈਂਟ, ਅਤੇ ਫੈਸਲੇ ਦੀ ਅੰਦਰੂਨੀ ਨੋਟ। ਜੇ ਇਹ ਤੁਰੰਤ ਮਿਲ ਨਹੀਂ ਸਕਦਾ, ਇਹ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਹੈ—ਫੀਚਰ ਨਹੀਂ।

ਕਿਹੜੀ ਚੀਜ਼ ਨੂੰ ਨਾਕਾਰ ਕਹਿਣਾ (ਅਤੇ ਪਹਿਲਾਂ ਕੱਟਣਾ)

ਪ੍ਰਾਥਮਿਕਤਾ ਕਰਨ ਸਮੇਂ, ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਕੱਟੋ:

1. ਏਜ ਕੇਸ (ਹੈਪੀ ਪਾਥ ਰੱਖੋ)
2. ਨਾਈਸ-ਟੂ-ਹੈਵਜ਼ (ਕੋਰ ਪ੍ਰੋਮਿਸ ਰੱਖੋ)
3. ਕਸਟਮਾਈਜੇਸ਼ਨ (ਇੱਕ ਨਿਰਣਾਇਤ ਡਿਫਾਲਟ ਰੱਖੋ)
4. ਪੋਲਿਸ਼ (ਵਰਤੋਂ ਸਾਬਤ ਹੋਣ ਤੋਂ ਬਾਅਦ)

ਵਾਈਬ ਕੋਡਿੰਗ ਸਭ ਤੋਂ ਵਧੀਆ ਤਬ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਹਰ "ਹਾਂ" ਨੂੰ ਆਉਟਕਮਜ਼ ਲਈ ਇੱਕ ਵਾਅਦਾ ਮੰਨਦੇ ਹੋ, ਨ ਕਿ ਸਿਰਫ਼ ਆਉਟਪੁੱਟ ਲਈ।

ਪ੍ਰੋਟੋਟਾਈਪ ਵਿਰੁੱਧ ਪ੍ਰੋਡਕਟ: ਕਿਹੜਾ ਪ੍ਰੋਟੋਟਾਈਪ "ਅਸਲੀ" ਬਣਦਾ ਹੈ

AI-ਸਹਾਇਤ ਕੋਡਿੰਗ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਤੇਜ਼ੀ ਨਾਲ ਬਣਦੇ ਹਨ—ਅਤੇ ਇਹ ਤੋਹਫ਼ਾ ਤੇ ਫੰਦਰ ਦੋਹਾਂ ਹੈ। ਜਦੋਂ ਟੀਮ ਇੱਕ ਦਿਨ ਵਿੱਚ ਤਿੰਨ ਵਰਜਨ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ, ਉਹ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਲੱਗਦੇ ਹਨ। ਲੋਕ ਸਭ ਤੋਂ ਚਮਕਦਾਰ ਡੈਮੋ ਨੂੰ ਯਾਦ ਰੱਖਦੇ ਹਨ, ਨਾ ਕਿ ਉਹ ਜੋ ਸਹੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ। ਜਲਦੀ ਹੀ ਤੁਸੀਂ "ਅਸਥਾਈ" ਚੀਜ਼ਾਂ ਦੀ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਲੱਗਦੇ ਹੋ ਜੋ ਅਚਾਨਕ ਨਿਰਭਰਤਾਵਾਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।

ਕਿਉਂ ਪ੍ਰੋਟੋਟਾਈਪ ਵਧਦੇ ਹਨ (ਅਤੇ ਸਭ ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰਦੇ)

ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣਾ ਆਸਾਨ, ਪਰ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੈ। ਉਹ ਮੁੱਖ ਸੜਕਾਂ ਨੂੰ ਧੁੰਦਲਾ ਕਰ ਦਿੰਦੇ:

• ਕੀ ਇਹ ਇੱਕ ਸੰਕਲਪ ਹੈ ਜਾਂ ਇੱਕ ਵਚਨਬੱਧਤਾ?
• ਕੀ ਇਹ ਸੁਰੱਖਿਅਤ, ਕੰਪਲਾਇਂਟ ਅਤੇ ਸਪੋਰਟਯੋਗ ਹੈ?
• ਕੀ ਇਹ ਕਿਸੇ ਅਸਲੀ ਚੀਜ਼ ਨੂੰ ਮਾਪ ਰਿਹਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਦਿਖਾ ਰਿਹਾ ਹੈ ਕਿ ਸੰਭਵ ਹੈ?

ਬਿਨਾਂ ਸਪਸ਼ਟ ਲੇਬਲਿੰਗ ਦੇ, ਟੀਮਾਂ ਅਕਸਰ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਵਿਵਾਦ ਕਰਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ਼ ਇਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਬਣਾਈਆਂ ਗਈਆਂ ਸਨ।

ਪ੍ਰੋਟੋਟਾਈਪ ਸੀੜੀ ਵਰਤੋ

ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੰਗਾਂ ਵਾਲੀਆਂ ਸੀੜੀਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਓ ਜਿਨ੍ਹਾਂ ਦੇ ਮਕਸਦ ਤੇ ਉਮੀਦਾਂ ਵੱਖ-ਵੱਖ ਹਨ:

1. ਸਕੈਚ: ਵਿਚਾਰ ਅਤੇ ਯੂਜ਼ਰ ਫਲੋ ਸਪਸ਼ਟ ਕਰੋ।
2. ਕਲਿੱਕੇਬਲ: ਸਮਝ ਅਤੇ ਚਾਹੁਣ ਯੋਗਤਾ ਟੈਸਟ ਕਰੋ।
3. ਫੰਕਸ਼ਨਲ: ਹਕੀਕਤੀ ਡੇਟਾ ਪਾਥਾਂ ਨਾਲ ਫੀਜੀਬਿਲਿਟੀ ਅਤੇ ਏਜ ਕੇਸ ਟੈਸਟ ਕਰੋ।
4. ਪ੍ਰੋਡਕਸ਼ਨ: ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਸਪੋਰਟ ਲਈ ਬਣਾਓ।

ਹਰੇਕ ਰੰਗ ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਸਵਾਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਉਹ ਜਵਾਬ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ।

ਵੈਧਤਾ ਸੰਕੇਤਾਂ ਨਾਲ ਨਿਰਣਾ ਕਰੋ

ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਉਹਦੋਂ ਗ੍ਰੈਜੂਏਟ ਕਰਦਾ ਹੈ ਜਦ ਸਬੂਤ ਮਿਲਦੇ ਹਨ, ਨ ਕਿ ਜਜਬੇ ਨਾਲ। ਅਜਿਹੇ ਸੰਕੇਤਾਂ 'ਚ ਸ਼ਾਮਿਲ ਹਨ:

• ਯੂਜ਼ਰ ਇੰਟਰਵਿਊਜ਼ ਜੋ ਸਮੱਸਿਆ ਅਤੇ ਸੁਝਾਏ ਗਏ ਵਰਕਫਲੋ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ
• ਛੋਟੇ ਪਾਇਲਟ ਇੱਕ ਨਿਰਧਾਰਿਤ ਦਰਸ਼ਕ ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਨਾਲ
• ਰੀਟੇਨਸ਼ਨ/ਵਰਤੋਂ ਪੈਟਰਨ (ਦੁਹਰਾਈ ਵਰਤੋਂ, ਟਾਈਮ-ਟੂ-ਵੈਲਯੂ, ਟਾਸਕ ਪੂਰਾ ਹੋਣਾ)

ਉਸ ਨਿਯਮ ਨੇ ਜੋ ਅਚਾਨਕ ਪ੍ਰੋਡਕਟ ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ

ਬਿਨਾਂ ਦਸਤਾਵੇਜਿਤ ਫੈਸਲੇ ਦੇ ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਵਧਾਉਣਾ ਨਾ ਕਰੋ—ਵੱਧੇ ਯੂਜ਼ਰ, ਵੱਧੇ ਡੇਟਾ, ਵੱਧੇ ਇੰਟੀਗਰੇਸ਼ਨ—ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਦੱਸਿਆ ਗਿਆ ਫੈਸਲਾ ਲਿਖਿਆ ਹੋਵੇ। ਉਹ ਫੈਸਲਾ ਮਾਲਕ, ਸਫਲਤਾ ਮੈਟਰਿਕ, ਅਤੇ ਉਹ ਚੀਜ਼ ਦੱਸੇ ਜਿਸਨੂੰ ਤੁਸੀਂ ਰੋਕ ਦੇ ਕੇ ਇਸਨੂੰ ਫੰਡ ਕਰੋਗੇ।

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ "ਰਿਵਰਸਬਿਲਿਟੀ" ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਮੰਗ ਬਣਾਓ। ਉਦਾਹਰਨ ਲਈ, Koder.ai snapshots and rollback ਨੂੰ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਤਜਰਬਾ ਕਰਨ ਲਈ ਇਕ ਪਰੈਕਟਿਕਲ ਤਰੀਕਾ ਹੈ—ਇਸਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਜਾਣੇ ਹੋਏ-ਚੰਗੇ ਹਾਲਤ 'ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ ਜੇ ਅਕਸਮਾਤ ਪ੍ਰੋਟੋਟਾਈਪ ਘਟਿਆ।

ਗੁਣਵੱਤਾ ਅਤੇ ਜੋਖਮ: ਤੇਜ਼ੀ ਜਿੰਨੀ ਵੀ ਹੋਵੇ ਜ਼ਿੰਮੇਵਾਰੀ ਘਟਦੀ ਨਹੀਂ

ਵਾਈਬ ਕੋਡਿੰਗ ਇਹ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀ ਹੈ ਕਿ ਤੁਸੀਂ "ਸਿਰਫ਼ ਸ਼ਿਪ ਕਰ ਦਿਓ" ਕਿਉਂਕਿ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਆ ਜਾਂਦਾ ਹੈ। ਪਰ ਜੋਖਮ ਦਾ ਪ੍ਰੋਫ਼ਾਈਲ ਘਟਦਾ ਨਹੀਂ—ਉਹ ਬਦਲਦਾ ਹੈ। ਜਦੋਂ ਆਉਟਪੁੱਟ ਸਸਤਾ ਹੁੰਦਾ ਹੈ, ਘੱਟ-ਗੁਣਵੱਤਾ ਫੈਸਲੇ ਅਤੇ ਕਮਜ਼ੋਰ ਸੁਰੱਖਿਆ ਤੇਜ਼ੀ ਨਾਲ ਵੱਡੇ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਹੁੰਦੀਆਂ ਹਨ

ਆਮ ਨਾਕਾਮੀ ਮੋਡ ਅਸਾਮਾਨ ਨਹੀਂ—ਉਹ ਆਮ गलਤੀਆਂ ਹਨ ਜੋ ਵੱਧ ਆਉਟਪੁੱਟ 'ਤੇ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਹੁੰਦੀਆਂ ਹਨ:

• ਸੁਰੱਖਿਆ ਦੀਆਂ ਖਾਮੀਆਂ: ਅਣ-ਸੁਰੱਖਿਅਤ auth checks, injection ਖਤਰ, ਖੁੱਲ੍ਹੇ endpoints, ਬਹੁਤ ਆਮ CORS ਪਛਾਣ।
• ਟੁੱਟੇ ਪਰਵਾਹ: ਏਜ ਕੇਸ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ, ਉਲਝਣ-ਪੂਰਨ UX ਸਥਿਤੀਆਂ, ਅਧੂਰੇ ਐਰਰ ਹੈਨਡਲਿੰਗ।
• ਡੇਟਾ ਮਾਲਕੀ ਅਸਪਸ਼ਟ: ਡੇਟਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਕੌਣ ਇਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ, ਰਿਟੇਨਸ਼ਨ ਨੀਤੀਆਂ, ਅਤੇ ਆਡੀਟਬਿਲਟੀ।

AI-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਵੀ ਉਹੀ ਚੇਕ ਮੰਗਦਾ ਹੈ

AI-ਸਹਾਇਤ ਕੋਡ ਨੂੰ ਇੱਕ ਨਵੇਂ ਟੀਮਮੇਟ ਵੱਲੋਂ ਲਿਖਿਆ ਕੋਡ ਮੰਨੋ ਜੋ ਬਹੁਤ ਤੇਜ਼ ਕੰਮ ਕਰਦਾ: ਮਦਦਗਾਰ, ਪਰ ਆਪਣੇ ਆਪ ਸਹੀ ਨਹੀਂ। ਰਿਵਿਊ ਬਿਨਾਂ ਗੱਲ ਨਹੀਂ—ਖਾਸ ਕਰਕੇ authentication, payments, permissions, ਅਤੇ ਗਾਹਕ ਡੇਟਾ ਨਾਲ ਸੰਬੰਧਤ ਹਿੱਸਿਆਂ 'ਤੇ।

ਗਾਰਡਰੈਲ ਜੋ ਤੇਜ਼ੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੇ ਹਨ

ਕੁਝ ਹਲਕੇ-ਫੁਲਕੇ ਅਭਿਆਸ ਤੇਜ਼ੀ ਬਣਾਏ ਰੱਖਦੇ ਹੋਏ ਅਣਚੱਲੇ ਨਤੀਜਿਆਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ:

• ਕੋਡ ਰਿਵਿਊ ਰੂਟੀਨ (ਛੋਟੇ ਬਦਲਾਅ ਲਈ ਵੀ ਗੇਟ)
• ਆਟੋਮੇਟੇਡ ਟੈਸਟ ਮੁੱਖ ਪਾਥਾਂ ਲਈ: ਲਾਗਿਨ, ਖਰੀਦ, ਕੋਰ CRUD, ਅਤੇ ਪਰਮੀਸ਼ਨ
• ਥ੍ਰੈਟ ਮੋਡਲਿੰਗ ਨਵੇਂ ਫੀਚਰ ਲਈ: "ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ, ਅਸੀਂ ਕਿਵੇਂ ਪਤਾ ਲਾਵਾਂਗੇ?"
• ਲੌਗਿੰਗ + ਮਾਨੀਟਰਿੰਗ: ਸੰਰਚਿਤ ਲੌਗ, ਐਰਰ ਟ੍ਰੈਕਿੰਗ, ਅਤੇ ਮੁੱਖ ਵਰਕਫਲੋ ਲਈ ਅਲਰਟ

ਇੱਕ ਸਧਾਰਨ "ਨੋ-ਗੋ" ਲਿਸਟ

ਇਹਨਾਂ ਕੜੇ ਨਿਯਮਾਂ ਨੂੰ ਜਲਦੀ ਬਣਾ ਦਿਓ ਅਤੇ ਦੁਹਰਾਓ:

• ਪ੍ਰੰਪਟਾਂ ਵਿੱਚ ਕੋਈ ਸਾਈਕ੍ਰੇਟ ਨਾ (API keys, tokens, ਗਾਹਕ ਡੇਟਾ)
• AI ਨੇ ਜਿਹੜਾ ਸੁਝਾਇਆ, ਉਹਨਾਂ ਨੂੰ ਬਿਨਾ-ਰਿਵਿਊ dependency ਨਾ ਜੋੜੋ
• ਉਹ ਲਾਈਬ੍ਰੇਰੀਆਂ ਜੋ ਲਾਈਸੰਸ ਸਪੱਸ਼ਟ ਨਹੀਂ ਉਹ ਨਾ ਲਿਆਓ
• ਮੁੱਖ ਪਾਥਾਂ 'ਤੇ ਟੈਸਟਾਂ ਬਿਨਾਂ ਮਰਜ ਨਾ ਕਰੋ

ਤੇਜ਼ੀ ਉਸੇ ਸਮੇਂ ਫਾਇਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕੋ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ—ਅਤੇ ਜਲਦੀ ਲਈ ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਪਛਾਣ ਵੀ ਸਕੋ ਜਦੋਂ ਨਹੀਂ।

ਫੀਡਬੈਕ ਲੂਪ ਜੋ ਆਉਟਪੁੱਟ ਨੂੰ ਨਤੀਜਿਆਂ ਵਿੱਚ ਬਦਲਦੇ ਹਨ

ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣਾ ਤਦ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦ ਹਰ ਇਟਰੈਸ਼ਨ ਤੁਹਾਨੂੰ ਕਿਸੇ ਅਸਲੀ ਗੱਲ ਬਾਰੇ ਸਿਖਾਉਂਦੀ ਹੈ। ਮਕਸਦ "ਹੁੰਦਾ ਹੈ ਜ਼ਿਆਦਾ ਆਉਟਪੁੱਟ" ਨਹੀਂ—ਮਕਸਦ ਹੈ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰਦੇ ਹੋ (ਜਾਂ ਮੌਕ-ਕੀਆ) ਉਸਨੂੰ ਸਬੂਤ ਬਣਾਉਣਾ ਜੋ ਅਗਲੇ ਫੈਸਲੇ ਦੀ ਰਹਨੁਮਾਈ ਕਰੇ।

ਹਰ ਵਾਰੀ ਚਲਾਉਣ ਲਈ ਲੂਪ

ਇੱਕ ਸਧਾਰਨ ਲੂਪ ਵਾਈਬ ਕੋਡਿੰਗ ਨੂੰ ਜ਼ਮੀਨੀ ਬਣਾਈ ਰੱਖਦਾ:

prompt → build → test → observe → decide

• Prompt: ਯੂਜ਼ਰ ਸਮੱਸਿਆ, ਮਨਜ਼ੂਰ ਬਿਹੇਵਿਅਰ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਸਿੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਦੱਸੋ।
• Build: ਸਭ ਤੋਂ ਛੋਟਾ ਵਰਜ਼ਨ ਬਣਾਓ ਜੋ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕੇ।
• Test: ਇਸਨੂੰ ਸਿਰਫ਼ "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਦੀ ਨਜ਼ਰ ਨਹੀਂ—ਅਸਲੀ ਵਰਤੋਂ ਨਾਲ ਪਰਖੋ।
• Observe: ਲੱਗੇ ਕਿ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਅਤੇ ਕੀ ਬੋਲਦੇ ਹਨ, ਨੂੰ ਕੈਪਚਰ ਕਰੋ।
• Decide: ਸਬੂਤ ਦੇ ਆਧਾਰ 'ਤੇ ਰੋਕੋ, ਜਾਰੀ ਰੱਖੋ, ਜਾਂ ਦਿਸ਼ਾ ਬਦਲੋ।

ਤੇਜ਼ੀ ਨਾਲ ਫੀਡਬੈਕ ਇਕੱਠਾ ਕਰੋ (ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਬਿਨਾਂ)

ਤੁਹਾਨੂੰ ਰਿਸਰਚ ਵਿਭਾਗ ਦੀ ਲੋੜ ਨਹੀਂ—ਇੱਕ ਤੇਜ਼ ਸਿਗਨਲ ਲਈ:

• ਇਨ-ਐਪ ਪ੍ਰੰਪਟ: ਮੁੱਖ ਕਾਰਵਾਈ ਤੋਂ ਬਾਅਦ ਇੱਕ-ਸਵਾਲ ਸਰਵੇ (“ਕੀ ਇਸ ਨੇ ਤੁਹਾਡੀ ਮਦਦ ਕੀਤੀ? ਹਾਂ/ਨਾ”)।
• ਸੈਸ਼ਨ ਨੋਟਸ: 3–5 ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਹੋ ਦੇਖਣ ਲਈ; ਸਹੀ ਤੌਰ 'ਤੇ ਯਥਾਰਥਿੱਕ ਕੌਟਸ ਤੇ ਜਿੱਥੇ ਉਹ ਹਿੱਚਕਿਚਾਏ ਹਨ ਲਿਖੋ।
• ਲਾਈਟਵੇਟ ਐਨਾਲਿਟਿਕਸ: ਨਤੀਜੇ ਨਾਲ ਜੁੜੇ ਕੁਝ ਇਵੈਂਟ ਟ੍ਰੈਕ ਕਰੋ (start → complete, time-to-complete, drop-off)।
• ਸਪੋਰਟ ਚੈਨਲ ਸਕੈਨਿੰਗ: ਫੀਚਰ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੇ ਸੁਨੇਹੇ ਟੈਗ ਕਰੋ; ਦੁਹਰਾਉਣ ਦੀ ਗਿਣਤੀ ਕਰੋ।

ਫੈਸਲਾ ਚੈਕਪોઈੰਟ ਅਤੇ ਟਾਈਮਬਾਕਸ

ਹਰੇਕ ਇਟਰੈਸ਼ਨ ਤੋਂ ਬਾਅਦ ਇੱਕ ਚੈਕਪੋਇੰਟ ਦੌੜਾਓ:

• Go: ਸਬੂਤ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਲਾਭਦਾਇਕ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੈ—ਸੁਧਾਰ ਕਰੋ।
• Change: ਕੁਝ ਮੁੱਲ ਹੈ, ਪਰ ਤਰੀਕਾ ਗਲਤ—ਹਿਪੋਥੈਸਿਸ ਸੋਧੋ।
• Stop: ਘੱਟ ਮੁੱਲ ਜਾਂ ਉੱਚ ਜੋਖਮ—ਅਰਕਾਈਵ ਕਰੋ।

ਅਨੰਤ ਇٽرੈਸ਼ਨ ਤੋਂ ਬਚਣ ਲਈ, ਟਾਈਮਬਾਕਸ ਲਗਾਓ (ਉਦਾਹਰਨ: "2 ਦਿਨ ਜਾਂ 20 ਯੂਜ਼ਰ ਸੈਸ਼ਨ"). ਜਦ ਟਾਈਮਬਾਕਸ ਖਤਮ ਹੋਵੇ, ਤੁਹਾਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਹੀ ਹੋਏਗਾ—ਚਾਹੇ ਫੈਸਲਾ "ਰੋਕੋ ਜਦ ਤੱਕ ਅਸੀਂ X ਮਾਪ ਨਹੀਂ ਕਰ ਸਕਦੇ" ਹੋਵੇ।

ਟੀਮ ਦੇ ਭੂਮਿਕਾ: ਕੌਣ ਫੈਸਲਾ ਕਰਦਾ, ਕੌਣ ਰਿਵਿਊ ਕਰਦਾ, ਕੌਣ ਨਤੀਜਿਆਂ ਦਾ ਮਾਲਕ

ਜਦੋਂ AI ਮੰਗ 'ਤੇ ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ, "ਕੌਣ ਇਸਨੂੰ ਇੰਪਲੀਮੈਂਟ ਕਰ ਸਕਦਾ" ਮੁੱਖ ਰੁਕਾਵਟ ਨਹੀਂ ਰਹਿੰਦੀ। ਜੋ ਟੀਮਾਂ ਵਾਈਬ ਕੋਡਿੰਗ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਉਹ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਹਟਾਉਂਦੀਆਂ ਨਹੀਂ—ਉਹਨਾਂ ਨੂੰ ਫੈਸਲਿਆਂ, ਰਿਵਿਊ, ਅਤੇ ਜਵਾਬਦੇਹੀ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮੁੜ-ਸਮਤਲ ਕਰਦੀਆਂ ਹਨ।

ਫੈਸਲੇ ਕਰਨ ਵਾਲਾ: ਇੱਕ ਠੋਟ (ਸੰਤੁਸ਼ਟ ਦ੍ਰਿਸ਼ਟਿਕੋਣ)

ਹਰੇਕ ਪਹਿਲਕਦਮੀ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ ਫੈਸਲਾਕਰ ਚਾਹੀਦਾ: PM, ਫਾਉਂਡਰ, ਜਾਂ ਡੋਮੇਨ ਲੀਡ। ਇਹ ਵਿਅਕਤੀ ਇਹ ਜਵਾਬ ਦੇਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ:

• ਅਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਕਿਸ ਲਈ, ਅਤੇ ਹੁਣ ਕਿਉਂ?
• "ਡਨ" ਕੀ ਮਤਲਬ ਹੈ (ਸਫਲਤਾ ਮੈਟਰਿਕ + ਸਵੀਕਾਰੋਤੀ ਮਾਪਦੰਡ)?
• ਅਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਕੀ ਨਹੀਂ ਬਣਾ ਰਹੇ?

ਬਿਨਾਂ ਨਾਂ-ਨਿਯਤ ਫੈਸਲਾਕਰ ਦੇ, AI ਆਉਟਪੁੱਟ ਅਧ-ਪੂਰਨ ਫੀਚਰਾਂ ਦਾ ਪਹਾੜ ਬਣ ਸਕਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਮੰਗੇ ਨਹੀਂ ਅਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਭਰੋਸੇ ਨਾਲ ਸ਼ਿਪ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਡਿਵੈਲਪਰ ਟਾਈਪਿਸਟ ਤੋਂ ਰਿਵਿਊਅਰ, ਆਰਕੀਟੈਕਟ, ਤੇ ਕੋਚ ਬਣਦੇ ਹਨ

ਡਿਵੈਲਪਰ ਅਜੇ ਵੀ ਬਣਾਉਂਦੇ ਹਨ—ਪਰ ਉਹਨਾਂ ਦੀ ਕੀਮਤ ਜ਼ਿਆਦਾ ਹਿੱਸਾ ਜਿੱਥੇ ਮੂਲਤਾ ਹੁੰਦੀ ਹੈ ਉਹ ਹੈ:

• AI-ਜਨਰੇਟ ਕੋਡ ਦੀ ਰਿਵਿਊ: ਸਹੀਪਨ, ਸੁਰੱਖਿਆ, ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਮੇਨਟੇਨੇਬਿਲਟੀ
• ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ: ਸੀਮਾਵਾਂ, ਡੇਟਾ ਮਾਡਲ, ਇੰਟੀਗਰੇਸ਼ਨ ਪੈਟਰਨ, ਅਤੇ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਫਿੱਟ
• ਕੋਚਿੰਗ: ਹੋਰਾਂ ਨੂੰ ਪ੍ਰੰਪਟ, ਪਾਬੰਦੀਆਂ, ਅਤੇ ਪ੍ਰੋਡਕਟ ਇਰਾਦੇ ਨੂੰ ਇੰਪਲੀਮੈਂਟੇਬਲ ਟਾਸਕ ਵਿੱਚ ਬਦਲਣਾ ਸਿਖਾਉਣਾ

ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਏਡੀਟਰ ਅਤੇ ਸਿਸਟਮ ਸੋਚਣ ਵਾਲੇ ਦੇ ਤੌਰ 'ਤੇ ਸੋਚੋ, ਸਿਰਫ਼ ਕੋਡ ਦੀਆਂ ਲਾਈਨਾਂ ਬਣਾਉਣ ਵਾਲੇ ਵਜੋਂ ਨਹੀਂ।

ਗੈਰ-ਟੈਕਨੀਕਲ ਯੋਗਦਾਨ: ਸਪੈੱਕ ਲੇਖਕ ਤੇ ਮੁਲਾਂਕਣਕਾਰ

ਡਿਜ਼ਾਈਨਰ, ਸਪੋਰਟ ਲੀਡ, ਓਪਸ, ਅਤੇ ਸੇਲਜ਼ ਸਿੱਧਾ ਯੋਗਦਾਨ ਦੇ ਸਕਦੇ ਹਨ—ਜੇ ਉਹ ਕਲਿਰਟੀ 'ਤੇ ਧਿਆਨ ਦੇਣ।

ਉਹ ਜੋ ਮਦਦਗਾਰ ਇਨਪੁਟ ਰੱਖ ਸਕਦੇ ਹਨ:

• ਇੱਕ-ਪੰਨਾ ਸਪੈੱਕ: ਯੂਜ਼ਰ ਸਟੋਰੀ, ਪਾਬੰਦੀਆਂ, ਏਜ ਕੇਸ, ਉਦਾਹਰਣ, ਅਤੇ ਕੀ ਮਾਪਣਾ ਹੈ
• ਇੱਕ ਟੈਸਟ ਸਕ੍ਰਿਪਟ: "ਇੱਥੇ ਕਲਿੱਕ ਕਰੋ, ਇਹ ਭਰੇ, ਇਹ ਉਮੀਦ ਕਰੋ"
• ਇੱਕ ਰਿਐਲਟੀ ਚੈਕ: ਕੀ ਪ੍ਰੋਟੋਟਾਈਪ ਅਸਲ ਵਿੱਚ ਗਾਹਕ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ?

ਮਕਸਦ "ਬਿਹਤਰ ਪ੍ਰੰਪਟ ਕਰਨਾ" ਨਹੀਂ, ਪਰ ਫੈਸਲਾ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਟੀਮ ਆਉਟਪੁੱਟਾਂ ਦਾ ਮੂਲਿਆਂਕਨ ਕਰ ਸਕੇ।

ਸਹਿਯੋਗ ਰੀਤੀਆਂ ਜੋ ਤੇਜ਼ੀ ਨੂੰ ਅਲਮੌੜ ਨਾ ਬਣਨ ਦਿੰਦੀਆਂ

ਕੁਝ ਹਲਕੇ ਰੀਤੀਆਂ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਰੱਖਦੀਆਂ ਹਨ:

• Prompt reviews (10 ਮਿੰਟ): ਵੱਡੇ ਕੋਡ ਬਲਾਕ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੰਪਟ + ਪਾਬੰਦੀਆਂ ਸਾਂਝਾ ਕਰੋ।
• Demo Fridays: ਦਿਖਾਓ ਕਿ ਕੀ ਬਦਲਿਆ, ਅਗਲਾ ਕੀ ਹੈ, ਅਤੇ ਕੀ ਰੱਦ ਕੀਤਾ ਗਿਆ।
• Decision logs: ਜੋ ਫੈਸਲੇ ਹੋਏ, ਕਿਸ ਨੇ ਕੀਤਾ, ਅਤੇ ਕਿਉਂ—ਇੱਕ ਛੋਟਾ ਰਿਕਾਰਡ (decision-log template) ਵਿੱਚ ਰੱਖੋ।

ਨਤੀਜਿਆਂ ਦਾ ਮਾਲਕ (ਕੇਵਲ ਸ਼ਿਪਿੰਗ ਨਹੀਂ)

ਹਰੇਕ ਫੀਚਰ ਲਈ ਇੱਕ "ਆਉਟਕਮ ਮਾਲਕ" ਨਿਯੁਕਤ ਕਰੋ—ਅਕਸਰ ਉਹੀ ਜੋ ਫੈਸਲਾ ਕਰਦਾ—ਜੋ ਅਡਾਪਸ਼ਨ, ਸਪੋਰਟ ਲੋਡ, ਅਤੇ ਕੀ ਫੀਚਰ ਮੈਟਰਿਕ ਨੂੰ ਅੱਗੇ ਵਧਾ ਰਿਹਾ ਹੈ ਦੇਖਦਾ ਹੈ। ਵਾਈਬ ਕੋਡਿੰਗ ਬਣਾਉਣਾ ਸਸਤਾ ਕਰ ਦਿੰਦੀ ਹੈ; ਇਹ ਸਿੱਖਣ ਤੇਜ਼ ਕਰ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਵਾਬਦੇਹੀ ਨੂੰ ਧੁੰਦਲਾ ਨਹੀਂ।

ਬੇਲੌੜੀ ਅਪਰਾਧ ਤੋਂ ਬਿਨਾਂ ਵਾਈਬ ਕੋਡਿੰਗ ਲਈ ਕਾਰਗਰ ਵਰਕਫਲੋ

ਤੇਜ਼ੀ ਮਦਦਗਾਰ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਇਹ ਸਹੀ ਲਕਸ਼ ਵੱਲ ਨਿਸ਼ਾਨਾ ਹੋਵੇ। ਇੱਕ ਹਲਕੀ ਵਰਕਫਲੋ AI-ਸਹਾਇਤ ਕੋਡਿੰਗ ਨੂੰ ਉਤਪਾਦਕ ਰੱਖਦੀ ਹੈ ਬਿਨਾਂ ਤੁਹਾਡੇ ਰੀਪੋ ਨੂੰ ਪ੍ਰਯੋਗ ਆਰ্কਾਈਵ ਬਣਨ ਦੇ।

ਇੱਕ ਸਧਾਰਨ ਅੰਤ-ਤੱਕ ਫਲੋ

ਆਈਡਿਆ ਤੋਂ ਮਾਪੇ ਗਏ ਨਤੀਜੇ ਤਕ ਸਾਫ਼ ਫਨਲ ਰੱਖੋ:

1. ਬੈਕਲੌਗ: ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ-ਲਾਈਨਰ ਰੂਪ ਵਿੱਚ ਰੱਖੋ ਅਤੇ "ਕਿਉਂ" ਵੀ ਜੋੜੋ (ਕੌਣ ਲਾਭ ਉਠਾਏਗਾ, ਕੀ ਸਮੱਸਿਆ ਹੱਲ ਹੁੰਦੀ)।
2. ਸਪੈੱਕ: ਚੁਣੇ ਹੋਏ ਆਇਟਮ ਨੂੰ ਇੱਕ ਛੋਟਾ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਵੇਰਵਾ ਵਿੱਚ ਬਦਲੋ (ਇਨਪੁਟ, ਆਊਟਪੁਟ, ਏਜ ਕੇਸ, ਅਤੇ "ਡਨ" ਕੀ ਮਤਲਬ)।
3. ਜਨਰੇਟ: ਸਪੈੱਕ ਤੋਂ AI ਨੂੰ ਕੋਡ, ਟੈਸਟ, ਅਤੇ ਡੌਕਸ ڈਰਾਫਟ ਕਰਨ ਲਈ ਵਰਤੋ—ਧੁੰਦਲੇ ਚੈਟ ਤੋਂ ਨਹੀਂ।
4. ਰਿਵਿਊ: ਮਨੁੱਖ ਵਰਤਾਰ, ਸੁਰੱਖਿਆ/ਪ੍ਰਾਈਵੇਸੀ ਪ੍ਰਭਾਵ, ਅਤੇ ਮਿਆਰਾਂ ਨਾਲ ਮਿਲਾਪ ਜਾਂਚਦੇ ਹਨ।
5. ਮਰਜ: ਜੇ ਸਕਦਾ ਤਾਂ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਸ਼ਿਪ ਕਰੋ।
6. ਮੈਜਰ: ਨਤੀਜਾ ਪੁਸ਼ਟੀ ਕਰੋ (ਐਕਟੀਵੇਸ਼ਨ, ਸਮਾਂ-ਬਚਤ, ਤਰੁੱਟੀ ਦਰ, ਸਪੋਰਟ ਟਿਕਟਾਂ)।

ਜੇ ਤੁਸੀਂ ਇਹ ਮਾਪ ਰਹੇ ਹੋ ਕਿ ਇਹ ਤੁਹਾਡੀ ਟੀਮ ਨਾਲ ਕਿਵੇਂ ਫਿੱਟ ਬੈਠਦਾ ਹੈ, ਇੱਕ ਸਧਾਰਨ ਬਾਰ ਰੱਖੋ: ਕੀ ਤੁਸੀਂ "ਆਈਡਿਆ" ਤੋਂ "ਮਾਪਯੋਗ ਬਦਲਾਅ" ਤੱਕ ਦੁਹਰਾਉਂਦੇ ਹੋ?

ਕੁਝ ਲਾਭਦਾਇਕ ਆਰਟੀਫੈਕਟ ਜੋ ਗੁਣਵੱਤਾ ਬਚਾਂਦੇ ਹਨ

ਕੁਝ ਛੋਟੇ "ਡਿਫਾਲਟ" ਬਹੁਤ ਸਾਰੀ ਉਲਝਣ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ:

• Prompt templates: "ਸੰਦਰਭ → ਲਕਸ਼ → ਪਾਬੰਦੀਆਂ → ਸਵੀਕਾਰੋਤੀ ਮਾਪਦੰਡ → ਨਾਨ-ਗੋਲ"।
• ਕੋਡਿੰਗ ਮਿਆਰ: ਨਾਂਕਰਨ, ਲੌਗਿੰਗ, ਐਰਰ ਹੈਨਡਲਿੰਗ, ਅਤੇ ਡਿਪੈਂਡੰਸੀ ਨਿਯਮ।
• ਸਵੀਕਾਰੋਤੀ ਟੈਸਟ: ਸਧਾਰਨ-ਭਾਸ਼ਾ ਵਿਚ ਸਥਿਤੀਆਂ + ਆਟੋਮੈਟੇਡ ਚੈੱਕ (ਯੂਨਿਟ/ਇੰਟੀਗਰੇਸ਼ਨ)।

ਫੈਸਲੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਕੇਵਲ ਕੋਡ ਨਹੀਂ

ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਨੂੰ ਫੈਸਲਾ ਰਿਕਾਰਡ ਵਜੋਂ ਰੱਖੋ:

• ਕੀ ਧਾਰਣਾਵਾਂ ਬਣਾਈਆਂ ਗਈਆਂ ਅਤੇ ਕੀ ਓਹਨਾਂ ਨੂੰ ਖੰਡਿਤ ਕਰੇਗਾ
• ਕਿਹੜੇ ਵਿਕਲਪ ਰੱਦ ਕੀਤੇ ਗਏ (ਅਤੇ ਕਿਉਂ)
• ਜਾਣੇ-ਪਹਿਲੇ ਜੋਖਮ ਅਤੇ ਫਾਲੋ-ਅਪਸ

ਇਕ ਪ੍ਰੈਕਟਿਕਲ ਸੁਝਾਅ ਜੇ ਤੁਸੀਂ Managed environment ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ: "exitable" ਹੋਣਾ ਸਪਸ਼ਟ ਕਰੋ। Koder.ai ਜਿਵੇਂ ਟੂਲ ਸਾਰਥਕ source code export ਦਿੰਦੇ ਹਨ, ਜੋ ਟੀਮਾਂ ਨੂੰ AI ਤੇਜ਼ੀ ਨੂੰ ਲੈਵਰੇਜ ਲਈ ਵਰਤਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ—ନ ਕਿ ਲਾਕ-ਇਨ।

ਜੇ ਤੁਹਾਨੂੰ ਇਹ ਵਰਕਫਲੋ ਸੈੱਟ ਕਰਨ ਜਾਂ ਰਿਵਿਊ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਕੈਲੀਬਰਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਚਾਹੀਦੀ ਹੋਵੇ, ਇੱਕ ਇਕੱਲੇ ਮਾਲਕ ਰਾਹੀਂ ਰੂਟ ਕਰੋ ਅਤੇ ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਬਾਹਰੀ ਮਦਦ ਲਓ।

ਉਦਾਹਰਨ: "ਇੱਕ ਫੀਚਰ ਬਣਾਓ" ਨੂੰ ਸਪਸ਼ਟ ਫੈਸਲਾ ਬਣਾਉਣਾ

ਇੱਕ PM ਨੇ ਸੁਨੇਹਾ ਭੇਜਿਆ: “ਕੀ ਅਸੀਂ 'Smart Follow‑Up' ਫੀਚਰ ਜੋੜ ਸਕਦੇ ਹਾਂ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਉਹਨਾਂ ਲੀਡਾਂ ਲਈ ਯਾਦ ਦਿਵਾਏ ਜੋ ਉਹਨਾਂ ਨੇ ਸੰਪਰਕ ਨਹੀਂ ਕੀਤੀਆਂ?” AI-ਸਹਾਇਤ ਕੋਡਿੰਗ ਨਾਲ, ਟੀਮ ਦੋ ਦਿਨਾਂ ਵਿੱਚ ਤਿੰਨ ਵਰਜਨ ਉਤਪੰਨ ਕਰ ਲੈਂਦੀ:

• ਇੱਕ ਨਿਯਤ ਯਾਦ ਦਿਵਾਉਣ ਵਾਲਾ ਮੋਡਲ
• ਇਕ ਇਨਬੌਕਸ-ਸਟਾਈਲ "Follow‑Ups" ਟੈਬ
• ਇੱਕ ਆਟੋਮੈਟਿਕ ਡਰਾਫਟ ਈਮੇਲ

ਫਿਰ ਸਭ ਕੁਝ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਸੇਲਜ਼ ਹੋਰ ਆਟੋਮੇਸ਼ਨ ਚਾਹੁੰਦੇ ("ਉਹਨਾਂ ਲਈ ਖ਼ਰਾਰੂਪ ਈਮੇਲ ਲਿਖੋ"), ਸਪੋਰਟ ਫਿਕਰ ਕਰਦਾ ਕਿ ਗਲਤ ਈਮੇਲ ਭੇਜੀਆਂ ਜਾਣਗੀਆਂ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਕਹਿੰਦੀ ਹੈ ਕਿ UI ਭਰ ਗਿਆ ਹੈ। ਕੋਈ ਵੀ ਤੈਅ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿਹੜਾ ਵਰਜਨ "ਸਭ ਤੋਂ ਵਧੀਆ" ਹੈ ਕਿਉਂਕਿ ਮੁੱਲ ਮੰਗ ਨੀ ਕਦੇ ਸਪਸ਼ਟ ਕੀਤਾ ਗਿਆ।

ਟੀਮ ਕਿੱਥੇ ਫਸ ਗਈ

ਉਹਨਾਂ ਕੋਲ ਸੀ:

• ਟਕਰਾਓ ਵਾਲੇ ਲਕਸ਼: ਸਮਾਂ ਬਚਾਉਣਾ ਵਿਰੁੱਧ ਗਲਤੀਆਂ ਤੋਂ ਬਚਨਾ ਵਿਰੁੱਧ ਐਪ ਦਾ ਸਾਦਗੀ ਬਣਾਈ ਰੱਖਣਾ
• ਅਸਪਸ਼ਟ ਯੂਜ਼ਰ: SDRs? Founders? Agencies?
• ਕੋਈ ਮੈਟ੍ਰਿਕ ਨਹੀਂ: ਘੱਟ ਫਾਲੋਅਪ, ਜ਼ਿਆਦਾ reply rate, ਜਾਂ ਘੱਟ churn?

ਇਸ ਲਈ ਟੀਮ ਵਿਕਲਪ ਬਣਾਉਂਦੀ ਰਹੀ ਨਿੱਕਲ ਦੀ ਥਾਂ ਕਿਸੇ ਇੱਕ ਫੈਸਲੇ ਤੇ ਨਾਹ ਆ ਸਕੀ।

ਠੀਕ ਕੀਤਾ: ਇਸਨੂੰ ਇਕ ਵਾਈਬ ਨਹੀਂ, ਇਕ ਫੈਸਲਾ ਬਣਾਓ

ਉਹ ਲੋਕਾਂ ਨੇ ਬੇਨਤੀ ਨੂੰ ਮਾਪਯੋਗ ਨਤੀਜੇ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਿਆ:

ਲਕਸ਼: “SDR ਟੀਮਾਂ ਲਈ 7 ਦਿਨਾਂ ਵਿੱਚ ਕੋਈ ਫਾਲੋਅਪ ਨਾ ਕਰਨ ਵਾਲੀਆਂ ਲੀਡਾਂ ਦੀ % 32% → 20% ਤੱਕ ਘਟਾਉਣਾ।”

ਸੰਕੁचित ਸਕੋਪ (v1): ਸਿਰਫ਼ ‘Hot’ ਸੂਚੀ ਵਾਲੀਆਂ ਲੀਡਾਂ ਲਈ ਯਾਦ ਦਿਵਾਉਣ।

ਸਵੀਕਾਰੋਤੀ ਮਾਪਦੰਡ:

• ਯੂਜ਼ਰ ਲੀਡ ਵੇਖਣ ਵਿਚ ਫਾਲੋ-ਅਪ ਦੀ ਮਿਤੀ ਸੈੱਟ ਕਰ ਸਕਦਾ ਹੈ
• ਰਿਮਾਈਂਡਰ ਇਨ-ਐਪ ਦਿਖਾਈ ਦੇਵੇ (ਈਮੇਲ ਨਹੀਂ) ਇੱਕ ਦਿਨ ਵਿੱਚ ਇੱਕ ਵਾਰੀ
• ਯੂਜ਼ਰ ਇੱਕ-ਕਲਿੱਕ ਨਾਲ snooze ਜਾਂ mark done ਕਰ ਸਕੇ
• ਟ੍ਰੈਕਿੰਗ ਇਵੈਂਟ: followup_reminder_completed

ਹੁਣ ਟੀਮ ਸਭ ਤੋਂ ਸਧਾਰਨ ਨਿਰਮਾਣ ਨੂੰ ਚੁਣ ਸਕਦੀ ਹੈ ਜੋ ਨਤੀਜਾ ਸਾਬਤ ਕਰਦਾ ਹੈ।

ਦੁਹਰਾਯੋਗ ਚੈੱਕਲਿਸਟ

• ਪ੍ਰਾਇਮਰੀ ਯੂਜ਼ਰ ਕੌਣ ਹੈ?
• ਨਤੀਜਾ ਕੀ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਕਿੰਨੇ ਤੋਂ?
• v1 ਵਿੱਚ ਕੀ ਹੈ (ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਕੀ ਬਾਹਰ ਹੈ)?
• ਕੀ ਚੀਜ਼ 'ਨੋ' ਬਣਾ ਦੇਵੇਗੀ? (ਜੋਖਮ, ਕੰਪਲਾਇੰਸ, ਸਪੋਰਟ ਭਾਰ)
• ਸਵੀਕਾਰੋਤੀ ਮਾਪਦੰਡ ਅਤੇ ਇੱਕ ਵੇਖਣਯੋਗ ਮੈਟ੍ਰਿਕ ਕੀ ਹੈ?