11 ਦਸੰ 2025·8 ਮਿੰਟ
ਪ੍ਰੋਂਪਟ, ਦੁਹਰਾਓ, ਰੀਫੈਕਟਰ: Vibe Coding ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਡੌਕਸ ਦੀ ਥਾਂ
ਜਾਣੋ ਕਿ ਕਿਵੇਂ ਪ੍ਰੋਂਪਟਿੰਗ, ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਇੱਕ vibe coding ਵਰਕਫਲੋ ਵਿੱਚ ਭਾਰੀ ਡਿਜ਼ਾਈਨ ਡੌਕਸ ਦੀ ਥਾਂ ਲੈ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਸਪਸ਼ਟਤਾ, ਸੰਗਤ ਜਾਂ ਗੁਣਵੱਤਾ ਘਟਾਏ।
ਜਾਣੋ ਕਿ ਕਿਵੇਂ ਪ੍ਰੋਂਪਟਿੰਗ, ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਇੱਕ vibe coding ਵਰਕਫਲੋ ਵਿੱਚ ਭਾਰੀ ਡਿਜ਼ਾਈਨ ਡੌਕਸ ਦੀ ਥਾਂ ਲੈ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਸਪਸ਼ਟਤਾ, ਸੰਗਤ ਜਾਂ ਗੁਣਵੱਤਾ ਘਟਾਏ।
“Vibe coding” ਇੱਕ ਐਸਾ ਤਰੀਕਾ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਇਰਾਦਾ ਅਤੇ ਉਦਾਹਰਣਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਫਿਰ ਲਾਗੂਆਮਾਲ ਨੂੰ ਤੇਜ਼ ਚੱਕਰਾਂ ਰਾਹੀਂ ਵਿਕਸਤ ਹੋਣ ਦਿੰਦੇ ਹੋ: ਪ੍ਰੋਂਪਟ, ਚਲਾਓ, ਅਤੇ ਸੋਧ ਕਰੋ। ਵੱਡੀ ਯੋਜਨਾ ਲਿਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਜਲਦੀ ਕੁਝ ਕੰਮ ਕਰਨ ਵਾਲਾ ਲਿਆਉਂਦੇ ਹੋ, ਜਿਨ੍ਹਾਂ ਤੋਂ ਸਿੱਖਦੇ ਹੋ ਅਤੇ ਕੋਡ ਨੂੰ ਉਸ ਨਤੀਜੇ ਵੱਲ ਮੋੜਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ।
Vibe coding ਵਰਕਫਲੋ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:
“Vibe” ਹਿੱਸਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ—ਇਹ ਤੇਜ਼ ਫੀਡਬੈਕ ਹੈ। ਤੁਸੀਂ ਅਜਿਹੇ ਇਕਜ਼ੈਕਿਊਸ਼ਨ ਅਤੇ ਇਟਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੰਮੇ ਅਨੰਦਾਜਿਆਂ ਦੀ ਥਾਂ ਸਿੱਖਦੇ ਹੋ।
AI ਕੋਸ਼ਿਸ਼ ਨੂੰ ਵਿਆਪਕ ਦਸਤਾਵੇਜ਼ ਲਿਖਣ ਤੋਂ ਸਪੱਸ਼ਟ, ਚਲਣਯੋਗ ਨਿਰਦੇਸ਼ ਦੇਣ ਵੱਲ ਸਥਾਨਾਂਤਰਿਤ ਕਰਦਾ ਹੈ:
ਇਹ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਸਭ ਤੋਂ ਵਧੀਆ ਉਹਨਾਂ ਹਾਲਤਾਂ ਲਈ ਹੈ ਜਿੱਥੇ ਉਤਪਾਦ ਇਟਰੇਸ਼ਨ, ਅੰਦਰੂਨੀ ਟੂਲ, ਸ਼ੁਰੂਆਤੀ-ਪੜਾਅ ਫੀਚਰ ਅਤੇ ਰੀਫੈਕਟਰ ਹਨ — ਜਿੱਥੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਬਣਾਉਣਾ ਬਨਾਉਣਾ ਅਤੇ ਸਿੱਖਣਾ ਹੈ।
ਇਹ ਉਹਨਾਂ ਹਾਲਤਾਂ ਲਈ ਠੀਕ ਨਹੀਂ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਸਰਕਾਰੀ ਮਨਜ਼ੂਰੀਆਂ, ਸਖਤ ਅਨੁਕੂਲਤਾ, ਲੰਬੀ-ਮਿਆਦੀ ਕ੍ਰਾਸ-ਟੀਮ ਵਚਨਬੱਧਤਾਵਾਂ ਜਾਂ ਅਪਰਿਵਰਤਨੀ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ ਦੀ ਲੋੜ ਹੈ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਤੁਸੀਂ ਹਾਲੇ ਵੀ ਲਿਖਤੀ ਫੈਸਲਾ ਰਿਕਾਰਡ ਚਾਹੁੰਦੇ ਹੋ—ਪਰ ਛੋਟਾ, ਤਿਕੜੀ ਅਤੇ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ।
ਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਪ੍ਰੋਂਪਟਸ ਨੂੰ ਹਲਕਾ-ਫੁਲਕਾ ਸਪੈਕ ਕਿਵੇਂ ਮੰਨਿਆ ਜਾਵੇ, ਇਟਰੇਸ਼ਨ ਨੂੰ ਆਪਣਾ ਯੋਜਨਾ ਟੂਲ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ, ਅਤੇ ਰੀਫੈਕਟਰਨਿਗ ਅਤੇ ਟੈਸਟਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਕੇ ਸਪਸ਼ਟਤਾ ਕਾਇਮ ਰੱਖਣੀ ਹੈ—ਬਿਨਾਂ ਭਾਰੀ ਡਿਜ਼ਾਈਨ ਡੌਕਸ ਵੱਲ ਮੁੜ ਦੇ।
ਰਵਾਇਤੀ ਡਿਜ਼ਾਈਨ ਡੌਕਸ ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਪਸ਼ਟਤਾ ਨਿਰਮਿਤ ਕਰਨ ਲਈ ਹੁੰਦੇ ਹਨ। ਤੇਜ਼ ਨਿਰਮਾਣ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਉਲਟ ਨਤੀਜਾ ਦਿੰਦੇ ਹਨ: ਇੱਕ ਹੌਲੀ, ਨਾਜ਼ੁਕ ਆਰਟੀਫੈਕਟ ਜੋ ਸਿੱਖਣ ਨਾਲ ਕੈਚ ਨਹੀਂ ਕਰ ਪਾਂਦਾ।
ਡਿਜ਼ਾਈਨ ਡੌਕਜ਼ ਜ਼ਿਆਦਾਤਰ ਤੰਗੀ ਨਾਲ ਸਟੇਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਜਿਵੇਂ ਹੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਟੀਮ ਏਜ ਕੇਸ, ਲਾਇਬਰੇਰੀ ਖਾਸੀਅਤਾਂ, ਪ੍ਰਦਰਸ਼ਨ ਸੀਮਾਵਾਂ ਅਤੇ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਹਕੀਕਤਾਂ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜੋ ਪਹਿਲੇ ਦਿਨ ਤੇ ਸਪਸ਼ਟ ਨਹੀਂ ਸੀ। ਜੇ ਕੋਈ ਲਗਾਤਾਰ ਡੌਕ ਐਡੀਟ ਨਾ ਕਰੇ (ਘੱਟ ਹੀ ਹੁੰਦਾ ਹੈ), ਤਾਂ ਇਹ ਇੱਕ ਇਤਿਹਾਸਕ ਰਿਕਾਰਡ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਰਾਹਦਰਸ਼ਨ।
ਉਹਨਾਂ ਨੂੰ ਲਿਖਣਾ ਵੀ ਹੌਲਾ ਅਤੇ ਪੜ੍ਹਨਾ ਵੀ ਹੌਲਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਰਫ਼ਤਾਰ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ, ਟੀਮ ਸ਼ਿਪਿੰਗ ਲਈ ਅਪਟੀਮਾਈਜ਼ ਕਰਨਦੀ ਹੈ: ਡੌਕ “ਠੀਕ ਹੋਣਾ” ਬਣ ਜਾਂਦਾ ਹੈ, ਝਲਕਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਚੁੱਪਚਾਪ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕੋਸ਼ਿਸ਼ ਫਿਰ ਵੀ ਲੱਗਦੀ ਹੈ—ਪਰ ਮੁਲਾਂਕਣ ਨਹੀਂ ਮਿਲਦਾ।
ਇੱਕ ਵੱਡਾ ਅੱਗੇ-ਤਰਫ਼ ਡੌਕ ਤੁਹਾਨੂੰ ਗਲਤ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ “ਡਿਜ਼ਾਈਨ ਮੁਕੰਮਲ” ਸਮਝ ਬੈਠਦੇ ਹੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਮੁਸ਼ਕਲ ਹਿੱਸਿਆਂ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ।
ਪਰ ਅਸਲ ਸੀਮਾਵਾਂ ਅਕਸਰ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਮਿਲਦੀਆਂ ਹਨ:
ਜੇ ਡੌਕ ਉਹਨਾਂ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਦੇਰ ਕਰ ਦੇਵੇ, ਤਾਂ ਟੀਮ ਦਾ ਸਿੱਖਣਾ ਉਸੇ ਤਰ੍ਹਾਂ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਤੇਜ਼ ਨਿਰਮਾਣ ਹਦਾਂ ਨਾਲ ਬਣਦੇ ਹਨ: ਫੀਡਬੈਕ ਰੋਜ਼ ਆਉਂਦਾ ਹੈ, ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਹੱਲ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਦੇਖਣ 'ਤੇ ਬਦਲ ਸਕਦਾ ਹੈ। ਰਵਾਇਤੀ ਡੌਕ ਇਹ ਮੰਨਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਭਵਿੱਖ ਦਾ ਪੂਰਾ ਅਨੁਮਾਨ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਮਿਲਾਅ ਜ਼ਿਆਦਾ ਖਰਚ ਵਾਲਾ ਹੈ—ਡੌਕ ਦੁਬਾਰਾ ਲਿਖਣ ਜਾਂ ਪੁਰਾਣੀ ਯੋਜਨਾ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਜ਼ਬਰਦਸਤੀ।
ਮਕਸਦ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ ਨਹੀ ਹੈ; ਇਹ ਸਾਂਝੀ ਸਮਝ ਹੈ: ਅਸੀਂ ਕੀ ਬਣਾ ਰਹੇ ਹਾਂ, ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ, “ਦੋਨ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਖਤਰੇ ਅਸੀਂ ਦੇਖ ਰਹੇ ਹਾਂ। ਬਾਕੀ ਸਿਰਫ਼ ਇੱਕ ਟੂਲ ਹੈ—ਅਤੇ ਤੇਜ਼ ਨਿਰਮਾਣ ਵਿੱਚ, ਭਾਰੀ ਡੌਕ ਅਕਸਰ ਗਲਤ ਟੂਲ ਹੁੰਦਾ ਹੈ।
ਰਵਾਇਤੀ ਡਿਜ਼ਾਈਨ ਡੌਕ ਭਵਿੱਖ ਦਾ ਅਨੁਮਾਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਕੀ ਬਣਾਉਂਦੇ ਹੋਗੇ, ਕਿਵੇਂ ਕੰਮ ਕਰੇਗਾ, ਅਤੇ ਜੇ ਕੁਝ ਬਦਲੇ ਤਾਂ ਕੀ ਕੀਤਾ ਜਾਵੇਗਾ। ਇੱਕ runnable ਪ੍ਰੋਂਪਟ ਇਸਨੂੰ ਪਲਟ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਜੀਵਤ ਸਪੈਸ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ ਹੋ, ਦੇਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਸੋਧ ਸਕਦੇ ਹੋ।
ਦਰਅਸਲ: “ਡੌਕ” ਇੱਕ ਸਥਿਰ PDF ਨਹੀਂ—ਇਹ ਉਹ ਸੂਚਨਾਵਾਂ ਹਨ ਜੋ ਅਗਲਾ ਸਹੀ ਇਨਕ੍ਰਿਮੈਂਟ ਪੈਦਾ ਕਰਨ ਲਈ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਨਿਰਦੇਸ਼ ਦਿੰਦੀਆਂ ਹਨ।
ਮਕਸਦ ਆਪਣੀ ਇਰਾਦੇ ਨੂੰ ਬੇਮਿਸਾਲ ਅਤੇ ਪੜਤਾਲਯੋਗ ਬਣਾਉਣਾ ਹੈ। ਇੱਕ ਚੰਗਾ runnable ਪ੍ਰੋਂਪਟ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ:
ਪੈਰਾਗ੍ਰਾਫਾਂ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰ ਰਹੇ ਹੋ ਜੋ ਸੀਧਾ ਕੋਡ, ਟੈਸਟ, ਜਾਂ ਚੈੱਕਲਿਸਟ ਜਨਰੇਟ ਕਰ ਸਕੇ।
ਜ਼ਿਆਦਾਤਰ ਅਚੰਭਿਆਂ ਦੀ ਵਜ੍ਹਾ ਇਹ ਹੁੰਦੀ ਹੈ ਕਿ ਧਾਰਨਾਵਾਂ ਅਮੂਮਨ ਅਚੁੱਕ ਰਹਿੰਦੀਆਂ ਹਨ। ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ:
ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਸੰਗਤ ਬਣਦੀ ਹੈ ਅਤੇ ਫੈਸਲੇ ਦੀ ਇੱਕ ਦ੍ਰਿਸ਼ਟੀਗਤ ਰਿਕਾਰਡ ਬਣਦੀ ਹੈ—ਬਿਨਾਂ ਭਾਰੀ ਡੌਕ ਦੇ ਭਾਰ ਦੇ।
ਡਿਜ਼ਾਈਨ ਡੌਕ ਦਾ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਹਿੱਸਾ ਅਕਸਰ ਅੰਤ ਹੁੰਦਾ ਹੈ: ਕਿਹੜੀ ਚੀਜ਼ ਮੁਕੰਮਲ ਦਿਖਾਈ ਵੇਖੀ ਜਾਵੇ। ਇਹ ਨੂੰ ਸੀਧਾ runnable ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਇਹ ਕੰਮ ਦੇ ਨਾਲ ਯਾਤਰਾ ਕਰੇ।
ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡਾ ਪ੍ਰੋਂਪਟ ਲੋੜ ਰਖ ਸਕਦਾ ਹੈ: ਪਾਸ ਹੋਣ ਵਾਲੇ ਯੂਨੀਟ ਟੈਸਟ, ਅਪਡੇਟ ਕੀਤੇ error handling, accessibility ਜਾਂਚਾਂ, ਅਤੇ ਬਦਲਾਅ ਦੀ ਇੱਕ ਛੋਟੀ ਸਾਰ। ਜਦੋਂ ਪ੍ਰੋਂਪਟ ਹੀ ਸਪੈਸ ਹੈ, “ਡੋਨ” ਹੋਣਾ ਤਰਕਸ਼ੀਲ ਬਹਿਸ ਨਹੀਂ ਰਹਿੰਦਾ—ਇਹ ਪੁਸ਼ਟੀਯੋਗ ਨਤੀਜਿਆਂ ਦਾ ਸੈੱਟ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਹਰ ਇਟਰੇਸ਼ਨ 'ਤੇ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇਹ ਵਰਕਫਲੋ ਸਭ ਤੋਂ ਵਧੀਆ ਤਦੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਂਪਟ ਕਰਨਾ, ਚਲਾਉਣਾ, ਸਮੀਖਿਆ ਕਰਨੀ, ਅਤੇ ਰੋਲਬੈਕ ਕਰਨਾ ਘਣ ਤਾਂ-ਬੰਨ੍ਹੇ ਹੋਣ। Vibe-coding ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਇਸ ਲੂਪ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਵੈੱਬ/ਸਰਵਰ/ਮੋਬਾਇਲ ਸਲਾਇਸ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਮਾਈਕ੍ਰੋ-ਪਲੈਨ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਪਲੈਨਿੰਗ ਮੋਡ ਵਰਤ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਇਟਰੇਸ਼ਨ ਗਲਤ ਹੋਵੇ ਤਾਂ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ 'ਤੇ ਨਿਰਭਰ ਰਹਿ ਸਕਦੇ ਹੋ। ਅਮਲੀ ਪ੍ਰਭਾਵ ਘੱਟ "prompt ਥੀਏਟਰ" ਅਤੇ ਜ਼ਿਆਦਾ ਅਸਲ, ਟੈਸਟਬਲ ਇਨਕ੍ਰਿਮੈਂਟ ਬਣਨਾ ਹੈ।
ਰਵਾਇਤੀ ਡਿਜ਼ਾਈਨ ਡੌਕ ਕਾਗਜ਼ ਉੱਤੇ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ “ਸਲਵ” ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਪਰ ਨਿਰਮਾਣ ਦੇ ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਹਿੱਸੇ ਉਹ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਸਾਫ਼-ਸੁਥਰੇ ਤਰੀਕੇ ਨਾਲ ਸੋਚ ਕੇ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ: ਏਜ ਕੇਸ, ਪਰਫਾਰਮੈਂਸ ਬੋਤਲਨੇਕ, ਉਲਝਣ-ਭਰਿਆ UX, ਤੀਜੇ-ਪੱਖੇ quirks, ਅਤੇ ਯੂਜ਼ਰਾਂ ਦਾ ਸ਼ਬਦਾਵਲੀ ਨੂੰ ਸਮਝਣਾ।
Vibe coding ਵਰਕਫਲੋ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਇੱਕ ਚੀਜ਼ ਵਜੋਂ ਮੰਨਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਤੰਗ ਚੱਕਰਾਂ ਰਾਹੀਂ ਘਟਾਉਂਦੇ ਹੋ। ਬਹਿਸ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਸਭ ਤੋਂ ਛੋਟਾ ਵਰਜਨ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਸਬੂਤ ਪੈਦਾ ਕਰ ਸਕੇ, ਫਿਰ ਸੁਧਾਰ ਕਰਦੇ ਹੋ।
ਉਸੇ ਸਭ ਤੋਂ ਛੋਟੀ ਲੋੜੀਂਦੀ ਸਲਾਇਸ ਚੁਣੋ ਜੋ ਫਿਰ ਵੀ ਐਂਡ-ਟੂ-ਐਂਡ ਚੱਲਦੀ ਹੋਵੇ: UI → API → ਡੇਟਾ → ਬੈਕ। ਇਹ ਉਹ “ਪਰਫੈਕਟ” ਮੋਡਯੂਲਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਇਕਠੇ ਨਹੀਂ ਹੁੰਦੇ।
ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ “saved searches” ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਹਰ ਇਕ ਫਿਲਟਰ ਵਿਕਲਪ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਥਾਂ ਇਕ ਫਿਲਟਰ, ਇਕ ਸੇਵ ਕੀਤੀ ਆਈਟਮ, ਅਤੇ ਇਕ ਰੀਟਰੀਵ ਰਾਹ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਉਹ ਸਲਾਇਸ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਵਧਾਓ।
ਚੱਕਰ ਛੋਟੇ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ:
30–90 ਮਿੰਟ ਦਾ ਟਾਈਮਬਾਕਸ ਸਫਾਈ ਲਿਆਉਂਦਾ ਹੈ। ਲਕਸ਼ ਇਹ ਨਹੀਂ ਕਿ ਫੀਚਰ ਮੁਕੰਮਲ ਹੋ ਜਾਵੇ—ਲਕਸ਼ ਹੈ ਅਗਲਾ ਸਭ ਤੋਂ ਵੱਡਾ ਅੰਜਾਣ ਘਟਾ ਦੇਣਾ। ਜੇ ਤੁਸੀਂ ਅਗਲਾ ਕਦਮ ਇੱਕ ਜਾਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਉਹ ਕਦਮ ਬਹੁਤ ਵੱਡਾ ਹੈ।
ਜਦੋਂ ਤੁਹਾਡੀ ਯਕੀਨੀਅਤ ਘੱਟ ਹੋਵੇ, ਇੱਕ ਛੀਕ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰੋ। ਪ੍ਰੋਟੋਟਾਈਪ "ਟੋਇ" ਕੋਡ ਨਹੀਂ ਜਿਹੜਾ ਬੇਕਾਰ ਹੋਵੇ—ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸੱਚਮੁੱਚੀ ਨਿਸ਼ਾਨਾ ਦਿੰਦੇ ਹੋ ਅਤੇ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰਦੇ ਹੋ: ਉਹ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।
ਵਧੀਆ ਪ੍ਰੋਟੋਟਾਈਪ ਸਵਾਲਾਂ ਦੇ ਉਦਾਹਰਣ:
ਅਸਲ ਫੀਡਬੈਕ ਅੰਦਰੂਨੀ बहਸਾਂ ਤੋਂ ਵਧੀਆ ਹੈ। ਇੱਕ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਸ਼ਿਪ ਕਰੋ, ਇੱਕ ਸਟੇਕਹੋਲਡਰ ਨੂੰ ਡੈਮੋ ਕਰੋ, ਜਾਂ ਟੈਸਟ ਡੇਟਾ ਨਾਲ ਖੁਦ ਹੀ ਫਲੋ ਚਲਾਓ। ਹਰ ਇਕ ਲੂਪ ਨੂੰ ਇੱਕ ठोस ਆਉਟਪੁੱਟ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: ਪਾਸ ਹੋਣ ਵਾਲਾ ਟੈਸਟ, ਕੰਮ ਕਰਦੀ ਸਕਰੀਨ, ਮਾਪਿਆ ਗਿਆ ਕੁਏਰੀ ਸਮਾਂ, ਜਾਂ ਇੱਕ ਸਪੱਸ਼ਟ “ਇਹ ਉਲਝਣ-ਭਰਿਆ ਹੈ।”
ਵੱਡੇ ਡਿਜ਼ਾਈਨ ਡੌਕ ਸਾਹਮਣੇ ਫੈਸਲੇ ਅੱਗੇ ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ। Vibe coding ਵਰਕਫਲੋ ਇਸ ਨੂੰ ਉਲਟ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਪ੍ਰੋਂਪਟ ਕਰਦੇ ਹੋ, ਜਿਹੜਾ ਕਿ ਮਾਈਕ੍ਰੋ-ਯੋਜਨਾਵਾਂ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕੋਡਬੇਸ ਅੰਦਰ ਅਭਿਗ੍ਰਹਣਯੋਗ ਹੁੰਦੇ ਹਨ ਅਤੇ ਰਿਵਿਊਅਰ ਵੱਲੋਂ ਪਰਖੇ ਜਾ ਸਕਦੇ ਹਨ।
“ਇੱਕ ਬਿਲਿੰਗ ਸਿਸਟਮ ਬਣਾਓ” ਦੀ ਥਾਂ, ਇੱਕ ਪ੍ਰੋਂਪਟ ਲਿਖੋ ਜੋ ਇਕੋ ਨਤੀਜੇ ਅਤੇ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਪਾਬੰਦੀਆਂ ਨਿਰਧਾਰਿਤ ਕਰੇ। ਲਕਸ਼ ਇਹ ਹੈ ਕਿ ਵਿਸ਼ਾਲ ਪ੍ਰੋਂਪਟਾਂ ਨੂੰ ਉਹਨਾਂ ਟਾਸਕਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾਵੇ ਜੋ ਕੋਡਬੇਸ ਸਿੱਧਾ ਪਚਾ ਸਕੇ—ਛੋਟੇ ਇੰਨੇ ਕਿ ਜਵਾਬ ਬਿਨਾਂ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ ਖੋਜਣ ਦੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕੇ।
ਇਕ ਲਾਭਦਾਇਕ ਢਾਂਚਾ:
ਯੋਜਨਾ ਨੂੰ ਲਾਜ਼ਮੀ ਕਦਮ ਬਣਾਓ: AI ਤੋਂ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਕਦਮ-ਬਾਈ-ਕਦਮ ਯੋਜਨਾ ਮਗਵਾਓ। ਤੁਸੀਂ ਪਰਫੈਕਟ ਅਣੁਮਾਨ ਨਹੀਂ ਚਾਹੁੰਦੇ—ਸਿਰਫ ਇੱਕ ਸਮੀਖਿਆਯੋਗ ਰਾਹ।
ਫਿਰ ਉਸ ਯੋਜਨਾ ਨੂੰ ਇਕ ਕਾਂਕਰੀਟ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਬਦਲੋ:
ਜੇ ਯੋਜਨਾ ਇਹਨਾਂ ਨੂੰ ਨਾਮ ਨਹੀਂ ਦੇ ਸਕਦੀ, ਤਾਂ ਉਹ ਅਜੇ ਵੀ ਬਹੁਤ vague ਹੈ।
ਮਾਈਕ੍ਰੋ-ਯੋਜਨਾਵਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਹਰ ਬਦਲਾਅ ਇੰਨਾ ਛੋਟਾ ਹੁੰਦਾ ਹੈ ਕਿ ਤੇਜ਼ੀ ਨਾਲ ਰਿਵਿਊ ਕੀਤਾ ਜਾ ਸਕੇ। ਹਰ ਪ੍ਰੋਂਪਟ ਨੂੰ ਇੱਕ PR-ਸਾਈਜ਼ ਸਲਾਇਸ ਮੰਨੋ: ਇਕ schema tweak ਜਾਂ ਇਕ endpoint ਜਾਂ ਇੱਕ UI ਸਥਿਤੀ ਦਾ ਬਦਲਾਅ—ਫਿਰ ਇਟਰੇਟ ਕਰੋ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ ਨਿਯਮ: ਜੇ ਰਿਵਿਊਅਰ ਨੂੰ ਬਦਲਾਅ ਸਮਝਣ ਲਈ ਮੀਟਿੰਗ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਫਿਰ ਵੰਡੋ।
ਟੀਮ ਸੰਗਤ ਲਈ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪ੍ਰੋਂਪਟ ਟੈਮਪਲੇਟਸ ਨੂੰ ਇਕ ਛੋਟੀ ਅੰਦਰੂਨੀਸਫੇ (ਉਦਾਹਰਨ /playbook/prompts) ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਡੀਕੋੰਪੋਜ਼ੀਸ਼ਨ ਆਦਤ ਬਣ ਜਾਵੇ, ਨ ਕਿ ਵਿਅਕਤੀਗਤ ਅੰਦਾਜ਼।
ਰੀਫੈਕਟਰ ਕਰਨਾ ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ “ਅਸੀਂ ਜੇ ਸਿੱਖਿਆ” ਨੂੰ “ਅਸੀਂ ਜਿਸਦਾ ਮਤਲਬ ਸੀ” ਵਿੱਚ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ। Vibe coding ਵਰਕਫਲੋ ਵਿੱਚ, ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਂਪਟ ਅਤੇ ਇਟਰੇਸ਼ਨ ਜਾਣ-ਬੂਝ ਕੇ exploratory ਹੁੰਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਪਤਲਾ ਸਲਾਇਸ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਵੇਖਦੇ ਹੋ ਕਿ ਕਿੱਦਾਂ ਤੋੜਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਸੀਮਾਵਾਂ ਪਤਾ ਲੱਗਦੀਆਂ ਹਨ। ਰੀਫੈਕਟਰ ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਡਿਜ਼ਾਈਨ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ—ਸਟ੍ਰਕਚਰ, ਨਾਮ, ਬਾਊਂਡਰੀਆਂ, ਅਤੇ ਉਹ ਟੈਸਟ ਜੋ ਭਵਿੱਖੀ ਸਾਥੀਆਂ ਲਈ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੁੰਦੇ ਹਨ।
ਸਾਫ਼ ਕੋਡਬੇਸ ਆਪਣਾ ਆਪ ਨੂੰ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ handleThing() ਵਰਗੇ ਅਸਪਸ਼ਟ ਫੰਕਸ਼ਨ ਦਾ ਨਾਮ calculateTrialEndDate() ਰੱਖਦੇ ਹੋ ਅਤੇ ਉਸਨੂੰ BillingRules ਮੋਡਯੂਲ ਵਿੱਚ ਰੱਖਦੇ ਹੋ, ਤੁਹਾਡਾ ਇੱਕ executable ਡਿਜ਼ਾਈਨ ਡੌਕ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੈ।
ਚੰਗੀਆਂ ਰੀਫੈਕਟਰੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਖਦੀਆਂ ਹਨ:
ਆਰਕੀਟੈਕਚਰ ਡਾਇਗਰਾਮ ਜਲਦੀ ਪੁਰਾਣੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਸਾਫ਼ ਇੰਟਰਫੇਸ ਵਧੀਆ ਉਮਰ ਪਾਉਂਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਉਹ ਟੈਸਟਾਂ ਨਾਲ ਸਮਰਥਿਤ ਹੁੰਦੇ ਹਨ ਜੋ ਵਰਤਾਵ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ।
“ਸਰਵਿਸਜ਼” ਦੇ ਬਾਕਸ-ਅਤੇ-ਤੀਰ ਡਾਇਗਰਾਮ ਦੀ ਥਾਂ ਪ੍ਰਾਥਮਿਕ ਰਹੋ:
ਜਦੋਂ ਕੋਈ ਪੁੱਛਦਾ ਹੈ “ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?”, ਜਵਾਬ ਹੁੰਦਾ ਹੈ ਕੋਡ ਵਿੱਚ ਬਾਊਂਡਰੀਆਂ ਅਤੇ ਉਹ ਟੈਸਟ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ enforce ਕਰਦੇ ਹਨ—ਸਲਾਈਡ ਡੈੱਕ ਨਹੀਂ।
ਰੀਫੈਕਟਰ ਉਹ ਵੇਲਾ ਸ਼ੇਡਿਊਲ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਕਾਫੀ ਸਬੂਤ ਇਕੱਠੇ ਕਰ ਲਏ ਹੋ: ਇਕੋ ਖੇਤਰ ਵਿੱਚ ਲਗਾਤਾਰ ਬਦਲਾਅ, ਗੁੰਝਲਦਾਰ ਮਾਲਕੀਅਤ, ਜਾਂ ਅਜਿਹੇ ਬੱਗ ਜੋ ਅਸਪਸ਼ਟ ਬਾਊਂਡਰੀਆਂ ਵੱਲੋ ਆ ਰਹੇ ਹਨ। ਪ੍ਰੋਂਪਟਿੰਗ ਅਤੇ ਇਟਰੇਸ਼ਨ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ; ਰੀਫੈਕਟਰਿੰਗ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਉਹ ਸਿੱਖਿਆ ਲਾਕ-ਇਨ ਕਰਦੇ ਹੋ ਤਾਂ ਜੋ ਅਗਲਾ ਨਿਰਮਾਣ ਸਪਸ਼ਟਤਾ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇ, ਅਨੁਮਾਨ ਤੋਂ ਨਹੀਂ।
ਲੰਬੇ ਡਿਜ਼ਾਈਨ ਡੌਕ ਛੱਡਣਾ ਇਹ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਯਾਦ ਰੱਖਣਾ ਬੰਦ ਕਰ ਦਿਆਂ। ਲਕਸ਼ ਇਹ ਹੈ ਕਿ ਥੋੜ੍ਹਾ ਪਰ ਉੱਚ-ਸੰਕੇਤ ਵਾਲਾ ਲਿਖਤੀ ਸੰਦਰਭ ਰੱਖਿਆ ਜਾਵੇ ਤਾਂ ਭਵਿੱਖ ਦਾ ਆਪ (ਅਤੇ ਤੁਹਾਡੇ ਸਾਥੀ) ਸਮਝ ਸਕਣ ਕਿ ਕੋਡ ਇਸ ਤਰ੍ਹਾਂ ਕਿਉਂ ਹੈ—ਬਿਨਾਂ ਪ੍ਰਗਤੀ ਨੂੰ ਜਮ੍ਹਾ ਕਰਨ ਦੇ।
ਜੋ ਪ੍ਰੋਂਪਟ ਮੱਤਵਪੂਰਨ ਸਨ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੀ ਬਦਲਿਆ, ਉਸ ਦਾ ਇੱਕ ਸਿੱਧਾ ਲੌਗ ਰੱਖੋ। ਇਹ ਰੇਪੋ ਵਿੱਚ ਇੱਕ markdown ਫਾਇਲ ਹੋ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ: /docs/prompt-log.md) ਜਾਂ ਤੁਹਾਡੇ issue tracker ਵਿੱਚ ਇੱਕ ਥ੍ਰੈੱਡ।
ਇਸ ਵਿੱਚ Capture ਕਰੋ:
ਇਸ ਨਾਲ “ਅਸੀਂ AI ਨੂੰ ਕਈ ਗੱਲਾਂ ਪੁੱਛੀਆਂ” ਤੋਂ ਇੱਕ ਆਡੀਟ ਜੋਗ੍ਹਾ ਟ੍ਰੇਲ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਰਿਵਿਊਆਂ ਅਤੇ ਭਵਿੱਖੀ ਰੀਫੈਕਟਰਾਂ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦੀ ਹੈ।
ਹਰ ਪ੍ਰੋਜੈਕਟ ਜਾਂ ਫੀਚਰ ਖੇਤਰ ਲਈ ਅੱਧੇ-ਪੰਨੇ ਵਰਗਾ “ਕਿਉਂ” ਦਸਤਾਵੇਜ਼ ਲਕਸ਼ ਰੱਖੋ। ਇਹ spec ਨਹੀਂ—ਜ਼ਿਆਦਾ ਇੱਕ ਤਰ੍ਹਾਂ:
ਜੇ ਕੋਈ ਪੁੱਛੇ “ਅਸੀਂ ਕਿਉਂ ਨਹੀਂ…?”, ਤਾਂ ਜਵਾਬ 2 ਮਿੰਟ ਵਿੱਚ ਲੱਭ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਕ ਘੱਟ-ਭਾਰੀ issue ਟੈਮਪਲੇਟ ਕਈ ਡੌਕ ਸੈਕਸ਼ਨਾਂ ਦੀ ਥਾਂ ਲੈ ਸਕਦਾ ਹੈ। ਖੇਤਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ: ਸਕੋਪ, ਖਤਰੇ, ਅਤੇ ਸਾਫ਼ acceptance criteria (“ਡੋਨ ਦਾ ਮਤਲਬ…”). ਇਹ AI-ਸਹਾਇਤ ਕਾਰਜ ਨੂੰ ਵੀ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ: ਤੁਸੀਂ issue ਨੂੰ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਪੇਸਟ ਕਰ ਕੇ ਆਉਟਪੁੱਟ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਨਿਰਧਾਰਿਤ ਬਾਊਂਡਰੀਆਂ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ।
ਜਦੋਂ ਲਾਗੂ ਹੋਵੇ, ਮੌਜੂਦਾ ਅੰਦਰੂਨੀ ਪੇਜਾਂ ਨੂੰ ਲਿੰਕ ਕਰੋ ਬਜਾਏ ਉਸੀ ਸਮੱਗਰੀ ਨੂੰ ਫਿਰ ਨਾਲ ਲਿਖਣ ਦੇ। ਲਿੰਕ ਸਾਤਤੀ ਰੱਖੋ (ਉਦਾਹਰਨ: /pricing) ਅਤੇ ਸਿਰਫ਼ ਉਹੋ ਸਮੇਂ ਜੋੜੋ ਜਦੋਂ ਇਹ ਕਿਸੇ ਫੈਸਲੇ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰੇ।
ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਤਦ ਤਕ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਲੋਕ ਉਹੀ ਲਕਸ਼ ਦੇ ਉੱਤੇ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਹੋਣ। ਟਿੱਪ ਇਹ ਹੈ ਕਿ “ਇੱਕ ਵੱਡਾ ਡੌਕ ਜੋ ਸਾਰੇ ਭੁਲਾ ਦਿੰਦੇ” ਦੀ ਥਾਂ ਕੁਝ ਛੋਟੀਆਂ ਰੀਤਾਂ ਅਤੇ ਆਰਟੀਫੈਕਟ ਰੱਖੇ ਜਾਣ ਜੋ ਮਨੁੱਖਾਂ ਨੂੰ ਕਾਬੂ ਵਿੱਚ ਰੱਖਣ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ AI ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਰਿਹਾ ਹੋਵੇ।
Vibe coding workflow ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਨਾ ਘਟਾਉਂਦਾ; ਇਹ ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।
ਪ੍ਰੋਂਪਟ ਲਈ ਸਪੱਸ਼ਟ ਰੱਖੋ ਕਿ ਕੌਣ ਕੀ ਦੇਖਦਾ ਹੈ: ਉਦਾਹਰਨ: “Product ਸਕੋਪ ਬਦਲਣ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ,” “Design interaction ਬਦਲਣ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ,” “Engineering ਆਰਕੀਟੈਕਚਰ ਬਦਲਣ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ।” ਇਸ ਨਾਲ AI-ਜਨਰੇਟ ਕੀਤੇ ਗਤੀਵਿਧੀ ਤੋਂ ਫੈਸਲਿਆਂ ਦੀ ਚੁੱਪਚਾਪ ਬਦਲਾਵ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸਾਰੇ ਨੂੰ 10-ਪੰਨੇ ਡੌਕ ਪੜ੍ਹਨ ਲਈ ਕਹਿਣ ਦੀ ਥਾਂ, ਕੁਝ 15–25 ਮਿੰਟ ਦੇ alignment ਰੱਖੋ ਮਹੱਤਵਪੂਰਨ ਬਿੰਦੂਆਂ 'ਤੇ:
ਆਉਟਪੁੱਟ ਇੱਕ ਛੋਟਾ, ਚਲਾਉਣ ਯੋਗ ਨਿਰਣਯ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਅਸੀਂ ਹੁਣ ਕੀ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹਾਂ, ਕੀ ਨਹੀਂ ਕਰ ਰਹੇ, ਅਤੇ ਕੀ ਅਸੀਂ ਫਿਰ ਦੇਖਾਂਗੇ। ਜੇ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰਤਾ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਹ ਨੂੰ ਰੇਪੋ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਨੋਟ (ਜਿਵੇਂ /docs/decisions.md) ਵਿੱਚ ਕੈਪਚਰ ਕਰੋ—ਪੈਸਤ-ਪੌੜੀ ਨਹੀਂ।
ਇੱਕ ਜੀਵਤ “constraints list” ਰੱਖੋ ਜੋ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰੋਂਪਟਾਂ ਅਤੇ PR ਵੇਰਨਾਂ ਵਿੱਚ ਨਕਲ ਕੀਤੀ ਜਾ ਸਕੇ:
ਇਹ ਤੁਹਾਡਾ ਹਲਕਾ-ਫੁਲਕਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਐਂਕਰ ਬਣ ਜਾਂਦਾ ਹੈ: ਜਦੋਂ ਇਟਰੇਸ਼ਨ ਦਬਾਅ ਵਧੇ, constraints list ਲੂਪ ਨੂੰ ਭਟਕਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕੌਣਾ ਕਿਹੜੀ ਚੀਜ਼ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ—ਅਤੇ ਕਦੋਂ escalation ਜ਼ਰੂਰੀ ਹੈ। ਇੱਕ ਸਿਧੀ ਨੀਤੀ ਜਿਵੇਂ “ ਸਕੋਪ/UX/ਸੁੁਰੱਖਿਆ ਬਦਲਾਵਾਂ ਨੂੰ ਖ਼ਾਸ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੈ” ਇਹ ਰੋਕਦੀ ਹੈ ਕਿ "ਛੋਟੇ" AI-ਸਹਾਇਤ ਸੰਪਾਦਨ ਬਿਨਾਂ ਸਮੀਖਿਆ ਦੇ ਅਣਡਿੱਠੇ ਨਵੇਂ ਡਿਜ਼ਾਈਨ ਨਾ ਬਣਾ ਲੈਣ।
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਰਹਿਨੁਮਾ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ: ਜਿੰਨਾ ਛੋਟਾ ਡੌਕ, ਉਨ੍ਹਾਂ ਮਨਜ਼ੂਰੀਆਂ ਓਨਾ ਸਖ਼ਤ। ਇਹ ਤਰੀਕਾ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਰਹਿਣ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਸੰਗਤ ਗੁਆਉਣ ਦੇ।
ਤੇਜ਼ੀ ਤਦੋਂ ਹੀ ਮਦਦਗਾਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਜੋ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੋ। Vibe coding ਵਰਕਫਲੋ ਵਿੱਚ, ਕੁਆਲਟੀ ਗੇਟ ਲੰਮੇ “ਮਨਜ਼ੂਰੀ” ਡੌਕਸ ਦੀ ਥਾਂ ਉਹ ਚੈੱਕ ਹਨ ਜੋ ਹਰ ਵਾਰੀ ਕੋਡ ਬਦਲਣ 'ਤੇ ਚਲਦੇ ਹਨ।
ਪ੍ਰੋਂਪਟ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, plain language ਵਿੱਚ acceptance criteria ਦੀ ਸੂਚੀ ਤਿਆਰ ਕਰੋ: ਯੂਜ਼ਰ ਕੀ ਕਰ ਸਕਦਾ, “ਡੋਨ” ਦਾ ਕੀ ਮਤਲਬ, ਅਤੇ ਕੀ ਕਦੇ ਵੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਇਸਨੂੰ ਇੱਨਾ ਤੰਗ ਰੱਖੋ ਕਿ ਇੱਕ ਰਿਵਿਊਅਰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।
ਫਿਰ ਉਹਨਾਂ ਮਾਪਦੰਡਾਂ ਨੂੰ ਰਨ ਕਰਨ ਯੋਗ ਬਣਾਓ। ਇੱਕ ਫਾਇਦੇਮੰਦ ਨਮੂਨਾ ਇਹ ਹੈ ਕਿ ਹਰ ਮਾਪਦੰਡ ਦੇ ਘੱਟੋ-ਘੱਟ ਇਕ ਆਟੋਮੇਟਡ ਚੈੱਕ ਹੋਵੇ।
ਫੀਚਰ “ਕੰਮ ਕਰਦਾ” ਹੋਣ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ—ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਰਾਹ ਐਂਡ-ਟੂ-ਐਂਡ ਚਲਾ ਸਕਦੇ ਹੋ, ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ:
ਜੇ ਤੁਾਡੇ ਕੋਲ acceptance criteria ਹਨ, ਤਾਂ AI ਨੂੰ ਉਹਨਾਂ ਤੋਂ ਸਿੱਧੇ ਟੈਸਟ ਕੇਸ ਜਨਰੇਟ ਕਰਨ ਲਈ ਕਹੋ, ਫਿਰ ਹਕੀਕਤ ਲਈ ਸੋਧ ਕਰੋ। ਲਕਸ਼ ਇਰਾਦੇ ਦਾ ਕਵਰੇਜ ਹੈ, ਨਾ ਕਿ ਵੱਡਾ ਟੈਸਟ ਸ੍ਵੈਟ।
ਕੋਡ ਰਿਵਿਊ ਨੂੰ ਡਿਜ਼ਾਈਨ ਅਤੇ ਸੁਰੱਖਿਆ ਚੈਕਪੁਆਇੰਟ ਮੰਨੋ:
ਰਿਵਿਊਅਰ AI ਨੂੰ ਵੀ ਪੁੱਛ ਸਕਦੇ ਹਨ ਕਿ “ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ” ਦੇ ਸਥਿਤੀਆਂ ਸੁਝਾਅ ਦੇਣ ਲਈ, ਪਰ ਅੰਤਿਮ ਫੈਸਲਾ ਟੀਮ ਦਾ ਹੁੰਦਾ ਹੈ।
ਗੈਰ-ਫੰਕਸ਼ਨਲ ਜ਼ਰੂਰਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਡੌਕਸ ਬਿਨਾਂ ਗੁੰਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਗੇਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ:
ਇਨ੍ਹਾਂ ਨੂੰ PR ਵੇਰਵਾ ਜਾਂ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਦਰਜ ਕਰੋ ਤਾਂ ਕਿ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਹੋਵੇ, ਅਨੁਮਾਨ ਨਹੀਂ।
Vibe coding ਵਰਕਫਲੋ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਚਲ ਸਕਦੀ ਹੈ—ਪਰ ਤੇਜ਼ੀ ਨਾਲ ਕੁਝ ਫੇਲਿਅਤਾਂ ਵੀ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਕੋਡਬੇਸ 'ਤੇ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੀਆਂ। ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਇਹ ਕੁਝ ਆਦਤਾਂ ਨਾਲ ਰੋਕੇ ਜਾ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਂਪਟਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਾ ਰਹੇ ਹੋ ਬਜਾਏ ਛੋਟੇ ਇਨਕ੍ਰਿਮੈਂਟ ਬਣਾਉਣ ਦੇ, ਤਾਂ ਤੁਸੀਂ ਨਵੇਂ ਫਰਮੈਟ ਵਿੱਚ ਡਿਜ਼ਾਈਨ-ਡੌਕ ਪੈਰਾਲਿਸਿਸ ਦੁਹਰਾਇਆ।
ਪ੍ਰੈਕਟਿਕਲ ਸੁਧਾਰ: ਪ੍ਰੋਂਪਟਾਂ ਨੂੰ ਟਾਈਮਬਾਕਸ ਕਰੋ: “ਚੰਗਾ-ਕਾਫੀ” প্রੋਂਪਟ ਲਿਖੋ, ਸਭ ਤੋਂ ਛੋਟਾ ਸਲਾਇਸ ਬਣਾਓ, ਫਿਰ ਸੋਧ ਕਰੋ। ਪ੍ਰੋਂਪਟ runnable ਰੱਖੋ: ਇਨਪੁਟ, ਆਉਟਪੁੱਟ, ਅਤੇ ਝਟ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੀ acceptance ਜਾਂਚ ਸ਼ਾਮਲ ਕਰੋ।
ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਅਕਸਰ ਮੁੱਖ ਚੋਣਾਂ ਨੂੰ ਛੁਪਾ ਦਿੰਦੇ ਹਨ—ਕਿਉਂ ਤੁਸੀਂ ਇੱਕ ਪਹਲ ਚੁਣੀ, ਕੀ ਤੁਸੀਂ ਰੱਦ ਕੀਤਾ, ਅਤੇ ਕਿਹੜੀਆਂ ਪਾਬੰਦੀਆਂ ਮਹੱਤਵਪੂਰਨ ਸਨ। ਬਾਅਦ ਵਿੱਚ ਟੀਮ ਵਾਰ-ਵਾਰ ਉਹੀ ਫੈਸਲੇ ਮੁੜ-ਚਰਚਾ ਕਰਦੀ ਹੈ ਜਾਂ ਅਣਜਾਣ ਕਰਕੇ ਧਾਰਣਾਵਾਂ ਨੂੰ ਤੋੜ ਦਿੰਦੀ ਹੈ।
ਇਸ ਨੂੰ ਰੋਕੋ:
/docs/decisions.md ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਹਰ ਮਹੱਤਵਪੂਰਨ ਚੋਣ ਲਈ ਇੱਕ ਬੁੱਲੇਟ ਹੋਵੇ।ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣਾ ਬਣਾਉਣਯੋਗੀ ਤਰੀਕਾ ਨਹੀਂ ਸਮਝੋ। ਜੇ ਹਰ ਇਟਰੇਸ਼ਨ ਵਿੱਚ ਸ਼ੌਟਕਟ ਜੋੜੇ ਜਾਂ, ਤਾਂ ਵਰਕਫਲੋ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਬਦਲਾਅ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦੇ ਹਨ।
ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ definition of done ਦਾ ਹਿੱਸਾ ਬਣਾਓ: ਇੱਕ ਫੀਚਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਹੋਰ ਪਾਸ ਦਿਆਂ ਜੋ ਨਾਮ ਸਧਾਰਨ ਕਰੇ, ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕੱਢੇ, ਅਤੇ ਮਰੇ ਹੋਏ ਰਸਤੇ ਹਟਾਏ। ਜੇ ਰੀਫੈਕਟਰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਟੈਸਟਾਂ ਜਾਂ ਸਪਸ਼ਟ ਬਾਊਂਡਰੀਆਂ ਦੀ ਲੋੜ ਹੈ।
ਬਿਨਾਂ ਗਾਰਡਰੇਲਾਂ ਦੇ, ਹਰ ਇਟਰੇਸ਼ਨ ਕੋਡ ਨੂੰ ਵੱਖਰੇ ਦਿਸ਼ਾ ਵਿੱਚ ਖਿੱਚ ਸਕਦੀ ਹੈ—ਨਵੀਂ ਪੈਟਰਨਾਂ, ਮਿਲੀ-ਜੁਲੀ ਨਾਮ-ਕਰਨ, ਫੋਲਡਰ ਪਰੰਪਰਾ 'ਚ ਘਲਾਟ।
ਡ੍ਰਿਫਟ ਰੋਕਣ ਲਈ:
ਇਹ ਆਦਤਾਂ ਵਰਕਫਲੋ ਨੂੰ ਤੇਜ਼ ਰੱਖਦੀਆਂ ਹਨ ਜਦੋਂ ਕਿ ਸਪਸ਼ਟਤਾ, ਲਗਾਤਾਰਤਾ, ਅਤੇ ਸੰਭਾਲਯੋਗਤਾ ਬਚਾਈ ਜਾਂਦੀ ਹੈ।
ਇਸਨੂੰ ਰੋਲਆਊਟ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਇੱਕ ਨਿਰੀਖਣਤਮਕ ਪ੍ਰਯੋਗ ਵਜੋਂ ਹੈ, ਨਾ ਕਿ ਪੂਰੇ ਕੰਪਨੀ ਲਈ ਇਕੋ ਵਾਰੀ ਦਾ ਬਦਲਾਉ। ਇੱਕ ਛੋਟੀ-ਸਲਾਇਸ ਕੰਮ ਚੁਣੋ ਜਿੱਥੇ ਤੁਸੀਂ ਪ੍ਰਭਾਵ ਨੂੰ ਮਾਪ ਸਕੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਢਾਲਵਾਂ।
ਇੱਕ ਫੀਚਰ ਖੇਤਰ (ਜਾਂ ਇੱਕ ਸਰਵਿਸ) ਚੁਣੋ ਅਤੇ ਅਗਲੇ sprint ਜਾਂ ਦੋ ਲਈ ਇੱਕ ਸਿੰਗਲ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਨਿਰਧਾਰਿਤ ਕਰੋ—ਉਦਾਹਰਨ: ਟਿਕਟ ਤੋਂ ਮਰਜ ਤੱਕ ਲੀਡ ਟਾਈਮ, ਰਿਵਿਊ ਚੱਕਰਾਂ ਦੀ ਗਿਣਤੀ, escaped bugs, ਜਾਂ on-call ਵਿਘਟਨ।
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ “ਡੋਨ” ਦਾ ਮਤਲਬ ਇੱਕ ਵਾਕ ਵਿੱਚ ਕੀ ਹੈ। ਇਸ ਨਾਲ ਪ੍ਰਯੋਗ ਸੱਚਾ ਰਹਿੰਦਾ ਹੈ।
ਸਾਂਝਾ ਪ੍ਰੋਂਪਟ ਟੈਮਪਲੇਟ ਲਾਗੂ ਕਰੋ ਤਾਂ ਜੋ ਪ੍ਰੋਂਪਟ ਤੁਲਨਯੋਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਹੋਣ। ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ:
ਪ੍ਰੋਂਪਟਾਂ ਨੂੰ ਰੇਪੋ (ਉਦਾਹਰਨ /docs/prompt-log.md) ਜਾਂ ਤੁਹਾਡੇ ਟਿਕਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਪਰ ਉਹ ਆਸਾਨੀ ਨਾਲ ਲੱਭਣਯੋਗ ਹੋਣ।
ਲੰਬੇ ਡੌਕ ਦੀ ਬਜਾਏ, ਹਰ ਬਦਲਾਅ ਲਈ ਤਿੰਨ ਹਲਕੇ-ਭਾਰੀ ਆਇਟਮ ਲਾਜ਼ਮੀ ਕਰੋ:
ਇਸ ਨਾਲ ਇਰਾਦੇ ਦਾ ਟ੍ਰੇਲ ਬਣਦਾ ਹੈ ਬਿਨਾਂ ਡਿਲੇ ਦੇ।
ਨਤੀਜਿਆਂ 'ਤੇ ਕੇਂਦਰਤ ਇੱਕ ਛੋਟੀ ਰੇਟ੍ਰੋ ਚਲਾਓ: ਕੀ ਮੈਟ੍ਰਿਕ ਹਿਲਿਆ? ਕਿਥੇ ਰਿਵਿਊ ਰੁਕੇ? ਕਿਹੜੇ ਪ੍ਰੋਂਪਟਾਂ ਨੇ ਗੁੰਝਲ ਪੈਦਾ ਕੀਤਾ? ਟੈਮਪਲੇਟ ਅਪਡੇਟ ਕਰੋ, ਘੱਟੋ-ਘੱਟ ਨਿਰਧਾਰਤ ਬਦਲੋ, ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅਗਲਾ ਖੇਤਰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ।
ਜੇ ਟੀਮ ਭਾਰੀ ਡੌਕਸ ਨੂੰ ਬਦਲਣ 'ਤੇ ਗੰਭੀਰ ਹੈ, ਤਾਂ ਉਹ ਟੂਲ ਵਰਤਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜੋ ਇਟਰੇਸ਼ਨ ਨੂੰ ਸੇਫ਼ ਬਣਾਉਂਦਾ: ਤੇਜ਼ deploys, ਆਸਾਨ environment resets, ਅਤੇ ਪ੍ਰਯੋਗ ਨਾਕਾਮ ਹੋਣ 'ਤੇ rollback ਕੀਤੇ ਜਾਣ ਦੀ ਖ਼ੁਬੀਅਤ।
ਉਦਾਹਰਨ ਲਈ, Koder.ai ਇਸ vibe-coding ਵਰਕਫਲੋ ਲਈ ਬਣਿਆ ਹੈ: ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਮਾਈਕ੍ਰੋ-ਪਲੈਨ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਕਰ ਸਕਦੇ ਹੋ, React-ਆਧਾਰਿਤ ਵੈੱਬ ਐਪ, Go + PostgreSQL ਬੈਕਏਂਡ, ਅਤੇ Flutter ਮੋਬਾਇਲ ਐਪ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਪੁਰਾਣੇ ਰੇਪੋ ਵਰਕਫਲੋ ਵਿੱਚ ਜਾਣਾ ਚਾਹੋ ਤਾਂ ਸੋурс ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹਨ।
Vibe coding ਵਰਕਫਲੋ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਡੌਕ ਮਿਟਦੇ ਨਹੀਂ—ਉਹੋ ਛੋਟੇ, ਜ਼ਿਆਦਾ ਨਿਰਧਾਰਿਤ, ਅਤੇ ਕੰਮ ਦੇ ਨੇੜੇ ਆ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਵੱਡੇ "ਬਿਗ ਡੌਕ" ਦੀ ਥਾਂ, ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਲਿਖਦੇ ਹੋ, ਦਸਤਾਵੇਜ਼ ਜੋ ਤੁਸੀਂ ਨਿਰਭਰ ਕਰਦੇ ਹੋ ਉਹ ਲਗਾਤਾਰ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: ਪ੍ਰੋਂਪਟ ਜੋ ਇਰਾਦਾ ਦੱਸਦੇ ਹਨ, ਇਟਰੇਸ਼ਨ ਜੋ ਹਕੀਕਤ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਰੀਫੈਕਟਰ ਜੋ ਨਤੀਜੇ ਨੂੰ ਸਮਝਣਯੋਗ ਅਤੇ ਸਥਾਈ ਬਣਾਉਂਦੇ ਹਨ।
Prompting ਇਰਾਦਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਇੱਕ ਚੰਗਾ ਪ੍ਰੋਂपਟ runnable design spec ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ: ਪਾਬੰਦੀਆਂ, acceptance criteria, ਅਤੇ “ਟੁੱਟਣਾ ਨਹੀਂ” ਨਿयਮ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
Iteration ਸੱਚਾਈ ਲੱਭਦੀ ਹੈ। ਛੋਟੇ ਚੱਕਰ (generate → run → inspect → adjust) ਕਾਗਜ਼ ਦੀ ਭਵਿੱਖਬਾਣੀ ਦੀ ਥਾਂ ਫੀਡਬੈਕ ਲਿਆਉਂਦੇ ਹਨ। ਜਦੋਂ ਕੁਝ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਬਹਿਸ ਨਹੀਂ ਕਰਦੇ—ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਮਾਪਦੇ ਹੋ, ਅਤੇ ਪ੍ਰੋਂਪਟ ਜਾਂ ਕੋਡ ਅਪਡੇਟ ਕਰਦੇ ਹੋ।
Refactoring ਇਸਨੂੰ ਲਾਕ-ਇਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਹੱਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਰੀਫੈਕਟਰ ਕਰਕੇ ਡਿਜ਼ਾਈਨ ਪੜ੍ਹਨਯੋਗ ਬਣਾਓ: ਨਾਮ, ਬਾਊਂਡਰੀਆਂ, ਟੈਸਟ ਅਤੇ ਟਿੱਪਣੀਆਂ ਜੋ “ਕਿਉਂ” ਦੱਸਦੀਆਂ ਹਨ। ਇਹ ਪੁਰਾਣੇ PDF ਤੋਂ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਲੰਬੇ ਸਮੇਂ ਲਈ ਹਵਾਲਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਯਾਦ ਰੱਖਣ ਲਈ ਕੁਝ ਸੰਕੁਚਿਤ, ਉੱਚ-ਸੰਕੇਤ ਆਰਟੀਫੈਕਟ ਰੱਖੋ:
ਇੱਕ ਸਧਾਰਤ prompt/PR ਟੈਮਪਲੇਟ ਅਪਨਾਓ, ਤੇਜ਼ੀ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟਾਂ ਨੂੰ ਤਿੱਖਾ ਕਰੋ, ਅਤੇ ਬਦਲਾਅ ਇੰਨੇ ਛੋਟੇ ਰੱਖੋ ਕਿ ਰਿਵਿਊ ਮਿੰਟਾਂ ਵਿੱਚ ਹੀ ਹੋ ਜਾਵੇ—ਦਿਨਾਂ ਵਿੱਚ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਰੋਲਆਊਟ ترتیب ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਵੇਖੋ /blog/a-practical-rollout-plan-for-your-team।
Vibe coding workflow ਇੱਕ ਇਟਰੇਟਿਵ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਥੇ ਤੁਸੀਂ ਪ੍ਰਭਾਵ ਨੂੰ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਵਿੱਚ ਦਰਸਾਉਂਦੇ ਹੋ, ਇੱਕ ਛੋਟੀ ਇਨਕ੍ਰਿਮੈਂਟ (ਅਕਸਰ AI ਨਾਲ) ਤਿਆਰ ਕਰਦੇ ਹੋ, ਉਸਨੂੰ ਚਲਾ ਕੇ ਨਤੀਜੇ ਵੇਖਦੇ ਹੋ ਅਤੇ ਸੁਧਾਰ ਕਰਦੇ ਹੋ।
ਇਹ ਲੰਬੇ ਅੱਗੇ-ਤਰਫ਼ ਦੀ ਯੋਜਨਾ ਦੀ ਥਾਂ ਤੇਜ਼ ਫੀਡਬੈਕ ਰੱਖਦਾ ਹੈ: prompt → implement → test → adjust।
ਜਦੋਂ ਅਸਲ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ constraints (API ਖਾਸੀਅਤਾਂ, ਏਜ ਕੇਸ, ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸੀਮਾਵਾਂ, ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਦੇ ਹਕੀਕਤੀ ਮਾਮਲੇ) ਦਰਸਾਉਂਦੀ ਹੈ, ਤਾਂ ਡਿਜ਼ਾਈਨ ਡੌਕਜ਼ ਜਲਦੀ ਹੀ 'ਸਟੇਲ' ਹੋ ਜਾਂਦੇ ਹਨ।
ਤੇਜ਼-ਰਫ਼ਤਾਰ ਕੰਮ ਵਿੱਚ, ਘਣੇ ਡੌਕਜ਼ ਨੂੰ ਲੋਕ ਅਕਸਰ ਝਲਕ ਕੇ ਦੇਖ ਲੈਂਦੇ ਹਨ ਜਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਹੁੰਦਾ ਇਹ ਹੈ ਕਿ ਕੋਸ਼ਿਸ਼ ਦਾ ਵੇਲਾ ਤਾਂ ਲਗਦਾ ਹੈ ਪਰ ਲਾਗਤ ਦਾ ਫਾਇਦਾ ਨੁਹੀਂ ਮਿਲਦਾ।
ਇੱਕ runnable design spec ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਚਾਰ ਮੁੱਖ ਚੀਜ਼ਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ ਕਿ ਕੋਈ ਆਸਾਨੀ ਨਾਲ ਕੋਡ ਜਨਰੇਟ ਕਰ ਸਕੇ ਅਤੇ ਉਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰ ਸਕੇ।
ਕੋਡਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਖੁੱਲ੍ਹ ਕੇ ਪੁੱਛੋ:
ਫਿਰ ਨਿਰਣਾ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਧਾਰਨਾਵਾਂ ਪਾਬੰਦੀਆਂ ਬਣਣਗੀਆਂ, ਕਿਹੜੀਆਂ ਟੈਸਟ ਬਣਨਗੀਆਂ ਅਤੇ ਕਿਹੜੀਆਂ ਲਈ Product/Design ਦੀ ਲੋੜ ਹੈ।
ਸਭ ਤੋਂ ਛੋਟੀ ਐਂਡ-ਟੂ-ਐਂਡ ਰਾਹ ਚੁਣੋ ਜੋ ਅਸਲ ਸਰਹੱਦਾਂ ਤੋਂ ਗੁਜ਼ਰਦੀ ਹੋਵੇ (UI → API → ਡੇਟਾ → ਬੈਕ)।
ਉਦਾਹਰਨ: “saved searches” ਲਈ ਹਰ ਇੱਕ ਫਿਲਟਰ ਦੀ ਰਚਨਾ ਕਰਨ ਦੀ ਥਾਂ ਇੱਕ ਫਿਲਟਰ, ਇਕ ਸੇਵ ਕੀਤੀ ਆਈਟਮ ਅਤੇ ਇਕ ਰੀਟਰੀਵ ਪਾਥ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜਦੋਂ ਉਹ ਸਲਾਇਸ ਠੀਕ ਚਲਣ ਜਾਵੇ ਤਾਂ ਵਧਾਓ।
ਹਰ ਇਕ ਲੂਪ ਨੂੰ 30–90 ਮਿੰਟ ਦੇ ਲਈ ਸਮੇਂ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਇੱਕ ਖਾਸ ਨਤੀਜਾ ਲਾਜ਼ਮੀ ਕਰੋ (ਪਾਸ ਹੋਣ ਵਾਲਾ ਟੈਸਟ, ਕੰਮ ਕਰਦੀ ਸਕਰੀਨ, ਮਾਪਿਆ ਗਿਆ ਕੁਏਰੀ ਸਮਾਂ, ਜਾਂ ਸਪੱਸ਼ਟ UX ਨਤੀਜਾ)।
ਜੇ ਅਗਲਾ ਕਦਮ 1–2 ਵਾਕਾਂ ਵਿੱਚ ਨਹੀਂ ਦੱਸਿਆ ਜਾ ਸਕਦਾ, ਤਾਂ ਉਸਨੂੰ ਛੋਟਾ ਕਰੋ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਯੋਜਨਾ ਮੰਗੋ, ਫਿਰ ਉਸਨੂੰ ਮਾਈਕ੍ਰੋ-ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਬਦਲੋ:
ਹਰ ਪ੍ਰੋਂਪਟ ਨੂੰ ਇੱਕ PR-ਸਾਈਜ਼ ਸਲਾਇਸ ਮੰਨੋ ਜੋ ਰਿਵਿਊਅਰ ਬੈਠਕੇ ਸਮਝ ਸਕੇ ਬਿਨਾਂ ਮੀਟਿੰਗ ਦੇ।
ਜਦੋਂ ਤੁਸੀਂ ਇਟਰੇਸ਼ਨ ਤੋਂ ਕਾਫੀ ਸਿੱਖ ਲੈ ਲੈਂਦੇ ਹੋ ਕਿ ਸੱਚੀਆਂ ਸੀਮਾਵਾਂ ਕਿਹੜੀਆਂ ਹਨ — ਇਕੋ ਖੇਤਰ ਵਿੱਚ ਲਗਾਤਾਰ ਬਦਲਾਅ, ਗੁੰਝਲਦਾਰ ਮਾਲਕੀਅਤ, ਜਾਂ ਅਜਿਹੇ ਬੱਗ ਜੋ ਅਸਪਸ਼ਟ ਸਰਹੱਦਾਂ ਕਾਰਨ ਹਨ — ਤਦ ਰੀਫੈਕਟਰ ਕਰੋ।
ਰੀਫੈਕਟਰਿੰਗ ਨਾਲ ਇਰਾਦਾ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ: ਨਾਮ, ਮੋਡਯੂਲ, ਬਾਊਂਡਰੀਆਂ ਅਤੇ ਟੈਸਟ ਜੋ ਭਵਿੱਖੀ ਟੀਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਸੂਚਨਾ ਦੇਣ।
ਲੰਬੇ ਡਿਜ਼ਾਈਨ ਡੌਕ ਛੱਡ ਕੇ ਵੀ ਯਾਦ ਰੱਖਣ ਲਈ ਛੋਟੀ-ਪਰ-ਮੁੱਖ ਚੀਜ਼ਾਂ ਰੱਖੋ:
ਦੋਹਰਾਈ ਕਰਨ ਦੀ ਥਾਂ ਅੰਦਰੂਨੀ ਲਿੰਕ (ਜਿਵੇਂ ) ਵਰਤੋ।
ਹਰ ਇਟਰੇਸ਼ਨ ਲਈ ਚਲਦੇ ਰਹਿਣ ਵਾਲੇ ਕੁਝ ਗੇਟ ਰੱਖੋ:
ਨਾਨ-ਫੰਕਸ਼ਨਲ ਜ਼ਰੂਰਤਾਂ (ਪਰਫਾਰਮੈਂਸ, accessibility, ਪਰਾਈਵੇਸੀ/ਸੁਰੱਖਿਆ) ਨੂੰ PR ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਇਹਨਾਂ ਵਿੱਚ ਗੁੰਮ ਨਾ ਹੋਣ।
/docs/decisions.md