ਪਤਾ ਕਰੋ ਕਿ ਕਿਵੇਂ ਸੂਝਬੂਝ (taste) ਅਤੇ ਫੈਸਲਾ ਕਰਨ ਦੀ ਸਮਰੱਥਾ (judgment) “vibe coding” ਨੂੰ ਰੂਪ ਦਿੰਦੇ ਹਨ, ਕਿਉਂ ਸ਼ੁਰੂਆਤੀ ਗਤੀ ਸੋਫਟਵੇਅਰ ਦੀ ਸੁੰਦਰਤਾ ਤੋਂ ਪਹਿਲਾਂ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਗਾਰਡਰੇਲ ਇਸ ਗਤੀ ਨੂੰ ਬੇਰকেਬਲ ਰੱਖ ਸਕਦੇ ਹਨ।
“Vibe coding” ਮਤਲਬ ਹੈ ਅਨੁਭਵ ਦੇ ਆਧਾਰ ਤੇ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣਾ—ਤੇਜ਼ ਫੀਡਬੈਕ, ਅੰਦਰੂਨੀ ਭਾਵਨਾ ਅਤੇ ਗਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੰਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਉਪਭੋਗੀਆਂ ਦੇ ਸਾਹਮਣੇ ਲਿਆਉਣਾ। ਇਹ ਉਹ ਰੁਝਾਨ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪਰਫੈਕਟ ਆਰਕੀਟੈਕਚਰ ਦੀ ਲੰਮੇ ਚਰਚਾ ਛੱਡ ਦੇ ਹੋ ਅਤੇ ਇਸ ਦੀ ਥਾਂ ਪੁੱਛਦੇ ਹੋ: ਕੀ ਅਸੀਂ ਸ਼ੁੱਕਰਵਾਰ ਤੱਕ ਇੱਕ ਛੋਟੀ, ਉਪਯੋਗੀ ਵਰਜਨ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਲੋਕ ਇਸ ਨਾਲ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ?
ਇਹ ਤਰੀਕਾ ਬੇਤਰਤੀਬੀ ਜਾਂ ਲਾਪਰਵਾਹੀ ਨਹੀਂ ਹੈ। ਇਹ ਸਿੱਖਣ ਦੀ ਰਫ਼ਤਾਰ 'ਤੇ ਧਿਆਨ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਤਬਦੀਲੀ ਕਰਦੇ ਹੋ, ਵੇਖਦੇ ਹੋ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ (ਸਪੋਰਟ ਟਿਕਟ, ਵਰਤੋਂ, churn, ਗੁਣਾਤਮਕ ਫੀਡਬੈਕ), ਅਤੇ ਫਿਰ ਢਲਦੇ ਹੋ। “Vibe” ਉਸ ਘੱਟ ਸਮੇਂ ਦੇ ਲੂਪ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਬਣਾਉਣ ਅਤੇ ਹਕੀਕਤ ਵਿਚਕਾਰ ਹੁੰਦਾ ਹੈ।
ਦੋ ਹੁਨਰ ਇਸ ਲੂਪ ਨੂੰ ਉਤਪਾਦਕ ਬਣਾ ਕੇ ਰੱਖਦੇ ਹਨ ਨਾ ਕਿ ਗੜਬੜੀ:
Vibe coding ਕੋਈ ਕੁਆਲਟੀ-ਵਿਰੋਧੀ ਦਲੀਲ ਨਹੀਂ ਹੈ। ਇਹ ਸ਼ੁਰੂਆਤੀ ਮੰਚ ਲਈ ਇੱਕ ਰਣਨੀਤੀ ਹੈ: ਪਹਿਲਾਂ ਵੈਧਿਤ ਮੁੱਲ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਫਿਰ ਸਾਫ਼-ਸਫਾਈ ਕਰਨ ਦਾ ਹੱਕ ਜਿੱਤੋ।
ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਡਕਟ ਦਾ ਕੰਮ ਅਕਸਰ ਸਿੱਖਣ ਬਾਰੇ ਹੁੰਦਾ ਹੈ, ਨਾਂ ਕਿ ਸੁੰਦਰਤਾ ਬਾਰੇ। ਤੁਹਾਡਾ ਲਕਸ਼੍ਹ ਫਰਮਾਪ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਇਕ ਪਰਫੈਕਟ ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦੇ—ਸਗੋਂ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਹੈ ਕਿ ਉਪਭੋਗੀ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੁੰਦੇ ਹਨ, ਉਹ ਕੀ ਭੁਗਤਣਗੇ, ਅਤੇ ਕਿਹੜੇ ਅਨੁਮਾਨ ਗਲਤ ਹਨ। “ਚੰਗੀ ਵਾਈਬ” ਇੱਥੇ ਮਤਲਬ ਗਤੀ ਹੈ: ਇੱਕ ਟੀਮ ਜੋ ਵਿਚਾਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੱਚੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ, ਉਹ ਲੋਕਾਂ ਦੇ ਸਾਹਮਣੇ ਰੱਖ ਸਕਦੀ ਹੈ, ਅਤੇ ਬਿਨਾਂ ਫਸੇ ਦੁਹਰਾਉਣਾ ਜਾਰੀ ਰੱਖਦੀ ਹੈ।
ਸਾਫ਼ ਕੋਡ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਆਸਾਨ ਹੈ ਜਿੱਥੇ ਲੋੜਾਂ ਥਿਰ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ, ਉਹਨਾਂ ਦਾ ਸਥਿਰ ਨਾ ਹੋਣਾ ਆਮ ਗੱਲ ਹੈ। ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ “ਸਧਾਰਨ ਓਨਬੋਡਿੰਗ ਫਲੋ” ਬਣਾ ਰਹੇ ਹੋ, ਫਿਰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਤੁਸੀਂ ਇਕ ਟਰਸਟ-ਬਿਲਡਿੰਗ ਲੜੀ, ਕੀਮਤ-ਵਿਆਖਿਆਕ, ਜਾਂ ਪਰਮੀਸ਼ਨ ਸਿਸਟਮ ਅਦਾ ਕਰ ਰਹੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਵਰਜਨ ਇੱਕ ਲਈ ਦੋ ਹਫ਼ਤੇ ਬਿਤਾ ਕੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਬਿਖੇਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ ਨੁੰ ਸ਼ੀਨਿਆਰ ਕਰ ਸਕਦੇ ਹੋ—ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਬਣ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਗੰਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਜੋ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ (“ਕੀ ਉਪਭੋਗੀ ਇਸ ਮੁੱਲ ਨੂੰ ਸਮਝਦੇ ਹਨ?”) ਅਕਸਰ ਉਸ ਸੁੰਦਰ ਇੰਜੀਨੀਅਰ ਕੀਤੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਜੋ ਗਲਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੀ ਹੈ।
ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨਾ ਸਿਰਫ਼ ਤੇਜ਼ੀ ਲੈਣ ਲਈ ਨਹੀਂ ਹੈ। ਗਤੀ ਆਕਰਸ਼ਿਤ ਕਰਦੀ ਹੈ:
ਜਦੋਂ ਇੱਕ ਟੀਮ ਚੱਲ ਰਹੀ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋ ਕਿ ਕੀ ਗੁੰਝਲਦਾਰ ਹੈ, ਕੀ ਘੱਟ ਹੈ, ਕੀ ਫਾਲਤੂ ਹੈ, ਅਤੇ ਉਪਭੋਗੀ ਕਿਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ। ਇਹੀ ਸਿੱਖਣ ਬਾਅਦ ਵਿੱਚ ਚੰਗੇ ਇੰਜੀਨੀਅਰਿੰਗ ਫੈਸਲਿਆਂ ਨੂੰ ਮਾਰਗਦਰਸ਼ਨ ਕਰਦੀ ਹੈ।
ਅਤਿ-ਪੋਲਿਸ਼ ਸਿਰਫ਼ ਫਜੂਲ ਮਿਹਨਤ ਨਹੀਂ ਹੈ; ਇਹ ਸਚਮੁਚ ਨੁਕਸਾਨਦਾਇਕ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਸੰਰਚਨਾ (ਗਹਿਰੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ, ਪੂਰਨ ਨਾਮਕਰਨ ਯੋਜਨਾ, ਇੱਕ ਜਨਰਲਾਈਜ਼ਡ ਸਿਸਟਮ) 'ਤੇ ਭਾਰੀ ਨਿਵੇਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬਦਲਾਅ ਦੇ ਖਿਲਾਫ਼ ਘਰ੍ਹਾ ਪੈਦਾ ਕਰ ਦਿੰਦੇ ਹੋ। ਲੋਕ ਇਸਨੂੰ ਸੋਧਣ ਤੋਂ ਕਤਰਾਉਂਦੇ ਹਨ ਜਾਂ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਉਤਪਾਦ ਨੂੰ ਕੁਝ ਹੋਰ ਚਾਹੀਦਾ ਹੋਵੇ।
ਚੰਗੀਆਂ ਵਾਈਬਜ਼ ਤੁਹਾਨੂੰ ਅਨੁਕੂਲ ਬਣਾਕੇ ਰੱਖਦੀਆਂ ਹਨ। ਇਹ ਕਹਿਣਾ “ਇਹ ਅਸਥਾਈ ਹੈ” ਸੋਸ਼ਲ ਤੌਰ 'ਤੇ ਸਹੀ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਅਸਲ ਸਮੱਸਿਆ ਜਾਣ ਲੈਂਦੇ ਹੋ ਤਾਂ ਇਸਨੂੰ ਬਦਲਣਾ ਵੀ ਅਸਾਨ ਹੁੰਦਾ ਹੈ।
Vibe coding ਲਾਪਰਵਾਹ ਹੋਣ ਦੀ ਛੂਟ ਨਹੀਂ ਦਿੰਦਾ। ਇਹ ਇੱਕ ਰਣਨੀਤੀ ਹੈ: ਉਲਟ-ਰਫਤਾਰ ਨਾਲ ਅਜਿਹੇ ਛੋਟੇ ਰਸਤੇ ਚੁਣੋ ਜੋ ਵਾਪਸ ਉਲਟ ਕੀਤੇ ਜਾ ਸਕਣ ਅਤੇ ਨਜ਼ਰ ਵਿੱਚ ਹੋਣ।
ਉਦਾਹਰਣ ਵਜੋਂ, ਮੰਗ ਦੀ ਜਾਂਚ ਲਈ ਇੱਕ ਵਰਕਫਲੋ ਨੂੰ ਹਾਰਡ-ਕੋਡ ਕਰਨਾ, ਇੱਕ ਜਟਿਲ ਮਾਡਲ ਦੀ ਥਾਂ ਸਧਾਰਨ ਟੇਬਲ ਵਰਤਣਾ, ਜਾਂ ਮੁੜ-ਉਪਯੋਗੀ ਪੈਟਰਨ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਿੱਧਾ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਲਿਖਣਾ।
ਮੁੱਖ ਚੀਜ ਮਨੋਰਥ ਹੈ: ਤੁਸੀਂ ਕੁਆਲਟੀ ਤੋਂ ਬਚ ਰਹੇ ਨਹੀਂ ਹੋ—ਤੁਸੀਂ ਇਸਨੂੰ ਮੁੜ-ਔਣ ਦਾ ਹੱਕ ਬਾਅਦ ਵਿੱਚ ਰੱਖ ਰਹੇ ਹੋ।
Vibe coding ਗਤੀ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ, ਪਰ ਦਿਸ਼ਾ ਤੋਂ ਬਿਨਾ ਗਤੀ ਸਿਰਫ਼ ਚਲਨਾ ਹੈ। ਉਹ ਦੋ ਹੁਨਰ ਜੋ “ਵਾਈਬਜ਼” ਨੂੰ ਉਤਪਾਦਕ ਰੱਖਦੇ ਹਨ ਉਹ ਹਨ ਸੂਝਬੂਝ (taste) ਅਤੇ ਫੈਸਲਾ ਕਰਨ ਦੀ ਸਮਰੱਥਾ (judgment)—ਅਤੇ ਇਹ ਇਕੋ ਨਹੀਂ ਹਨ।
ਸੂਝਬੂਝ ਤੁਹਾਡੀ ਉਹ ਸਮਰੱਥਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸادہ ਹੱਲ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਜੋ ਉਪਭੋਗੀ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ "ਸਹੀ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਹ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਘੱਟ ਅਤੇ ਅਨੁਭਵ ਤੋਂ ਜ਼ਿਆਦਾ ਸਬੰਧਿਤ ਹੈ: ਉਪਭੋਗੀ ਕੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਉਹ ਕੀ ਮਾਫ਼ ਕਰ ਦੇਵੇਗਾ, ਅਤੇ ਉਹ ਤੁਰੰਤ ਕੀ ਨੋਟਿਸ ਕਰੇਗਾ।
ਸੂਝਬੂਝ ਨਾਲ ਤੁਸੀਂ ਇਹ ਫੈਸਲੇ ਕਰ ਸਕਦੇ ਹੋ:
ਸੂਝਬੂਝ ਜਨਮਜਾਤ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਅਸਲੀ ਵਰਤੋਂ ਨੂੰ ਦੇਖ ਕੇ, ਕੰਮ ਕਰਨ ਵਾਲੇ ਪੈਟਰਨ ਨਕਲ ਕਰਕੇ, ਅਤੇ “ਇਹ friction ਅਪਣਾਹੀ ਨੂੰ ਮਾਰਦਾ ਹੈ” ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਦੀ ਅੰਤਰ-ਯਾਦاشت ਬਣਾਕੇ ਸਿੱਖੀ ਜਾਂਦੀ ਹੈ।
ਫੈਸਲਾ ਇਹ ਨੀਰਣਾ ਹੈ ਕਿ ਜਦ ਤੁਹਾਨੂੰ ਸਭ ਜਵਾਬ ਨਹੀਂ ਪਤਾ, ਤੁਸੀਂ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰੋਗੇ। ਇਹ ਗਤੀ ਬਨਾਮ ਖਤਰੇ, ਤੁਰੰਤ ਹੈਕਸ ਬਨਾਮ ਲੰਬੇ ਸਮੇਂ ਦੀ ਰਖ-ਰਖਾਵ, ਅਤੇ ਪ੍ਰਯੋਗ ਬਨਾਮ ਭਰੋਸੇਯੋਗਤਾ ਵਿਚਕਾਰ ਤਜਵੀਜ਼ ਕਰਨ ਦੀ ਹੁਨਰ ਹੈ।
ਚੰਗਾ ਫੈਸਲਾ ਕਹਿੰਦਾ ਹੈ, “ਇੱਥੇ ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹਾਂ ਕਿਉਂਕਿ blast radius ਛੋਟਾ ਹੈ,” ਜਾਂ “ਇਹ ਖੇਤਰ ਬਿਲਿੰਗ/ਸੁਰੱਖਿਆ ਛੂਹਦਾ ਹੈ—ਧੀਮੇ ਹੋ ਕੇ ਧਿਆਨ ਨਾਲ ਕਰੋ।”
ਇੱਕ ਮਦਦਗਾਰ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ “ਰਿਵਰਸੇਬਲ ਵਿਰੁੱਧ ਮੁਸ਼ਕਲ-ਉਲਟ” ਫੈਸਲੇ:
ਜਦੋਂ ਸੂਝਬੂਝ ਅਤੇ ਫੈਸਲਾ ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ vibe coding ਇਰਾਦਾ ਨਾਲ ਹੋ ਜਾਂਦੀ ਹੈ: ਤੁਸੀਂ ਸਭ ਤੋਂ ਛੋਟੀ ਚੀਜ਼ ਦਿੰਦੇ ਹੋ ਜੋ ਉਪਭੋਗੀ ਨੂੰ ਪਸੰਦ ਆਉਂਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਜਾਨ-ਬੁਝ ਕੇ ਦਰਜਾ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਭਵਿੱਖ ਦਾ ਕੀ ਧਾਰਿਆਂ ਕਰ ਰਹੇ ਹੋ—ਅਤੇ ਕਿਉਂ।
ਸੂਝਬੂਝ ਉਹ ਸਮਰੱਥਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਜੁਝਾਰੂ ਨੂੰ ਸਹੀ ਚੀਜ਼ 'ਤੇ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ। vibe coding ਵਿੱਚ, ਇਹ ਅਕਸਰ ਇੱਕ ਉਪਭੋਗੀ ਨਤੀਜੇ ਲਈ ਅਨੁਕੂਲ ਹੁੰਦਾ ਹੈ ਜੋ ਮਹਿਸੂਸ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ: “ਮੈਂ ਝੱਟ ਮੁੱਲ ਲੈ ਲਿਆ,” “ਮੈਨੂੰ ਇਸ 'ਤੇ ਭਰੋਸਾ ਹੋ ਗਿਆ,” “ਇਹ ਸਮਝ ਆਉਂਦਾ ਹੈ,” ਭਾਵੇਂ ਅੰਦਰੂਨੀ ਹਿੱਸੇ ਗੁੰਝਲਦਾਰ ਹੋਣ।
ਟੇਬਲਾਂ, ਸਰਵਿਸਾਂ ਜਾਂ ਕੰਪੋਨੇਟ ਹੈਰੇਰਕੀ ਖਾਕਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰਯੋਗਕਰਤਾ ਜੋ ਨਤੀਜਾ ਚਾਹੁੰਦਾ ਹੈ ਉਸਨੂੰ ਸਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਨਾਮ ਦਿਓ।
ਇੱਕ ਛੋਟਾ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਇਹ ਫੀਚਰ ਹਟਾਉਂਦੇ ਹੋ ਤਾਂ ਕਿਹੜਾ ਉਪਭੋਗੀ ਮੁੱਦਾ ਤੁਰੰਤ ਵਾਪਸ ਆਵੇਗਾ? ਜੇ ਤੁਸੀਂ ਇਸਦਾ ਸਪੱਸ਼ਟ ਜਵਾਬ ਨਾ ਦੇ ਸਕੋ ਤਾਂ ਤੁਸੀਂ ਆਪਣੇ ਲਈ vibe ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ—ਉਨ੍ਹਾਂ ਲਈ ਮੁੱਲ ਨਹੀਂ।
“ਇਹ ਕਿਉਂ ਮੌਜੂਦ ਹੈ?” ਇੱਕ ਕਦਮ ਹੋਰ ਪੁੱਛੋ।
ਬਹੁਤ ਵਧੀਆ—ਤਾਂ ਫੀਚਰ “ਸੂਚਨਾਵਾਂ” ਨਹੀਂ, “ਕੋਈ ਡੈਡਲਾਈਨ ਮਿਸ ਨਾ ਹੋਵੇ” ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਦੈਨੀਕ ਡੈਜੈਸਟ, ਕੈਲੰਡਰ ਸਿੰਕ ਜਾਂ ਇੱਕ-ਕ੍ਰਿਆ-ਵਿਚ ਸੂਚਨਾ ਹੋ ਸਕਦੀ ਹੈ।
ਸੂਝਬੂਝ ਇਹ ਸਿੱਖਾਉਂਦੀ ਹੈ ਕਿ ਜੋ ਸੱਚਾ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ ਉਹ ਸਧਾਰਨ ਚੀਜ਼ ਚੁਣੋ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਉਪਭੋਗੀ ਫਲੋਜ਼ ਦਾ ਤਜਰਬਾ ਕਰਦੇ ਹਨ, ਫ੍ਰੇਮਵਰਕ ਨਹੀਂ। ਸੂਝਬੂਝ ਦਾ ਮਤਲਬ ਹੈ ਖੁਸ਼ਪੂਰਕ ਰਸਤੇ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਣਾ:
ਜੇ ਕੋਈ ਅਬਸਟ੍ਰੈਕਸ਼ਨ UI ਜਾਂ ਵਿਵਹਾਰ ਨੂੰ ਸਮਝਾਉਣਾ ਮੁਸ਼ਕਲ ਕਰਦੀ ਹੈ, ਤਾਂ ਸ਼ਾਇਦ ਇਹ ਬਹੁਤ ਜਲਦੀ ਹੈ।
Vibes ਸਿਰਫ਼ ਦਰਸ਼ਨ ਨਹੀਂ—ਉਹ ਕਾਪੀ, ਏਰਰ ਸੁਨੇਹੇ, ਲੋਡਿੰਗ ਸਥਿਤੀਆਂ ਅਤੇ ਏਜ-ਕੇਸ ਵਿਵਹਾਰ ਵੀ ਹੁੰਦੇ ਹਨ। ਇਕ ਇਕਸਾਰ ਆਵਾਜ਼ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ: ਉਤਪਾਦ ਇਰਾਦੇ ਨਾਲ ਬਣਿਆ ਲੱਗਦਾ ਹੈ, ਭਾਵੇਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਤ ਹੋ ਰਿਹਾ ਹੋਵੇ।
ਵਿਕਲਪ ਤਰੱਕੀ ਜਾਪਦੇ ਹਨ ਪਰ ਅਕਸਰ ਸੰਦੇਹ ਨੂੰ ਛੁਪਾਉਂਦੇ ਹਨ। ਸੈਟਿੰਗਾਂ, ਟੀਅਰਾਂ ਅਤੇ ਟੌਗਲਾਂ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਥਾਂ, ਇੱਕ ਮਜ਼ਬੂਤ, ਨਿਰਧਾਰਤ ਰਸਤਾ ਸ਼ਿਪ ਕਰੋ, ਵਰਤੋਂ ਤੋਂ ਸਿੱਖੋ, ਫਿਰ ਜਦੋਂ ਅਸਲੀ ਮੰਗ ਸਾਹਮਣੇ ਆਏ ਤਾਂ ਵਧਾਓ।
ਜੱਜਮੈਂਟ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਾਫੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੁੰਦੀ—ਅਤੇ ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਮਕਸਦ ਕੁਆਲਟੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਨਹੀਂ ਹੈ; ਇਹ ਉਸ ਅਨਿਸ਼ਚਿਤਤਾ 'ਤੇ ਆਪਣੇ ਸੀਮਤ ਸਮੇਂ ਨੂੰ ਲਗਾਉਣਾ ਹੈ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਮੈਟਰ ਕਰਦੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਯਕੀਨ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਉਪਭੋਗੀ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਨਗੇ, ਸਾਰਾ ਸਿਸਟਮ ਨਾ ਬਣਾਉ—ਇਕ ਹਲਕਾ-ਫੇਲ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ ਜੋ ਸਭ ਤੋਂ ਜੋਖ਼ਮ ਭਰ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਦੇਵੇ:
ਇੱਕ ਝਟਪਟ ਫਲੋ ਜੋ ਅਸਲ ਫੀਡਬੈਕ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਇਕ ਸੁਰਖ਼ੀ ਪ੍ਰਸੰਸਿਤ ਫੀਚਰ ਤੋਂ ਬਿਹਤਰ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਵਰਤਿਆ ਹੀ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਚੋਣ ਚੁਣੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਬਦਲੀ ਜਾ ਸਕੇ: ਸਧਾਰਨ ਡੇਟਾ ਮਾਡਲ, ਇੱਕ ਮੂਲ ਕਤਾਰ, ਇੱਕ ਸਿੰਪਲ ਇੰਟੈਗਰੇਸ਼ਨ।
“ਮੁਸ਼ਕਲ-ਉਲਟ” ਵਚਨਾਂ—ਜਟਿਲ ਪਰਮੀਸ਼ਨ, ਮਲਟੀ-ਟੇਨੈਂਟ ਸਕੀਮਾ, ਭਾਰੀਆਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨ—ਨੂੰ ਉਸ ਵੇਲੇ ਰਾਖੋ ਜਦੋਂ ਤੁਸੀਂ ਵਰਤੋਂ ਨਾਲ ਉਹਨਾਂ ਦਾ ਹੱਕ ਜਿੱਤ ਲਓ।
ਉਪਭੋਗੀ ਬਹੁਤ ਵਾਰ ਵੱਧ ਸੈਟਿੰਗਾਂ ਨਹੀਂ ਚਾਹੁੰਦੇ; ਉਹ ਘੱਟ ਫੈਸਲੇ ਚਾਹੁੰਦੇ ਹਨ।
ਸਮਝਦਾਰ ਡਿਫੌਲਟ ਚੁਣੋ (ਆਟੋ-ਭਰੇ ਹੋਏ ਮੁੱਲ, ਇਕ-ਕਲਿਕ ਓਨਬੋਡਿੰਗ, ਇਕ-ਸੁਝਾਅ ਰਸਤਾ). ਫਿਰ ਉਤਪਾਦ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਣ ਲਈ ਪਾਬੰਦੀਆਂ ਲਗਾਓ: ਘੱਟ ਮੋਡ, ਘੱਟ ਟੌਗਲ, ਘੱਟ “ਅਡਵਾਂਸਡ” ਖੰਡ। ਪਾਬੰਦੀਆਂ ਸੂਝਬੂਝ ਵਰਗੀਆਂ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਫਲੈਟ-ਏਰੀਆ, ਬਢੀਆ ਬੱਗ ਅਤੇ ਸਹਾਇਤਾ ਲਾਗਤ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨਾ “ਹਰ ਚੀਜ਼ ਸ਼ਿਪ ਕਰੋ” ਨਹੀਂ ਹੈ। ਇਹ ਉਸ ਵੇਲੇ ਸ਼ਿਪ ਕਰਨਾ ਹੈ ਜਦੋਂ ਕੋਰ ਲੂਪ ਕੰਮ ਕਰਦਾ ਹੋਵੇ। ਜੇ ਉਪਭੋਗੀ ਨਿਰੰਤਰ:
ਤਾਂ ਤੁਹਾਨੂੰ ਸਫਾਈ ਜਾਂ ਵਿਸਥਾਰ ਕਰਨ ਦੀ ਵਜਹ ਮਿਲ ਗਈ ਹੈ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਤਕਨੀਕੀ ਕਰਜ਼ ਇਕ ਜਾਣ-ਪਛਾਣ ਰੀਫੈਕਟਰਿੰਗ ਰਣਨੀਤੀ ਹੋ ਸਕਦਾ ਹੈ—ਇੱਕ IOU ਜਿਸਦੀ ਇੱਕ ਸਪੱਸ਼ਟ ਵਜ੍ਹ ਹੈ ਅਤੇ ਇੱਕ ਮਿਆਦ ਹੈ।
“ਵਾਈਬਜ਼ ਵਿਰੁੱਧ ਸਾਫ਼-ਸੁਥਰਾ” ਦਾ ਮਕਸਦ ਢਿੱਲਾ ਹੋਣਾ ਨਹੀਂ—ਇਹ ਉਹ ਜਗ੍ਹਾ ਚੁਣਨਾ ਹੈ ਜਿੱਥੇ ਤੇਜ਼ੀ ਸਿੱਖਣ ਖਰੀਦਦੀ ਹੈ, ਅਤੇ ਉਹ ਜਗ੍ਹਾ ਜਿੱਥੇ ਸਖ਼ਤੀ ਭਰੋਸਾ ਬਚਾਈਏ।
ਇੱਕ ਫਾਉਂਡਰ ਨੇ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ “ਟੀਮ ਟਿੱਪਣੀਆਂ” ਜੋੜਣ ਦੀ ਚਾਹ ਕੀਤੀ। ਸਾਫ਼ ਸੰਸਕਰਨ ਵਿੱਚ ਪਰਮੀਸ਼ਨ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਥ੍ਰੈਡਿੰਗ ਅਤੇ ਪੋਲਿਸ਼ਡ ਐਡੀਟਰ ਸ਼ਾਮਲ ਹੁੰਦੇ।
ਬਦਲੇ ਵਿੱਚ, ਉਹਨਾਂ ਨੇ ਇੱਕ ਸਧਾਰਨ ਟਿੱਪਣੀ ਬਾਕਸ ਸ਼ਿਪ ਕੀਤਾ: ਪLAIN ਟੈਕਸਟ, ਕੋਈ @mentions, ਕੋਈ reactions ਨਹੀਂ, ਘੱਟ ਸਟਾਈਲਿੰਗ। ਇਹ UI ਦੇ ਨਾਲ ਥੋੜ੍ਹਾ ਅਜੀਬ ਲੱਗ ਰਿਹਾ ਸੀ, ਪਰ 48 ਘੰਟਿਆਂ ਵਿੱਚ ਇਸ ਨੇ ਅਸਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਦਿੱਤਾ: ਕੀ ਲੋਕ ਪ੍ਰੋਡਕਟ ਅੰਦਰ ਗੱਲ ਕਰਦੇ ਹਨ, ਜਾਂ ਉਹ Slack ਵਰਤਣਾ ਜਾਰੀ ਰੱਖਦੇ ਹਨ?
ਨਤੀਜਾ: ਪਹਿਲੇ ਹਫ਼ਤੇ ਵਿੱਚ ਭਾਰੀ ਵਰਤੋਂ, ਜਿਸ ਨੇ ਬਾਅਦ ਵਿੱਚ ਇਕ ਮੌਜੂਦਾ ਮਾਡਲ ਅਤੇ UI ਵਿਚ ਨਿਵੇਸ਼ ਕਰਨ ਨੂੰ ਜਾਇਜ਼ ਬਣਾਇਆ।
ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ ਟੀਮ ਆਟੋਮੈਟਡ ਮੈਚਿੰਗ ਦੀ ਸੋਚ ਰਹੀ ਸੀ। ਉਹਨਾਂ ਨੇ “Request a match” ਬਟਨ ਨਾਲ ਸ਼ੁਰੂ ਕੀਤਾ, ਜਿਸ ਨੇ ਇੱਕ ਸਾਂਝੇ ਇਨਬਾਕਸ ਵਿੱਚ ਟਿਕਟ ਬਣਾਇਆ।
ਪਿਛੋਕੜ ਵਿੱਚ, ਇੱਕ ਓਪਸ ਵਿਅਕਤੀ ਮੈਨੁਅਲ ਤੌਰ 'ਤੇ ਮੈਚ ਕਰਦਾ ਅਤੇ ਨਤੀਜਾ ਈਮੇਲ ਕਰਦਾ ਸੀ। ਇਹ ਸਕੇਲਬਲ ਨਹੀਂ ਸੀ, ਪਰ ਇਸਨੇ ਦੱਸਿਆ ਕਿ “ਚੰਗੇ ਮੈਚ” ਦਾ ਮਤਲਬ ਕੀ ਹੈ, ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਘੱਟ ਹੈ, ਅਤੇ ਕੌਣ-ਕੌਣੇ ਕੇਸ ਅਹੰਕਾਰ ਰੱਖਦੇ ਹਨ।
ਨਤੀਜਾ: ਜਦੋਂ ਉਹਨਾਂ ਨੇ ਆਟੋਮੇਟ ਕੀਤਾ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੇ ਸਹੀ ਵਰਕਫਲੋ ਆਟੋਮੈਟ ਕੀਤਾ—ਅਣੁਮਾਨ ਨਹੀਂ।
ਇੱਕ ਸਟਾਰਟਅਪ ਜਿਸ ਨੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਬਣਾ ਰਹੇ ਸਨ, ਉਹਨਾਂ ਨੇ ਭਵਿੱਖ-ਪ੍ਰੂਫ ਸਕੀਮਾ ਨਾਲ ਦਸ ਟੇਬਲਾਂ ਬਣਾਉਣ ਦੀ ਥਾਂ ਸਿਰਫ਼ ਲੋੜੀਅਤ ਫੀਲਡ ਸੰਭਾਲੇ: ਪਲੈਨ, ਸਟੈਟਸ, ਨਵੀਨਕਰਨ ਦੀ ਤਾਰੀਖ।
ਨਤੀਜਾ: ਘੱਟ ਬਗ, ਕੀਮਤ 'ਤੇ ਤੇਜ਼ ਇਟਰੈਸ਼ਨ, ਅਤੇ ਸਪੱਸ਼ਟ ਸੰਕੇਤ ਕਿ ਕਿਹੜੇ ਫੀਲਡ ਬਾਅਦ ਵਿੱਚ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਬਣਨੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ ਉਤਪਾਦ ਨੇ ਕੁਝ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਹਲਕੇ ਤਫਾਵਤ ਵਾਲੇ ਬਟਨ ਸਟਾਇਲ ਨਾਲ ਸ਼ਿਪ ਕੀਤਾ। ਉਪਭੋਗੀਆਂ ਨੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ।
ਪਰ ਉਹ ਕਿਸੇ ਕੋਰ ਫਲੋ ਨੂੰ ਜਦੋਂ ਵੀ ਅਜਿਹਾ ਜੋ ਉਪਭੋਗੀ ਦੀ ਸੇਵਿੰਗ ਖੋ ਦੇਵੇਗਾ, ਉਨ੍ਹਾਂ ਨੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ—ਉਨ੍ਹਾਂ ਨੇ ਆਪਣੀ ਸੀਮਿਤ ਸਮੇਂ ਨੂੰ ਆਟੋ-ਸੇਵ ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ 'ਤੇ ਲਗਾਇਆ।
ਇਹੀ ਵਪਾਰ ਹੈ: ਛੋਟੀ UI ਗੰਝਲਦਾਰੀ ਨੂੰ ਸਹਿਣਯੋਗ ਮਨੋ, ਪਰ ਉਹ ਛੇਤੀ-ਛੇਤੀ ਲਹਿਰਾਂ ਜਿਨ੍ਹਾਂ ਤੇ ਭਰੋਸਾ ਬਣਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਦੀ ਰੱਖਿਆ ਕਰੋ।
Vibe coding ਉਦੋਂ ਹੀ ਲਾਭਕਾਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਗਤੀ ਸਿੱਖਣ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਇਹ ਅਸਫਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਗਤੀ ਖਤਰਾ ਪੈਦਾ ਕਰਦੀ ਹੈ—ਜਾਂ ਜਦੋਂ ਗੰਦੇ shortcut ਤੁਹਾਨੂੰ ਸਿੱਖਣ ਤੋਂ ਹੀ ਰੋਕ ਦੇਂਦੇ ਹਨ। ਆਮ ਧਾਗਾ “ਅਸਾਫ਼ ਕੋਡ” ਨਹੀਂ; ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਘਾਟ ਹੈ ਕਿ ਕੀ ਹਥਪਾ ਨਹੀਂ ਹਲ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਇੱਥੇ ਵੀ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਯੋਗ ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਖਤਰੇ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਛੇਤੀ “ਟੈਮਪਰੇਰੀ” ਐਡਮਿਨ ਏਂਡਪੋਇੰਟ, ਕਨਸੋਲ ਵਿੱਚ ਟੋਕਨ ਲੌਗ ਕਰਨਾ, ਜਾਂ ਬੁਨਿਆਦੀ ਐਕਸੈਸ ਕੰਟਰੋਲ ਨੂੰ ਛੱਡਣਾ ਇੱਕ ਨਿਰਦੋਸ਼ ਡੈਮੋ ਨੂੰ ਅਸਲ ਘਟਨਾ ਬਣਾ ਸਕਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਟੀਮ, ਟੈਸਟਰ ਜਾਂ ਸ਼ੁਰੂਆਤੀ ਗ੍ਰਾਹਕ ਇਸਨੂੰ ਵਰਤਣ ਲੱਗਦੇ ਹਨ।
ਤੇਜ਼ ਕੋਡ ਅਕਸਰ ਸਟੇਟ ਦੀ ਰੱਖਿਆ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਹਾਨੂੰ ਡੇਟਾ ਨੁਕਸਾਨ ਅਤੇ ਅਣਪਛਾਤੇ ਹਾਲਤਾਂ ਮਿਲਦੀਆਂ ਹਨ: ਗਲਤ ਰਿਕਾਰਡ ਮਿਟਾਉਣਾ, ਉਪਭੋਗੀ ਇਨਪੁੱਟ ਓਵਰਰਾਈਟ ਕਰਨਾ, ਬੈਕਅੱਪ ਬਿਨਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣਾ। ਇਹ “ਛੋਟੇ ਬੱਗ” ਨਹੀਂ; ਇਹ ਉਹ ਸਬੂਤ ਮਿਟਾ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਉਪਭੋਗੀਆਂ ਨੂੰ ਸਮਝਣ ਲਈ ਚਾਹੀਦੇ ਹਨ।
Vibes ਦੀ ਛੁਪੀ ਲਾਗਤ ਉਹ ਹੈ ਉਹ ਕਾਮਪਲੈਕਸਿਟੀ ਜੋ ਤੁਸੀਂ ਅਜੇ ਤੱਕ ਨਹੀਂ ਦੇਖਦੇ। ਜਦੋਂ ਹਰ ਚੀਜ਼ ਘੰਟੇ ਤੰਗ-ਜੁੜੀ ਹੋਵੇ, ਹਰ ਬਦਲਾਅ ਤਿੰਨ ਹੋਰ ਚੀਜ਼ਾਂ ਨੂੰ ਤੋੜਦਾ ਹੈ। ਕੋਡਬੇਸ ਪ੍ਰਗਤੀ ਦਾ ਵਿਰੋਧੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਓਨਬੋਡਿੰਗ ਸੁਸਤ ਹੁੰਦੀ ਹੈ, ਫਿਕਸ ਬਣਾਉਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਅਤੇ “ਸਿਰਫ਼ ਇਕ ਹੋਰ ਫੀਚਰ” ਇੱਕ ਹਫ਼ਤਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜੇ ਕੋਈ ਵੀ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕੋਰ ਫਲੋ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਟੀਮ ਸਮਝ ਦੀ ਕਮੀ ਪਾਂਦੇ ਹੋ: ਗੈਰ-ਇਕਸਾਰ ਸੋਧਾਂ, ਨਕਲ-ਲਾਜ਼ਮੀ ਲੌਜਿਕ, ਅਤੇ ਗਲਤੀ-ਸਮਝੇ ਹੋਏ ਰੀਰਾਈਟ। Vibes ਲੋਕਾਂ ਦੀਆਂ ਲੋਕ-ਦੇ-ਕਹਾਣੀਆਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਕੁਝ ਖੇਤਰ vibe-ਮਿੱਤਰ ਨਹੀਂ ਹਨ। ਬਿਲਿੰਗ, ਪ੍ਰਮਾਣੀਕਰਨ, ਪਰਮੀਸ਼ਨ, ਅਤੇ ਕੋਰ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਬੱਗ ਸਿਰਫ਼ ਉਪਭੋਗੀ ਨੂੰ ਚੀੜਾਉਂਦੇ ਨਹੀਂ—ਉਹ ਭਰੋਸਾ ਨੁਕਸਾਨ ਕਰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਕਠੋਰ ਹੱਦਾਂ ਖਿੱਚੋ: ਕਿਨਾਰੇ 'ਤੇ ਪ੍ਰਯੋਗ, ਕੇਂਦਰ 'ਚ ਸਹੀਤਾ।
Vibe coding ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ “ਤੇਜ਼” ਦਾ ਮਤਲਬ “ਲਾਪਰਵਾਹ” ਨਾ ਹੋਵੇ। ਗਾਰਡਰੇਲ ਉਹਨਾਂ ਛੋਟੀਆਂ ਪ੍ਰਥਾਵਾਂ ਦਾ ਸੈੱਟ ਹਨ ਜੋ ਤੁਹਾਡੇ ਸ਼ਿਪਿੰਗ ਟੈਂਪੋ ਨੂੰ ਉੱਚਾ ਰੱਖਦੀਆਂ ਹਨ ਤੇ ਉਪਭੋਗੀਆਂ (ਅਤੇ ਤੁਹਾਡੇ ਭਵਿੱਖ ਦੇ ਆਪ) ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ।
ਇਸ ਸੂਚੀ ਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਇਹ ਹਰ ਵਾਰੀ ਹੋਵੇ:
ਜਵਾਬ ਲਈ ਕਾਫੀ ਨਜ਼ਰਤਾ ਜੋ ਤੁਹਾਨੂੰ ਦੱਸ ਸਕੇ: “ਕੀ ਇਹ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ?” ਅਤੇ “ਕਿਸ ਨੂੰ ਨੁਕਸਾਨ ਹੋ ਰਿਹਾ ਹੈ?”
Errors, performance, ਅਤੇ ਕੁਝ ਮੁੱਖ ਉਪਭੋਗੀ ਕਾਰਵਾਈਆਂ (ਉਦਾਹਰਣ ਲਈ activation step completion, successful payment, file processed) ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ। ਤੁਸੀਂ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਨਹੀਂ ਬਣਾ ਰਹੇ—ਸਿਰਫ਼ ਇੱਕ ਸ੍ਰੌਤ-ਅਲਾਰਮ।
ਉਹ заранее ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਤੁਰੰਤ ਰੋਲਬੈਕ ਜਾਂ ਹਾਟਫਿਕਸ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ:
ਜਦੋਂ ਜੋਖਿਮ ਅਸਪਸ਼ਟ ਹੋਵੇ ਤਾਂ ਸਟੇਜਡ ਰੋਲਆਊਟ ਵਰਤੋ (ਇੰਟਰਨਲ → ਛੋਟੀ ਕੋਹੋਰਟ → ਸਾਰਿਆਂ)। ਇਹ ਤੁਹਾਨੂੰ ਅਧੂਰਾ ਭੇਜਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਪਰ ਜਿੰਨੇ ਉਪਭੋਗੀਆਂ rough edges ਵੇਖਣਗੇ ਉਹ ਸੀਮਿਤ ਰਹਿਣਗੇ।
ਲੰਮੇ ਨੋਟ ਨਹੀਂ। ਇਹ ਲਿਖੋ:
ਇਹ ਅਜੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਲਈ ਕਾਫੀ ਹੈ ਬਿਨਾਂ ਭਵਿੱਖ ਵਿੱਚ ਰਹਸ੍ਯ ਬਣਾਉਣ ਦੇ।
ਤਕਨੀਕੀ ਕਰਜ਼ ਪਾਪ ਨਹੀਂ ਹੈ; ਅਣ-ਟਰੈਕ ਕੀਤਾ ਕਰਜ਼ ਹੈ। Vibe coding ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ shortcut ਨੂੰ ਇੱਕ ਫਾਇਨੈਨਸ ਫੈਸਲੇ ਵਾਂਗ ਵੇਖਦੇ ਹੋ: ਹੁਣ ਗਤੀ 'ਤੇ ਕਰਜ਼ ਲੋ, ਅਤੇ ਜਦੋਂ ਸਟੇਕ ਪਾਇਆ ਤਾਂ ਵਾਪਸੀ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।
ਇੱਕ ਹਲਕਾ debt register (ਇਕ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਇੱਕ ਸਿੰਗਲ ਇਸ਼ਯੂ ਟ੍ਰੈਕਰ ਵਿਊ) ਬਣਾਓ ਜਿੱਥੇ ਹਰ ਇਰਾਦੇਮੰਦ shortcut ਇੱਕ ਲਾਈਨ ਆਏ:
ਇਸ ਨਾਲ “ਬਾਅਦ ਵਿੱਚ ਠੀਕ” ਇੱਕ ਸਪੱਸ਼ਟ ਸਮਝੌਤਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਹਰ debt ਆਈਟਮ ਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਇੱਕ ਮਾਲਿਕ ਅਤੇ ਇਕ ਟ੍ਰਿਗਰ ਜਦੋਂ ਮੁੜ ਵੇਖਣਾ ਹੈ। ਟ੍ਰਿਗਰ ਮਾਪ਼ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਭਾਵੇਂ ਭਾਵਨਾਤਮਕ ਨਹੀਂ।
ਉਦਾਹਰਣ: “ਜਦ ਇਹ endpoint 1k requests/ਦਿਨ ਤੱਕ ਪਹੁੰਚੇ,” “ਜਦ ਇਸ ਯੋਜਨਾ ਤੋਂ ਆਮਦਨ $10k MRR ਪਾਰ ਕਰੇ,” ਜਾਂ “ਜੇ churn ਇੱਕ ਹਫਤੇ ਵਿੱਚ ਇਸ ਬੱਗ ਦਾ ਦੋ ਵਾਰ ਜ਼ਿਕਰ ਕਰੇ।” ਹੁਣ ਟੀਮ ਜਾਣਦੀ ਹੈ ਕਿ ਕਰਜ਼ ਕਦੋਂ ਵਾਪਸ ਅਦਾ ਕਰਨਾ ਹੈ।
ਇੱਕ ਡਰਾਮੈਟਿਕ ਰੀਰਾਈਟ ਤੋਂ ਵਧੀਆ, ਅਕਸਰ ਛੋਟੇ, ਨਿਰੰਤਰ ਮੁੜ-ਅਦਾਇਗੀ ਵਧੀਆ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਮੌਡਿਊਲ ਨੂੰ ਛੂਹੋ, ਇੱਕ ਫੰਕਸ਼ਨ ਸੁਧਾਰੋ; ਇੱਕ ਟੈਸਟ ਜੋੜੋ; ਇੱਕ ਹੈਕ ਹਟਾਓ।
ਲਾਂਚ, ਕੀਮਤ ਬਦਲਾਅ, ਮੱਖੀ ਇੰਟੈਗਰੇਸ਼ਨ ਵਰਗੇ ਉਤਪਾਦ ਮੀਲਾਂ-ਪੱਥਣਾਂ ਦੇ ਬਾਅਦ ਛੋਟੇ ਸਫਾਈ ਵਿੰਡੋ ਸ਼ਡਿਊਲ ਕਰੋ। ਤੁਸੀਂ ਅਜੇ-ਹੀ ਸਿੱਖਿਆ ਕੀਤੀ—ਉਹ ਸਮਾਂ ਜਦ ਉਪਭੋਗੀਆਂ ਨੇ ਸੱਚ-ਮੁੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਛੂਹਿਆ।
ਕੁਝ ਕੋਡ ਸਿਰਫ਼ ਗੰਦਾ ਹੈ; ਕੁਝ ਖਤਰਨਾਕ ਹਨ। ਅਨਸੇਫ ਕਰਜ਼ (ਡੇਟਾ ਲੋਸ, ਸੁਰੱਖਿਆ ਮੁੱਦੇ, ਚੁਪਚਾਪ ਸਹੀਤਾ ਬੱਗ) ਨੂੰ ਤੁਰੰਤ ਮੰਨੋ। ਉਗਲੀ-ਪਰ-ਸੇਫ਼ ਕਰਜ਼ ਨੂੰ ਯੋਜਨਾ ਨਾਲ ਰੱਖੋ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਗੰਦਾ ਕੋਡ ਸਵਾਲਾਤੀ ਵਪਾਰ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਗਤੀ ਅਤੇ ਸਿੱਖਣ ਖਰੀਦ ਰਹੇ ਹੋ। ਗਲਤੀ ਇਹ ਹੈ ਕਿ “ਅਸਥਾਈ” ਨੂੰ बिना ਧਿਆਨ ਦੇ “ਸਥਾਈ” ਬਣਨ ਦਿਓ। ਸਫਾਈ ਕੋਈ ਨੈਤਿਕ ਉੱਤਮ ਨਹੀਂ—ਇਹ ਇੱਕ ਨਿਵੇਸ਼ ਫੈਸਲਾ ਹੈ।
ਜਦੋਂ ਬਦਲਾਅ ਡਰਾਉਣੇ, ਹੌਲੇ ਜਾਂ ਅਣਪੇਸ਼ਗੁਆਂਹ ਹੋਣ ਲੱਗਣ, ਤਦ ਰੀਫੈਕਟਰ ਕਰੋ। ਜੇ ਇਕ ਸਧਾਰਨ ਸੋਧ ਤਿੰਨ ਹੋਰ ਚੀਜ਼ਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੀ ਹੈ, ਜਾਂ ਤੁਹਾਨੂੰ “ਉਹ ਇੱਕ ਵਿਅਕਤੀ” ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਕਰਜ਼ 'ਤੇ ਸੂਦ ਦੇ ਰਹੇ ਹੋ।
ਕਾਪੀ-ਪੇਸਟ ਵਰਕਅਰਾਊਂਡ ਅਤੇ ਵਧਤ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਪਹਿਲਾ ਵਰਕਅਰਾਊਂਡ ਇੱਕ ਪੈਚ ਹੈ। ਪੰਜਵਾਂ ਇੱਕ ਪੈਟਰਨ ਹੈ ਜੋ ਸਾਂਝੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਬਣਨ ਦੀ ਤਲਬ ਕਰਦਾ ਹੈ।
ਵੱਡੇ ਗੁਣਵੱਤਾ ਅੱਪਗਰੇਡ ਲਈ traction ਸੰਕੇਤ ਵਰਤੋ। ਜਦੋਂ ਕੋਈ ਫੀਚਰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਚਿੱਪਕ ਜਾਂਦਾ—ਵਰਤੋਂ, ਆਮਦਨੀ, ਰਿਟੇਨਸ਼ਨ, ਸਪੋਰਟ ਟਿਕਟ ਵਧਦੇ ਹਨ—ਤੁਸੀਂ ਪ੍ਰਮਾਣਿਤ ਕਰ ਚੁੱਕੇ ਹੋ ਕਿ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਉਸ ਵੇਲੇ ਬੁਨਿਆਦੀ ਕੋਡ ਨੂੰ ਮਜ਼ਬੂਤ ਬਣਾਉਣ, ਟੈਸਟ ਜੋੜਨ, ਮਾਨੀਟਰਨਿੰਗ ਬਿਹਤਰ ਕਰਨ ਅਤੇ ਖਰਾਬ ਕੋਨਾਂ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਵਰਤੇਯੋਗ ਨਿਯਮ: ਅਨੁਮਾਨੀ ਰਸਤੇ ਨੂੰ ਜ਼ਰੂਰਤ ਤੋਂ ਵੱਧ ਇੰਜੀਨੀਅਰ ਨਾ ਕਰੋ। ਉਨ੍ਹਾਂ ਰਸਤੇ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ ਜਿੱਥੇ ਉਪਭੋਗੀ ਪਹਿਲਾਂ ਹੀ ਤੁਰਦੇ ਹਨ।
ਸਥਿਰ ਇੰਟਰਫੇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਗੁਣਵੱਤਾ ਅੱਪਗਰੇਡ ਕਰੋ: APIs, ਡੇਟਾ ਮਾਡਲ, ਅਤੇ ਕੋਰ ਯੂਜ਼ਰ ਫਲੋਜ਼। ਇਹ ਉਹ ਹਿੱਸੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਹੋਰ ਕੋਡ ਨਿਰਭਰ ਹੈ, ਇਸ ਲਈ ਇੱਥੇ ਸੁਧਾਰ ਕੰਪਾਉਂਡ ਹੁੰਦੇ ਹਨ।
ਸਭ ਕੁਝ ਰੀਰਾਈਟ ਨਾ ਕਰੋ। ਥਾਂ-ਥਾਂ ਪਰਬੰਧਿਤ ਬੋਤਲਨੈਕਸ ਚੁਣੋ:
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਮਾਪਣਯੋਗ ਟ੍ਰਿਗਰ ਚਾਹੀਦਾ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ “ਕੋਡ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦਿਆਂ ਵੱਧ ਸਮਾਂ ਬਿਤਾ ਰਹੇ ਹੋ ਬਜਾਏ ਮੁੱਲ ਜੋੜਨ” ਤਾਂ ਸਫਾਈ ਕਰਨ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ।
ਸੂਝਬੂਝ ਧੁੰਦਲੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਸਿਖाई ਜਾ ਸਕਦੀ ਹੈ। Vibe coding ਵਿੱਚ, ਸੂਝਬੂਝ ਉਹ ਸਮਰੱਥਾ ਹੈ ਕਿ ਜੋ ਤੁਹਾਨੂੰ ਮਹਿਸੂਸ ਕਰਨ ਦਿੰਦੀ ਹੈ ਕਿ ਕੀ ਸਪੱਸ਼ਟ, ਅਟਲ, ਅਤੇ ਉਪਯੋਗੀ ਲਈ ਮਦਦਗਾਰ ਹੈ—ਅਤੇ ਜੋ ਵੀ ਥਾਂ ਨਹੀਂ ਕਮਾਉਂਦੀ ਉਸਨੂੰ ਕੱਟ ਦੇਣੀ।
ਸਿਰਫ਼ ਕਿਸੇ ਉਤਪਾਦ ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਨਾ ਕਰੋ—ਉਸਨੂੰ ਪ੍ਰਸ਼ਨ ਕਰੋ। ਜਦੋਂ ਕੁਝ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਪੁੱਛੋ ਕਿਉਂ ਉਹ ਸਧਾਰਨ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਯਹ ਵੇਖੋ ਕਿ: ਪਹਿਲਾ ਸਕਰੀਨ ਕੀ ਹੈ? ਸਪਸ਼ਟ ਕੀ ਗਈ ਹੈ? ਕਿਹੜੀਆਂ ਫੈਸਲਿਆਂ ਨੂੰ ਸਥਾਈ ਬਣਾਉਣ ਵਿਚ ਦੇਰੀ ਕੀਤੀ ਗਈ ਹੈ?
ਇਕ ਹਲਕਾ ਲਾਗ ਰੱਖੋ ਉਹਨਾਂ ਨਿਰਣਿਆਂ ਦਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਦੁਬਾਰਾ ਬਦਲਦੇ।
ਉਦਾਹਰਣ:
ਇਹ ਨੋਟਸ ਬਾਅਦ ਵਿੱਚ ਅਨੁਭਵ ਨੂੰ ਸੂਝਬੂਝ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
ਪੇਅਰਿੰਗ ਸਿਰਫ਼ ਸਹੀਤਾ ਲਈ ਨਹੀਂ ਹੈ; ਇਹ ਕੈਲਿਬ੍ਰੇਸ਼ਨ ਲਈ ਹੈ। ਕਿਸੇ ਐਸੇ ਵਿਅਕਤੀ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰੋ ਜਿਸ ਦੀ ਉਤਪਾਦ ਸੂਝ ਤੁਹਾਨੂੰ ਭਰੋਸੇਯੋਗ ਲੱਗਦੀ ਹੋਵੇ ਅਤੇ ਇੱਕ ਸਵਾਲ ਬਾਰ-ਬਾਰ ਪੁੱਛੋ: “ਇੱਥੇ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ?”
ਤੁਸੀਂ ਉਹਨਾਂ ਦੀਆਂ ਤਰਜੀਹਾਂ ਅਸਿਮੇਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ—ਉਹ ਕੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ, ਉਹ ਕੀ ਜ਼ਰੂਰੀ ਮੰਨਦੇ ਹਨ, ਅਤੇ “ਚੰਗਾ-ਕਾਫੀ” ਦੇ ਫੈਸਲੇ ਕਿਉਂ ਕਰਦੇ ਹਨ।
ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਰਿਲੀਜ਼ਾਂ ਦਾ ਮੁੱਲ ਟਿਕਟਾਂ ਅਤੇ ਸਮਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਜਾਚਦੀਆਂ ਹਨ। ਸੂਝਬੂਝ ਤੇਜ਼ੀ ਨਾਲ ਤਬਦੀਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਭਾਵ ਦੇਖਦੇ ਹੋ:
ਇਸ ਨਾਲ ਹਕੀਕਤ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਆਦਤ ਬਣਦੀ ਹੈ, ਨਾਂ ਕਿ ਸਪੈਕ ਲਈ।
ਵੈਕਤੀਗਤ ਸੂਝਬੂਝ ਲਾਭਕਾਰੀ ਹੈ; ਸਾਂਝੀ ਸੂਝਬੂਝ ਫ਼ਾਇਦਾ ਦਿੰਦੀ ਹੈ। ਕੁਝ ਪ੍ਰਿੰਸੀਪਲ ਲਿਖੋ ਜੋ ਤੇਜ਼ ਫੈਸਲਿਆਂ ਨੂੰ ਮਾਰਗਦਰਸ਼ਿਤ ਕਰਨ—ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਰੀਵਿਊਜ਼ ਅਤੇ ਵਿਚਾਰ-ਵਟਾਂਦਰੇ ਵਿੱਚ ਵਰਤੋ।
ਉਦਾਹਰਣ:
ਜਦ ਇਹ ਸਿਧਾਂਤ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ, “vibes” ਚਰਚਾ ਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ—ਅਤੇ ਟੀਮ ਬਿਨਾਂ ਵਿੱਬ-ਭਿੰਨਤਾ ਦੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧ ਸਕਦੀ ਹੈ।
Vibe coding ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਲਕਸ਼੍ਹ ਸਪਸ਼ਟ ਰੱਖਦੇ ਹੋ: ਪਹਿਲਾਂ ਮੁੱਲ ਦਿੱਤਾ, ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋ, ਅਤੇ ਸਿਰਫ਼ ਉਹ ਸਮੇਂ “ਪਰਫੈਕਸ਼ਨ ਲਈ ਭੁਗਤਾਨ” ਕਰੋ ਜਦੋਂ ਉਤਪਾਦ ਨੇ ਉਸ ਦਾ ਦਾਅਵਾ ਕੀਤਾ ਹੋਵੇ। ਟ੍ਰਿਕ vibes ਅਤੇ ਸਫਾਈ ਵਿਚ ਉਸਨੂੰ ਜੋੜਨਾ ਹੈ—ਤੇ ਇੱਕ ਸਫਾਈ ਯੋਜਨਾ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਅਮਲ ਕਰੋ।
ਇਹ ਸਵਾਲਾਂ ਲੜੀਵਾਰ ਪੁੱਛੋ:
ਇੱਕ ਹਲਕੀ ਲੂਪ ਰੱਖੋ:
ਕੁਝ ਸਿਗਨਲ ਟ੍ਰੈਕ ਕਰੋ: ਉਪਭੋਗੀ ਸਫਲਤਾ (activation, retention), ਭਰੋਸੇਯੋਗਤਾ (errors, incidents), ਅਤੇ ਬਦਲਾਅ ਦੀ ਤੀਜ਼ੀ (ਅਗਲਾ ਸੋਧ ਕਿੰਨਾ ਮੁਸ਼ਕਲ ਲੱਗਦਾ ਹੈ)।
ਟੀਮ ਨੂੰ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ “ਚੰਗਾ-ਕਾਫੀ” ਤੇ ਇਕਹਿੱਤ ਕਰਵਾਓ: ਇਸ ਹਫ਼ਤੇ ਤੁਸੀਂ ਕੀ ਸਹਿਣ ਕਰੋਂਗੇ, ਕੀ ਨਹੀਂ, ਅਤੇ ਅਗਲੇ ਮੀਲ-ਪੱਥਰ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਸਾਫ਼ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਹਿਮਤ ਨਹੀਂ ਹੋ, ਤਾਂ ਕੋਡ ਤੁਹਾਡੀ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ।
ਜੇ vibe coding ਦਾ ਮਤਲਬ ਵਿਚਾਰ→ਸੋਫਟਵੇਅਰ→ਫੀਡਬੈਕ ਲੂਪ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨਾ ਹੈ, ਤਾਂ ਟੂਲਜ਼ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਇੱਕ ਚੈਟ-ਚਲਿਤ ਬਿਲਡ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਢੀਠ ਉਤਪਾਦ ਮਨਸੂਬੇ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਚੱਲਦੇ ਐਪ ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ—ਖਾਸ ਕਰਕੇ ਪਹਿਲੇ ਪੁਸ਼ਟੀ ਲਈ।
ਟੀਮਾਂ ਦਾ ਇੱਕ ਵਰਤੋਂ-ਪ੍ਰਣਾਲੀ ਇਹ ਹੈ ਕਿ Koder.ai ਨੂੰ vibe-coding ਵਰਕਫਲੋ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਵਰਤਦੇ ਹਨ:
ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ—ਖਾਸ ਕਰਕੇ ਸੁਰੱਖਿਆ, ਬਿਲਿੰਗ, ਪਰਮੀਸ਼ਨਸ, ਅਤੇ ਡੇਟਾ ਇੰਟੀਗ੍ਰਿਟੀ ਦੇ ਮਾਮਲਿਆਂ 'ਤੇ—ਪਰ ਇਹ “ਕੌਸ਼ਸ਼ ਕਰੋ, ਦਿਖਾਓ, ਸਿੱਖੋ” ਦੀ ਲਾਗਤ ਘਟਾ ਸਕਦਾ ਹੈ, ਜੋ ਵਧੀਆ vibes ਦਾ ਮੁੱਖ ਵਾਅਦਾ ਹੈ।
ਇਹ ਸੋਫਟਵੇਅਰ ਬਣਾਉਣ ਦੀ ਇੱਕ ਵਿਧੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਤੰਗ ਫੀਡਬੈਕ ਲੂਪ ਹੁੰਦੀ ਹੈ: ਛੋਟਾ, ਅਸਲੀ ਵਰਜਨ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੋ, ਵੇਖੋ ਕਿ ਅਸਲ ਦੁਨੀਆ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ (ਉਪਯੋਗ, ਸਪੋਰਟ, churn, ਗੁਣਾਤਮਕ ਫੀਡਬੈਕ), ਫਿਰ ਦੁਹਰਾਓ। “ਵೖਬ” ਇੱਥੇ ਰੁਕਾਵਟ ਨਹੀਂ, ਬਲਕਿ ਗਤੀ ਅਤੇ ਸਿੱਖਣ ਦੀ ਕਾਬਲियत ਹੈ—ਪੁakketੇ ਹੱਕ ਦੀ ਚੱਲ-ਫਿਰ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਮੰਗ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਗਲਤ ਚੀਜ਼ ਬਣਾਉਣਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਕੁੱਝ-ਕਾਲਪਣਿਕ ਵਰਜਨ ਮੁੱਖ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਦੇ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਕੀ ਉਪਭੋਗੀ ਇਸਨੂੰ ਵਰਤਣਗੇ—ਇਹ ਸੁੰਦਰਗਤੀ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਲਚਕੀਲਾ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਗਲਤ ਅਭਿਵਿਆਕਤੀਆਂ ’ਤੇ ਫਸ ਨਹੀਂ ਜਾਂਦੇ।
ਟੇਸਟ (taste) ਉਹ ਸਮਰੱਥਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉਪਭੋਗੀ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਉਹ ਸੌਖਾ ਹੱਲ ਚੁਣਣ ਦਿੰਦੀ ਹੈ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਕਦਰਦੇ ਹੋਏ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਜੱਜਮੈਂਟ (judgment) ਉਹ ਹੈ ਜੋ ਅਨਿਸ਼ਚਿਤਤਾ ਵਿੱਚ ਛੋਟੀਆਂ-ਵੱਡੀਆਂ ਵਪਾਰ-ਫੈਸਲਿਆਂ ਨੂੰ ਲੈਣ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦੀ ਹੈ—ਜਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਤੁਰੰਤ ਲੰਘ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕਿਹੜੀਆਂ ਨੂੰ ਸੰਭਾਲ ਕੇ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ।
ਉਪਭੋਗੀ ਨਤੀਜੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਕੰਮ ਘਟਾਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦਿਨਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰ ਸਕੋ।
ਅਨਵਰਤਨੀਆਂ ਨੂੰ ਮਹਿੰਗਾ ਮੰਨੋ।
ਜਦੋਂ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾ ਰਹੇ ਹੋ, ਉਹ ਚੀਜ਼ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਿਨਾਂ ਉਪਭੋਗੀਆਂ ਨੂੰ ਤੋੜੇ ਬਦਲ ਸਕੋ।
ਟੇਮਪਲੇਟ ਗਾਰ্ডਰੈਲ ਜੋ ਭਰੋਸਾ ਰੱਖਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦੀਆਂ ਹਨ ਪਰ ਟੈਮਪੋ ਦੀ ਰੁਕਾਵਟ ਨਹੀਂ ਬਣਦੀਆਂ:
ਉਹਨਾਂ ਸ਼ੌਰਟਕੱਟਾਂ ਤੋਂ ਬਚੋ ਜੋ ਚੁਪਚਾਪ ਅਤੇ ਮੁੜ-ਪੂਰਨ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ:
ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਟੈਮਪਲੇਟ ਹੱਲ ਨੇ ਸਿੱਖਣਾ ਰੋਕ ਨਾ ਦਿੱਤਾ ਹੋਵੇ।
ਛੋਟੀ ਦਸਤਾਵੇਜ਼ੀ ‘debt register’ ਰੱਖੋ ਤਾਂ ਕਿ ਕਰਜ਼ ਵਾਜਬ ਹੋਵੇ, ਨਾਂ ਕਿ ਅਚਾਨਕ।
ਇਸ ਨਾਲ “ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਾਂਗੇ” ਇੱਕ ਸਪੱਸ਼ਟ ਸਮਝੌਤੇ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਸੂਦ ਵੱਖ-ਵੱਖ ਢੰਗ ਨਾਲ ਦਿੱਖਾਈ ਦੇਣ ਲੱਗੇ:
ਸਥਿਰ ਇੰਟਰਫੇਸ (APIs, ਡੇਟਾ ਮਾਡਲ, ਕੋਰ ਫਲੋਜ਼) ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਬੋਤਲਨੈਕ ਠੀਕ ਕਰੋ—ਹਰ ਚੀਜ਼ ਨੂੰ ਨਹੀਂ।
ਟੇਸਟ ਨੂੰ ਟ੍ਰੇਿਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:
