ਵਾਇਬ ਕੋਡਿੰਗ ਸਮਝਾਈ ਗਈ: ਵਰਕਫਲੋ ਅਤੇ 3 ਅਸਲ ਬਿਲਡ ਉਦਾਹਰਣਾਂ

ਵਾਇਬ ਕੋਡਿੰਗ ਦਾ ਸਧਾਰਨ ਅਰਥ

Vibe coding ਹੈ AI ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸ ਕੇ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣਾ, ਫਿਰ ਨਤੀਜੇ ਤੇ ਦੁਹਰਾਉਂਦੇ ਰਹਿਣਾ ਜਦ ਤਕ ਇਹ ਤੁਹਾਡੀ ਉਮੀਦਾਂ ਅਨੁਸਾਰ ਕੰਮ ਨਾ ਕਰਨ ਲੱਗੇ।

ਮਕਸਦ ਸਧਾਰਾ ਹੈ: ਖਾਲੀ ਕੋਡ ਫਾਈਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਨਿਯਤ ਇਰਾਦੇ ਨੂੰ ਵਰਣਨ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਸਕ੍ਰੀਨ, API ਅਤੇ ਫੀਚਰ ਤਿਆਰ ਕਰਨਾ। ਤੁਸੀਂ ਦੱਸਦੇ ਹੋ ਕਿ ਐਪ ਕਿਵੇਂ ਕੰਮ ਕਰੇ, ਕਿਹੜੇ ਡੇਟਾ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ "ਮੁੱਕਮਲ" ਕੀ ਵੇਖਣਾ ਹੈ। AI ਇਸਨੂੰ ਕੋਡ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਢਾਂਚੇ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਫੀਡਬੈਕ ਨਾਲ ਦਿਸ਼ਾ ਦਿੰਦੇ ਹੋ, ਜਿਵੇਂ "ਲੌਗਿਨ ਸਧਾਰਨ ਬਣਾਓ" ਜਾਂ "ਆਰਡਰਜ਼ ਨੂੰ ਸਟેટਸ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਨਾਲ ਸਟੋਰ ਕਰੋ।"

ਇਸਨੂੰ ਇੱਕ ਤੇਜ਼ ਜੂਨੀਅਰ ਡਿਵੈਲਪਰ ਦਾ ਨਿਰਦੇਸ਼ ਦੇਣ ਵਾਂਗ ਸੋਚੋ। ਇਹ ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖ ਸਕਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਸਾਫ਼ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਅਤੇ ਆਕਸਮੀ ਦਰੁਸਤੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ, ਚੈਟ ਮੁੱਖ ਇੰਟਰਫੇਸ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਐਪ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਇਹ React ਵੈੱਬ UI, Go ਬੈਕਐਂਡ, ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ PostgreSQL ਡੈਟਾਬੇਸ ਸੈਟਅਪ ਜਨਰੇਟ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਫਿਰ ਤਬਦੀਲੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਗਲਤ ਹੋਏ ਤਾਂ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਪੂਰਾ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।

ਕੁਝ ਗਾਈਡਰੈਲਜ਼ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:

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

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

ਬੁਨਿਆਦੀ ਵਰਕਫਲੋ: ਵਰਣਨ ਕਰੋ, ਬਣਾਓ, ਚੈੱਕ ਕਰੋ, ਦੁਹਰਾਓ

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

1) ਵਰਣਨ ਕਰੋ

ਸਭ ਤੋਂ ਛੋਟੀ ਲਾਭਦਾਇਕ ਸਲਾਇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪੂਰੇ ਸੁਪਨੇ ਨਾਲ ਨਹੀਂ। ਦੱਸੋ ਕਿ ਐਪ ਕਿਸ ਲਈ ਹੈ, کون ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ, ਅਤੇ "ਮੁੱਕਮਲ" ਕੀ ਹੋਵੇਗਾ।

ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਇਹ ਹੈ: “Y ਲਈ X ਬਣਾਓ, ਇਹ A ਅਤੇ B ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ C ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।” ਇੱਥੇ ਮਨੁੱਖਾਂ ਦੀ ਅਗਵਾਈ ਜ਼ਰੂਰੀ ਹੈ। ਤੁਸੀਂ ਫੀਚਰ, ਨਿਯਮ, ਅਤੇ ਪਹਿਲਾਂ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਚੁਣਦੇ ਹੋ।

2) ਬਣਾਉ

ਸਿਸਟਮ ਤੁਹਾਡੇ ਲਈ ਬੋਰਿੰਗ ਹਿੱਸੇ ਬਣਾਉਂਦਾ ਹੈ: ਪ੍ਰੋਜੈਕਟ ਸੈਟਅਪ, ਰਾਊਟਿੰਗ, ਡੈਟਾਬੇਸ ਵਾਇਰਿੰਗ, ਬੇਸਿਕ UI, ਅਤੇ ਲਾਜਿਕ ਦਾ ਪਹਿਲਾ ਵਰਜਨ। Koder.ai ਵਰਗਾ vibe-coding ਟੂਲ ਇਸਨੂੰ ਘੰਟਿਆਂ ਦੇ ਸੈਟਅਪ ਅਤੇ ਬਾਇਲਰਪਲੇਟ ਦੀ ਥਾਂ ਚੈਟ ਰਾਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।

ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਢਾਂਚਾ ਮੰਗੋ: “ਤਿੰਨ ਸਕ੍ਰੀਨ ਬਣਾਓ,” “ਲੌਗਿਨ ਜੋੜੋ,” “ਆਈਟਮਾਂ ਨੂੰ PostgreSQL ਟੇਬਲ ਵਿੱਚ ਸਟੋਰ ਕਰੋ,” ਜਾਂ “ਇੱਕ ਐਂਡਪੌਇੰਟ ਐਕਸਪੋਜ਼ ਕਰੋ ਜੋ JSON ਰਿਟਰਨ ਕਰੇ।” ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਪਰਫੈਕਟ ਕੋਡ ਦੀ ਪਿੱਛਾ ਨਾ ਕਰੋ। ਇੱਕ ਚੱਲਣਯੋਗ ਡਰਾਫਟ ਲਈ ਮੰਨੋ ਜੋ ਤੁਸੀਂ ਟਚ ਕਰ ਸਕੋ।

3) ਚੈੱਕ

ਕੇਵਲ ਚੈਟ ਆਉਟਪੁੱਟ ਨੂੰ ਨਾ ਪੜ੍ਹੋ। ਐਪ ਚਲਾ ਕੇ ਅਸਲ ਸਿਗਨਲ ਲੱਭੋ।

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

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਮਾਂ ਹੋਵੇ, ਤਾਂ ਉਹ ਨਿਯਮਾਂ ਲਈ ਕੁਝ ਸਧਾਰਨ ਟੈਸਟ ਜ਼ੋਰ ਨਾਲ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਬਾਅਦ ਵਿੱਚ ਚੁਪ ਚਾਪ ਟੁੱਟਣ ਨਾ ਪਾਏਂ।

4) ਦੁਹਰਾਓ

ਹੁਣ ਇਕ ਪ੍ਰੋਡਕਟ ਓਨਰ ਅਤੇ ਸਮੀਖਿਆਕਾਰ ਦੀ ਤਰ੍ਹਾਂ ਪ੍ਰਤੀਕ੍ਰਿਆ ਦਿਓ। ਦੱਸੋ ਕਿ ਕੀ ਗਲਤ ਹੈ, ਕੀ ਬਦਲਣਾ ਹੈ, ਅਤੇ ਕੀ ਰੱਖਣਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਬਣੋ: “ਲੇਆਊਟ ਰੱਖੋ, ਪਰ ਬਟਨ ਨੂੰ ਹੈਡਰ ਵਿੱਚ ਲਿਜਾਓ,” ਜਾਂ “ਨੈਗੇਟਿਵ ਰਕਮਾਂ ਨੂੰ 400 ਐਰਰ ਨਾਲ ਰਿਜੈਕਟ ਕਰੋ।”

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

ਕਿਥੇ vibe coding ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ (ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ)

Vibe coding ਸਭ ਤੋਂ ਵਧੀਆ ਤਾਂ ਹੈ ਜਦੋਂ ਲਕੜੀ ਕਾਫ਼ੀ ਸਪਸ਼ਟ ਹੋ ਜੋ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਣਨ ਕੀਤੀ ਜਾ ਸਕੇ, ਅਤੇ "ਲਗਭਗ ਠੀਕ" ਹੋਣ ਦੀ ਲਾਗਤ ਘੱਟ ਹੋਵੇ। ਤੁਹਾਨੂੰ ਤੇਜ਼ ਫੀਡਬੈਕ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਪਹਿਲੇ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਪਰਫੈਕਟ ਸਿਸਟਮ। ਜੇ ਤੁਸੀਂ ਨਤੀਜੇ ਵੱਲ ਇशਾਰਾ ਕਰਕੇ ਕਹਿ ਸਕਦੇ ਹੋ “ਹਾਂ, ਇਹ ਠੀਕ ਹੈ” ਜਾਂ “ਇਸ ਹਿੱਸੇ ਨੂੰ ਬਦਲੋ,” ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਜ਼ੋਨ ਵਿੱਚ ਹੋ।

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

ਇਹ ਅਕਸਰ ਪ੍ਰੋਟੋਟਾਈਪ, ਅੰਦਰੂਨੀ ਟੂਲ (ਡੈਸ਼ਬੋਰਡ, ਐਡਮਿਨ ਪੈਨਲ, ਸਧਾਰਨ ਆਟੋਮੇਸ਼ਨ), ਅਤੇ ਮਿਆਰੀ ਫਲੋ ਨਾਲ ਸੰਕੁਚਿਤ MVPs ਲਈ ਚਮਕਦਾ ਹੈ। ਇਹ “ਗਲੂ” ਐਪਾਂ ਲਈ ਵੀ ਚੰਗਾ ਹੈ ਜੋ ਕੁਝ ਸਰਵਿਸਜ਼ ਨੂੰ ਜੋੜਦੇ ਹਨ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਨਪੁੱਟ ਅਤੇ ਆਉਟਪੁੱਟ ਪਰਿਭਾਸ਼ਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ।

ਜਦੋਂ ਲੋੜਾਂ ਕਠੋਰ, ਗਹਿਰੇ, ਜਾਂ ਛੋਟੇ-ਛੋਟੇ ਅਪਵਾਦਾਂ ਨਾਲ ਭਰੀਆਂ ਹੋਵਨ ਤਾਂ ਇਹ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਜਟਿਲ ਕੰਪਲਾਇਂਸ ਨਿਯਮ (ਜਿੱਥੇ ਸ਼ਬਦਬੰਦੀ ਸਰਪ੍ਰਾਕ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ), ਭਾਰੀ ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ (ਜਿੱਥੇ ਛੋਟੀ ਚੋਣਾਂ ਦੇ ਵੱਡੇ ਖ਼ਰਚ ਹੁੰਦੇ ਹਨ), ਅਤੇ ਵੱਡੇ ਲੈਗੇਸੀ ਸਿਸਟਮ (ਜਿੱਥੇ ਛੁਪੇ ਹੋਏ ਨਿਰਭਰਤਾਵਾਂ ਹਰ ਜਗ੍ਹਾ ਹਨ)। ਇੱਥੇ ਵੀ ਤੁਸੀਂ vibe coding ਵਰਤ ਸਕਦੇ ਹੋ, ਪਰ ਕੰਮ ਸਾਵਧਾਨ ਵਿਸ਼ੇਸ਼ਣਾਂ, ਸਮੀਖਿਆਵਾਂ, ਅਤੇ ਟੈਸਟਿੰਗ ਵੱਲ ਵੱਧ ਗਿਆ।

ਇਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਬਰੀਕ ਸਲਾਇਸ ਪਹਿਲਾਂ ਬਣਾਓ ਅਤੇ ਕੇਵਲ ਉਸੇ ਨੂੰ ਵਧਾਓ ਜੇ ਨਤੀਜਾ ਪੂਛੇ ਤੱਕ ਭਰੋਸੇਯੋਗ ਰਹੇ। ਇੱਕ ਸਕ੍ਰੀਨ, ਇੱਕ API ਰੂਟ, ਇੱਕ ਡੇਟਾ ਟੇਬਲ ਲਈ ਇੱਕ ਪੂਰਾ ਏਂਡ-ਟੂ-ਏਂਡ ਸਲਾਇਸ ਬਣਾਓ। ਜੇ ਉਹ ਸਲਾਇਸ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਆ ਜਾਂਦੀ ਹੈ ਤਾਂ ਅਗਲਾ ਜੋੜੋ।

ਜਦੋਂ ਤੁਸੀਂ ਹੇਠਾਂ ਲਿਖੇ ਨਿਸ਼ਾਨ੍ਹੇ ਵੇਖੋ ਤਾਂ ਰੁੱਖੋ ਅਤੇ ਯੋਜਨਾ ਕਸਦੀ ਕਰੋ:

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

ਜੇ ਇਹ ਲੱਭੋ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਸਪਸ਼ਟ ਨਿਯਮ, ਉਦਾਹਰਨ ਇੰਪੁੱਟ/ਆਉਟਪੁੱਟ, ਅਤੇ ਕੁਝ “ਪਾਸ ਹੋਣ-ਚਾਹੀਦਾ” ਟੈਸਟ ਲਿਖੋ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ planning mode ਅਤੇ snapshots ਤੁਹਾਨੂੰ ਇੱਕ ਚਲਦੀ ਹੋਈ ਵਰਜਨ ਗੁਆਣ ਤੋਂ ਬਿਨਾਂ ਦੁਹਰਾਉ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।

AI ਨੂੰ ਕੀ ਦਿਓ: ਉਹ ਪ੍ਰੋਂਪਟ ਜੋ ਚੱਲਣਯੋਗ ਕੋਡ ਵਲ ਲਿਜਾਂਦੇ ਹਨ

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

ਚੈਟ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਜੈਕਟ ਬ੍ਰੀਫ ਬਣਾਓ। ਇਸਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ: ਮੰਤਵ (ਇੱਕ ਵਾਕ), ਕੌਣ ਵਰਤਦਾ ਹੈ, ਕੁਝ ਸਕ੍ਰੀਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਕਲਿਕ ਕਰਨ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਮੁੱਖ ਡੇਟਾ ਜੋ ਤੁਸੀਂ ਸਟੋਰ ਕਰਦੇ ਹੋ (ਅਤੇ ਜਿਹੜੇ ਫੀਲਡ ਮਾਇਆਨੇ ਰੱਖਦੇ ਹਨ), ਅਤੇ ਕੋਈ ਵੀ ਕਠੋਰ ਪਾਬੰਦੀਆਂ (ਮੋਬਾਈਲ-ਮਿੱਤਰ, UTC ਵਿੱਚ ਤਾਰੀਖਾਂ, ਡਾਰਕ ਮੋਡ, ਆਦਿ)।

ਫੀਚਰਾਂ ਦੀ ਵਰਣਨਾ ਉਦਾਹਰਣਾਂ ਨਾਲ ਕਰੋ, ਨਾਂ ਕਿ ਨਾਅਰੇ ਨਾਲ। “Users can manage tasks” ਨੇ ਸਪਸ਼ਟਤਾ ਨਹੀਂ ਦਿੰਦਾ। “A user can create a task with title, due date, and priority; mark it done; and filter by status” AI ਨੂੰ ਇਕ ਟੈਸਟ ਕਰਨਯੋਗ ਚੀਜ਼ ਦਿੰਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਐਸਾ ਕੋਡ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਸੰਭਾਲ ਸਕੋ, ਤਾਂ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਢਾਂਚਾ ਮੰਗੋ: ਕਿਹੜੇ ਪੇਜ਼ ਮੌਜੂਦ ਹਨ, ਕਿਹੜੇ ਟੇਬਲ ਲੋੜੀਂਦੇ ਹਨ, ਅਤੇ ਕਿਸ API ਐਂਡਪੌਇੰਟ ਉਹਨਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ। ਇਸ ਲਈ ਤੁਸੀਂ ਟੈਕਨੀਕਲ ਹੋਏ ਬਿਨਾਂ ਵੀ ਇਹ ਮੰਗ ਸਕਦੇ ਹੋ—ਸਧਾਰਨ ਸ਼ਬਦ ਕਾਫ਼ੀ ਹਨ।

ਇੱਥੇ ਇੱਕ ਪ੍ਰੋਂਪਟ ਹੈ ਜੋ ਤੁਸੀਂ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹੋ (Koder.ai ਵਰਗੇ ਟੂਲਾਂ ਵਿੱਚ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ):

Build a small web app called “Team Tasks”.

Users: Admin, Member.
Goal: track tasks for a small team.

Screens:
1) Login
2) Task list (filter: All, Open, Done)
3) Task details
4) Admin: Users list

Data:
Task(id, title, description, status, due_date, created_by, assigned_to)
User(id, name, email, role)

Rules:
- Members can only edit tasks they created.
- Admin can view and edit everything.

Please propose:
- Pages/components
- Database tables
- API endpoints (CRUD)
Then generate the first working version.

ਸਕੋਪ ਨੂੰ ਨਿਯੰਤਰਿਤ ਰੱਖਣ ਲਈ, ਆਪਣੇ “v1” ਨੂੰ ਛੋਟੀ ਫੀਚਰ ਲਿਸਟ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਇੱਕ ਲਾਭਦਾਇਕ ਲਾਈਨ ਜੋ ਜੋੜਨੀ ਚੰਗੀ ਰਹਿੰਦੀ ਹੈ: “If anything is unclear, ask up to 5 questions before building.” ਇਸ ਨਾਲ ਅਟਕਲੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਅਣਚਾਹੀਆਂ ਫੀਚਰ ਆਉਣ ਦੀ ਸੰਭਾਵਨਾ ਕੱਟਦੀ ਹੈ।

ਇੱਕ ਦੁਹਰਣਯੋਗ ਪ੍ਰਕਿਰਿਆ ਜੋ ਛੋਟੀ ਰਹਿੰਦੀ ਹੈ (ਅਤੇ ਸਮਝਦਾਰ)

ਇੱਕ ਸਧਾਰਨ ਰਿਦਮ ਜੋ ਜ਼ਿਆਦਾਤਰ ਬਿਲਡਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ:

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

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

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

ਜਦੋਂ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਚੈੱਕਪੌਇੰਟ ਕੈਪਚਰ ਕਰੋ (ਸਨੇਪਸ਼ੌਟ, ਟੈਗ, ਜਾਂ ਜੋ ਭੀ ਤੁਹਾਡਾ ਟੂਲ ਸਪੋਰਟ ਕਰਦਾ ਹੈ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਗਲੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸ ਜਾ ਸਕੋ। ਇਹੀ ਜੱਗਾ ਹੈ ਜਿੱਥੇ Koder.ai ਵਰਗੇ ਟੂਲ ਵਿਹਵਾਰਕ ਤੌਰ 'ਤੇ ਸਹਾਇਕ ਸਾਬਤ ਹੁੰਦੇ ਹਨ: ਸਨੇਪਸ਼ੌਟ ਅਤੇ ਰੋਲਬੈਕ ਤਜਰਬਾ ਨਿੁਕਸਾਨ-ਰਹਿਤ ਬਣਾਉਂਦੇ ਹਨ।

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

ਉਦਾਹਰਨ 1: ਚੈਟ ਰਾਹੀਂ ਬਣਾਈ ਗਈ ਵੈੱਬ ਐਪ (ਖਿਆਲ ਤੋਂ ਚੱਲ ਰਹੀਆਂ ਸਕ੍ਰੀਨਾਂ ਤੱਕ)

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

ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਐਕਸ਼ਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, טੈਕਨੋਲੋਜੀ ਨਾਲ ਨਹੀਂ। ਉਦਾਹਰਨ ਵਜੋਂ: ਇੱਕ ਸਾਇਨ-ਇਨ ਪੇਜ (ਈਮੇਲ + ਪਾਸਵਰਡ, ਸਾਈਨ ਆਊਟ), ਇੱਕ ਟਾਸਕ ਲਿਸਟ (ਲਿਸਟ, ਬਣਾਓ, ਸੋਧੋ, ਮਿਟਾਓ), ਅਤੇ ਵਿਕਲਪਕ ਟਾਸਕ ਡੀਟੇਲਸ ਵਿਊ (ਨੋਟਸ, ਡਿਊ ਡੇਟ, ਸਟੇਟਸ) ਅਤੇ ਇੱਕ ਬੇਸਿਕ ਸੈਟਿੰਗਸ ਸਕ੍ਰੀਨ।

ਫਿਰ, ਡੇਟਾ ਮਨੁੱਖੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵੇਰਵਾ ਕਰੋ। “Schema ਡਿਜ਼ਾਈਨ ਕਰੋ” ਦੀ ਬਜਾਏ ਦੱਸੋ ਕਿ ਇੱਕ ਟਾਸਕ ਵਿੱਚ ਕੀ ਸਟੋਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਇੱਕ ਟਾਈਟਲ, ਵਿਕਲਪਕ ਨੋਟਸ, ਇੱਕ ਸਟੇਟਸ (todo/doing/done), ਇੱਕ ਵਿਕਲਪਕ ਡਿਊ ਡੇਟ, ਅਤੇ ਬਣਾਉਣ ਤੇ ਅਪਡੇਟ ਹੋਣ ਦੇ ਟਾਈਮਸਟੈਂਪ। ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਟਾਸਕ ਇੱਕ ਯੂਜ਼ਰ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਪਹਿਲਾ ਵਰਜਨ ਮੰਗੋ ਜੋ ਏਂਡ-ਟੂ-ਏਂਡ ਚੱਲਦਾ ਹੋਵੇ: React ਸਕ੍ਰੀਨਾਂ, ਇਕ Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਡੈਟਾਬੇਸ ਵਿੱਥ ਵਰਣਨ ਕੀਤੇ ਫੀਲਡ। ਪਹਿਲੀ ਪਾਸ ਤੰਗ ਰੱਖੋ: ਸਾਇਨ ਇਨ, ਟਾਸਕ ਵੇਖੋ, ਟਾਸਕ ਜੋੜੋ। ਜਦੋਂ ਇਹ ਕੰਮ ਕਰੇ, ਫਿਰ ਦੁਹਰਾਓ।

ਦੁਹਰਾਓ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ

ਅਮਲਕਾਰੀ ਰਿਦਮ ਹੈ “ਇਸਨੂੰ ਚਲਾਉ, ਫਿਰ ਸੁਧਾਰ ਕਰ।” ਇੱਕ ਹਕੀਕਤੀ ਕ੍ਰਮ ਇਹ ਹੋ ਸਕਦਾ ਹੈ:

1. ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼: ਲੋਕਲ ਐਪ ਏਂਡ-ਟੂ-ਏਂਡ ਕੰਮ ਕਰਦਾ (ਸਾਇਨ ਇਨ, ਲਿਸਟ, ਜੋੜੋ)
2. ਦੂਜੀ ਕੋਸ਼ਿਸ਼: ਸੋਧ ਅਤੇ ਮਿਟਾਓ, ਨਾਲ ਹੀ ਬੇਸਿਕ ਲੇਆਊਟ
3. ਤੀਜੀ ਕੋਸ਼ਿਸ਼: ਫਿਲਟਰ (ਸਟੇਟਸ, ਡਿਊ ਡੇਟ, ਖੋਜ)
4. ਚੌਥੀ ਕੋਸ਼ਿਸ਼: ਸਾਂਝਾ-ਕਰਨ (ਟੀਮੀਟ ਨੂੰ ਨਿਯੋਤਾ, ਜਾਂ ਪੜ੍ਹਨ-ਕੇਵਲ ਲਿੰਕ)

ਹਰੇਕ ਰਾਊਂਡ ਇੱਕ ਹੋਰ ਚੈਟ ਬੇਨਤੀ ਹੁੰਦੀ ਹੈ ਜੋ ਪਹਿਲਾਂ ਦਿੱਤੇ ਕੰਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਬਦਲਾਅ ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਹੋਣ ਅਤੇ ਕੀ ਨਹੀਂ ਟੁੱਟਣਾ ਚਾਹੀਦਾ, ਇਹ ਯਕੀਨੀ ਹੋਵੇ।

"ਡਨ" ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਚੈੱਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਇੱਕ ਛੋਟੀ ਵੈੱਬ ਐਪ ਲਈ ਵੀ ਕੁਝ ਵਿਸਥਾਰ ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਹਕੀਕਤ ਵਿੱਚ ਚੰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ:

• ਲਿਸਟ ਲੋਡ ਹੋਣ ਸਮੇਂ ਲੋਡਿੰਗ ਸਟੇਟ, ਅਤੇ ਸੇਵ ਹੋਣ ਦੌਰਾਨ ਬਟਨ ਡਿਸੇਬਲ ਹੋਣਾ।
• ਫਾਰਮ ਵੈਲਿਡੇਸ਼ਨ (ਖਾਲੀ ਟਾਈਟਲ, ਗਲਤ ਤਾਰીખ) ਸਾਫ਼ ਸੁਨੇਹੇ ਦੇਣ।
• ਡੇਟਾ ਸੇਵ ਹੋ ਰਿਹਾ ਹੈ (ਪੇਜ਼ ਰਿਫਰੈਸ਼ ਕਰੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਟਾਸਕ ਰਹਿੰਦੇ ਹਨ)।
• ਪ੍ਰਮੀਸ਼ਨ (ਇੱਕ ਯੂਜ਼ਰ ਹੋਰ ਯੂਜ਼ਰ ਦੇ ਟਾਸਕ ਨਾ ਵੇਖ ਸਕੇ)।
• ਕੁਝ ਅਸਲ-ਦੁਨੀਆ ਏਜ ਕੇਸ ਜਿਵੇਂ ਧੀਮਾ ਨੈੱਟਵਰਕ, ਨਕਲ ਕਲਿੱਕ, ਅਤੇ ਓਹੁ ਆਇਟਮ ਮਿਟਾਉਣਾ ਜੋ ਤੁਸੀਂ ਵੇਖ ਰਹੇ ਹੋ।

ਇੱਕ ਚੰਗੀ ਦੁਹਰਾਉ ਬੇਨਤੀ ਅਜਿਹੀ ਹੁੰਦੀ ਹੈ: “Add a status filter with tabs (All, Todo, Doing, Done). Keep the database the same. Update the API so it can filter by status, and show a loading state when switching tabs.” ਛੋਟੀ, ਟੈਸਟਯੋਗ, ਅਤੇ ਗਲਤ ਸਮਝਣ ਮੁਸ਼ਕਲ।

ਉਦਾਹਰਨ 2: ਇੱਕ API ਜੋ ਤੁਸੀਂ ਵਾਕਾਂ ਵਿੱਚ ਵੇਰਵਾ ਕਰ ਸਕਦੇ ਹੋ

API ਵਰਣਨ ਕਰਨਾ vibe coding ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਜਗ੍ਹਾ ਹੈ ਕਿਉਂਕਿ ਕੰਮ ਜ਼ਿਆਦਾਤਰ ਨਿਯਮਾਂ ਦਾ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਕਿਹੜਾ ਡੇਟਾ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਮਨਜ਼ੂਰ ਹਨ, ਅਤੇ ਜਵਾਬ ਕਿਵੇਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਸੋਚੋ ਇੱਕ ਛੋਟੇ ਸਟੋਰ ਸਿਸਟਮ ਬਾਰੇ ਜਿਸ ਵਿੱਚ ਦੋ ਚੀਜ਼ਾਂ ਹੋਣ: customers ਅਤੇ orders. ਤੁਹਾਡੇ ਵਾਕ ਬਹੁਤ ਸਧਾਰਨ ਹੋ ਸਕਦੇ ਹਨ: “Customers have name and email. Orders belong to a customer, have items, total price, and a status like draft, paid, shipped.” ਇਹ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ।

ਐਂਡਪੌਇੰਟਸ ਨੂੰ ਇੱਕ ਸਾਥੀ ਵਾਂਗ ਦੱਸੋ

ਇਹ ਸਪਸ਼ਟ ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਕੀ ਭੇਜਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੀ ਵਾਪਸ ਮਿਲੇਗਾ।

ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦੇ ਸਕਦੇ ਹੋ (create, list, get one, update, delete) customers ਅਤੇ orders ਲਈ, ਫਿਰ ਕੁਝ ਫਿਲਟਰ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹਨ (ਉਦਾਹਰਨ: list orders by customer_id and status). ਫਿਰ ਇਹ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਕਿ “not found”, “bad input”, ਅਤੇ “not allowed” ਲਈ ਐਰਰ ਕਿਵੇਂ ਵਰਤਣੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਐਂਡਪੌਇੰਟ ਲੌਗਿਨ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ।

ਫਿਰ ਇਨਪੁੱਟ ਨਿਯਮ ਅਤੇ ਐਰਰ ਜਵਾਬ ਜੋੜੋ। ਉਦਾਹਰਨ ਨਿਯਮ: email ਵੈਧ ਅਤੇ ਯੂਨੀਕ ਹੋਣਾ ਚਾਹੀਦਾ; order items ਘੱਟੋ-ਘੱਟ 1 ਹੋਣ; total items ਦੇ ਜੋੜਾ ਦੇ ਬਰਾਬਰ ਹੋਣਾ ਚਾਹੀਦਾ; ਸਟੇਟਸ ਸਿਰਫ਼ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ (draft -> paid -> shipped)।

ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹੋ, ਤਾਂ token auth (bearer token), ਸਧਾਰਨ ਰੋਲ (admin vs support), ਅਤੇ rate limiting (ਉਦਾਹਰਨ: 60 requests per minute per token) ਮੰਗੋ। Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ planning mode ਤੁਹਾਨੂੰ ਇਹ ਨਿਯਮਾਂ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਕਿਸੇ ਵੀ ਕੋਡ ਨੂੰ ਜਨਰੇਟ ਨਾ ਕੀਤਾ ਜਾਵੇ।

ਕੁਝ ਨਮੂਨਾ ਬੇਨਤੀਆਂ ਨਾਲ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਪੱਕਾ ਕਰੋ

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

# Create customer
curl -X POST http://localhost:8080/customers \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"name":"Mina Lee","email":"[email protected]"}'

# Expected: 201 + JSON with id, name, email

# Create order
curl -X POST http://localhost:8080/orders \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"customer_id":1,"items":[{"sku":"A1","qty":2,"price":12.50}]}'

# Expected: 201 + status "draft" + computed total 25.00

# Bad input example (invalid email)
# Expected: 400 + {"error":"invalid_email"}

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

ਉਦਾਹਰਨ 3: ਮੋਬਾਈਲ ਐਪ ਵਰਕਫਲੋ (ਸ਼ੁਰੂ 'ਤੇ ਕੀ ਪਰਿਭਾਸ਼ਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ)

ਇੱਕ ਚੰਗਾ ਮੋਬਾਈਲ ਉਦਾਹਰਨ ਇੱਕ ਸਧਾਰਣ habit tracker ਹੈ। ਮੋਬਾਈਲ ਐਪਾਂ ਛੋਟੇ ਸਕ੍ਰੀਨ, ਆਫਲਾਈਨ ਵਰਤੋਂ, ਅਤੇ ਡਿਵਾਈਸ ਫੀਚਰਾਂ ਕਾਰਨ “ਕਠਿਨ” ਲੱਗਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਸੀਮਾਵਾਂ ਪਹਿਲੇ ਬਿਲਡ ਤੋਂ ਪਹਿਲਾਂ ਵਿਆਖਿਆ ਕਰਦੇ ਹੋ ਤਾਂ ਨਤੀਜੇ ਵਧੀਆ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਬੱਗ ਆਉਣ ਤੋਂ ਬਾਅਦ।

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

ਇੱਕ ਮਜ਼ਬੂਤ ਪਹਿਲਾ ਵਰਜਨ:

• Onboarding: ਆਦਤਾਂ ਚੁਣੋ ਅਤੇ ਰਿਮਾਈਂਡਰ ਸਮਾਂ ਸੈੱਟ ਕਰੋ
• Daily list: ਅੱਜ ਦੀਆਂ ਆਦਤਾਂ ਇੱਕ ਸਧਾਰਨ done/not done ਟੌਗਲ ਨਾਲ
• Add habit: ਨਾਮ, ਸ਼ੈਡਿਊਲ (روزਾਨਾ ਜਾਂ ਕਸਟਮ ਦਿਨ), ਵਿਕਲਪਕ ਲਕਸ਼
• Stats: ਪਿਛਲੇ 7 ਦਿਨ, streaks, ਸਧਾਰਨ ਪ੍ਰੋਗਰੈਸ ਚਾਰਟ
• Settings: ਰਿਮਾਈਂਡਰ on/off, ਡੇਟਾ ਐਕਸਪੋਰਟ ਜਾਂ ਰੀਸੈੱਟ

ਫਿਰ, ਆਫਲਾਈਨ ਅਤੇ ਸਿੰਕਿੰਗ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਮੋਬਾਈਲ ਐਪਾਂ ਨਜ਼ੁਕ ਡੇਟਾ ਨਾਲ ਨਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਪਾਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਆਫਲਾਈਨ-ਫਰਸਟ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕਹੋ: “ਸਭ ਕੁਝ ਆਫਲਾਈਨ ਕੰਮ ਕਰੇ। ਜੇ ਯੂਜ਼ਰ ਬਾਅਦ ਵਿੱਚ ਸਾਇਨ ਕੀਤਾ ਤਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਸਿੰਕ ਹੋਵੇ ਅਤੇ ਕਾਨਫਲਿਕਟ ਨੂੰ ਸਭ ਤੋਂ ਨਵੀਂ ਤਬਦੀਲ ਰੱਖ ਕੇ ਹੱਲ ਕੀਤਾ ਜਾਵੇ।” ਜੇ ਤੁਹਾਨੂੰ ਮੌਸਮ ਦੀ ਸਿੰਕਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਤਾਂ ਇਹ ਵੀ ਦੱਸੋ — ਲੋਕਲ-ਓਨਲੀ ਪਹਿਲਾ ਰਿਲੀਜ਼ ਅਕਸਰ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਜੋਖਮ ਵਾਲਾ ਹੁੰਦਾ ਹੈ।

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

ਸੀਧੇ ਤੌਰ 'ਤੇ, ਇੱਕ ਪਲੇਟਫਾਰਮ ਦਿਸ਼ਾ ਚੁਣੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਧਾਓ। ਉਦਾਹਰਨ: “ਪਹਿਲਾਂ Android ਬਣਾਓ ਸਧਾਰਨ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨਾਲ. iOS ਬਾਅਦ ਵਿੱਚ ਆ ਸਕਦਾ ਹੈ।” ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ Flutter ਮੰਗਣਾ ਅਮਲੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕੋ ਕੋਡਬੇਸ ਰੱਖਦਾ ਹੋਇਆ ਵਿਚਾਰ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ।

ਇੱਕ ਕਾਰਗਰ ਪ੍ਰੋਂਪਟ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗਾ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ:

“Build a Flutter habit tracker app with 4 screens: Onboarding, Daily List, Add Habit, Stats. Offline first using local storage. No login for v1. Daily reminder notification at a user-chosen time. Keep the UI clean with a bottom nav. Generate sample data for testing.”

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

ਆਮ غلطੀਆਂ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ

Vibe coding ਤੋਂ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਮੁੱਲ ਪਾਉਣਾ ਇਸਨੂੰ ਛੋਟੀ, ਟੈਸਟਯੋਗ ਸ਼ਰਤਾਂ ਵਾਂਗ ਦੇਖਣ ਨਾਲ ਹੁੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਉਨ੍ਹਾਂ ਘੜੀਆਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸਿੱਧੇ "ਮੁਕੰਮਲ ਉਤਪਾਦ" ਦੀ ਮੰਗ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕੀਤੇ ਕਿ "ਚੱਲਣਯੋਗ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ।

ਉਹ ਗਲਤੀਆਂ ਜੋ ਤੁਹਾਨੂੰ ਧੀਰਾ ਕਰਦੀਆਂ ਹਨ

• "ਬਹੁਤ ਵੱਡੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ." ਇੱਕ ਛੋਟਾ ਪਹਿਲਾ ਵਰਜਨ ਮੰਗੋ ਜਿਸ ਵਿੱਚ ਕੇਵਲ ਕੋਰ ਫਲੋ ਹੋਵੇ। “Login + create an item + list items” ਇੱਕ "ਪੂਰੇ ਮਾਰਕੀਟਪਲੇਸ" ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਬੇਹਤਰ ਹੈ।
• "ਧੁੰਦਲੇ ਪ੍ਰੋਂਪਟ." “make it modern and user-friendly” ਦੀ ਬਜਾਏ ਨਿਯਮ ਅਤੇ ਉਦਾਹਰਨ ਦਿਓ: ਲਾਜ਼ਮੀ ਫੀਲਡ, ਬਟਨ ਲੇਬਲ, ਐਰਰ ਸੁਨੇਹੇ, ਅਤੇ ਕੁਝ ਨਮੂਨਾ ਰਿਕਾਰਡ।
• "ਏਜ ਕੇਸ ਛੱਡਣਾ." ਖਾਲੀ ਸਟੇਟਸ, ਗਲਤ ਇੰਪੁੱਟ, ਅਤੇ ਧੀਮਾ ਨੈੱਟਵਰਕ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਨਾ ਕਰੋ ਤਾਂ ਤੁਹਾਨੂੰ ਅਕਸਰ ਇਹ ਮਿਲਦਾ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਸਿਰਫ਼ ਮਨਪਸੰਦ ਹਾਲਤਾਂ ਵਿੱਚ ਹੀ ਅਚ്ਛਾ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
• "ਇਕ ਵਾਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਬਦਲਾਅ karna." ਇੱਕ ਅਧਿਆਯ ਵਿੱਚ UI, ਡੇਟਾਬੇਸ, ਅਤੇ ਬਿਜ਼ਨਸ ਲਾਜਿਕ ਸਾਰੇ ਬਦਲਣ ਨਾਲ ਡਿਬੱਗਿੰਗ ਅਨੁਮਾਨ ਬਣ ਜਾਂਦੀ ਹੈ।
• "ਮੁੱਢੀਆਂ ਗੱਲਾਂ ਦੇ ਬਿਨਾਂ ਸ਼ਿਪ ਕਰਨਾ." ਕਿਸੇ ਚੀਜ਼ ਨੂੰ “ਡਨ” ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ, ਰੋਲਬੈਕ ਰਸਤਾ, ਅਤੇ ਬੈਕਅਪ ਯੋਝਨਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

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

ਯੂਜ਼ਰਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਸੁਰੱਖਿਆ ਬਣਿਆਉ

ਚਾਹੇ ਤੁਸੀਂ Koder.ai ਜਾਂ ਹੋਰ ਕੋਈ ਟੂਲ ਵਰਤ ਰਹੇ ਹੋ, ਇਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਸ਼ੁਰੂ 'ਚ ਚੈੱਕ ਕਰੋ (ਅੰਤ 'ਤੇ ਨਹੀਂ):

• Auth ਅਤੇ permissions: ਕੌਣ ਵੇਖ ਸਕਦਾ/ਬਣਾ ਸਕਦਾ/ਸੋਧ ਸਕਦਾ/ਮਿਟਾ ਸਕਦਾ।
• Input validation: ਗਲਤ ਡੇਟਾ ਰੱਦ ਕਰਨਾ ਅਤੇ ਸਾਫ਼ ਸੁਨੇਹੇ ਦikhਾਉਣਾ।
• Secrets handling: API ਕੁੰਜੀਆਂ ਫਰੰਟਏਂਡ ਵਿੱਚ ਨਾ ਰੱਖੋ।
• Backups ਅਤੇ rollback: ਇਹ ਪਤਾ ਹੋਵੇ ਕਿ ਕੱਲ੍ਹ ਦੀ ਚੱਲਦੀ ਹੋਈ ਸਥਿਤੀ ਕਿਵੇਂ بحال ਕਰਨੀ ਹੈ।
• Logging: ਇੰਨੀ ਜਾਣਕਾਰੀ ਜੋ ਸਮਝਣ ਲਈ ਕਾਫ਼ੀ ਹੋਵੇ ਕਿ ਕੀ ਫੇਲ ਹੋਇਆ ਪਰ ਨਿੱਜੀ ਡੇਟਾ ਨਾ ਪ੍ਰਗਟ ਹੋਵੇ।

ਸਕੋਪ ਛੋਟਾ ਰੱਖੋ, ਪ੍ਰੋਂਪਟ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ, ਅਤੇ ਬਦਲਾਅ ਕਦਮ-ਕਦਮ ਕਰਕੇ ਕਰੋ। ਇੱਥੇ vibe coding ਮਜ਼ੇਦਾਰ ਅਤੇ ਉਪਜਾਊ ਰਹਿੰਦੀ ਹੈ ਨਾ ਕਿ ਗੁੰਝਲਦਾਰ।

ਇੱਕ ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ, ਫਿਰ ਤੁਹਾਡੇ ਅਗਲੇ ਕਦਮ

ਅੱਗੇ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ "ਕੀ ਇਹ ਅਸਲ ਹੈ?" ਜਾਂਚ ਕਰੋ। Vibe coding ਤੇਜ਼ ਹੈ, ਪਰ ਛੋਟੀਆਂ ਗਲਤੀਆਂ (ਟੁੱਟਾ ਬਟਨ, ਇੱਕ ਫੀਲਡ ਜੋ ਕਦੇ ਵੀ ਸੇਵ ਨਹੀਂ ਹੁੰਦੀ) ਆਖਰੀ ਪਲ ਤੱਕ ਛੁਪ ਸਕਦੀਆਂ ਹਨ।

ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ (10 ਮਿੰਟ)

ਮੁੱਖ ਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਪਹਿਲੀ ਵਾਰ ਵਰਤੋਂਕਾਰ ਵਾਂਗ ਕਲਿਕ ਕਰੋ ਅਤੇ ਐਪ ਦੀ ਮਦਦ ਨਾ ਕਰੋ।

• ਮੁੱਖ ਫਲੋ ਏਂਡ-ਟੂ-ਏਂਡ ਕੰਮ ਕਰਦਾ (ਸਾਇਨ ਅਪ/ਸਾਇਨ ਇਨ, ਆਈਟਮ ਬਣਾਓ, ਵੇਖੋ, ਸੋਧੋ, ਮਿਟਾਓ).
• ਡੇਟਾ ਵੈਲਿਡੇਟ ਅਤੇ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸੇਵ ਹੁੰਦਾ (ਲਾਜ਼ਮੀ ਫੀਲਡ, ਢਾਂਚੇ ਜਿਵੇਂ email/phone, ਨਕਲ ਹੈਂਡਲਿੰਗ).
• ਐਰਰ ਸਪਸ਼ਟ ਹਨ (ਸਧਾਰਨ ਸੁਨੇਹੇ, ਕੋਈ ਖ਼ਤਰਨਾਕ ਕੋਡ ਨਹੀਂ, ਅਤੇ ਐਪ ਫੇਲ ਹੋਣ 'ਤੇ ਮੁੜ ਸਹੀ ਹੋ ਜਾਂਦੀ ਹੈ).
• ਡਿਫੌਲਟਸ ਸਮਝਦਾਰ ਹਨ (ਖਾਲੀ ਸਟੇਟ, ਪਹਿਲੀ-ਚਲਾਉਣ ਸੈੱਟਅਪ, ਵਾਜਿਬ ਪੂਰ-ਭਰੇ ਮੁੱਲ).
• ਬੁਨਿਆਦੀ ਟੈਸਟ, ਜੇ ਸੰਭਵ ਹੋਵੇ (ਘੱਟੋ-ਘੱਟ ਇੱਕ ਹੈਪੀ-ਪਾਥ ਟੈਸਟ ਅਤੇ ਇੱਕ ਫੇਲਿਅਰ ਕੇਸ core ਫੀਚਰ ਲਈ).

ਫਿਰ ਰਿਲੀਜ਼ ਦੀ ਹਕੀਕਤ ਚੈੱਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸ਼ਿਪ ਕੀਤਾ ਅਤੇ ਕੁਝ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਵਾਪਸ ਜਾਣ ਦਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

• ਰੋਲਬੈਕ ਯੋਜਨਾ ਪਰਿਭਾਸ਼ਿਤ ਹੈ (ਤੁਹਾਡੇ ਐਪ ਲਈ “ਵਾਪਸ ਜਾਣ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਅਤੇ ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ)।
• ਮਹੱਤਵਪੂਰਨ ਡੇਟਾ ਲਈ ਬੈਕਅਪ ਹਨ (ਅਤੇ ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ ਬਹਾਲ ਕਰਨਾ ਹੈ)।
• ਹੋਸਟਿੰਗ ਫੈਸਲ ਕੀਤੀ ਗਈ ਹੈ (ਕਿੱਥੇ ਇਹ ਚلےਗਾ, ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਰੀਜਨ ਚਾਹੀਦਾ, ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਐਕਸੇਸ ਕਰ ਸਕਦਾ ਹੈ)।

ਤੁਹਾਡੇ ਅਗਲੇ ਕਦਮ

ਇੱਕ ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਚੁਣੋ ਜੋ ਛੋਟਾ ਪਰ ਪੂਰਾ ਹੋ। ਇੱਕ ਚੰਗੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਇਕ-ਉਦੇਸ਼ ਟੂਲ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਮੁੱਖ ਸਕ੍ਰੀਨ ਅਤੇ ਇੱਕ ਡੇਟਾਬੇਸ ਟੇਬਲ ਹੋਵੇ (ਉਦਾਹਰਨ: ਇੱਕ ਸਧਾਰਨ ਬੁਕਿੰਗ ਲਿਸਟ, ਇੱਕ ਹਲਕਾ CRM, ਜਾਂ ਇੱਕ habit tracker). ਇਸਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਪੂਰਾ ਲੂਪ ਖਤਮ ਕਰ ਸਕੋ।

ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ planning mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਜੋ ਬਿਲਡ ਕੋਡ ਜਨਰੇਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵੀ ਵਿਵਸਥਿਤ ਰਹੇ। ਇੱਕ ਛੋਟਾ ਸਲਾਇਸ ਬਣਾਓ, ਅਕਸਰ snapshots ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਦਲਾਅ ਤੁਲਨਾ ਕਰ ਸਕੋ ਅਤੇ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਰੋਲਬੈਕ ਕਰ ਸਕੋ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਨਿਯੰਤਰਣ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ।

ਇੱਕ ਵਾਕ ਵਿੱਚ ਆਪਣੀ “definition of done” ਲਿਖੋ (ਉਦਾਹਰਨ: “A user can add an item, see it in a list, and it stays after refresh”). ਉਹ ਇੱਕ ਵਾਕ vibe coding ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਬਿਲਡ ਨੂੰ ਲੰਬੀ ਸੋਚ-ਵਿੱਚਕਾਰੋਂ ਬਚਾਉਂਦਾ ਹੈ।