ਸਿੱਖੋ ਕਿ ਵਾਇਬ-ਕੋਡਿੰਗ ਕਿਵੇਂ AI-ਪਹਿਲੇ ਉਤਪਾਦਾਂ, ਅੰਦਰੂਨੀ ਟੂਲਾਂ ਅਤੇ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਲਈ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਵਾਉਂਦੀ ਹੈ—ਸਾਥ ਹੀ ਗਾਰਡਰੇਲ, ਟੈਸਟ ਅਤੇ ਸਮੀਖਿਆਵਾਂ ਰਾਹੀਂ ਗੁਣਵੱਤਾ ਕਾਇਮ ਰੱਖਦੀ ਹੈ।
“ਵਾਇਬ-ਕੋਡਿੰਗ” ਇੱਕ ਪ੍ਰਯੋਗਕਾਰੀ ਢੰਗ ਹੈ ਜੋ AI ਮਦਦ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦਾ ਹੈ—ਤੁਹਾਡੀ ਉਤਪਾਦੀ ਇੰਟਿਊਸ਼ਨ (“ਵਾਇਬ”) ਨੂੰ AI ਨਾਲ ਜੋੜ ਕੇ। ਤੁਸੀਂ ਦੱਸਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕੀ ਹਾਸਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਇੱਕ LLM ਪਹਿਲਾ ਡਰਾਫਟ ਕੋਡ ਜਾਂ UI ਜਨਰੇਟ ਕਰਦਾ ਹੈ, ਫਿਰ ਛੋਟੇ-ਲੂਪਾਂ ਵਿੱਚ ਇਟਰੈਟ ਕਰਦੇ ਹੋ: ਚਲਾਓ, ਦੇਖੋ ਕਿ ਕੀ ਟੁੱਟਦਾ ਹੈ, ਪ੍ਰਾਂਪਟ ਨੂੰ ਐਡਜਸਟ ਕਰੋ, ਅਤੇ ਅੱਗੇ ਵਧੋ।
ਮਕਸਦ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਪੂਰੀ ਕੋਡਿੰਗ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਕੁਝ ਐਸਾ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਣਾ ਹੈ ਜੋ ਸਿਖਾਏ: ਕੀ ਇਹ ਵਰਕਫਲੋ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਕੀ ਮਾਡਲ ਆਉਟਪੁੱਟ ਸਮਝਦਾਰ ਹੈ, ਅਤੇ ਕੀ ਕਿਸੇ ਨੂੰ ਇਹ ਫੀਚਰ ਹਕੀਕਤ ਵਿੱਚ ਚਾਹੀਦਾ ਹੈ?
ਰਵਾਇਤੀ ਵਿਕਾਸ ਅਕਸਰ ਅੱਗੇ ਤੋਂ ਡਿਜ਼ਾਈਨ, ਵਿਸਥਾਰਪੂਰਵ ਟਿਕਟਾਂ ਅਤੇ ਧਿਆਨਪੂਰਵ ਇੰਪਲੀਮੇੰਟੇਸ਼ਨ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਪ੍ਰੋਡਕਟ ਦੇਖੇ। ਵਾਇਬ-ਕੋਡਿੰਗ ਇਸ ਕ੍ਰਮ ਨੂੰ ਉਲਟਦਾ ਹੈ: ਤੁਸੀਂ ਇਕ ਪਤਲਾ, ਕੰਮ ਕਰਨ ਵਾਲਾ ਸਲਾਈਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਫਿਰ ਸੁਧਾਰ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਫਿਰ ਵੀ ਇੰਜੀਨੀਅਰਿੰਗ ਫੈਸਲੇ ਲੈਂਦੇ ਹੋ—ਸਿਰਫ ਉਹਨਾਂ ਨੂੰ ਅਗਲੇ ਸਮੇਂ ਤੱਕ ਮੁਲਤਵੀ ਰੱਖਦੇ ਹੋ ਜੋ ਹੁਣ ਜ਼ਰੂਰੀ ਨਹੀਂ।
ਇਸਦਾ ਇਹ ਮਤਲਬ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਢਾਂਚਾ ਛੱਡ ਦਿਓ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਢਾਂਚਾ ਉਸ ਜਗ੍ਹਾ ਲਾਗੂ ਕਰਦੇ ਹੋ ਜਿੱਥੇ ਇਹ ਤੇਜ਼ੀ ਦਿੰਦਾ ਹੈ: ਤੰਗ ਸਕੋਪ, ਤੇਜ਼ ਡੈਮੋ, ਅਤੇ ਸਪਸ਼ਟ ਅਕਸੈਪਟੈਂਸ ਚੈੱਕ (ਭਾਵੇਂ ਉਹ ਸਧਾਰਣ ਹੀ ਹੋਣ)।
ਜਦੋਂ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਇਕ ਪਲੇਟਫਾਰਮ ਦੇ ਬਲੌਕਾਂ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦੀ ਹੈ ਤਾਂ ਨੋ-ਕੋਡ ਟੂਲ ਚੰਗੇ ਹੁੰਦੇ ਹਨ। ਵਾਇਬ-ਕੋਡਿੰਗ ਵੱਖਰਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਫਿਰ ਵੀ ਅਸਲ ਸੌਫਟਵੇਅਰ ਬਣਾ ਰਹੇ ਹੋ: APIs, ਡੇਟਾ ਮਾਡਲ, ਇੰਟिगਰੇਸ਼ਨਾਂ, auth, ਅਤੇ ਸਾਰੇ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੇ ਕਿਨਾਰੇ-ਕੇਸ। AI ਤੁਹਾਨੂੰ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖਣ ਅਤੇ ਸੋਧਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਸੀਮਾਵਾਂ ਵਿੱਚ ਫਸਾਏ।
ਹਕੀਕਤ ਵਿੱਚ, ਵਾਇਬ-ਕੋਡਿੰਗ ਅਕਸਰ “ਪ੍ਰਾਂਪਟ-ਕੋਡ” ਦੇ ਰੂਪ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਪਰ ਜਲਦੀ ਹੀ ਇਹ “ਪ੍ਰਾਂਪਟ-ਸੇ-ਤਰਮੀਮ” ਬਣ ਜਾਂਦੀ ਹੈ: ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਇਕ ਫੰਕਸ਼ਨ ਰੀਫੈਕਟਰ ਕਰਨ ਲਈ, ਲੌਗਿੰਗ ਜੋੜਨ ਲਈ, ਇੱਕ ਟੈਸਟ ਜਨਰੇਟ ਕਰਨ ਲਈ ਜਾਂ ਸਕੀਮਾ ਨੂੰ ਦੁਬਾਰਾ ਆਕਾਰ ਦੇਣ ਲਈ ਅਨੁਰੋਧ ਕਰਦੇ ਹੋ।
ਇਹ ਸੋਚ ਛੱਡਣ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਹਜੇ ਵੀ ਇੱਕ ਸਪਸ਼ਟ ਨਤੀਜੇ, ਪਾਬੰਧੀਆਂ, ਅਤੇ "ਕੰਮ ਕਰਦਾ" ਦੀ ਪਰਿਭਾਸ਼ਾ ਦੀ ਲੋੜ ਹੈ। ਜੇ ਤੁਸੀਂ ਫੀਚਰ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਇੱਕ LLM ਖੁਸ਼ੀ-ਖੁਸ਼ੀ ਕੁਝ ਐਸਾ ਜਨਰੇਟ ਕਰ ਦੇਵੇਗਾ ਜੋ ਸਹੀ ਦਿਖਾਈ ਦੇਵੇ ਪਰ ਗਲਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰੇ।
ਇਹ ਪ੍ਰਮਾਣੀਕਰਨ ਛੱਡਣ ਨਹੀਂ ਹੈ। ਇੱਕ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਜੋ ਕਿਸੇ ਵੱਲੋਂ ਵਰਤਿਆ ਹੀ ਨਹੀਂ ਜਾਂਦਾ, ਫੇਰ ਵੀ ਅਸਫਲ ਹੈ। ਵਾਇਬ-ਕੋਡਿੰਗ ਉਤਪਾਦ ਖੋਜ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਸਦੀ ਥਾਂ ਨਹੀਂ ਲੈਣਾ।
ਵਾਇਬ-ਕੋਡਿੰਗ AI-ਪਹਿਲੇ ਉਤਪਾਦਾਂ, ਅੰਦਰੂਨੀ ਟੂਲਾਂ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਲਈ ਚਮਕਦਾਰ ਹੁੰਦਾ ਹੈ—ਉਹ ਥਾਵਾਂ ਜਿੱਥੇ ਮੁੱਖ ਜੋਖਮ ਇਹ ਹੈ ਕਿ “ਕੀ ਅਸੀਂ ਸਹੀ ਚੀਜ਼ ਬਣਾ ਰਹੇ ਹਾਂ?” ਇਹ ਸੁਰੱਖਿਆ-ਜਰੂਰੀ ਸਿਸਟਮਾਂ, ਕੜੀ ਰੈਗੂਲੇਟਿਡ ਡੋਮੇਨ ਜਾਂ ਵੱਡੇ-ਪੈਮਾਨੇ ਰੀ-ਰਾਈਟਾਂ ਲਈ ਕਮਜ਼ੋਰ ਫਿੱਟ ਹੈ ਜਿੱਥੇ ਸਹੀਤਾ ਅਤੇ ਲੰਬੀ ਮਿਆਦ ਦੀ ਰੱਖ-ਰਖਾਵ ਹਰ ਫੈਸਲੇ 'ਤੇ ਹਕਦਾਰ ਹੁੰਦੀ ਹੈ।
AI-ਪਹਿਲੇ ਉਤਪਾਦ ਤੇਜ਼ੀ ਦੀ ਕਦਰ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਤਪਾਦ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਵਰਤਾਅ ਦਾ ਰਵੱਈਆ ਹੁੰਦਾ ਹੈ, ਸਿਰਫ ਸਕ੍ਰੀਨਾਂ ਨਹੀਂ। ਇੱਕ ਆਮ ਐਪ ਵਿੱਚ ਤੁਸੀਂ ਅਕਸਰ ਰਿਕ੍ਵਾਇਰਮੈਂਟਸ ਨੂੰ ਅੱਗੇ ਤੋਂ ਸੋਚ ਸਕਦੇ ਹੋ: ਇਨਪੁੱਟ, ਨਿਯਮ ਅਤੇ ਆਉਟਪੁੱਟ। LLM ਨਾਲ, ਸਿੱਖਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਅਸਲ ਸਨਾਰੀਓ ਚਲਾਕੇ ਵੇਖਣਾ ਕਿ ਅਸਲੀ ਤੌਰ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।
ਤੁਸੀਂ ਬਹੁਤ ਹੀ ਘਣ-ਘੱਟ ਇੱਕ ਚੀਜ਼ ਦੀ ਪਰਖ ਨਹੀਂ ਕਰ ਰਹੇ ਹੁੰਦੇ। ਪ੍ਰਾਂਪਟ ਵਿਚ ਹਲਕੀ ਬਦਲਾਵ, ਨਵੀਂ ਟੂਲ ਕਾਲ, ਜਾਂ ਵੱਖ-ਵੱਖ UI ਅਫੋਰਡੈਂਸ ਪੂਰੇ ਅਨੁਭਵ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ। ਵਾਇਬ-ਕੋਡਿੰਗ ਇਸ ਹਕੀਕਤ ਨੂੰ ਫਿੱਟ ਕਰਦੀ ਹੈ: ਇੱਕ ਵਰਕਫਲੋ ਸਕੈਚ ਕਰੋ, ਤੁਰੰਤ ਟੈਸਟ ਕਰੋ, ਫਿਰ ਜੋ ਕੁਝ ਤੁਸੀਂ ਪ੍ਰੇਖਿਆ ਉਹਦੇ ਆਧਾਰ 'ਤੇ ਏਡਜਸਟ ਕਰੋ।
ਉਦਾਹਰਣ ਲਈ, “ਇਸ ਟਿੱਕਟ ਦਾ ਸਾਰ ਲਿਖੋ” ਫੀਚਰ ਨਿਮਨ ਚੀਜ਼ਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦਾ ਹੈ:
ਕਿਉਂਕਿ ਆਉਟਪੁੱਟ ਪ੍ਰੋਬੈਬਿਲਿਸਟਿਕ ਹੁੰਦੇ ਹਨ, ਸਹੀਤਾ ਦੋ-ਮੁਖੀ ਨਹੀਂ ਰਹਿੰਦੀ। ਤੁਸੀਂ ਪੈਟਰਨ ਸਿੱਖਦੇ ਹੋ: ਕਦੋਂ ਇਹ ਹੇਲੂਸੀਨੇਟ ਕਰਦਾ ਹੈ, ਕਦੋਂ ਇਹ ਇਨਕਾਰ ਕਰਦਾ ਹੈ, ਕਦੋਂ ਓਵਰਕਾਂਫਿਡੈਂਟ ਅਨੁਮਾਨ ਲਗਾਂਦਾ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੇ ਹਨ। ਅੱਜ 30 ਅਸਲੀ ਉਦਾਹਰਣ ਚਲਾਉਣਾ ਇੱਕ ਹਫ਼ਤੇ ਲਈ ਕਿਨਾਰੇ-ਕੇਸ 'ਤੇ बहਿਸ ਕਰਨ ਤੋਂ ਜਿਆਦਾ ਸਿੱਖ ਦਿੰਦਾ ਹੈ।
ਮਾਡਲ ਬਦਲਣਾ, temperature ਸੈਟਿੰਗ ਬਦਲਣਾ, ਸੰਦਰਭ ਵਿਂਡੋ ਲਿਮਟਾਂ ਨੂੰ ਮਾਰਨਾ, ਜਾਂ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਜੋੜਨਾ ਅਸ਼ਚਰਜਕਾਰੀ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਨਤੀਜੇ ਦੇ ਸਕਦਾ ਹੈ। ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਇਟਰੈਸ਼ਨ ਦੀ ਰਫ਼ਤਾਰ ਪੂਰੇ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ—ਕਿਉਂਕਿ ਤੁਸੀਂ ਅਜੇ ਵੀ ਖੋਜ ਰਹੇ ਹੋ ਕਿ ਉਤਪਾਦ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਵਾਇਬ-ਕੋਡਿੰਗ ਤੁਹਾਨੂੰ ਛੋਟੇ, ਟੈਸਟੇਬਲ ਫਲੋਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ: ਛੋਟੀ ਜਗ੍ਹਾ, ਜੋ ਮੁੱਲ ਦਿਖਾਉਂਦੀ ਹੈ (ਅਤੇ ਜੋਖਮ ਦਿਖਾਉਂਦੀ ਹੈ) ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਲੰਬੀ-ਮਿਆਦ ਢਾਂਚੇ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ।
ਅੰਦਰੂਨੀ ਟੂਲ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਵਾਇਬ-ਕੋਡਿੰਗ ਸਭ ਤੋਂ "ਕੁਦਰਤੀ" ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ: ਦਰਸ਼ਕ ਜਾਣੇ ਹੋਏ, ਸਟੇਕਸ ਨਿਯੰਤ੍ਰਿਤ, ਅਤੇ ਤੇਜ਼ੀ ਪੋਲ੍ਹੀ। ਜਦੋਂ ਉਦਯੋਗੀ ਨੇੜੇ ਬੈਠੇ ਹੋਂਦੇ ਹਨ, ਤੁਸੀਂ ਮਾਨਿਆਤਮਕ ਫੀਡਬੈਕ ਨਾਲ ਇਟਰੈਟ ਕਰ ਸਕਦੇ ਹੋ ਨਾਂ ਕਿ ਕਲਪਨਾਤਮਕਾਂ ਦੀ ਚਰਚਾ ਕਰਨ।
ਅੰਦਰੂਨੀ ਬੇਨਤੀ ਅਕਸਰ ਅਸਪਸ਼ਟ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: “ਕੀ ਅਸੀਂ ਮਨਜ਼ੂਰੀਆਂ ਆਟੋਮੈਟ ਕਰ ਸਕਦੇ ਹਾਂ?” ਜਾਂ “ਮੈਨੂੰ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਚਾਹੀਦਾ ਹੈ।” ਵਾਇਬ-ਕੋਡਿੰਗ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਨਿੱਕੀ ਵਰਜਨ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਕੇ ਅਸਲ ਵਰਕਫਲੋ ਨੂੰ ਐਕਸਪਲੋਰ ਕਰਦੇ ਹੋ—ਇੱਕ ਸਕਰੀਨ, ਇੱਕ ਰਿਪੋਰਟ, ਇੱਕ ਸਕ੍ਰਿਪਟ—ਫਿਰ ਲੋਕਾਂ ਨੂੰ ਕਿਸੇ ठੋਸ ਚੀਜ਼ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨ ਦਿਓ।
ਇਕ ਲਾਭਕਾਰੀ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਉਪਯੋਗਕਰਤਾ ਦੇ ਇੱਕ ਐਂਡ-ਟੂ-ਐਂਡ ਰਸਤੇ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ:
ਲੰਬਾ ਸਪੈੱਕ ਲਿਖਣ ਦੀ ਬਜਾਏ, ਉਸੇ ਦਿਨ ਇੱਕ ਕਲਿੱਕ ਯੋਗ ਸਕਰੀਨ ਜਾਂ ਇੱਕ ਸਧਾਰਣ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਬੇਨਤੀ ਦਾ ਅਨੁਵਾਦ ਕਰੋ। ਹੱਦ-ਤੱਕ, ਸਖਤ ਡੈਟਾ ਨਾਲ ਬੈਕ ਕੀਤੀ ਇੱਕ "ਫੇਕ" UI ਵੀ ਮੁੱਖ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਲਈ ਕਾਫੀ ਹੁੰਦੀ ਹੈ: ਕਿਹੜੇ ਫੀਲਡ ਲਾਜ਼ਮੀ ਹਨ? ਕੌਣ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ? ਜਦੋਂ ਡੇਟਾ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
ਅੰਦਰੂਨੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹੈਅਰ exceptions ਨਾਲ ਭਰੀ ਹੁੰਦੀਆਂ ਹਨ: ਗਾਇਬ ID, ਡੁਪਲੀਕੇਟ ਰਿਕਾਰਡ, ਮੈਨੇਜਰ ਓਵਰਰਾਈਡ, ਕੰਪਲਾਇੰਸ ਚੈੱਕ। ਇੱਕ ਤੁਰੰਤ ਪ੍ਰੋਟੋਟਾਈਪ ਇਹ ਏਜ ਕੇਸ ਪਹਿਲਾਂ ਹੀ ਸਾਹਮਣੇ ਲਿਆਂਦਾ ਹੈ—ਸਾਥ ਹੀ ਉਹ ਡੇਟਾ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਨਹੀਂ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰੀਆਂ ਜੋ ਤੁਸੀਂ ਭੁੱਲ ਗਏ ਹੋ।
5 ਮਿੰਟ ਦੀ ਡੈਮੋ ਇੱਕ ਘੰਟੇ ਦੀ ਸਹਿਮਤੀ ਦੀ ਬੈਠਕ ਨੂੰ ਹਰਾਵੇਗੀ। ਲੋਕ ਦੱਸਣ ਦੀ ਬਜਾਏ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕੀ ਗਲਤ ਹੈ, ਕੀ ਘਾਟ ਹੈ, ਅਤੇ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਸੀ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਘੱਟ ਸਮਾਂ ਵਿਵਰਣਾਂ ਦੀ ਵਿਆਖਿਆ ਵਿੱਚ ਬਿਤਾਇਆ ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਉਸ ਟੂਲ ਨੂੰ ਆਕਾਰ ਦੇਣ ਵਿੱਚ ਲਗਾਓ ਜੋ ਵਰਤਿਆ ਜਾਵੇਗਾ।
ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਹੁੰਦੇ ਹਨ: ਕੀ ਇਹ ਬਣਾਉਣ ਯੋਗ ਹੈ? ਵਾਇਬ-ਕੋਡਿੰਗ ਇਸ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼, ਵਿਸ਼ਵਾਸਯੋਗ ਪ੍ਰਯੋਗਾਂ ਲਈ ਅਨੁਕੂਲ ਹੈ—ਨਾ ਕਿ ਸੁਤੰਤਰ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ।
ਉਸ ਸਭ ਤੋਂ ਛੋਟੀ ਲੂਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਮੁੱਲ ਸਾਬਤ ਕਰਦੀ ਹੈ: ਇਨਪੁੱਟ → ਪ੍ਰੋਸੈਸਿੰਗ → ਆਉਟਪੁੱਟ। ਜੇ ਟੂਲ ਸਪੋਰਟ ਟਿਕਟਾਂ ਨੂੰ ਸੰਖੇਪ ਕਰਦਾ ਹੈ, ਤਾਂ ਰੋਲਜ਼, ਡੈਸ਼ਬੋਰਡ, ਅਤੇ ਸੈਟਿੰਗਾਂ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਸ਼ੁਰੂ ਕਰੋ: ਇੱਕ ਟਿਕਟ ਪੇਸਟ ਕਰੋ → ਇੱਕ ਸੰਖੇਪ ਮਿਲੇ → ਜਵਾਬ ਵਿੱਚ ਕਾਪੀ ਕਰੋ।
ਇੱਕ ਚੰਗਾ ਪ੍ਰੋਟੋਟਾਈਪ ਅਸਲੀ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਰ ਲੂਪ ਕੰਮ ਕਰਦਾ ਹੈ। ਹੋਰ ਸਭ ਪਤਲੇ ਹੀ ਰਹਿ ਸਕਦੇ ਹਨ।
ਇੰਟਿਗਰੇਸ਼ਨ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪ੍ਰੋਟੋਟਾਈਪ ਅਕਸਰ ਰੁਕਦੇ ਹਨ। ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਮੌਕ ਕਰੋ:
ਜਦੋਂ ਤੁਸੀਂ ਮੁੱਲ ਪ੍ਰਮਾਣਿਤ ਕਰ ਲੈਂਦੇ ਹੋ ਤਾਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਮੌਕਸ ਨੂੰ ਅਸਲ APIs ਨਾਲ ਬਦਲੋ। ਇਹ ਮੋਮੈਂਟਮ ਰੱਖਦਾ ਹੈ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਜਟਿਲਤਾ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਅਪਡੇਟ ਨਾਬਲਗ, ਛੋਟੇ ਅਤੇ ਨਿਰਧਾਰਿਤ ਦਰਸ਼ਕ (5–20 ਲੋਕ) ਨੂੰ ਭੇਜੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣ ਦਿਓ:
ਹਰ ਰਿਲੀਜ਼ ਨੂੰ ਇੱਕ ਟੈਸਟ ਕੀਤੇ ਜਾ ਰਹੇ ਹਾਈਪੋਥੇਸਿਸ ਵਜੋਂ ਸਮਝੋ, ਨਾਂ ਕਿ ਇੱਕ ਮਾਈਲਸਟੋਨ ਵਜੋਂ।
ਸਬੂਤ-ਅਧਾਰਤ ਚੈੱਕਪਾਈਂਟ ਸੈੱਟ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ: “ਘੱਟੋ-ਘੱਟ 60% ਯੂਜ਼ਰ AI ਆਉਟਪੁੱਟ ਨੂੰ ਭਾਰੀ ਸੋਧਾਂ ਤੋਂ ਬਿਨਾਂ ਚੁਣਦੇ ਹਨ” ਜਾਂ “ਇਹ ਹਰ ਟਾਸਕ ਲਈ 5 ਮਿੰਟ ਬਚਾਉਂਦਾ ਹੈ।” ਜੇ ਤੁਸੀਂ ਲੱਕੜੀ ਵਿਚ ਨਿਸ਼ਾਨੇ 'ਤੇ ਖੜੇ ਨਹੀਂ ਹੋ, ਤਾਂ ਵਰਕਫਲੋ ਨੂੰ ਪਿਵਟ ਕਰੋ—ਜਾਂ ਰੋਕ ਦਿਓ। ਪ੍ਰੋਟੋਟਾਈਪ ਸਫਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜੇ ਇਸ ਨੇ ਤੁਹਾਨੂੰ ਗਲਤ ਚੀਜ਼ ਬਨਾਉਣ ਤੋਂ ਬਚਾਇਆ।
ਵਾਇਬ-ਕੋਡਿੰਗ ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨੂੰ ਇੱਕ ਸੀਮਿਤ ਬਣਾ ਕੇ ਦੇਖਦੇ ਹੋ, ਨਾ ਕਿ ਉਦੇਸ਼। ਉਦੇਸ਼ ਤੇਜ਼ ਸਿੱਖਣ ਹੈ—ਇਸਨੇ ਇੰਨੀ ਬਣਤਰ ਹੋਵੇ ਕਿ ਤੁਸੀਂ ਅਸਫਲ ਪ੍ਰਾਂਪਟ ਟਿਊਨਿੰਗ ਅਤੇ ਅੱਧ-ਪੂਰਨ ਫੀਚਰਾਂ ਵਿੱਚ ਖ਼ੋ ਜਾਵੋ।
ਸੰਪਾਦਕ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ:
AI-ਪਹਿਲੇ ਫੀਚਰਾਂ ਲਈ, ਉਦਾਹਰਣ ਅਭਾਸਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਕੁਦਰਤੀ ਹਨ। “ਟਿਕਟਾਂ ਸੰਖੇਪ ਕਰੋ” ਦੇ ਬਜਾਏ, 10 ਅਸਲੀ ਟਿਕਟਾਂ ਅਤੇ ਉਹੀ ਸੰਖੇਪ ਫਾਰਮੈਟ ਦਿੱਤੋ ਜਿਹੜਾ ਤੁਸੀਂ ਸਵੀਕਾਰ ਕਰੋਗੇ।
ਇਸਨੂੰ ਇੱਕ ਪੰਨਾ ਰੱਖੋ। ਸ਼ਾਮਿਲ ਕਰੋ:
ਇਹ ਸਪੈਕ ਤੁਹਾਡਾ ਐਂਕਰ ਬਣ ਜਾਂਦਾ ਹੈ ਜਦ ਮਾਡਲ “ਚੰਗੀਆਂ-ਹੋਣ-ਯੋਗ” ਵਧਾਵਾਂ ਸੁਝਾਏ।
ਰੇਪੋ (ਜਾਂ ਸਾਂਝੇ ਡ੍ਰਾਈਵ) ਵਿੱਚ ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਫੋਲਡਰ ਬਣਾਓ ਜਿਸ ਵਿੱਚ:
ਜਦੋਂ ਤੁਸੀਂ LLM ਨੂੰ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਲਈ ਆਖਦੇ ਹੋ, ਉਦਾਹਰਣਾਂ ਨੂੰ ਇਸ ਫੋਲਡਰ ਤੋਂ ਸਿੱਧਾ ਪੇਸਟ ਕਰੋ। ਇਹ ਅੰਦੇਹੀ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਵਾਇਬ-ਕੋਡਿੰਗ ਬਹੁਤ ਸਾਰੇ ਮਾਈਕ੍ਰੋ-ਫੈਸਲੇ ਬਣਾਉਂਦੀ ਹੈ: ਪ੍ਰਾਂਪਟ ਸ਼ਬਦਾਵਲੀ, ਟੂਲ ਚੋਣ, UI ਫਰੇਜ਼ਿੰਗ, ਫਾਲਬੈਕ ਵਿਵਹਾਰ। ਇੱਕ ਸਧਾਰਨ ਲੌਗ (README ਜਾਂ /docs/decisions.md) ਵਿੱਚ ਕਿਉਂ ਤੁਸੀਂ ਇਹ ਚੁਣਿਆ, ਇਹ ਕੈਪਚਰ ਕਰੋ। ਭਵਿਖ ਦਾ ਤੁਹਾਡਾ-ਆਪ ਅਤੇ ਟੀਮਮੇਟਸ ਦੇ ਜਾਣਨ ਲਈ ਇਹ ਜਰੂਰੀ ਹੈ ਕਿ ਕਿਹੜੇ ਫੈਸਲੇ ਇਰਾਦਨਸਹਿਤ ਬਣਾਏ ਗਏ ਸਨ।
ਜੇ ਤੁਸੀਂ ਸਪੈਕ ਅਤੇ ਫੈਸਲੇ-ਲੌਗ ਲਈ ਇੱਕ ਟੈਮਪਲੇਟ ਚਾਹੁੰਦੇ ਹੋ, ਇਸਨੂੰ ਆਂਦਰੂਨੀ ਤੌਰ 'ਤੇ ਲਿੰਕ ਰੱਖੋ (ਉਦਾਹਰਨ /blog/vibe-coding-templates) ਤਾਂ ਜੋ ਵਰਕਫਲੋ ਪ੍ਰਾਜੈਕਟਾਂ ਵਿੱਚ ਸਥਿਰ ਰਹੇ।
ਜੇ ਤੁਸੀਂ ਟੀਮ ਵਿੱਚ ਬਹੁਤ ਸਾਰਾ ਪ੍ਰਾਂਪਟ-ਸੇ-ਚੈਂਜ ਇਟਰੈਸ਼ਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਕ ਵਿਸ਼ੇਸ਼ ਵਾਇਬ-ਕੋਡਿੰਗ ਪਲੇਟਫਾਰਮ ਰੁਕਾਵਟ ਘਟਾ ਸਕਦਾ ਹੈ: ਤੰਗ ਲੂਪ, ਦੁਹਰਾਉਣਯੋਗ ਦੌੜਾਂ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੋਲਬੈਕ।
ਉਦਾਹਰਨ ਲਈ, Koder.ai ਇੱਕ ਚੈਟ-ਚਲਿਤ ਬਿਲਡ ਵਰਕਫਲੋ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਿਆ ਹੈ: ਤੁਸੀਂ ਫੀਚਰ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, UI ਅਤੇ ਬੈਕਐਂਡ ਤਬਦੀਲੀਆਂ 'ਤੇ ਇਟਰੈਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਜਗ੍ਹਾ ਤੋਂ ਵਰਕ ਪ੍ਰਗਟ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਉਹੀ ਸਕੈਫੋਲਡਿੰਗ ਦੁਹਰਾਉਣ ਦੇ। ਇਹ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, ਅਤੇ ਸਨੇਪਸ਼ਾਟਸ ਨਾਲ ਰੋਲਬੈਕ ਦਾ ਸਮਰਥਨ ਵੀ ਕਰਦਾ ਹੈ—ਜੋ ਉਨ੍ਹਾਂ ਟੀਮਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜ ਰਹੀਆਂ ਹਨ ਪਰ ਫਿਰ ਵੀ ਸੁਰੱਖਿਆ ਜਾਲ ਚਾਹੁੰਦੀ ਹਨ।
AI-ਪਹਿਲੇ ਫੀਚਰ ਉਹਨਾਂ ਸਮੇਂ “ਜਾਦੂਈ” ਲੱਗਦੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੇ ਇੱਕ LLM ਦੇ ਆਲੇ-ਦੁਆਲੇ ਚੰਗੀ ਰੀਤੀ ਨਾਲ ਬਣੇ ਸਿਸਟਮ ਹੋਣ। ਤੇਜ਼ ਟੀਮਾਂ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪੈਟਰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਸਮਝਣਯੋਗ ਅਤੇ ਅੱਪਗਰੇਡ ਕਰਨਯੋਗ ਰੱਖਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤ ਉਹ ਲੂਪ ਡਰਾਇੰਗ ਕਰਕੇ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਫੀਚਰ ਹਰ ਵਾਰੀ ਚਲਾਉਂਦੀ ਹੈ:
ਯੂਜ਼ਰ ਸੁਨੇਹਾ → ਰੀਟ੍ਰੀਵਲ (ਸੰਦਰਭ) → ਟੂਲ ਕਾਲ(ਜ) → ਜਵਾਬ.
ਇਕ ਸਧਾਰਣ ਸਕੈਚ ਵੀ ਚੰਗੇ ਫੈਸਲੇ ਬੰਨ੍ਹਦਾ ਹੈ: ਕਿਹੜਾ ਡੇਟਾ ਲੋੜੀਂਦਾ, ਟੂਲ ਕਦੋਂ ਕਾਲ ਹੋਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਕਿੱਥੇ ਤੁਸੀਂ ਅੰਤਰਿਮ ਨਤੀਜੇ ਸਟੋਰ ਕਰੋਂਗੇ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ "ਪ੍ਰਾਂਪਟ ਕੰਮ" ਹਨ ਅਤੇ ਕਿਹੜੇ "ਸਿਸਟਮ ਕੰਮ"।
ਪ੍ਰਾਂਪਟ ਕਾਪੀਰਾਈਟਿੰਗ ਨਹੀਂ—ਉਹ ਲੋਜਿਕ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨ, ਰਿਵਿਊ, ਅਤੇ ਟੈਸਟ ਰੱਖੋ।
ਵਿਆਵਹਾਰਿਕ ਰਵੱਈਆ ਇਹ ਹੈ ਕਿ ਪ੍ਰਾਂਪਟਜ਼ ਨੂੰ ਆਪਣੇ ਰੇਪੋ ਜਾਂ ਕਿਸੇ কਨਫਿਗ ਸਟੋਰ ਵਿੱਚ ਰੱਖੋ ਸਾਫ ਨਾਂ, ਚੇਂਜਲੌਗ, ਅਤੇ ਛੋਟੇ ਯੂਨਿਟ-ਸਟਾਈਲ ਟੈਸਟਾਂ ਦੇ ਨਾਲ: ਇਨਪੁੱਟ X ਅਤੇ ਸੰਦਰਭ Y ਦੇ ਨਾਲ, ਮਾਡਲ ਨੂੰ ਇਰਾਦਾ Z ਜਾਂ ਟੂਲ ਕਾਲ A ਪ੍ਰੋਡਿਊਸ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਹ ਹੈ ਕਿ ਵਾਇਬ-ਕੋਡਿੰਗ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੀ ਹੈ: ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇٹرੈਟ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਇਹ ਭੁੱਲਣ ਦੇ ਕਿ ਕੀ ਬਦਲਿਆ।
ਅਸਲ ਯੂਜ਼ਰ ਤੁਰੰਤ ਕਿਨਾਰੇ-ਕੇਸ ਤੱਕ ਧਕਾਅ ਦੇਣਗੇ। ਖਾਸ ਵਿਵਹਾਰ ਬਣਾਓ:
ਤੁਸੀਂ ਸਿਰਫ ਖਰਾਬ ਨਤੀਜਿਆਂ ਤੋਂ ਬਚ ਨਹੀਂ ਰਹੇ—ਤੁਸੀਂ ਵਿਸ਼ਵਾਸ ਦੀ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਗੱਲ-ਬਾਤ ਨੂੰ ਉਸੇ ਪ੍ਰਾਪਤ ਸੰਦਰਭ, ਟੂਲ ਆਉਟਪੁੱਟ, ਅਤੇ ਪ੍ਰਾਂਪਟ ਵਰਜਨ ਨਾਲ ਦੁਹਰਾਉਣ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਡਿਬੱਗਿੰਗ ਅਨੁਮਾਨ ਬਣ ਜਾਂਦਾ ਹੈ। ਲੂਪ ਦੇ ਹਰ ਕਦਮ ਨੂੰ ਲੌਗ ਕਰੋ (ਇਨਪੁੱਟ, ਰੀਟ੍ਰੀਵਡ ਡੌਕਸ, ਟੂਲ ਕਾਲ, ਜਵਾਬ) ਅਤੇ ਆਪਣੀ ਟੀਮ ਲਈ "ਰੀ-ਰਨ" ਬਟਨ ਜੋੜੋ। ਇਹ ਅਸਪਸ਼ਟ ਫੀਡਬੈਕ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਫਿਕਸਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਨਾਲ ਸੁਧਾਰ ਮਾਪਣ ਵਿੱਚ ਸਹਾਇਕ ਹੈ।
ਤੇਜ਼ੀ ਵਾਇਬ-ਕੋਡਿੰਗ ਦੀ ਮਕਸਦ ਹੈ—ਪਰ ਗੁਣਵੱਤਾ ਉਹ ਹੈ ਜੋ ਪ੍ਰਯੋਗ ਨੂੰ ਯੂਜ਼ੇਬਲ ਰੱਖਦੀ ਹੈ। ਚਾਲ ਇਹ ਹੈ ਕਿ ਕੁਝ ਹਲਕੇ ਗਾਰਡਰੇਲ ਜੋ ਆਸਾਨੀ ਨਾਲ ਪਛਾਣਯੋਗ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ, ਜੋ ਤੁਹਾਡੇ ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਪੂਰੇ ਸੈਫ-ਇੰਟਰਪ੍ਰਾਈਜ਼ ਬਣਾਉਣ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ “ਅਜੀਬ ਆਉਟਪੁੱਟ” ਨੂੰ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਘਟਨਾਵਾਂ ਬਣਨ ਤੋਂ ਰੋਕਦੇ ਹਨ:
ਇਹ ਗਾਰਡਰੇਲ ਸਸਤੇ ਹਨ ਅਤੇ ਆਮ ਪ੍ਰੋਟੋਟਾਈਪ ਅਸਫਲਤਾਵਾਂ (ਚੁੱਪ-ਚੁੱਪ ਬ੍ਰੇਕ, ਅਨੰਤ ਇੰਤਜ਼ਾਰ, ਅਤੇ ਅਸੰਗਤ ਫਾਰਮੈਟਿੰਗ) ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਵਿਆਪਕ ਆਟੋਮੇਟਿਕ ਟੈਸਟਿੰਗ ਦੀ ਬਜਾਏ, ਇੱਕ ਗੋਲਡਨ ਸੈੱਟ ਬਣਾਓ: 10–30 ਫਿਕਸਡ ਪ੍ਰਾਂਪਟ ਜੋ ਅਸਲੀ ਉਪਯੋਗ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦੇ ਹਨ (ਨਾਲ ਕੁਝ ਵਿਰੋਧੀ ਕੇਸ)। ਹਰ ਪ੍ਰਾਂਪਟ ਲਈ, ਸਹੀ ਪੱਖਵਾਲੀਆਂ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋ ਨਾਂ ਕਿ ਸਹੀ ਲਿਖਤ, ਜਿਵੇਂ:
ਹਰ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ 'ਤੇ ਗੋਲਡਨ ਸੈੱਟ ਚਲਾਓ। ਇਹ ਤੇਜ਼ ਹੈ, ਅਤੇ ਮਨੁੱਖਾਂ ਤੋਂ ਛੁੱਟੀਆਂ ਹੋਈਆਂ ਰੈਗਰੈਸ਼ਨਾਂ ਨੂੰ ਪਕੜਦਾ ਹੈ।
ਪ੍ਰਾਂਪਟ, ਟੂਲ ਪਰਿਭਾਸ਼ਨ, ਅਤੇ ਸੁਰੱਖਿਆ ਨीतੀਆਂ ਨੂੰ ਵਰਜ਼ਨਡ ਅਸੈੱਟਸ ਵਜੋਂ ਟਰੀਟ ਕਰੋ। ਡਿਫਸ ਅਤੇ ਸਧਾਰਨ ਸਮੀਖਿਆ ਨਿਯਮ ਵਰਤੋ (ਭਾਵੇਂ ਇੱਕ ਹਲਕੀ PR ਵਿੱਚ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਸਕੋ: ਕੀ ਬਦਲਿਆ, ਕਿਉਂ, ਅਤੇ ਕੀ ਟੁੱਟ ਸਕਦਾ ਹੈ?
ਉਹ ਲਿਖੋ ਕਿ ਜਦੋਂ ਤੁਸੀਂ “ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ” ਰੋਕ दੋਗੇ, ਉਦਾਹਰਨ ਲਈ: ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਸੰਭਾਲਣਾ, ਭੁਗਤਾਨ ਕਰਨ ਵਾਲੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਪੋਰਟ ਕਰਨਾ, ਉੱਚ ਆਵਾਜ਼ਗੀ, ਜਾਂ ਗੋਲਡਨ-ਸੈੱਟ ਅਸਫਲਤਾਵਾਂ। ਜਦੋਂ ਕੋਈ ਰੁਕਣ ਦੀ ਸ਼ਰਤ ਚਾਲੂ ਹੋਵੇ, ਤਾਂ ਸਮਾਂ ਹੈ ਕਿ ਤੁਸੀਂ ਸਖ਼ਤੀ ਕਰੋ, ਰੀਫੈਕਟਰ ਕਰੋ, ਜਾਂ ਸਕੋਪ ਨਿਸ਼ਾਨਾ ਘਟਾਓ।
ਪ੍ਰੋਟੋਟਾਈਪ ਅਕਸਰ ਤਦ ਤੱਕ ਚੰਗੇ ਮਹਿਸੂਸ ਹੋਂਦੇ ਹਨ ਜਦ ਤੱਕ ਉਹ ਅਸਲੀ ਡੇਟਾ ਨੂੰ ਛੂਹਦੇ ਨਹੀਂ: ਢਿੱਲਾ ਤੀਜੀ-ਪਾਰਟੀ APIs, ਧੀਮੀ ਡੈਟਾਬੇਸ, ਅਸੰਗਤ ਸਕੀਮਾਂ, ਅਤੇ ਪਰਮਿਸ਼ਨ ਸਮੱਸਿਆਵਾਂ। ਤਰਕੀਬ ਇਹ ਹੈ ਕਿ ਇੰਟਿਗਰੇਸ਼ਨਾਂ ਨੂੰ ਪੜਾਅਵਾਰ ਪੈਦਾ ਕਰੋ ਬਿਨਾਂ ਹਰੇਕ ਹਫ਼ਤੇ ਆਪਣੀ ਪੂਰੀ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।
ਮੌਕ API (ਸਥਿਰ JSON, ਲੋਕਲ ਫਿਕਸਚਰ, ਜਾਂ ਇੱਕ ਛੋਟਾ ਸਟਬ ਸਰਵਰ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਡਕਟ ਫਲੋ ਅਤੇ AI ਵਿਵਹਾਰ ਨੂੰ ਪਰਖ ਸਕੋ। ਜਦੋਂ UX ਲਾਭਕਾਰੀ ਸਾਬਤ ਹੋ ਜਾਏ, ਉਹੀ ਇੰਟਰਫੇਸ ਪਿੱਛੇ ਅਸਲੀ ਇੰਟਿਗਰੇਸ਼ਨ ਲਗਾਓ। ਅਸਲ ਟ੍ਰੈਫਿਕ ਅਤੇ ਏਜ ਕੇਸ ਦੇ ਦੇਖਲਏ ਬਾਅਦ ਹੀ ਕਠੋਰ ਕਰਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ: ਰੀਟ੍ਰਾਇਜ਼, ਰੇਟ ਲਿਮਿਟਿੰਗ, ਦਿੱਖਯੋਗਤਾ, ਅਤੇ ਬੈਕਫਿਲ।
ਇਹ ਤੁਹਾਨੂੰ ਸਿੱਖਿਆ ਨੂੰ ਜਲਦੀ ਭੇਜਣ ਦੇ ਯੋਗ ਕਰਦਾ ਹੈ ਅਤੇ "ਇੰਟਿਗਰੇਸ਼ਨ ਕਰ" ਦੇ ਖਰਚ ਨੂੰ ਸਬੂਤ ਦੇ ਅਨੁਪਾਤ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।
ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਅਤੇ ਪ੍ਰੋਟੋਟਾਈਪ ਅਕਸਰ ਇਕ-ਵਾਰੀ ਕਾਲਾਂ ਨਾਲ ਭਰ ਜਾਂਦੇ ਹਨ। ਇਸਦੀ ਥਾਂ, ਹਰ ਸਰਵਿਸ ਲਈ ਇੱਕ ਪਤਲਾ ਰੈਪਰ ਬਣਾਓ (ਜਿਵੇਂ PaymentsClient, CRMClient, VectorStoreClient) ਜੋ ਇੱਕ ਛੋਟਾ, ਸਥਿਰ ਮੈਥਡ ਸੈੱਟ ਇੱਕਸਪੋਜ਼ ਕਰਦਾ ਹੈ।
ਉਹ ਰੈਪਰ ਤੁਹਾਡੇ ਲਈ ਬਦਲਾਅ ਸਥਾਨ ਬਣ ਜਾਂਦਾ ਹੈ:
ਚਾਹੇ ਪ੍ਰੋਟੋਟਾਈਪ ਹੋਵੇ, ਸਕ੍ਰਿਡੈਂਸ਼ੀਅਲ ਸੁਰੱਖਿਅਤ ਰੱਖੋ: ਐਨਵਾਇਰਨਮੈਂਟ ਵੈਰੀਏਬਲਜ਼, ਸਿਕ੍ਰੇਟਸ ਮੈਨੇਜਰ, ਅਤੇ ਨਿਊਨਤਮ-ਅਧਿਕਾਰ API ਕੀਜ਼। ਟੋਕਨਾਂ ਨੂੰ ਰੇਪੋ ਵਿੱਚ ਕਮਿਟ ਨਾ ਕਰੋ, ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪੇਸਟ ਨਾ ਕਰੋ, ਜਾਂ ਕੱਚੇ ਰਿਕਵੇਸਟ ਪੇਲੋਡ ਲੌਗ ਨਾ ਕਰੋ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਗਾਹਕ ਡੇਟਾ ਹੋ ਸਕਦਾ ਹੈ।
AI ਆਉਟਪੁੱਟ ਪ੍ਰਾਂਪਟ ਬਦਲਾਅ, ਮਾਡਲ ਅਪਡੇਟ, ਅਤੇ ਨਵੇਂ ਸੰਦਰਭ ਸਰੋਤਾਂ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ। ਨਵੇਂ AI ਵਿਵਹਾਰ ਨੂੰ ਫੀਚਰ ਫਲੈਗਾਂ ਦੇ ਪਿੱਛੇ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ:
ਫੀਚਰ ਫਲੈਗਾਂ ਜੋਖਮ ਭਰੇ ਬਦਲਾਅ ਨੂੰ ਨਿਯੰਤਰਿਤ ਪ੍ਰਯੋਗਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ—ਵਹੀ ਜੋ ਇਕ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਉਤਪਾਦ ਰਾਹ ਲਈ ਚਾਹੀਦਾ ਹੈ।
ਵਾਇਬ-ਕੋਡਿੰਗ ਮੋਮੈਂਟਮ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀ ਹੈ। ਰੀਫੈਕਟਰ ਲਾਭਦਾਇਕ ਹੈ—ਪਰ ਸਿਰਫ ਜਦੋਂ ਇਹ ਮੋਮੈਂਟਮ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ ਨਾਂ ਕਿ "ਸਫਾਈ ਦਾ ਕੰਮ" ਜਿਸ ਨਾਲ ਨਤੀਜੇ ਨਹੀਂ ਬਦਲਦੇ। ਇੱਕ ਵਧੀਆ ਨਿਯਮ: ਜੇ ਮੌਜੂਦਾ ਢਾਂਚਾ ਤੁਹਾਨੂੰ ਸਿੱਖਣ, ਭੇਜਣ ਅਤੇ ਟੀਮ ਨੂੰ ਸਹਾਇਤਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਛੱਡ ਦਿਓ।
ਵੱਡੇ-ਪੈਮਾਨੇ ਰੀਫੈਕਟਰ ਤੋਂ ਬਚੋ। ਛੋਟੇ, ਨਿਸ਼ਾਨੇਦਾਰ ਸੁਧਾਰ ਕਰੋ ਜਦੋਂ ਕੁਝ ਵਾਸ਼ਤਵ ਵਿੱਚ ਤੁਹਾਨੂੰ ਧੀਮਾ ਕਰ ਰਹਾ ਹੋਵੇ:
ਜਦੋਂ ਤੁਸੀਂ ਰੀਫੈਕਟਰ ਕਰੋ, ਸਕੋਪ ਤੰਗ ਰੱਖੋ: ਇੱਕ ਬੋਟਲਨੈਕ ਸੁਧਾਰੋ, ਭੇਜੋ, ਫਿਰ ਅੱਗੇ ਵਧੋ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਇਹ ਠੀਕ ਹੈ ਕਿ ਪ੍ਰਾਂਪਟ ਟੈਕਸਟ, ਟੂਲ ਪਰਿਭਾਸ਼ਨ, ਅਤੇ UI ਵਾਇਰਿੰਗ ਨੇੜੇ-ਨੇੜੇ ਰਹਿਣ। ਜਦੋਂ ਪੈਟਰਨ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ, ਮੋਡੀਊਲ ਕੱਢੋ:
ਇੱਕ ਕਾਰਗਰ ਸੰਕੇਤ: ਜਦੋਂ ਤੁਸੀਂ ਇੱਕੋ ਹੀ ਲੋਜਿਕ ਦੋ ਵਾਰੀ ਕਾਪੀ ਕੀਤਾ ਹੋਵੇ, ਤਾਂ ਇਹ ਮਾਡਿਊਲ ਬਣਨ ਲਈ ਤਿਆਰ ਹੈ।
AI-ਪਹਿਲੇ ਫੀਚਰ ਅਜਿਹਾ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜੋ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦੇ। ਸ਼ੁਰੂ ਵਿੱਚ ਮੂਲ ਦਿੱਖਯੋਗਤਾ ਜੋੜੋ: ਐਰਰ ਦਰ, ਟੂਲ ਸਫਲਤਾ ਦਰ, ਲੇਟੈਂਸੀ, ਅਤੇ ਪ੍ਰਤੀ ਕਾਰਜ ਲਾਗਤ। ਜੇ ਲਾਗਤ ਚੜ੍ਹਦੀ ਹੈ ਜਾਂ ਟੂਲ ਕਾਲ ਅਕਸਰ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਰੀਫੈਕਟਰ ਟ੍ਰਿੱਗਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਿੱਧਾ ਉਪਯੋਗਤਾ ਅਤੇ ਬਜਟ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦਾ ਹੈ।
ਇੱਕ ਸੰਖੇਪ ਕਰਜ਼ ਸੂਚੀ ਰੱਖੋ ਜਿਸਦਾ ਹਰ ਆਈਟਮ ਲਈ ਸਪਸ਼ਟ ਟ੍ਰਿੱਗਰ ਹੋਵੇ (ਜਿਵੇਂ, “ਤৃতੀਆ ਟੂਲ ਜੋੜਦੇ ਸਮੇਂ ਟੂਲ ਰੂਟਰ ਰੀਫੈਕਟਰ ਕਰੋ” ਜਾਂ "ਦੋ ਲੋਕ ਹਫ਼ਤੇ ਵਿੱਚ ਪ੍ਰਾਂਪਟੋੰ ਨੂੰ ਸੋਧਣ ਤਾਂ ਪ੍ਰਾਂਪਟ-ਇਨ-ਕੋਡ ਨੂੰ ਬਦਲੋ"). ਇਹ ਕਰਜ਼ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਹੁੰਦਾ ਪਰ ਰੋਡਮੈਪ ਨੂੰ ਕਬਜ਼ਾ ਨਹੀਂ ਕਰਨ ਦਿੰਦਾ।
ਵਾਇਬ-ਕੋਡਿੰਗ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੇਜ਼ੀ ਸੁਧਾਰ ਨਾਲ ਲੰਬੀ-ਮਿਆਦ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਜ਼ਿਆਦਾ ਮੁੱਲ ਲੈ ਕੇ ਆਉਂਦੀ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਲਕੜ੍ਹੀ ਖੋਜ ਹੈ। ਜੇ ਕੰਮ ਖੋਜ-ਮੁਖ ਹੈ, ਉਪਯੋਗਤਾ-ਮੁਖ ਪੌਲਿਸ਼ ਦੂਸਰੇ ਨੰਬਰ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕਦੇ-ਕਦੇ ਖਰਾਬ ਕਿਨਾਰੇ-ਕੇਸ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੇ ਹੋ, ਤਾੰ ਤੁਹਾਨੂੰ ਕਾਫੀ ਨਤੀਜੇ ਮਿਲਣਗੇ।
ਅੰਦਰੂਨੀ ਟੂਲ ਆਦਰਸ਼ ਹਨ ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ ਕੌੰਟਰੈਕਟ ਲਚਕੀਲਾ ਹੁੰਦਾ ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ ਛੋਟਾ ਹੁੰਦਾ। ਵਧੀਆ ਉਮੀਦਵਾਰ:
ਇਹ ਜ਼ਰੂਰੀ ਹਨ ਭਾਵੇਂ ਕੋਡ ਸਦੀਵੀ ਨਾ ਰਹੇ:
ਵਾਇਬ-ਕੋਡਿੰਗ ਤੋਂ ਪਰਹੇਜ਼ ਕਰੋ ਜੇ ਗਲਤੀ ਦਾ ਅਸਰ ਵਾਸਤਵ ਵਿੱਚ ਨੁਕਸਾਨ ਜਾਂ ਠੇਕੇ-ਜੋੜੀ ਜੋਖਮ ਬਣਾਉਂਦੀ ਹੈ:
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ:
ਜੇ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਭੇਜ, ਨਿਰੀਖਣ, ਅਤੇ ਵਾਪਸ ਲੈ ਸਕਦੇ ਹੋ, ਤਾਂ ਵਾਇਬ-ਕੋਡਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਫਾਇਦੇਮੰਦ ਰਹਿੰਦੀ ਹੈ।
ਵਾਇਬ-ਕੋਡਿੰਗ AI ਦੀ ਮਦਦ ਨਾਲ ਕੋਡ ਤਿਆਰ ਅਤੇ ਸੋਧਣ ਦਾ ਇੱਕ ਤੇਜ਼, ਇਟਰੈਟਿਵ ਢੰਗ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਸਾਫ ਪ੍ਰੋਡਕਟ ਲਕੜੀ ਰੱਖ ਕੇ AI ਨੂੰ ਦਿਸ਼ਾ ਦਿੰਦੇ ਹੋ।
ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਸਿੱਖਣ (ਕੀ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਕੀ ਕਿਸੇ ਨੂੰ ਇਹ ਚਾਹੀਦਾ ਹੈ?) ਲਈ ਉਤਪਾਦਿਤ ਹੈ, ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਪੂਰਨ ਇੰਪਲੀਮੇੰਟੇਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨਹੀਂ।
ਇੱਕ ਘੱਟੋ-ਘੱਟ ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ:
ਤੁਹਾਨੂੰ ਹਜੇ ਵੀ ਸੋਚ ਅਤੇ ਢਾਂਚਾ ਦੀ ਲੋੜ ਹੈ: ਪਾਬੰਧੀਆਂ, "ਕੰਮ ਕਰਦਾ" ਦੀ ਪਰਿਭਾਸ਼ਾ, ਅਤੇ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਪ੍ਰਮਾਣੀਕਰਨ।
ਵਾਇਬ-ਕੋਡਿੰਗ ਸਪਸ਼ਟੀਕਰਨ ਛੱਡਣ ਦਾ Bahana ਨਹੀਂ ਹੈ; ਬਿਨਾਂ ਸਾਫ ਨਤੀਜੇ ਦੇ, ਮਾਡਲ ਅਕਸਰ ਸੰਭਾਵੀ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਚੀਜ਼ ਬਣਾ ਦੇਵੇਗਾ ਜੋ ਗਲਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੀ ਹੈ।
No-code ਪਲੇਟਫਾਰਮ ਆਪਣੇ ਬਲਾਕਾਂ ਦੇ ਅੰਦਰ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ।
ਵਾਇਬ-ਕੋਡਿੰਗ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਹਕੀਕਤੀ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੇ ਹੋ — APIs, auth, ਇੰਟਿਗਰੇਸ਼ਨਾਂ, ਡੇਟਾ ਮਾਡਲ — ਅਤੇ AI ਤੁਹਾਡੇ ਲਈ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖਣ ਅਤੇ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਲਗਾਉਂਦਾ।
AI-ਪਹਿਲੇ ਫੀਚਰ ਪ੍ਰੋਬੈਬਿਲਿਸਟਿਕ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਿਹੇਵਿਅਰ-ਡਰਿਵਨ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਸੀਂ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਅਸਲੀ ਸਟੇਟਾਂ ਚਲਾਕੀ ਕਰ ਕੇ ਸਿੱਖਦੇ ਹੋ, ਨਾ ਕਿ ਰਿਕ੍ਵਾਇਰਮੈਂਟਸ 'ਤੇ ਚਰਚਾ ਕਰਕੇ।
ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ (ਪ੍ਰਾਂਪਟ ਸ਼ਬਦਾਵਲੀ, temperature, ਮਾਡਲ ਚੋਣ, ਟੂਲ ਕਾਲ) ਨਤੀਜੇ ਜ਼ਿਆਦਾ ਬਦਲ ਸਕਦੇ ਹਨ; ਇਸ ਲਈ ਇਟਰੈਸ਼ਨ ਦੀ ਰਫ਼ਤਾਰ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਇੰਟਰਨਲ ਟੂਲਾਂ ਵਿੱਚ ਫੀਡਬੈਕ ਲੂਪ ਤੰਗ ਹੁੰਦਾ ਹੈ (ਉਪਭੋਗਤਾ ਨੇੜੇ ਹਨ), ਜੋਖਮ ਸੀਮਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਮਾਂ ਬਚਤ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ।
ਇਸ ਕਰਕੇ ਤੂੰ ਇੱਕ ਰਫ਼-ਪਰੰਪਟ ਪਰੰਚਾਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੀ ਫਲੋ ਨੂੰ ਛੇਤੀ ਪੈਦਾ ਕਰ ਕੇ ਡੈਮੋ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਲੰਮੇ ਸਪੈਕਾਂ ਅਤੇ ਮੀਟਿੰਗਾਂ ਦੀ ਬਜਾਏ ਅਸਲ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਅਧਾਰ 'ਤੇ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹੋ।
“ਹੈਪੀ ਪਾਥ” ਏਂਡ-ਟੂ-ਏਂਡ 'ਤੇ ਧਿਆਨ ਦਿਓ: ਇਨਪੁੱਟ → ਪ੍ਰੋਸੈਸਿੰਗ → ਆਉਟਪੁੱਟ।
ਹਰ ਹੋਰ ਚੀਜ਼ ਪਤਲੀ ਰਹੇ, ਅਤੇ ਇੰਟਿਗਰੇਸ਼ਨਾਂ ਲਈ ਮੌਕਸ ਵਰਤੋਂ ਤਾਂ ਜੋ ਪਹਿਲਾਂ ਵਰਕਫਲੋ ਦੀ ਸੰਪੂਰਣਤਾ ਪ੍ਰਮਾਣਿਤ ਕੀਤੀ ਜਾ ਸਕੇ। ਜਦੋਂ ਮੁੱਲ ਸਾਬਤ ਹੋ ਜਾਵੇ, ਮੌਕਸ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਅਸਲੀ APIs ਨਾਲ ਬਦਲੋ।
ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਤੁਰੰਤ ਲਾਭ ਪਾਉਂਦੀਆਂ ਹਨ:
ਇੱਕ ਛੋਟੀ “ਗੋਲਡਨ ਸੈੱਟ” ਟੈਸਟ ਸੂਟ (10–30 ਅਸਲੀ ਕੇਸ) ਜੋ ਹਰ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀ ਤੇ ਦੌੜਾਇਆ ਜਾਵੇ, ਰੈਗਰੈਸ਼ਨ ਪਕੜਨ ਲਈ ਬਹੁਤ ਉਪਯੋਗ ਹੈ।
ਫੇਜ਼ਾਂ: ਮੌਕ → ਅਸਲੀ → ਹਾਰਡਨਡ।
ਹਰ ਬਾਹਰੀ ਸਰਵਿਸ ਲਈ ਇੱਕ ਪਤਲਾ ਰੈਪਰ ਬਣਾਓ (ਉਦਾਹਰਣ ਲਈ PaymentsClient, CRMClient, VectorStoreClient) ਤਾਂ ਜੋ ਤੁਸੀਂ ਮੌਕ ਤੋਂ ਅਸਲੀ, ਕੈਸ਼ਿੰਗ/ਰੀਟ੍ਰਾਇਜ਼, ਅਤੇ ਡੇਟਾ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਬਿਨਾਂ ਬਹੁਤ ਵਿਆਪਕ ਪੁਨਰਲਿਖਾਈ ਦੇ ਜੋੜ ਸਕੋ।
ਵੱਡੇ ਰੀਫੈਕਟਰਿੰਗ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਇਹ ਤੁਹਾਡੇ ਗਤੀਵਿਧੀ ਨੂੰ ਬੰਦ ਨਾ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਰੀਫੈਕਟਰ ਉਸ ਵੇਲੇ ਕਰੋ ਜਦੋਂ:
ਜੇ ਕੋਈ ਲਾਜ਼ਮੀ ਲਾਜ਼ਮੀ ਤੱਤ ਦੋ ਵਾਰੀ ਨਕਲ ਹੋ ਗਿਆ ਹੋਵੇ, ਉਹ ਨੂੰ ਮੋਡੀਊਲ ਵਜੋਂ ਕੱਢੋ (prompt ਲਾਇਬ੍ਰੇਰੀ, ਟੂਲ ਲੇਅਰ, UI ਕੰਪੋਨੈਂਟ)।
ਉੱਚ-ਲਾਭ, ਘੱਟ-ਜੋਖਮ ਸੰਦਾਂ ਲਈ ਵਾਇਬ-ਕੋਡਿੰਗ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ—ਜਿੱਥੇ ਗਤੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਆਈਡੀਲੇਆਰਵਾਲ ਕੰਮ ਜ਼ਿਆਦਾ ਨਹੀਂ।
ਖਾਸ ਤੌਰ 'ਤੇ ਉਚਿਤ ਉਮੀਦਾਂ ਹਨ:
ਪਰ ਐਸੇ ਪ੍ਰਾਜੈਕਟਾਂ ਲਈ ਇਹ ਵਰਤੋਂ ਤੋਂ ਬਚੋ ਜਿੱਥੇ ਗਲਤੀ ਮਹਿੰਗੀ ਪੈ ਸਕਦੀ ਹੈ: ਹੇਲਥ ਕੇਅਰ, ਫਾਇਨੈਨਸ, ਬਿਲਿੰਗ/ਆਥ, ਉੱਚ-ਅਪਟਾਈਮ ਕੋਰ ਸਿਸਟਮ, ਜਾਂ ਕੰਟਰੈਕਟੂਅਲ ਆਡਿਟ ਮੰਗਾਂ ਵਰਗੇ।
ਅਕਸਰ ਗਲਤੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਸਧਾਰਣ ਫਿਕਸਾਂ:
ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ ਇੱਕ ਟੀਮ ਲਈ ਇੱਕ ਤੰਗ ਫੀਡਬੈਕ ਲੂਪ ਬਣਾਉਣ ਲਈ ਇੱਕ 30-ਦਿਨ ਯੋਜਨਾ:
ਹਫ਼ਤਾ 1: ਇੱਕ ਵਰਕਫਲੋ ਚੁਣੋ, ਸਫਲਤਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਡੈਮੋ ਬਣਾਓ
ਹਫ਼ਤਾ 2: ਲਾਗਿੰਗ, ਟੈਸਟ ਸੈੱਟ, ਅਤੇ ਮੂਲ ਗਾਰਡਰੇਲ ਜੋੜੋ
ਹਫ਼ਤਾ 3: ਇੱਕ ਅਸਲੀ ਡੇਟਾ ਸੋర్స్ ਨਾਲ ਜੁੜੋ ਅਤੇ 5–15 ਅੰਦਰੂਨੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਰਿਲੀਜ਼ ਕਰੋ
ਹਫ਼ਤਾ 4: ਫੈਸਲਾ ਕਰੋ—ਪ੍ਰੋਡਕਸ਼ਨਾਈਜ਼, ਸੀਮਾ ਵਧਾਓ, ਜਾਂ ਰੋਕੋ—ਅਤੇ ਦੱਸੋ ਕੀ ਸਿੱਖਿਆ ਮਿਲੀ।
