Vibe coding ਉਹਨਾਂ ਬਿਲਡਰਾਂ ਨੂੰ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਦੇਖਦੇ, ਤੇਜ਼ ਟੈਸਟ ਕਰਦੇ ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਹਨ। ਪੜ੍ਹੋ ਕਿ ਕਿਉਂ ਉਤਪਾਦੀ ਸੁਝਾਨ ਫਰੇਮਵਰਕ ਦੀ ਡਿੱਗਰੀ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ।
“Vibe coding” ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹੋ — ਆਪਣੀ ਆਦਤ (ਉਪਭੋਗਤਾ ਦੀ ਲੋੜ ਮਹਿਸੂਸ ਕਰਨ ਦੀ ਸਮਰੱਥਾ) ਨੂੰ ਆਧੁਨਿਕ ਔਜ਼ਾਰਾਂ (AI ਸਹਾਇਕ, ਟੈਂਪਲੇਟ, ਤਿਆਰ ਕੰਪੋਨੈਂਟ, ਹੋਸਟ ਕੀਤੀਆਂ ਸਰਵਿਸਿਜ਼) ਨਾਲ ਜੋੜ ਕੇ। ਤੁਸੀਂ ਕਿਸੇ ਪੂਰਨ ਯੋਜਨਾ ਤੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਸਕੈਚ ਕਰ ਰਹੇ ਹੋ, ਟਰਾਇ ਕਰ ਰਹੇ ਹੋ, ਠੀਕ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਛੋਟੇ ਹਿੱਸਿਆਂ ਨੂੰ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਜੋ ਦੇਖਿਆ ਜਾ ਸਕੇ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ।
Vibe coding ਇਹ ਹੈ:
“Vibe” ਹਿੱਸਾ ਬੇਇੰਤਜ਼ਾ ਨਹੀਂ ਹੈ। ਇਹ ਦਿਸ਼ਾ ਹੈ। ਤੁਸੀਂ ਉਪਭੋਗਤਾ ਮੁੱਲ ਬਾਰੇ ਇੱਕ ਅਨੁਮਾਨ ਦੀ ਪਾਲਣਾ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਅਸਲ ਇੰਟਰੈਕਸ਼ਨ ਨਾਲ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਚਰਚਾ ਨਾਲ ਨਹੀਂ।
ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਵਸਥਾ ਦੇ ਵਿਰੁੱਧ ਤਰਕ ਨਹੀਂ ਹੈ।
Vibe coding ਨਹੀਂ ਹੈ:
ਇਹ ਇਹ ਵੀ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਫਰੇਮਵਰਕ ਦੀ ਮਹਿਰਤ ਲਾਭਹੀਨ ਹੈ। ਆਪਣੇ ਸਟੈਕ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਨਾ ਇੱਕ ਸ਼ਕਤੀ ਹੋ ਸਕਦੀ ਹੈ। ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਵੱਡੇ-ਅਰੰਭਿਕ ਉਤਪਾਦਾਂ ਅਤੇ ਪ੍ਰਯੋਗਾਂ ਲਈ, ਫਰੇਮਵਰਕ ਦੇ ਨੁਕਤੇ ਅਕਸਰ ਇਹ ਫੈਸਲਾ ਨਹੀਂ ਕਰਦੇ ਕਿ ਉਪਭੋਗਤਾ ਪਰਵਾਹ ਕਰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
Vibe coding ਉਹਨਾਂ ਬਿਲਡਰਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਲਗਾਤਾਰ ਮਜ਼ਬੂਤ ਉਤਪਾਦੀ ਫੈਸਲੇ ਲੈਂਦੇ ਹਨ: ਇੱਕ ਸਪੱਸ਼ਟ ਉਪਭੋਗਤਾ ਚੁਣਨਾ, ਜੌਬ-ਟੂ-ਬੀ-ਡਨ ਨੂੰ ਸੀਮ ਕਰਨਾ, ਸਭ ਤੋਂ ਸਧਾਰਨ ਫਲੋ ਤਿਆਰ ਕਰਨਾ, ਅਤੇ ਫੀਡਬੈਕ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣਾ। ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਕਰ ਸਕਦੇ ਹੋ, AI ਅਤੇ ਆਧੁਨਿਕ ਟੂਲਾਂ "ਜਾਣਦਾ ਹੈ ਹਰ ਫਰੇਮਵਰਕ ਵੇਰਵਾ" ਨਾਲ "ਇਸ ਹਫ਼ਤੇ ਇੱਕ ਉਪਯੋਗੀ ਅਨੁਭਵ ਦੇ ਸਕਦਾ ਹੈ" ਦੇ ਵਿਚਕਾਰ ਦੀ ਖਾਈ ਨੂੰ ਘਟਾ ਦਿੰਦੀਆਂ ਹਨ।
Vibe coding ਕੋਡ ਲਿਖਣ ਨੂੰ ਸਸਤਾ ਕਰਦਾ ਹੈ। ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ, ਇਹ ਕਿਸ ਲਈ ਹੈ, ਅਤੇ ਕਾਮਯਾਬੀ ਕੀ ਹੈ। ਜਦੋਂ AI ਇੱਕ UI ਦਾ ਸਕੈਫੋਲਡ ਤਿਆਰ ਕਰ ਸਕਦਾ, CRUD ਰੂਟ ਜਨਰੇਟ ਕਰ ਸਕਦਾ, ਅਤੇ ਮਿੰਟਾਂ ਵਿੱਚ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ, ਤਾਂ ਰੁਕਾਵਟ ਹੁਣ ਹੁੰਦੀ ਹੈ “ਕੀ ਅਸੀਂ ਇਹ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਾਂ?” ਦੇ ਬਦਲੇ “ਕੀ ਇਹ ਸਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਅਸੀਂ ਲਾਗੂ ਕਰ ਰਹੇ ਹਾਂ?”
ਜਿਨ੍ਹਾਂ ਬਿਲਡਰਾਂ ਕੋਲ ਮਜ਼ਬੂਤ ਉਤਪਾਦੀ ਸੁਝਾਨ ਹੈ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹਨ, ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਉਹ ਤੇਜ਼ ਟਾਈਪ ਕਰਦੇ ਹਨ, ਪਰ ਇਸ ਲਈ ਕਿ ਉਹ ਘੱਟ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੇ ਹਨ। ਉਹ ਘੱਟ ਗਲਤ ਮੋੜ ਖਾਂਦੇ ਹਨ, ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਚੰਗੇ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ, ਅਤੇ ਵਿਚਾਰਾਂ ਨੂੰ ਐਸੇ ਵਰਜ਼ਨ ਵਿੱਚ ਘਟਾਉਂਦੇ ਹਨ ਜੋ ਜਲਦੀ ਟੈਸਟ ਕੀਤਾ ਜਾ ਸਕੇ।
ਸਪੱਸ਼ਟ ਸਮੱਸਿਆ ਫਰੇਮਿੰਗ ਕਿਸੇ ਵੀ ਫਰੇਮਵਰਕ ਫੀਚਰ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਰੀਵਰਕ ਘਟਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ:
…ਤਾਂ ਜੋ ਕੋਡ ਤੁਸੀਂ ਜਨਰੇਟ ਕਰੋਗੇ ਉਸਦੀ ਪਹਿਲੀ ਹਫ਼ਤਾ ਵਾਲੀ ਸਹਾਇਤਾ ਬਿਹਤਰ ਜੀਵੰਤ ਫੀਡਬੈਕ ਵਿੱਚ ਜੀਵਤ ਰਹਿਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਜਾੲੇਗੀ।
ਉਸ ਸਪੱਸ਼ਟਤਾ ਦੇ ਬਿਨਾਂ, ਤੁਸੀਂ ਤਕਨੀਕੀ ਰੂਪ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਫੀਚਰ ਸ਼ਿਪ ਕਰੋਗੇ ਜੋ ਸਿੱਖਣ ਤੋਂ ਬਾਅਦ ਰੀਰਾਈਟ ਜਾਂ ਹਟਾਏ ਜਾਂਦੇ ਹਨ।
ਇੱਕ “ਸਟੱਡੀ ਪਲੈਨਰ” ਐਪ ਦੀ ਕਲਪਨਾ ਕਰੋ।
Team A (ਫਰੇਮਵਰਕ-ਪਹਿਲਾ) ਬਣਾਉਂਦਾ ਹੈ: ਖਾਤੇ, ਕੈਲੰਡਰ, ਸੂਚਨਾਵਾਂ, ਟੈਗ, ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਅਤੇ ਇੱਕ ਡੈਸ਼ਬੋਰਡ।
Team B (ਉਤਪਾਦ-ਪਹਿਲਾ) ਦੋ ਦਿਨਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰਦਾ ਹੈ: ਇੱਕ ਸਿੰਗਲ ਸਕ੍ਰੀਨ ਜਿੱਥੇ ਸਟੂਡੈਂਟ ਇੱਕ ਇਮਤਿਹਾਨ ਦੀ ਤਾਰੀਖ ਚੁਣਦਾ ਹੈ, ਵਿਸ਼ੇ ਦਾਖਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਰੋਜ਼ਾਨਾ ਚੈਕਲਿਸਟ ਮਿਲਦੀ ਹੈ। ਕੋਈ ਖਾਤੇ ਨਹੀਂ—ਸਿਰਫ਼ ਇੱਕ ਸ਼ੇਅਰੇਬਲ ਲਿੰਕ।
Team B ਤੁਰੰਤ ਫੀਡਬੈਕ ਲੈਂਦਾ ਹੈ (“ਚੈਕਲਿਸਟ ਵਧੀਆ ਹਨ, ਪਰ ਮੈਨੂੰ ਸਮਾਂ ਅੰਦਾਜ਼ੇ ਚਾਹੀਦੇ ਹਨ”)। Team A ਅਜੇ ਵੀ ਸੈਟਿੰਗ ਪੰਨਿਆਂ 'ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।
Vibe coding ਉਸ ਬਿਲਡਰ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਮੁੱਲ ਕੱਟ ਕੇ ਬਿਨਾਂ ਕੀਮਤੀ ਗੁਣ ਖੋਹੇ ਸਕੋਪ ਘਟਾ ਸਕਦਾ—ਕਿਉਂਕਿ ਇਹੀ ਕੋਡ ਨੂੰ ਤਰੱਕੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
AI ਬਹੁਤ ਸਾਰੀ “ਕਬੂਲਯੋਗ” ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਬੋਤਲਨੇਕ ਟਾਈਪ ਕਰਨ ਤੋਂ ਬਦਲ ਕੇ ਇਹ ਬਣ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ, ਕਿਉਂ, ਅਤੇ ਕੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਹੈ। ਜਿੱਤਣ ਵਾਲੇ ਬਿਲਡਰ ਉਹ ਨਹੀਂ ਜੋ ਹਰ ਫਰੇਮਵਰਕ ਦਾ ਕੋਨਾ-ਕੋਨਾ ਜਾਣਦੇ ਹਨ—ਇਹ ਉਹ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਉਤਪਾਦੀ ਸੁਝਾਨ ਕੰਮ ਨੂੰ ਅਸਲ ਉਪਭੋਗਤਾ ਮੁੱਲ ਵੱਲ ਰੱਖਦੇ ਹਨ।
ਸਮੁਦਰਤਾ ਉਹ ਕਾਬਲੀਅਤ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਦੇ ਦਿਨ ਨੂੰ ਜ਼ਾਹਿਰ ਕਰੇ ਅਤੇ ਵੇਖੇ ਕਿ ਤੁਹਾਡਾ ਉਤਪਾਦ ਕਿੱਥੇ ਮਦਦ ਕਰਦਾ ਹੈ (ਜਾਂ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ)। Vibe coding ਵਿੱਚ, ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਕਈ UI ਅਤੇ ਫੀਚਰ ਵਿਕਲਪ ਜਨਰੇਟ ਕਰੋਗੇ। ਸਮੁਦਰਤਾ ਤੁਹਾਨੂੰ ਉਹ ਚੁਣਨ ਵਿੱਚ ਸਹਾਇਤਾ ਦਿੰਦੀ ਹੈ ਜੋ ਭੁੱਲ, ਕਦਮ ਅਤੇ ਕੋਗਨਟਿਵ ਲੋਡ ਘਟਾਉਂਦੇ ਹਨ—ਬਿਨਾਂ ਔਖੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਲੋੜ ਦੇ।
ਜਦੋਂ ਹਰ ਚੀਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਹਰ ਚੀਜ਼ ਜੋੜਨ ਦੀ ਲਾਲਸਾ ਹੁੰਦੀ ਹੈ। ਮਜ਼ਬੂਤ ਤਰਜੀਹ ਨਿਰਧਾਰਨ ਦਾ ਮਤਲਬ ਹੈ ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਫੀਚਰ ਸੈੱਟ ਚੁਣਨਾ ਜੋ ਵਿਚਾਰ ਨੂੰ ਸਾਬਤ ਕਰੇ। ਇਸਦਾ ਮਤਲਬ ਹੈ “ਇੱਕ ਚੀਜ਼” ਦੀ ਰੱਖਿਆ ਕਰਨਾ ਜੋ ਉਤਪਾਦ ਨੂੰ ਬੇਹਤਰੀਨ ਬਣਾਉਂਦੀ।
ਸਪਸ਼ਟਤਾ ਤੀਖੇ ਸਮੱਸਿਆ ਬਿਆਨਾਂ, ਸਧਾਰਨ ਯੂਜ਼ਰ ਫਲੋ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਕਾਪੀ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਵਰਨਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਫੀਚਰ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਕੀ ਹੈ, ਤਾਂ AI-ਜਨਰੇਟਡ ਕੋਡ ਸੰਭਵਤ: AI-ਜਨਰੇਟਡ ਗੜਬੜ ਬਣ ਜਾਵੇਗਾ।
ਸਵਾਦ ਸਿਰਫ਼ ਸੁੰਦਰਤਾ ਨਹੀਂ। ਇਹ ਉਹ ਅਨੁਭਵ ਹੈ ਜੋ ਸਭ ਤੋਂ ਸਧਾਰਨ ਹੱਲ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਜੋ ਫਿਰ ਵੀ ਚਟਕਾਰੇਦਾਰ ਅਤੇ "ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਠੀਕ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ—ਘੱਟ ਸੈਟਿੰਗ, ਘੱਟ ਸਕ੍ਰੀਨ, ਘੱਟ ਐਡਜ-ਕੇਸ ਵਾਅਦੇ। ਸਵਾਦ ਤੁਹਾਨੂੰ ਕਹਿਣ 'ਚ ਮਦਦ ਕਰਦਾ ਹੈ, “ਇਹ ਕਾਫੀ ਹੈ,” ਫਿਰ ਸ਼ਿਪ ਕਰੋ।
ਕੱਟਨਾ ਮਿਆਰੀ ਨੂੰ ਘਟਾਉਣਾ ਨਹੀਂ; ਇਹ ਗੈਰ-ਆਵਸ਼ਯਕ ਸਕੋਪ ਨੂੰ ਹਟਾਉਣਾ ਹੈ ਜਦੋਂ ਕੋਰ ਲਾਭ ਬਰਕਰਾਰ ਰਹੇ। ਇੱਥੇ ਉਤਪਾਦ-ਪਹਿਲੇ ਬਿਲਡਰ ਅੱਗੇ ਰਹਿੰਦੇ ਹਨ: ਡੂੰਘਾ ਫਰੇਮਵਰਕ ਗਿਆਨ ਕਾਰਜਨੁਸ਼ੀਲਤਾ ਨੂੰ ਸੁਧਾਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸੁਝਾਨ ਨਤੀਜੇ ਦੀ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਕਰਦੇ ਹਨ।
ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਕਿਸੇ ਫਰੇਮਵਰਕ ਨੂੰ ਅੰਦਰੋਂ-ਬਾਹਰ ਜਾਣਨਾ ਇੱਕ ਵੱਡੀ ਫਾਇਦੇਮੰਦ ਸੀ। ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਛੋਟੇ-ਛੋਟੇ ਅਮਲ ਕਰ ਸਕਦੇ ਸਨ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ API ਵੇਰਵੇ ਸਨ, ਤੁਸੀਂ ਆਮ ਗਲਤੀਆਂ ਤੋਂ ਬਚਦੇ, ਅਤੇ ਫੀਚਰ ਸੰਯੋਜਿਤ ਕਰਨ ਲਈ ਰੁਕਦੇ ਨਹੀਂ ਸੀ।
AI-ਸਹਾਇਤ ਕੋਡਿੰਗ ਅਤੇ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ ਟੈਂਪਲੇਟ ਉਸ ਫਾਇਦੇ ਨੂੰ ਕਸਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਹਾਇਕ ਤੋਂ ਪੁੱਛ ਸਕਦੇ ਹੋ, “Next.js ਵਿੱਚ auth middleware ਕਿਵੇਂ ਲਾਗੂ ਕਰਾਂ?” ਜਾਂ “X ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ CRUD ਸਕ੍ਰੀਨ ਜਨਰੇਟ ਕਰੋ,” ਤਾਂ ਸਹਾਇਕ ਸਕੈਫੋਲਡ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਫਾਈਲਾਂ ਨੂੰ ਨਾਮ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਆਮ ਰਿਵਾਜ਼ ਦੀ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ।
ਟੈਂਪਲੇਟ ਹੋਰ ਅੱਗੇ ਲੈ ਜਾਂਦੇ ਹਨ: ਸਟੈਂਡਰਡ ਪ੍ਰੋਜੈਕਟ ਹੁਣ ਰਾਊਟਿੰਗ, auth, ਫਾਰਮ, UI ਕੰਪੋਨੈਂਟ ਅਤੇ ਡਿਪਲੌਇਮੈਂਟ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਵਾਇਰਡ ਹੁੰਦੇ ਹਨ। ਦਿਨਾਂ ਬਜਾਏ, ਤੁਸੀਂ ਉਸ ਪੁਆਇੰਟ ਤੇ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਜਿੱਥੇ ਵਾਸਤਵਿਕ ਉਤਪਾਦੀ ਫੈਸਲੇ ਮਹੱਤਵਪੂਰਕ ਹਨ।
ਜੇ ਤੁਸੀਂ ਇਸਦਾ ਹੋਰ ਐਂਡ-ਟੂ-ਐਂਡ ਵਰਜ਼ਨ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਇਹ ਵਿਚਾਰ ਹੋਰ ਅੱਗੇ ਲੈ ਜਾਂਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਇੱਕ ਐਪ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਸਕ੍ਰੀਨ ਅਤੇ ਫਲੋ 'ਤੇ ਦੁਹਰਾਅ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਕੰਮ ਕਰ ਰਹੀ ਵੈੱਬ/ਬੈਕਐਂਡ/ਮੋਬਾਈਲ ਬੁਨਿਆਦ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ: React ਫਰੰਟਐਂਡ, Go + PostgreSQL ਬੈਕਐਂਡ, Flutter ਮੋਬਾਈਲ)। ਮਕਸਦ ਕਿਸੇ ਖਾਸ ਸਟੈਕ ਦਾ ਨਹੀਂ—ਇਹ ਹੈ ਕਿ ਸੈਟਅਪ ਟਾਈਮ ਘੱਟ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਉਤਪਾਦੀ ਫੈਸਲੇ ਪ੍ਰਭਾਵਤ ਹੁੰਦੇ ਹਨ।
ਅਕਸਰ ਜੋ ਚੀਜ਼ ਟੀਮਾਂ ਨੂੰ ਧੀਮਾ ਕਰਦੀ ਹੈ ਉਹ ਹੋਰ endpoint ਲਿਖਣਾ ਜਾਂ ਪਲੱਗਇਨ ਕਨਫਿਗਰ ਕਰਨਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਹੁੰਦਾ ਹੈ:
AI glue ਕੋਡ ਸਸਤਾ ਕਰਦਾ ਹੈ—ਸਰਵਿਸਾਂ ਨੂੰ ਜ਼ੁੜਨ, ਬੋਇਲਰਪਲੇਟ ਜਨਰੇਟ ਕਰਨ, ਲਾਇਬ੍ਰੇਰੀਜ਼ ਦਰਮਿਆਨ ਪੈਟਰਨ ਟ੍ਰਾਂਸਲੈਟ ਕਰਨ ਵਿੱਚ। ਪਰ ਇਹ ਪੱਕੇ ਤੌਰ 'ਤੇ ਫੈਸਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕੀ ਬਣਾਉਣਾ ਲਾਇਕ ਹੈ, ਕੀ ਕੱਟਣਾ ਹੈ, ਜਾਂ ਸਫਲਤਾ ਕੀ ਦਿਖਦੀ ਹੈ। ਇਹ ਉਤਪਾਦੀ ਸੁਝਾਨ ਹਨ।
ਫਰੇਮਵਰਕ ਦੀਆਂ ਸਭ ਤੋਂ ਵਧੀਆ ਪ੍ਰਥਾਵਾਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ: ਨਵੇਂ ਰਾਊਟਰ, ਨਵਾਂ ਡਾਟਾ-ਫੈਚਿੰਗ ਪੈਟਰਨ, ਨਵੀਆਂ ਸਿਫਾਰਿਸ਼ ਕੀਤੀਆਂ ਟੂਲਿੰਗ। ਇਸ ਦੇ ਨਾਲ-ਨਾਲ, ਉਪਭੋਗਤਾ ਦੀਆਂ ਲੋੜਾਂ ਮੁਕੱਦਰ ਤੌਰ 'ਤੇ ਇਕੋ ਰਹਿੰਦੀਆਂ ਹਨ: ਸਪਸ਼ਟਤਾ, ਤੇਜ਼ੀ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਇੱਕ ਵਰਕਫਲੋ ਜੋ ਉਹ ਸੋਚਦੇ ਹਨ ਉਸ ਦੇ ਮਿਲਦਾ ਜੁਲਦਾ ਹੋਵੇ।
ਇਸ ਲਈ vibe coding ਉਹ ਬਿਲਡਰਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਸਹੀ ਸਮੱਸਿਆ ਚੁਣ ਸਕਦੇ ਹਨ, ਹੱਲ ਸਧਾਰਨ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਅਸਲ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਦੁਹਰਾਅ ਕਰਦੇ ਹਨ—ਸਿਰਫ਼ ਉਹ ਨਹੀਂ ਜੋ ਫਰੇਮਵਰਕ ਇੰਟਰਨਲ ਯਾਦ ਰੱਖ ਸਕਦੇ ਹਨ।
Vibe coding ਸਭ ਤੋਂ ਵਧੀਆ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਮਾਰਤ ਨਿਰਮਾਣ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ, ਬਲਕਿ ਛੋਟੇ ਦਾਅਵੇ ਵਾਂਗ ਬਿਲਡਿੰਗ ਕਰਦੇ ਹੋ। ਲਕਸ਼ “ਕੋਡਬੇਸ ਨੂੰ ਮੁਕੰਮਲ ਕਰਨਾ” ਨਹੀਂ ਹੈ। ਲਕਸ਼ ਹੈ ਅਣਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣਾ—ਉਪਭੋਗਤਾ, ਸਮੱਸਿਆ ਅਤੇ ਮੁੱਲ ਬਾਰੇ—ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਮਹੀਨੇ ਉਸ ਗਲਤ ਚੀਜ਼ ਨੂੰ ਪਾਲिश ਕਰਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਉਤਪਾਦ ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:
Hypothesis → prototype → test → learn → iterate.
ਇਹ ਲੂਪ ਉਤਪਾਦੀ ਸੁਝਾਨ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਫੈਸਲੇ ਸਪਸ਼ਟ ਕਰਨ ਨੂੰ ਮਜਬੂਰ ਕਰਦਾ ਹੈ: ਕੀ ਜਰੂਰੀ ਹੈ, ਕੀ ਸ਼ੋਰ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਸਿਗਨਲ ਤੁਹਾਡਾ ਮਨ ਬਦਲ ਦੇਵੇਗਾ।
ਸ਼ੁਰੂਆਤੀ “ਪੂਰਨ ਕੋਡ” ਅਕਸਰ ਉਹ ਸਮੱਸਿਆਵਾਂ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਨਹੀਂ ਹਨ: ਉਹ ਸਕੇਲ ਜੋ ਤੁਸੀਂ ਅਰਜੀ ਨਹੀਂ ਕਮਾਈ, ਅਜਿਹੇ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਜੋ ਤੁਸੀਂ ਸਮਝਦੇ ਨਹੀਂ, ਐਡਜ-ਕੇਸ ਜੋ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾ ਨਹੀਂ ਮਿਲਦੇ। ਇਸ ਦੌਰਾਨ, ਸਭ ਤੋਂ ਵੱਡਾ ਖ਼ਤਰਾ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਗਲਤ ਫੀਚਰ ਬਣਾਉ ਰਹੇ ਹੋ ਜਾਂ ਉਸਨੂੰ ਗਲਤ ਢੰਗ ਨਾਲ ਪੇਸ਼ ਕਰ ਰਹੇ ਹੋ।
ਛੋਟੇ ਫੀਡਬੈਕ ਲੂਪ ਇੱਥੇ ਜਿੱਤਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦੇ ਹਨ:
ਜੇ ਪ੍ਰੋਟੋਟਾਈਪ ਕੋਰ ਮੱਲ ਮਹੱਤਵ ਅਸਲੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰੀਫੈਕਟਰ ਕਰਨ ਦਾ ਹੱਕ ਕਮਾਂਦੇ ਹੋ।
ਤੁਹਾਨੂੰ ਮੰਗ ਜਾਂ ਯੂਜ਼ਬਿਲਿਟੀ ਟੈਸਟ ਕਰਨ ਲਈ ਪੂਰੇ ਰਿਲੀਜ਼ ਦੀ ਲੋੜ ਨਹੀਂ:
ਮਕਸਦ ਢਿੱਲਾ ਹੋਣ ਨਹੀਂ—ਇਹ ਸੋਚ-ਸਮਝ ਕੇ ਬਣਾਉਣਾ ਹੈ: ਸਿੱਖਣ ਲਈ ਹੁੰਨੀ ਬਿਲਕੁਲ ਕਾਫੀ ਬਣਾਉ।
Vibe coding ਵਿੱਚ ਇੱਕ ਹੋਰ ਚੀਜ਼ ਜੋੜਨ ਦੀ ਲਾਲਸਾ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ AI ਤੁਰੰਤ ਉਸਨੂੰ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਤੇਜ਼ੀ ਮੁਫ਼ਦ ਨਹੀਂ ਜੇ ਤੁਸੀਂ ਕਦੇ ਸ਼ਿਪ ਨਹੀਂ ਕਰਦੇ। ਜਿੱਤਣ ਵਾਲੇ ਉਹ ਹਨ ਜੋ ਜਲਦੀ ਅਤੇ ਅਕਸਰ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਹੈ।
ਸ਼ਿਪਿੰਗ ਤੇਜ਼ੀ ਨਾਲ ਟਾਈਪ ਕਰਨ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਕੋਰ ਵਾਅਦੇ ਦੀ ਰੱਖਿਆ ਬਾਰੇ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਸਕੋਪ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੱਟਦੇ ਹੋ, ਉਤਪਾਦ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਅਧੂਰਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿਸੇ ਵੀ ਫੀਚਰ ਨੂੰ ਨਾਂ ਕਹਿਣਾ ਜੋ:
MVP ਸਭ ਤੋਂ ਛੋਟੀ ਵਰਜ਼ਨ ਹੈ ਜੋ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਅਤੇ ਵਿਚਾਰ ਨੂੰ ਸਾਬਤ ਕਰਦੀ। ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਰਹੜਕਦਾਰ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਕੀ ਕੋਈ ਇਸਨੂੰ ਵਰਤੇਗਾ?
MLP ਸਭ ਤੋਂ ਛੋਟੀ ਵਰਜ਼ਨ ਹੈ ਜੋ ਨਿਸ਼ਾਨ ਉਪਭੋਗਤਾ ਲਈ ਸਪਸ਼ਟ ਅਤੇ ਮਨਮੋਹਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਹ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਕੋਈ ਯਾਤਰਾ ਪੂਰੀ ਕਰੇਗਾ ਅਤੇ ਮੁੜ ਆਵੇਗਾ ਜਾਂ ਸਿਫ਼ਾਰਸ਼ ਕਰੇਗਾ?
ਇੱਕ ਅਚਛਾ ਨਿਯਮ: MVP ਮੰਗ ਸਾਬਤ ਕਰਦਾ ਹੈ; MLP ਭਰੋਸਾ ਕਮਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੋ ਕਿ ਇਸ ਹਫ਼ਤੇ ਕੀ ਸ਼ਿਪ ਹੋਵੇ, ਹਰ ਆਈਟਮ ਨੂੰ ਇਕ ਥੈਲੇ ਵਿੱਚ ਰੱਖੋ:
Must-have (ਹੁਣ ਸ਼ਿਪ ਕਰੋ)
Nice-to-have (ਜੇ ਸਮਾਂ ਬਚੇ ਤਾਂ ਹੀ)
Later (ਸਪਸ਼ਟ ਤੋਰ ਤੇ ਹੁਣ ਨਹੀਂ)
ਸਕੋਪ ਕੱਟਣਾ ਮਿਆਰ ਘਟਾਉਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਛੋਟਾ ਵਾਅਦਾ ਚੁਣਨਾ ਅਤੇ ਉਸਦੀ ਪਾਲਣਾ ਹੈ।
ਲੋਕ ਤੁਹਾਡੇ ਫਰੇਮਵਰਕ ਚੋਣ ਨਾਲ ਪਿਆਰ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਉਸ ਪਲ ਨਾਲ ਪਿਆਰ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੇ ਹਨ। Vibe coding ਵਿੱਚ, ਜਿੱਥੇ AI ਤੇਜ਼ੀ ਨਾਲ "ਕੰਮ ਕਰਨ ਵਾਲੇ" ਫੀਚਰ ਜਨਰੇਟ ਕਰ ਸਕਦੀ ਹੈ, ਫਰਕ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਉਤਪਾਦ ਸਪਸ਼ਟ ਵਾਅਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਪਹਿਲੀ ਜਿੱਤ ਤੱਕ ਰਹਿਨੁਮਾਈ ਕਰਦਾ ਹੈ।
ਇੱਕ ਸਪਸ਼ਟ ਵਾਅਦਾ ਤੁਰੰਤ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਇਹ ਕੀ ਹੈ? ਇਹ ਕਿਸ ਲਈ ਹੈ? ਮੈਂ ਪਹਿਲਾਂ ਕੀ ਕਰਾਂ? ਜੇ ਇਹ ਸਪਸ਼ਟ ਨਹੀਂ, ਉਪਭੋਗਤਾ ਬਾਊਂਸ ਕਰ ਲੈਂਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੇ ਤਕਨੀਕੀ ਫੈਸਲੇ ਕਿਸੇ ਕੰਮ ਦੇ ਨਹੀਂ ਬਣਦੇ।
Onboarding ਸਿਰਫ਼ ਉਤਪਾਦ ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਰੂਪ ਤੋਂ ਨਤੀਜੇ ਤੱਕ ਪਹੁੰਚਾਉਣ ਦਾ ਸਭ ਤੋਂ ਛੋਟਾ ਰਾਸਤਾ ਹੈ। ਜੇ ਪਹਿਲੀ ਵਾਰੀ ਦੇ ਅਨੁਭਵ ਲਈ ਪੜ੍ਹਨਾ, ਅਨੁਮਾਨ ਲਾਉਣਾ, ਜਾਂ ਸੈਟਅਪ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਭਰੋਸਾ ਖ਼ਰਚ ਕਰ ਰਹੇ ਹੋ ਜੋ ਤੁਸੀਂ ਕਮਾਇਆ ਨਹੀਂ।
ਇੱਕ ਬਿਲਕੁਲ ਤੈਅ ਕੀਤੀ ਐਪ ਵੀ ਹਾਰ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਉਤਪਾਦ ਉਲਝਣ ਭਰਾ ਹੋਵੇ। ਆਮ ਨੁਕਸਾਨ ਕਰਨ ਵਾਲੇ ਬਿੰਦੂ:
ਘੱਟ ਰਾਹ ਘਟਾ ਕੇ ਇਹ ਨਿਯਮ ਲਾਗੂ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਹੋਰ ਕੁਝ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਪਹਿਲੀ ਕਾਮਯਾਬ ਕਾਰਵਾਈ ਨੂੰ ਸਪਸ਼ਟ, ਤੇਜ਼ ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ ਬਣਾਓ। ਇੱਥੇ ਹੀ ਗਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ—ਅਤੇ ਇੱਥੇ vibe coding ਦਾ ਅਸਲੀ ਮੱਲੀ ਮਿਲਦਾ ਹੈ।
Vibe coding ਕੰਮ ਕਰਨਯੋਗ ਬਣਾਉਣ ਦੀ ਰੁਕਾਵਟ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਫਰੇਮਵਰਕ ਗਿਆਨ ਦੀ ਮਹੱਤਤਾ ਮਿਟਾਉਂਦਾ ਨਹੀਂ। ਇਹ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹ ਗਿਆਨ ਕਿੱਥੇ ਜ਼ਿਆਦਾ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ: API ਯਾਦ ਕਰਨ ਵਿੱਚ ਘੱਟ, ਪਰ ਸਹੀ ਸਮੇਂ 'ਤੇ ਸਹੀ ਟਰੇਡ-ਅਫ਼ ਕਰਨ ਵਿੱਚ ਜ਼ਿਆਦਾ।
ਜੇ ਤੁਹਾਡਾ ਮਕਸਦ ਸ਼ਿਪ ਕਰਨਾ ਅਤੇ ਸਿੱਖਣਾ ਹੈ, ਤਾਂ ਇੱਕ ਐਸਾ ਸਕੈੱਟ ਚੁਣੋ ਜੋ:
ਇੱਕ ਸਮਝਦਾਰ ਡਿਫਾਲਟ ਅਕਸਰ “ਲੋਕਪ੍ਰਿਆ ਫਰੰਟਐਂਡ + ਰੁਟਿਨ ਬੈਕਐਂਡ + ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ + ਹੋਸਟਡ auth” ਵਰਗਾ ਹੁੰਦਾ ਹੈ—ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਇਹ ਟ੍ਰੈਂਡੀ ਹੈ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਇਹ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਨਾਲ ਲੜਾਈ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਮੱਲ ਨੂੰ ਵੈਰਿਫਾਈ ਕਰਨ 'ਤੇ ਫੋਕਸ ਵਧਾਉਂਦਾ ਹੈ।
ਸਭ ਤੋਂ ਆਮ ਨੁਕਸਾਨ-ਮੋਡ “ਫਰੇਮਵਰਕ-ਬਦਲਣਾ” ਹੈ: ਇੱਕ ਨਵੀਂ ਲਾਇਬਰੇਰੀ ਦੇਖ ਕੇ ਦੁਬਾਰਾ ਲਿਖਣਾ, ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟਰਿਕਸ ਦੀ ਪਿੱਛੇ ਦੌੜਨਾ ਜਦ ਤੱਕ ਉਪਭੋਗਤਿਆਂ ਨੇ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਕੀਤੀ।
ਪੂਰਵ-ਕਮਾਈ ਉਪਟਿਮਾਈਜ਼ੇਸ਼ਨ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀ ਹੈ:
ਜੇ ਵਰਕਅਰਾਉਂਡ ਥੋੜ੍ਹਾ ਢਿੰਗਲਾ ਪਰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਵਾਪਸੀਯੋਗ ਹੈ, ਤਾਂ ਸਿਖਾਈ ਦੇ ਦੌਰਾਨ ਇਹ ਅਕਸਰ ਸਹੀ ਚੋਣ ਹੁੰਦੀ ਹੈ।
ਗਹਿਰਾ ਫਰੇਮਵਰਕ ਗਿਆਨ ਉਹ ਵੇਲੇ ਮੁੱਲਵਾਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਐਸੇ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਹੋਵੇ ਜੋ AI ਸਧਾਰਣ ਟੁਕੜਿਆਂ ਨਾਲ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ:
ਨਿਯਮ-ਹਾਰ: AI ਅਤੇ ਸਰਲ ਪੈਟਰਨ ਨਾਲ “ਕੰਮ ਕਰਦਾ” ਦਰਜੇ ਤੱਕ ਪਹੁੰਚੋ, ਫਿਰ ਜਦੋਂ ਰਿਅਲ ਮਾਪਦੰਡ ਜਾਂ ਘਟਨਾਵਾਂ ਦਿਖਾਈ ਦੇਣ, ਫਰੇਮਵਰਕ ਡਿਪਥ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ।
Vibe coding ਜਾਦੂ ਹੋ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਵਰਣਨ ਕਰੋ, AI ਖਾਲੀ ਥਾਵਾਂ ਭਰ ਦੇਵੇ, ਅਤੇ ਕੁਝ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰੇ। ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਤੇਜ਼ੀ ਇਹ ਛੁਪਾ ਸਕਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਗਨਲ ਭੇਜ ਰਹੇ ਹੋ ਜਾਂ ਸ਼ੋਰ।
ਇੱਕ ਫੰਦਾ ਹੈ ਅਜਿਹਾ ਫੀਚਰ ਸ਼ਿਪ ਕਰਨਾ ਜੋ ਜਨਰੇਟ ਕਰਨ ਲਈ ਆਸਾਨ ਹੋ ਪਰ ਜਿਨ੍ਹਾਂ ਦਾ ਢੰਗ ਸਹੀ ਢੰਗ ਨਾਲ ਜਾਇਜ਼ਾ ਨਹੀਂ। ਤੁਸੀਂ ਛੋਟੇ ਇੰਟਰੈਕਸ਼ਨ ਪਾਲਿਸ਼ ਕਰਦੇ ਰਹਿੰਦੇ ਹੋ, ਸੈਟਿੰਗਾਂ ਜੋੜਦੇ ਹੋ, ਜਾਂ UI ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹੋ ਕਿਉਂਕਿ ਇਹ ਮਜ਼ੇਦਾਰ ਹੈ—ਜਦਕਿ ਅਸਲ ਉਪਭੋਗਤਾ ਸਮੱਸਿਆ ਅਜ਼ਮਾਈ ਨਹੀਂ ਗਈ।
ਦੂਜਾ ਹੈ ਸਿਰਫ਼ ਆਪਣੇ ਲਈ ਬਣਾਉਣਾ। ਜੇ ਇਕੱਲਾ ਫੀਡਬੈਕ ਲੂਪ ਤੁਹਾਡਾ ਆਪਣਾ ਉਤਸ਼ਾਹ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੰਪ੍ਰੈੱਸਿਵ ਪਰ ਨਾ-ਟਿਕਨ ਵਾਲੀ ਚੀਜ਼ ਬਣਾਉਂਦੇ ਹੋ। ਨਤੀਜਾ ਇੱਕ ਐਸਾ ਉਤਪਾਦ ਹੈ ਜੋ ਡੈਮੋ ਵਿਚ ਸੋਹਣਾ ਲੱਗਦਾ ਹੈ ਪਰ टिकਦਾ ਨਹੀਂ।
ਤੀਜਾ ਹੈ “ਸੁਣਨ ਨਾ” ਇੱਕ ਸੁਤੰਤਰ ਰੂਪ: ਫੀਡਬੈਕ ਇਕੱਟਾ ਕਰਨਾ, ਫਿਰ ਉਹਨਾਂ ਟਿੱਪਣੀਆਂ ਤੇ ਮਾਤਰ ਕਾਰਵਾਈ ਕਰਨਾ ਜੋ ਤੁਹਾਡੇ ਮੁਢਲੇ ਵਿਚਾਰ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ। ਇਹ ਇਟਰੇਸ਼ਨ ਨਹੀਂ—ਇਹ ਪੁਸ਼ਟੀਕਰਨ ਹੈ।
AI ਸਕ੍ਰੀਨ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਫੋਲਡ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਬੁਨਿਆਦੀਆਂ ਮਿਟਦੀਆਂ ਨਹੀਂ:
ਜੇ ਇਹ ਗੱਲਾਂ ਹਵਾਈ ਢੰਗ ਨਾਲ ਨਜਰਅੰਦਾਜ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਸ਼ੁਰੂਆਤੀ ਉਪਭੋਗਤਾ ਸਿਰਫ਼ churn ਨਹੀਂ ਹੋਉਂਦੇ; ਉਹ ਭਰੋਸਾ ਗੁਆਂਦੇ ਹਨ।
ਹਰੇਕ ਇਟਰੇਸ਼ਨ ਲਈ ਇੱਕ ਸਫਲਤਾ ਮੈਟਰਿਕ define ਕਰੋ (ਉਦਾਹਰਨ: “3 ਉਪਭੋਗਤਾ bina help ਦੇ onboarding ਪੂਰਾ ਕਰਦੇ ਹਨ”)। ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ changelog ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਦਲਾਅ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਜੁੜ ਸਕੋ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ: ਅਸਲ ਉਪਭੋਗਤਿਆਂ ਨਾਲ ਜਲਦੀ ਟੈਸਟ ਕਰੋ। 5 ਛੋਟੀਆਂ ਸੈਸ਼ਨ ਵੀ ਉਹ ਮਸਲੇ ਬੇਨਕਾਬ ਕਰਦੇ ਹਨ ਜੋ ਕੋਈ prompt ਨਹੀਂ ਲੱਭ ਸਕਦੀ—ਗੁੰਝਲਦਾਰ ਕਾਪੀ, ਗੁੰਮ ਹੋਈ ਹਾਲਤਾਂ, ਅਤੇ ਵਹੋਰਕਲੋਜੀ ਜੋ ਲੋਕ ਸੋਚਦੇ ਨਹੀਂ।
Vibe coding ਸਭ ਤੋਂ ਵਧੀਆ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਨਿਰਮਾਣ ਨੂੰ ਛੋਟੇ ਉਤਪਾਦੀ ਦਾਓਂ ਵਾਂਗ ਦੇਖਦੇ ਹੋ, ਨਾ ਕਿ perfeita ਆਰਕੀਟੈਕਚਰ ਲੱਭਣ ਦੇ ਮਿਸ਼ਨ ਵਜੋਂ। ਇੱਥੇ ਇੱਕ ਵਰਕਫਲੋ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਮੁੱਲ, ਸਿੱਖਣ, ਅਤੇ ਸ਼ਿਪਿੰਗ 'ਤੇ ਧਿਆਨ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ।
ਟਾਰਗੇਟ ਨੂੰ ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਬਣਾਉ: “ਜੋ ਫ੍ਰੀਲੈਂਸ ਡਿਜ਼ਾਈਨਰ 5–10 ਇਨਵੌਇਸ/ਹਫ਼ਤਾ ਭੇਜਦੇ ਹਨ” "ਸਮਾਨ" “ਛੋਟੇ ਵਪਾਰ” ਤੋ ਬਿਹਤਰ ਹੈ। ਫਿਰ ਇਕ ਸਪਸ਼ਟ ਸਮੱਸਿਆ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ।
ਅਖੀਰ 'ਚ, ਇੱਕ ਇਕਲ ਨਤੀਜਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਤੁਸੀਂ ਦੋ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਮਾਪ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ: “2 ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਇਨਵੌਇਸ ਬਣਾਉਣਾ ਅਤੇ ਭੇਜਣਾ” ਜਾਂ “ਹਫ਼ਤੇ ਵਿਚੋਂ 5 ਤੋਂ 1 ਤੱਕ ਮਿਸਡ ਫਾਲੋਅੱਪ ਘਟਾਉਣਾ”)। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਮਾਪ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਸਿੱਖ ਨਹੀਂ ਸਕੋਗੇ।
ਤੁਹਾਡਾ “ਡਨ” ਤਕਨੀਕੀ ਨਹੀਂ, ਬਲਕਿ ਉਪਭੋਗਤਾ-ਦਿੱਖਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਹੋਰ ਸਭ ਕੁਝ “ਬਾਅਦ ਵਿੱਚ” ਵਿੱਚ ਜਾਏ।
ਸਭ ਤੋਂ ਛੋਟੀ ਵਰਜ਼ਨ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ, ਉਸਦਾ ਯੋਜ਼ਨਾਬੱਧ ਸਮਾਂ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ ਚੈਟ-ਚਲਿਤ ਬਿਲਡ ਟੂਲ ਵਰਤ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, Koder.ai), ਤਾਂ ਇਹ ਥਾਂ ਜਿੱਥੇ ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਫਲੋ 'ਤੇ ਯੋਜਨਾਬੱਧ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਅ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਉਸਦੀ snapshot ਲੈ ਸਕਦੇ ਹੋ, ਅਤੇ ਜੇ ਕੋਈ ਪ੍ਰਯੋਗ ਉਤਪਾਦ ਨੂੰ ਖਰਾਬ ਕਰਦਾ ਹੈ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲ-ਬੈਕ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ ਲੂਪ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਅਨੁਸ਼ਾਸਨ ਬਰਕਰਾਰ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ ਇਸ਼ੂ ਲਿਸਟ ਵਰਤੋਂ (GitHub Issues, Linear, ਜਾਂ ਇੱਕ ਸਿੰਗਲ ਦਸਤਾਵੇਜ਼), ਰੋਜ਼ਾਨਾ 60–90 ਮਿੰਟ ਬਿਨਾਂ ਰੁਕਾਵਟ ਦੇ ਨਿਰਮਾਣ ਲਈ ਬਲੋਕ ਕਰੋ, ਅਤੇ ਹਫ਼ਤਾਵਾਰ 20 ਮਿੰਟ ਦੇ ਯੂਜ਼ਰ ਕਾਲ ਨਿਯਤ ਕਰੋ। ਹਰ ਕਾਲ ਵਿੱਚ, ਉਨ੍ਹਾਂ ਨੂੰ ਕੋਰ ਟਾਸਕ ਕਰਨ ਵੇਲੇ ਦੇਖੋ ਅਤੇ ਜਿੱਥੇ ਉਹ ਹਚਕਚਾਉਂਦੇ ਹਨ, ਓਥੇ ਨੋਟ ਲਓ—ਉਹ ਪਲ ਤੁਹਾਡੇ ਰੋਡਮੈਪ ਦੇ ਨਕਸ਼ੇ ਹਨ।
Vibe coding ਤੇਜ਼ੀ ਨਾਲ ਫੀਚਰ ਜਨਰੇਟ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਤੇਜ਼ੀ ਸਿਰਫ਼ ਉਸੇ ਵਕਤ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪਤਾ ਲਗਾ ਸਕੋ ਕਿ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਮੈਟਰਿਕਸ ਤੁਹਾਨੂੰ “ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ” ਤੋਂ “ਸਬੂਤ” ਤੱਕ ਲੈ ਜਾਂਦੇ ਹਨ।
ਕੁਝ ਸੰਕੇਤ ਜੋ ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ ਲਾਗੂ ਰਹਿੰਦੇ ਹਨ:
ਲੀਡਿੰਗ ਇੰਡਿਕੇਟਰ ਜਲਦੀ ਨਤੀਜੇ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ: “% ਉਪਭੋਗਤਾ ਜੋ onboarding ਪੂਰਾ ਕਰਦੇ ਹਨ” ਅਕਸਰ retention ਦੀ ਪੇਸ਼ਗੋਈ ਕਰਦਾ ਹੈ।
ਲੈਗਿੰਗ ਇੰਡਿਕੇਟਰ ਬਾਅਦ ਵਿੱਚ ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ: “30-ਦਿਨ ਰਿਟੇਨਸ਼ਨ” ਜਾਂ “ਮਾਸਿਕ ਆਮਦਨ”। ਇਹ ਲਾਭਦਾਇਕ ਹਨ, ਪਰ ਸਲੋ।
ਜਦੋਂ ਤੁਸੀਂ ਫੀਚਰ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਉਸਨੂੰ ਇੱਕ ਮੈਟਰਿਕ ਨਾਲ ਜੋੜੋ।
ਜੇ activation ਘੱਟ ਹੈ, ਤਾਂ ਹੋਰ ਫੀਚਰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ onboarding, defaults ਅਤੇ ਪਹਿਲੀ-ਚਲਨ ਅਨੁਭਵ ਸੁਧਾਰੋ।
ਜੇ activation ਠੀਕ ਹੈ ਪਰ retention ਕਮਜ਼ੋਰ ਹੈ, ਤਾਂ ਦੁਹਰਾਈ ਵਾਲੀ ਮੁੱਲ 'ਤੇ ਕੰਮ ਕਰੋ: ਯਾਦ ਦਿਵਾਵਾਂ, saved state, ਟੈਮਪਲੇਟ, ਜਾਂ ਇੱਕ ਸਪਸ਼ਟ "ਅਗਲਾ ਕਦਮ"।
ਜੇ retention ਠੀਕ ਹੈ ਪਰ revenue ਫਲੇਟ ਹੈ, ਤਾਂ ਪੈਕੇਜਿੰਗ 'ਤੇ ਧਿਆਨ ਦਿਓ: ਯੋਜਨਾ ਸੀਮਾਵਾਂ, ਕੀਮਤ ਪੇਜ ਦੀ ਸਪਸ਼ਟਤਾ, ਜਾਂ ਇੱਕ ਮਹੱਤਵਪੂਰਕ paid ਫੀਚਰ।
ਇਹ ਉਤਪਾਦੀ ਸੁਝਾਨ ਦਾ ਕਾਰਜ ਹੈ: ਬਣਾਓ, ਮਾਪੋ, ਸਿੱਖੋ—ਫਿਰ ਅੰਕੜਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਦੋਬਾਰਾ ਬਣਾਓ।
Vibe coding ਇੱਕ ਗਤੀ ਗੁਣਾ-ਵਧਾਉਣ ਵਾਲਾ ਹੈ—ਪਰ ਸਿਰਫ਼ ਜਦੋਂ ਤੁਸੀਂ ਉਤਪਾਦੀ ਸੁਝਾਨ ਨਾਲ ਸਟੀਅਰ ਕਰ ਰਹੇ ਹੋ। ਫਰੇਮਵਰਕ ਡਿਪਥ ਫਿਰ ਵੀ ਮਦਦ ਕਰਦੀ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸਹਾਇਕ ਕਿਰਦਾਰ ਨਿਭਾਂਦਾ ਹੈ: ਜਿੱਤਣ ਵਾਲੇ ਉਹ ਬਿਲਡਰ ਹਨ ਜੋ ਸਹੀ ਸਮੱਸਿਆ ਚੁਣ ਸਕਦੇ, ਇੱਕ ਸਪਸ਼ਟ ਵਾਅਦਾ ਢਾਲ ਸਕਦੇ, ਅਤੇ ਅਸਲ ਉਪਭੋਗਤਿਆਂ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਸਕਦੇ ਹਨ।
ਇਹ ਵਰਤੋਂ ਨਾਲ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਚੀਜ਼ ਪਹਿਲਾਂ ਘੁੰਮਦੀ ਹੈ—ਅਤੇ ਕੀ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ:
ਜੇ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਘੱਟ ਸਕੋਰ scope discipline ਜਾਂ feedback velocity ਵਿੱਚ ਹਨ, ਤਾਂ “ਹੋਰ ਫਰੇਮਵਰਕ ਪੜ੍ਹੋ” ਨਹੀਂ—ਆਪਣੀ ਲੂਪ ਨੂੰ ਤੰਗ ਕਰੋ।
ਇਸ ਹਫ਼ਤੇ ਇੱਕ ਉਤਪਾਦੀ ਦਾਅਵਾ ਚੁਣੋ:
ਆਪਣੇ “instinct reps” ਦਾ ਲੋਗ ਰੱਖੋ: ਜੋ ਅਨੁਮਾਨ ਤੁਸੀਂ ਬਣਾਏ, ਉਪਭੋਗਤਿਆਂ ਨੇ ਕੀ ਕੀਤਾ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਉਹੀ ਹੈ ਜੋ ਇੱਕ ਹੋਰ ਫਰੇਮਵਰਕ API ਯਾਦ ਕਰਨ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸੰਚਿਤ ਹੋਵੇਗਾ।
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਸਿੱਖਣ ਸਾਂਝੇ ਕਰਦੇ ਹੋ, ਕੁਝ ਪਲੇਟਫਾਰਮ (ਸ਼ਾਮਲ Koder.ai) ਸਮੱਗਰੀ ਅਤੇ ਰੈਫਰਲ ਲਈ ਕ੍ਰੈਡਿਟ ਦੇਣ ਵਾਲੇ ਕਾਰਜਾਂ ਚਲਾਉਂਦੇ ਹਨ—ਇੱਕ ਵਾਧੂ ਪ੍ਰੋਤਸਾਹਨ ਤੁਹਾਡੀ ਲੂਪ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਲਈ।
Vibe coding ਇਕ ਤੇਜ਼, ਦੁਹਰਾਊ ਤਰੀਕਾ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਉਤਪਾਦੀ ਅਨੁਮਾਨ (ਉਹ ਕਿ ਉਪਭੋਗਤਾ ਕੀ ਚਾਹੁੰਦੇ ਹਨ) ਨੂੰ ਆਧੁਨਿਕ ਔਜ਼ਾਰਾਂ (AI ਸਹਾਇਕ, ਟੈਂਪਲੇਟ, ਹੋਸਟ ਕੀਤੀ ਕੰਪੋਨੇਂਟ) ਨਾਲ ਜੋੜਕੇ ਛੋਟੇ, ਉਪਯੋਗੀ ਹਿੱਸੇ ਜਲਦੀ ਸ਼ਿਪ ਕਰਦੇ ਹੋ ਅਤੇ ਅਸਲੀ ਇੰਟਰੈਕਸ਼ਨ ਤੋਂ ਸਿੱਖਦੇ ਹੋ।
ਇਹ ਦਿਖਲਾਈ ਜਾਂ ਤੁਹਾਡੇ ਮਨ ਦੇ ਅਨੁਭਵ ਤੋਂ ਨਹੀਂ—ਇਹ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਤ ਤਜਰਬਾ ਹੈ।
ਨਹੀਂ। ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾਂ ਇੱਕ ਲਕਸ਼, ਬਾਧਾਵਾਂ ਅਤੇ “ਡਨ” ਦਾ ਢੰਗ ਜਰੂਰੀ ਹੈ।
ਫਰਕ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਐਸਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੂਰਾ ਪਲਾਨ ਬਣਾਉਣ ਤੋਂ ਬਚਦੇ ਹੋ ਜੋ ਇਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
ਇਹ “ਕੋਈ ਗੁਣਵੱਤਾ ਨਹੀਂ” ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾਂ ਬੁਨਿਆਦੀ ਸਹੀਤਾ, ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸਾ ਯੋਗਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ auth, permissions ਅਤੇ ਡਾਟਾ ਹੈਂਡਲਿੰਗ ਦੇ ਵ੍ਹਾਲੇ।
Vibe coding ਦਾ ਮਤਲਬ ਹੈ ਗੈਰ-ਅਹੰਕਾਰਕ ਪਾਲਿਸ਼ਿੰਗ ਅਤੇ ਅਗੇਰੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਟਾਲਣਾ, ਨਾਂ ਕਿ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਨੂੰ ਛੱਡ देना।
ਕਿਉਂਕਿ AI “ਕਬੂਲਯੋਗ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ” ਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ, ਰੁਕਾਵਟ ਹੁਣ ਇਸ ਗੱਲ 'ਤੇ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ: ਇਹ ਕਿਸ ਲਈ ਹੈ, ਕੀ ਨਤੀਜਾ ਮਹੱਤਵਪੂਰਣ ਹੈ, ਅਤੇ ਕੀ ਛੱਡਣਾ ਹੈ।
ਉਹ ਬਿਲਡਰ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ ਜੋ ਗਲਤ ਰਾਹਾਂ 'ਤੇ ਘੱਟ ਸਮਾਂ ਖਰਚ ਕਰਦੇ ਹਨ ਅਤੇ ਇਸ ਲਈ ਪਹਿਲੀ ਵਾਰ ਅਸਲ ਉਪਭੋਗਤਿਆਂ ਨਾਲ ਮਿਲ ਕੇ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਸਿੱਖਦੇ ਹਨ।
ਇਹ ਤੇਜ਼ ਫਰੇਮਵਰਕ-ਨਿਰਭਰਤਾ ਤੋਂ ਬਚਣ ਲਈ ਛੋਟੀ ਫਰੇਮ:
ਜੇ ਤੁਸੀਂ ਇਹ ਕੁਝ ਲਾਈਨਾਂ ਵਿੱਚ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਜੋ ਕੋਡ ਜਨਰੇਟ ਕਰਾਂਗੇ ਉਹ ਜ਼ਿਆਦਾਤਰ ਬੇਕਾਰ ਜਾਂ ਰੀਵਰਕ ਬਣ ਜਾਵੇਗਾ।
ਅਜੇਸ਼ ਲਈ ਤਰਜੀਹ ਦਿਓ:
ਇੱਕ ਠੀਕ ਸਕੋਪ ਜੋ ਫੀਡਬੈਕ ਲਿਆਉਂਦਾ ਹੈ, ਇੱਕ ਵੱਡੇ ਸਕੋਪ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ ਜੋ ਸیکھਣ ਨੂੰ ਦੇਰ ਕਰਦਾ ਹੈ।
MVP ਉਹ ਸਭ ਤੋਂ ਛੋਟੀ ਵਰਜਨ ਹੈ ਜੋ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਵਿਚਾਰ ਕੰਮ ਕਰਦਾ ਹੈ।
MLP ਉਹ ਸਭ ਤੋਂ ਛੋਟੀ ਵਰਜਨ ਹੈ ਜੋ ਲਕਸ਼ਤ ਉਪਭੋਗਤਾ ਲਈ ਇਤਨੀ ਸਪਸ਼ਟ ਅਤੇ ਮਨਪਸੰਦ ਹੈ ਕਿ ਉਹ ਯਾਤਰਾ ਪੂਰੀ ਕਰਕੇ ਮੁੜ ਆ ਸਕਦਾ ਹੈ ਜਾਂ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: MVP ਮੰਗ ਸਾਬਤ ਕਰਦਾ ਹੈ; MLP ਭਰੋਸਾ ਕਮਾਉਂਦਾ ਹੈ।
ਇੱਕ ਛੋਟਾ ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
ਹਰੇਕ ਇਟਰੇਸ਼ਨ ਨੂੰ ਇੱਕ ਮਾਪਯੋਗ ਨਿਸ਼ਾਨ ਨਾਲ ਜੋੜੋ (ਉਦਾਹਰਨ: “3 ਉਪਭੋਗਤਾ ਬਿਨਾਂ ਮਦਦ ਦੇ onboarding ਪੂਰਾ ਕਰਦੇ ਹਨ”) ਤਾਂ ਕਿ ਤੁਸੀਂ ਜੋੜੀ ਕਾਰਵਾਈ ਕਰ ਰਹੇ ਹੋ ਉਹ ਸਿੱਖਣ ਵਾਲੀ ਹੋਵੇ, ਸਿਰਫ਼ ਫੀਚਰ ਜੋੜਨ ਵਾਲੀ ਨਹੀਂ।
ਜਦੋਂ ਅਸਲ ਪ੍ਰੇਸ਼ਾਨੀਆਂ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ AI ਸਧਾਰਣ ਟੁਕੜੇ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ:
ਜਦੋਂ ਮੈਟਰਿਕਸ ਜਾਂ ਸਪੋਰਟ ਟਿਕਟਸ ਦਿਖਾਉਣ ਲਗਦੇ ਹਨ ਤਾਂ ਫਰੇਮਵਰਕ ਦੀ ਗਹਿਰਾਈ ਵਿੱਚ ਨਿਵੇਸ਼ ਕੀਤਾ ਜਾਏ।
ਇਕ ਛੋਟੀ ਸੈੱਟ ਮੈਟਰਿਕਸ ਜੋ ਮੁੱਲ ਦਰਸਾਉਂਦੀ ਹੈ:
ਹਰੇਕ ਸ਼ਿਪ ਕੀਤੇ ਗਏ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਮੈਟਰਿਕ ਦੇ ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਰੋਡਮੈਪ ਦਾਅਵੇ ਨਹੀਂ, ਸਬੂਤ 'ਤੇ ਅਧਾਰਿਤ ਹੋਵੇ।
