ਹਰ ਬਣਾਉਣ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ LLM: ਇੱਕ ਅਮਲੀ ਮਾਡਲ ਨਕਸ਼ਾ

ਇਕੋ LLM ਹਰ ਕੰਮ ਲਈ ਵਰਤਣ ਨਾਲ ਮੁਸ਼ਕਲਾਂ ਕਿਉਂ ਹੁੰਦੀਆਂ ਹਨ

ਇੱਕ ਹੀ ਮਾਡਲ ਨੂੰ ਹਰ ਕੰਮ ਲਈ ਵਰਤਣਾ ਆਸਾਨ ਲੱਗਦਾ ਹੈ। ਅਮਲ ਵਿੱਚ, ਇਹ ਜ਼ਿਆਦਾਤਰ ਵਾਰੀ ਬਣਾਉਣ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਘਟਾਉਂਦਾ, ਲਾਗਤ ਵਧਾਉਂਦਾ ਅਤੇ ਭਰੋਸਾ ਘਟਾਉਂਦਾ ਹੈ। ਜਿਹੜਾ ਮਾਡਲ ਡੀਪ ਰੀਜ਼ਨਿੰਗ ਵਿੱਚ ਸਫਲ ਹੋਵੇ ਉਹ ਛੋਟੀ UI ਕਾਪੀ ਲਈ ਬੇਹੱਦ ਧੀਮਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਅਤੇ ਜੋ ਮਾਡਲ ਤੇਜ਼ ਅਤੇ ਸਸਤਾ ਹੈ, ਉਹ SQL ਜਾਂ ਕੋਰ ਲੌਜਿਕ ਬਦਲਦੇ ਵੇਲੇ ਖ਼ਤਰनाक ਗਲਤੀਆਂ ਕਰ ਸਕਦਾ ਹੈ।

ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਮੁਦਦੇ ਕੁਝ ਆਮ ਲੱਛਣਾਂ ਰਾਹੀਂ ਨੋਟ ਕਰਦੀਆਂ ਹਨ:

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

ਮਕਸਦ ਸਭ ਤੋਂ ਬੜੇ ਮਾਡਲ ਦੇ ਪਿੱਛੇ ਭੱਜਣਾ ਨਹੀਂ ਹੈ। मकसद ਇਹ ਹੈ ਕਿ ਹਰ ਬਣਾਉਣ ਕੰਮ ਲਈ ਉਹੀ LLM ਚੁਣੀ ਜਾਵੇ ਜੋ ਤੁਹਾਨੂੰ ਹੁਣ ਲੋੜ ਹੈ: ਰਫ਼ਤਾਰ, ਸਹੀਪਣ, ਸਥਿਰਤਾ, ਜਾਂ ਧਿਆਨ-ਪੂਰਵਕ ਰੀਜ਼ਨਿੰਗ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਣ: ਕਲਪਨਾ ਕਰੋ ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ React ਡੈਸ਼ਬੋਰਡ ਬਣਾ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਇੱਕੋ ਹੀ ਉੱਚ-ਸਤਹ ਦੇ ਮਾਡਲ ਨੂੰ (1) ਬਟਨ ਲੇਬਲ ਲਿਖਣ ਲਈ, (2) React ਕੰਪੋਨੈਂਟ ਬਣਾਉਣ ਲਈ, (3) SQL ਮਾਈਗ੍ਰੇਸ਼ਨ ਤਿਆਰ ਕਰਨ ਲਈ, ਅਤੇ (4) ਇੱਕ ਜਟਿਲ ਬੱਗ ਫਿਕਸ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹੋ। ਤੁਸੀਂ ਲੇਬਲਾਂ ਲਈ ਪ੍ਰੀਮੀਅਮ ਕੀਮਤ ਦਿਓਗੇ, ਕੰਪੋਨੈਂਟ ਲਈ ਜ਼ਿਆਦਾ ਉਡੀਕ ਕਰੋਗੇ, ਅਤੇ ਫਿਰ ਵੀ SQL ਅਤੇ ਬੱਗ ਫਿਕਸ 'ਤੇ ਵਾਧੂ ਚੈਕਸ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।

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

ਤਿੰਨ ਤਰਫ਼ੇ ਵਾਲੇ ਟਰੇਡ-ਆਫ: ਕੁਆਲਟੀ, ਲੇਟੈਂਸੀ, ਅਤੇ ਲਾਗਤ

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

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

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

ਲਾਗਤ ਸਿਰਫ਼ ਪ੍ਰਤੀ-ਰਿਕਵੈਸਟ ਕੀਮਤ ਨਹੀਂ ਹੈ। ਛੁਪੀਆਂ ਹੋਈ ਲਾਗਤ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਤਦੋਂ ਦੇ ਰਹੇ ਹੋ ਜਦੋਂ ਪਹਿਲਾ ਜਵਾਬ ਗਲਤ ਜਾਂ ਅਸਪਸ਼ਟ ਹੋਵੇ:

• ਵਾਧੂ ਰੀਟ੍ਰਾਇਜ਼ ਅਤੇ ਲੰਬੀਆਂ ਚੈਟ
• ਡੀਬੱਗਿੰਗ ਸਮਾਂ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਫਿਕਸ
• ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਉਣ ਜਾਂ ਡਿਪਲੌਇਮੈਂਟ ਮੁੜ ਬਣਾਉਣ
• ਉਹ ਸੰਦਰਭ ਜੋ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਪੇਸਟ ਕਰਨਾ ਪੈਂਦਾ ਹੈ

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

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

ਦੈਨੰਦਿਨ ਕੰਮਾਂ ਵਿੱਚ ਮਾਡਲ ਸਮਰੱਥਾਵਾਂ ਦਾ ਅਸਲ ਮਤਲਬ

ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇੱਕ ਮਾਡਲ “X 'ਚ ਵਧੀਆ” ਹੈ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੈ ਕਿ ਉਹ ਉਸ ਕਿਸਮ ਦੇ ਕੰਮ 'ਤੇ ਸਮਾਂ ਬਚਾਉਂਦਾ ਅਤੇ ਘੱਟ ਰੀਟ੍ਰਾਇਜ਼ ਲੈਂਦਾ ਹੈ। ਅਮਲ ਵਿੱਚ, ਜ਼ਿਆਦਾਤਰ ਸਮਰੱਥਾਵਾਂ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ।

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

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

ਭਰੋਸੇਯੋਗਤਾ ਇੱਕ ਛੁਪਾ ਹੋਇਆ ਫਾਇਦਾ ਹੈ। ਕੁਝ ਮਾਡਲ ਹਦਾਇਤਾਂ (ਫਾਰਮੈਟ, ਸਟਾਈਲ, ਪਾਬੰਦੀਆਂ) ਨੂੰ ਜ਼ਿਆਦਾ ਲਗਾਤਾਰ ਫਾਲੋ ਕਰਦੇ ਹਨ। ਇਹ ਬੋਰੀਂਗ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਦੁਬਾਰਾ-ਕੰਮ ਘਟਾਉਂਦਾ ਹੈ: ਘੱਟ "ਕਿਰਪਾ ਕਰਕੇ ਇਹ TypeScript ਵਿੱਚ ਦੁਬਾਰਾ ਕਰੋ" ਜਾਂ ਘੱਟ ਗੁਆਚੀਆਂ ਫਾਇਲਾਂ, ਘੱਟ SQL ਅਚਰਜ।

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

ਉਦਾਹਰਨ ਲਈ, ਬਟਨ ਮਾਈਕ੍ਰੋਕਾਪੀ ਕੁਝ ਇੱਟਰੇਸ਼ਨਾਂ ਸਹਿਣ ਕਰ ਸਕਦੀ ਹੈ। ਪਰ ਭੁਗਤਾਨ ਫਲੋ, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਜਾਂ auth ਚੈੱਕ ਬਦਲਣ ਵੇਲੇ ਤੁਸੀਂ ਉਹ ਮਾਡਲ ਚਾਹੋਗੇ ਜੋ ਸਾਵਧਾਨ ਅਤੇ ਲਗਾਤਾਰ ਹੋਵੇ, ਭਾਵੇਂ ਉਹ ਪ੍ਰਤੀ-ਰਨ ਮਹਿੰਗਾ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ ਵਰਗੇ Koder.ai ਨੂੰ ਵਰਤਦੇ ਹੋ ਜੋ ਕਈ ਮਾਡਲ ਪਰਿਵਾਰਾਂ ਨੂੰ ਸਹਿਯੋਗ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਇਹ ਥਾਂ ਮਾਡਲ ਬਦਲਣ ਜਲਦੀ ਫਾਇਦੇਮੰਦ ਹੋ ਜਾਦੀ ਹੈ।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਟਾਸਕ ਮੈਪ (ਕਦੋਂ ਕੀ ਵਰਤਣਾ)

ਜੇ ਤੁਸੀਂ ਹਰ ਬਣਾਉਣ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ LLM ਚੁਹਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਮਾਡਲ ਦੇ ਨਾਂ ਸੋਚਣਾ ਛੱਡੋ ਅਤੇ "ਟੀਅਰ": fast-cheap, balanced, ਅਤੇ reasoning-first ਵਿੱਚ ਸੋਚੋ। ਤੁਸੀਂ ਇੱਕੋ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵੀ ਟੀਅਰ ਮਿਲਾ ਸਕਦੇ ਹੋ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕੋ ਫੀਚਰ ਅੰਦਰ ਵੀ।

ਇੱਥੇ ਇੱਕ ਸਧਾਰਣ ਮੈਪ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਬੈਕਲੋਗ ਦੇ ਨੇੜੇ ਰੱਖ ਸਕਦੇ ਹੋ:

ਇੱਕ ਉਪਯੋਗ ਨਿਯਮ: ਜਿੱਥੇ ਗਲਤੀਆਂ ਆਸਾਨੀ ਨਾਲ ਦੇਖੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਉਥੇ "ਸਸਤਾ" ਚਲਾਓ, ਅਤੇ ਜਿੱਥੇ ਗਲਤੀਆਂ ਮਹਿੰਗੀਆਂ ਹਨ ਉਥੇ "ਮਜ਼ਬੂਤ" ਚੁਣੋ।

ਤੇਜ਼ ਮਾਡਲਾਂ 'ਤੇ ਸੁਰੱਖਿਅਤ: ਕਾਪੀ ਸੰਪਾਦਨ, ਛੋਟੇ UI ਟਵੀਕਸ, ਨਾਮ ਬਦਲਣਾ, ਸਧਾਰਨ ਹੇਲਪਰ ਫੰਕਸ਼ਨ, ਅਤੇ ਫਾਰਮੈਟਿੰਗ। ਲੀਕ ਮਾਡਲਾਂ 'ਤੇ ਖ਼ਤਰਨਾਕ: ਉਹ ਕੁਝ ਜੋ ਡੇਟਾ ਨੂੰ ਛੂਹਦੇ ਹਨ (SQL), auth, payments, ਜਾਂ ਕ੍ਰਾਸ-ਫਾਇਲ ਰੀਫੈਕਟਸ।

ਇੱਕ ਹਕੀਕਤੀ ਫਲੋ: ਤੁਸੀਂ ਨਵੇਂ Settings ਪੇਜ ਲਈ ਕਹਿੰਦੇ ਹੋ। Balanced ਮਾਡਲ ਦਾ ਉਪਯੋਗ ਕਰਕੇ React ਕੰਪੋਨੈਂਟ ਦਾ ਡਰਾਫਟ ਬਣਾਓ। state ਹੈਂਡਲਿੰਗ ਅਤੇ ਏਜ ਕੇਸਾਂ ਦੀ ਸਮੀਖਿਆ ਲਈ reasoning-first ਮਾਡਲ 'ਤੇ ਸਵਿੱਚ ਕਰੋ। ਫਿਰ UI ਟੈਕਸਟ ਨੂੰ ਤਿੱਖਾ ਕਰਨ ਲਈ ਤੇਜ਼ ਮਾਡਲ ਵਰਤੋ। Koder.ai ਵਿੱਚ, ਟੀਮਾਂ ਅਕਸਰ ਇਹ ਇੱਕ ਹੀ ਚੈਟ ਵਿੱਚ ਕਰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਕਦਮ ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ ਨੂੰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਕਿ ਜਿੱਥੇ ਲੋੜ ਨਹੀਂ ਉੱਠਦੀ ਉੱਥੇ ਕ੍ਰੈਡਿਟ ਨਾ ਬਰਬਾਦ ਹੋਣ।

ਤੇਜ਼ ਮਿਲਾਉਣ ਵਾਲੇ ਨਿਯਮ

• Draft ਤੇਜ਼, verify ਧੀਮੇ।
• ਜਿਸ ਵੀ ਚੀਜ਼ ਨੂੰ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ "ਆਈ-ਆਏ-ਬੱਸ" ਨਹੀਂ ਕਰ ਸਕਦੇ, reasoning-first ਵਰਤੋ।
• ਇੱਕ ਰੀਫੈਕਟਰ ਪਾਸ ਲਈ ਇੱਕੋ ਮਾਡਲ ਰੱਖੋ ਤਾਂ ਕਿ ਸਟਾਈਲ ਡ੍ਰਿਫਟ ਨਾ ਹੋਵੇ।
• ਫਿਕਸਾਂ ਦੇ ਬਾਅਦ, ਛੁਪੇ ਸਾਈਡ-ਏਫੈਕਟਾਂ ਲਈ ਦੂਜੇ ਮਾਡਲ ਨੂੰ ਸਮੀਖਿਆ ਲਈ ਕਹੋ।

UI ਕਾਪੀ ਅਤੇ ਪ੍ਰੋਡਕਟ ਟੈਕਸਟ: ਪਹਿਲਾਂ ਰਫ਼ਤਾਰ, ਫਿਰ ਤੇਜ਼ QA

UI ਕਾਪੀ ਲਈ ਮਕਸਦ ਆਮ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਹੋਣਾ ਹੁੰਦਾ ਹੈ, ਬਹੁਤਰੇ ਅਦਭੁਤਤਾ ਨਹੀਂ। ਬਟਨ ਲੇਬਲ, empty states, ਹੇਲਪਰ ਟੈਕਸਟ, ਐਰਰ ਸੁਨੇਹੇ ਅਤੇ ਛੋਟੇ onboarding ਕਦਮਾਂ ਲਈ ਤੇਜ਼, ਘੱਟ-ਲਾਗਤ ਮਾਡਲ ਇੱਕ ਚੰਗਾ ਡਿਫੌਲਟ ਹਨ। ਤੁਹਾਨੂੰ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਮਿਲਦੀ ਹੈ, ਜੋ ਪਰਫੈਕਟ ਫ੍ਰੇਜ਼ਿੰਗ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਕ ਹੁੰਦੀ ਹੈ।

ਜਦੋਂ ਦਾਅਵੇ ਵੱਧ ਹੋਣ ਜਾਂ ਪਾਬੰਦੀਆਂ ਕੱਸਤ ਕਰਨ ਵਾਲੀਆਂ ਹੋਣ, ਤਦ ਮਜ਼ਬੂਤ ਮਾਡਲ ਵਰਤੋ। ਜਿਸ ਵਿੱਚ ਟੋਨ ਹਮਾਹੰਗੀ across screens, ਬਰਾਬਰ ਮੀਨਿੰਗ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਵਾਲੀਆਂ ਰੀ-ਰਾਈਟਸ, ਸੰਵੇਦਨਸ਼ੀਲ ਟੈਕਸਟ (ਬਿਲਿੰਗ, ਪ੍ਰਾਈਵੇਸੀ, ਸੁਰੱਖਿਆ), ਜਾਂ ਕੋਈ ਵੀ ਗੱਲ ਜੋ ਵਾਅਦਾ ਵਾਂਗ ਪੜ੍ਹੀ ਜਾ ਸਕਦੀ ਹੋਵੇ ਸ਼ਾਮਿਲ ਹੈ।

ਉਹਨਾਂ ਪ੍ਰਾਂਪਟ ਨੁਕਸਾਂ ਦੇ ਟਿੱਪਸ ਜੋ ਮਾਡਲ ਬਦਲਣ ਨਾਲੋਂ ਵੱਧ ਸੁਧਾਰ ਲਿਆਉਂਦੇ ਹਨ:

• 3-5 ਉਦਾਹਰਨ ਪੇਸਟ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਬ੍ਰਾਂਡ ਦੀ ਆਵਾਜ਼ ਦਿਖਾਉਂਦੀਆਂ ਹੋਣ (ਛੋਟਾ ਠੀਕ ਹੈ)।
• ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੇ ਜਿਹੜੇ ਵਾਕਾਂਸ਼ ਕਦੇ ਨਹੀਂ ਵਰਤਣੇ, ਉਹ ਲਿਸਟ ਕਰੋ।
• ਪੜ੍ਹਨ ਦੀ ਪੱਧਰ ਅਤੇ ਲੰਬਾਈ ਦੀ ਹੱਦ ਦਸੋ (ਉਦਾਹਰਨ ਲਈ, 60 ਅੱਖਰ ਤੋਂ ਘੱਟ)।
• ਸਹੀ UI ਸੰਦਰਭ ਦਿਓ (ਸਕ੍ਰੀਨ, ਯੂਜ਼ਰ ਦਾ ਮਕਸਦ, ਅੱਗੇ ਕੀ ਹੁੰਦਾ ਹੈ)।

ਤੇਜ਼ QA ਇੱਕ ਮਿੰਟ ਲੈਂਦੀ ਹੈ ਅਤੇ ਹਫ਼ਤਿਆਂ ਦੀ ਛੋਟੀ ਉਲਝਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕ ਕਰੋ:

• ਅਸਪਸ਼ਟਤਾ: ਕੀ ਵਰਤੋਂਕਾਰ ਇਸ ਨੂੰ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਪੜ੍ਹ ਸਕਦਾ ਹੈ?
• ਦਾਵੇ: ਕੀ ਇਹ ਐਸੇ ਨਤੀਜੇ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਨਾਹ ਕਰ ਸਕਦੇ?
• ਟਰਮੀਨੋਲੋਜੀ: ਕੀ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਇਕੋ ਸ਼ਬਦ ਵਰਤ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ: “snapshot” vs “backup”)?
• ਟੋਨ: ਐਰਰ 'ਚ ਸ਼ਾਂਤ ਅਤੇ ਬਟਨ 'ਚ ਸਿੱਧਾ ਹੈ?
• ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ: ਜਦੋਂ ਅਨੁਵਾਦ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਕੀ ਅਰਥ ਸਹੀ ਰਹੇਗਾ?

ਉਦਾਹਰਨ: Koder.ai ਵਿੱਚ, ਇੱਕ ਤੇਜ਼ ਮਾਡਲ “Deploy” ਬਟਨ ਟੂਲਟਿਪ ਦਾ ਡਰਾਫਟ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਮਜ਼ਬੂਤ ਮਾਡਲ ਮੁਫ਼ਤ, Pro, Business, ਅਤੇ Enterprise ਵਿੱਚ ਕਾਪੀ ਨੂੰ ਇਕਸਾਰ ਬਣਾਓ ਬਗੈਰ ਨਵੇਂ ਵਾਅਦੇ ਜੋੜੇ।

React ਕੰਪੋਨੈਂਟ: ਰਚਨਾਤਮਕਤਾ ਉੱਤੇ ਨਿਰਭਰਤਾ ਦੇ ਨਾਲ ਸਹੀਪਣ ਚੁਣੋ

React ਕੰਪੋਨੈਂਟਾਂ ਲਈ, ਸਭ ਤੋਂ ਤੇਜ਼ ਮਾਡਲ ਅਕਸਰ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ "ਕਾਫ਼ੀ" ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਰਫੇਸ ਏਰੀਆ ਛੋਟਾ ਹੋਵੇ। ਸੋਚੋ: ਇੱਕ ਬਟਨ ਵੈਰੀਅੰਟ, ਇੱਕ ਸਪੇਸਿੰਗ ਫਿਕਸ, ਦੋ ਫੀਲਡਾਂ ਵਾਲਾ ਸਧਾਰਨ ਫਾਰਮ, ਜਾਂ flex ਤੋਂ grid ਵਿੱਚ ਲੇਆਉਟ swap। ਜੇ ਤੁਸੀਂ ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਮਿੰਟ ਦੇ ਅੰਦਰ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਰਫ਼ਤਾਰ ਜਿੱਤਦੀ ਹੈ।

ਜਿਵੇਂ ਹੀ state, ਸਾਈਡ-ਏਫੈਕਟਸ, ਜਾਂ ਰੀਅਲ ਯੂਜ਼ਰ ਇੰਟਰੈਕਸ਼ਨ ਆਉਂਦਾ ਹੈ, ਇੱਕ ਮਜ਼ਬੂਤ ਕੋਡਿੰਗ ਮਾਡਲ ਚੁਣੋ ਭਾਵੇਂ ਇਹ ਮਹਿੰਗਾ ਹੋਵੇ। ਵਾਧੂ ਸਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਫਲੇਕੀ ਕੰਪੋਨੈਂਟ ਦੀ ਡੀਬੱਗਿੰਗ ਨਾਲੋਂ ਸਸਤਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ state management, ਜਟਿਲ ਇੰਟਰੈਕਸ਼ਨ (drag and drop, debounced search, multi-step flows), ਅਤੇ accessibility ਲਈ ਮਹੱਤਵਪੂਰਕ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਨਿਰਭਰ ਪਰ ਗਲਤ ਜਵਾਬ ਘੰਟਿਆਂ ਦਾ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ।

ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲ ਨੂੰ ਪਾਬੰਦੀਆਂ ਦਿਓ। ਇੱਕ ਛੋٹی spec "ਰਚਨਾਤਮਕ" ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਰੋਕਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।

• TypeScript ਅਤੇ ਆਪਣੀ ਟਾਰਗਟ React ਵਰਜਨ ਵਰਤਣ ਦੱਸੋ
• ਕੰਪੋਨੈਂਟ API (props, events, default values) ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
• UI ਸਟੇਟਸ ਲਿਸਟ ਕਰੋ (loading, empty, error, disabled)
• accessibility ਲੋੜਾਂ ਦੱਸੋ (keyboard, ARIA, focus order)
• ਏਜ ਕੇਸ ਸੂਚੀ ਦਿਓ (ਲੰਮਾ ਟੈਕਸਟ, ਸਲੋ ਨੈਟਵਰਕ, ਡਬਲ ਕਲਿਕ)

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਉਦਾਹਰਨ: “UserInviteModal” ਬਣਾਉਣਾ। ਇੱਕ ਤੇਜ਼ ਮਾਡਲ ਮੋਡਲ ਲੇਆਉਟ ਅਤੇ CSS ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ। ਫਾਰਮ ਵੈਧਤਾ, async invite ਅਨੁਰੋਧ, ਅਤੇ ਡੁਪਲੀਕੇਟ ਸਬਮਿਟਜ਼ ਰੋਕਣ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ।

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

• ਸਿਰਫ਼ ਕੰਪੋਨੈਂਟ ਕੋਡ (ਕੋਈ ਅਜਿਹੇ ਪਲੇਸਹੋਲਡਰ ਨਹੀਂ ਜੋ ਕੰਪਾਇਲ ਨਹੀਂ ਹੁੰਦੇ)
• ਔਖੇ ਹਿੱਸਿਆਂ ਦੀ ਛੋਟੀ ਵਿਆਖਿਆ (state, effects, memoization)
• ਇੱਕ ਛੋਟੀ ਟੈਸਟ ਯੋਜਨਾ (ਕੀ ਕਲਿਕ ਕਰਨਾ ਹੈ ਅਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ)
• accessibility ਚੈੱਕਾਂ 'ਤੇ ਨੋਟਸ (tab order, focus trap, labels)

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਮਾਡਲ ਤੋਂ ਕੰਪੋਨੈਂਟ ਬਣਵਾਉਣ ਤੋਂ ਬਾਅਦ ਇੱਕ snapshot ਲਓ ਪਹਿਲਾਂ ਹੀ integrate ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ। ਇਸ ਤਰ੍ਹਾਂ, ਜੇ "correctness" ਮਾਡਲ ਕਿਸੇ ਸੁੰਦਰ ਰਿਗ੍ਰੈਸ਼ਨ ਨੂੰ ਲਿਆਇਆ, ਤਾਂ rollback ਇਕ ਕਦਮ ਹੋਵੇਗਾ ਨਾ ਕਿ ਇੱਕ ਵੱਡਾ ਸਫਾਈ ਪ੍ਰੋਜੈਕਟ। ਇਹ ਤਰੀਕਾ ਹਰ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ LLM ਮਨਸੂਬੇ ਦੇ ਅਨੁਸਾਰ ਹੈ: ਜਿੱਥੇ ਗਲਤੀਆਂ ਮਹਿੰਗੀਆਂ ਹਨ, ਓਥੇ ਡੈਪਥ ਲਈ ਭੁਗਤਾਨ ਕਰੋ।

SQL ਟਾਸਕ: ਸਹੀਪਣ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਪਹਿਲ ਦਿਓ

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

ਜਦੋਂ ਕਵੇਰੀ ਵਿੱਚ ਜਟਿਲ joins, window functions, CTE ਚੇਨਾਂ, ਜਾਂ ਕੋਈ ਵੀ ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਚੀਜ਼ ਹੋਵੇ ਤਾਂ ਇੱਕ ਮਜ਼ਬੂਤ ਮਾਡਲ ਵਰਤੋ। ਸਕੀਮਾ ਬਦਲਣ (migrations) ਵੀ ਓਸੇ ਤਰ੍ਹਾਂ ਹਨ, ਜਿੱਥੇ ਅਨੁਕ੍ਰਮ ਅਤੇ constraints ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਸਸਤਾ ਤੇਜ਼ ਮਾਡਲ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ SELECTs, ਬੇਸਿਕ ਫਿਲਟਰਿੰਗ, ਅਤੇ CRUD ਸਕੈਫੋਲਡ ਲਈ ਠੀਕ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਨਤੀਜੇ ਨੂੰ ਜਲਦੀ ਨਿਰੀਖਣ ਕਰ ਸਕਦੇ ਹੋ।

ਗਲਤ SQL ਨੂੰ ਰੋਕਣ ਲਈ ਪ੍ਰਾਂਪਟਿੰਗ

ਸਹੀ SQL ਪਾਉਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਅਨੁਮਾਨ ਹਟਾਉਣਾ ਹੈ। ਸਕੀਮਾ (ਟੇਬਲ, ਕੀਜ਼, ਟਾਈਪ), ਜੋ ਆਉਟਪੁੱਟ ਸ਼ੇਪ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ (ਕਾਲਮ ਅਤੇ ਮਤਲਬ), ਅਤੇ ਕੁਝ ਸੈਂਪਲ ਰੋਜ਼ ਸ਼ਾਮਿਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ PostgreSQL ਐਪ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ (Koder.ai ਪ੍ਰਾਜੈਕਟਾਂ ਵਿੱਚ ਆਮ), ਤਾਂ ਇਹ ਦੱਸੋ ਕਿਉਂਕਿ ਸਿੰਟੈਕਸ ਅਤੇ ਫੰਕਸ਼ਨ ਡੇਟਾਬੇਸ-ਵਾਈਜ਼ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਣ ਪ੍ਰਾਂपਟ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:

“PostgreSQL. Tables: orders(id, user_id, total_cents, created_at), users(id, email). Return: email, total_spend_cents, last_order_at for users with at least 3 orders in the last 90 days. Sort by total_spend_cents desc. Include indexes if needed.”

ਕੂੜੇ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਸੁਰੱਖਿਆ ਚੈਕ ਸ਼ਾਮਿਲ ਕਰੋ:

• ਕਿਸੇ ਵੀ UPDATE/DELETE ਤੋਂ ਪਹਿਲਾਂ SELECT ਪ੍ਰੀਵਿਊ ਮੰਗੋ।
• Writes ਲਈ WHERE ਕਲਾਜ਼ ਦੀ ਮੰਗ ਕਰੋ (ਜਾਂ ਖੁੱਲ੍ਹ ਕੇ ਫੁੱਲ-ਟੇਬਲ ਚੇਂਜ ਨੂੰ ਅਨੁਮਤ ਕਰੋ)।
• ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਲਈ Transaction ਅਤੇ rollback ਯੋਜਨਾ ਮੰਗੋ।
• Edge cases ਮੰਗੋ (NULLs, duplicates, time zones)।
• ਮਾਡਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਜੋਇਨ ਕੀਜ਼ ਠੀਕ ਕਿਉਂ ਹਨ, ਇਹ ਸਮਝਾਓ।

ਇਹ ਤਰੀਕਾ ਤੇਜ਼ ਜਵਾਬਾਂ ਦੀ ਪਿਛੇ ਭੱਜਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਅਤੇ ਕਰੈਡਿਟ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਨੂੰ ਵਾਪਸ ਕਰਦੇ ਹੋ।

ਰੀਫੈਕਟਰਸ: ਧਿਆਨ-ਪੂਰਵਕ ਅਤੇ ਲਗਾਤਾਰ ਮਾਡਲ ਚੁਣੋ

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

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

ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਲਈ ਪ੍ਰਾਂਪਟਿੰਗ

ਜੋ ਕੋਈ ਬਦਲਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਉਸ ਬਾਰੇ ਬਹੁਤ ਸਪਸ਼ਟ ਹੋਵੋ। ਮਾਡਲ ਦੱਸ-ਫਿਰ ਬੜ੍ਹੇ ਸੰਦੇਹ 'ਤੇ ਹੀ ਅਨੁਮਾਨ ਲੱਗੇਗਾ।

• ਕਠੋਰ ਪਾਬੰਦੀਆਂ ਲਿਸਟ ਕਰੋ: public APIs, props shape, routes, DB schema, outputs, ਅਤੇ error messages
• "ਉਹੀ ਵਿਹਾਰ" ਦਾ ਮਤਲਬ ਦੱਸੋ: ਇੱਕੋ ਟੈਸਟਾਂ ਦਾ ਪਾਸ ਹੋਣਾ, ਇੱਕੋ UI ਸਟੇਟਸ, ਇੱਕੋ ਕਵੇਰੀ ਨਤੀਜੇ
• ਇੱਕ ਨਿਊਨਤਮ ਡਿਫ਼ ਮੰਗੋ: “ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਹੀ rename” ਅਤੇ “ਕੇਵਲ ਫਾਰਮੇਟਿੰਗ-ਸਬੰਧੀ ਬਦਲਾਅ ਨਾ”
• ਇੱਕ ਛੋਟੀ self-check ਮੰਗੋ: “ਕੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਵੀ ਵਿਹਾਰ ਬਦਲਣ ਦੇ ਖਤਰੇ ਨੂੰ ਕਾਲ ਆਊਟ ਕਰੋ”

ਪਹਿਲਾਂ ਯੋਜਨਾ ਮੰਗੋ (ਫਿਰ ਕੋਡ)

ਇੱਕ ਛੋਟੀ ਯੋਜਨਾ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਖਤਰੇ ਦਿਖਾਉਂਦੀ ਹੈ। ਮੰਗੋ: ਕਦਮ, ਖਤਰੇ, ਕਿਹੜੀਆਂ ਫਾਇਲਾਂ ਬਦਲਣਗੀਆਂ, ਅਤੇ ਰੋਲਬੈਕ ਤਰੀਕਾ।

ਉਦਾਹਰਨ: ਤੁਸੀਂ React ਫਾਰਮ ਨੂੰ mixed state logic ਤੋਂ single reducer ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰਵਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਇੱਕ ਧਿਆਨ-ਪੂਰਵਕ ਮਾਡਲ ਕਦਮ-ਦਰ-ਕਦਮ ਮਾਈਗਰੇਸ਼ਨ ਦੀੁ ਸੁਝਾਅ ਦੇਵੇਗਾ, validation ਅਤੇ disabled states ਦੇ ਖਤਰੇ ਨੋਟ ਕਰੇਗਾ, ਅਤੇ ਸੁਝਾਅ ਦੇਵੇਗਾ ਕਿ tests ਚਲਾਉਣ (ਜਾਂ 2-3 ਛੋਟੇ ਟੈਸਟ ਜੋੜਨ) ਤੋਂ ਬਾਅਦ ਆਖ਼ਰੀ ਪਾਸ ਕਰੋ।

ਜੇ ਤੁਸੀਂ ਇਹ Koder.ai ਵਿੱਚ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਰੀਫੈਕਟਰ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ snapshot ਲਓ ਅਤੇ ਟੈਸਟਾਂ ਪਾਸ ਹੋਣ 'ਤੇ ਇਕ ਹੋਰ ਲਓ, ਤਾਂ ਜੋ ਜੇ ਕੁਝ ਠੀਕ ਨਾ ਲੱਗੇ ਤਾਂ rollback ਇਕ ਕਲਿਕ 'ਚ ਹੋ ਜਾਵੇ।

ਬੱਗ ਫਿਕਸ: ਰਫ਼ਤਾਰ ਨਾਲੋਂ ਰੀਜ਼ਨਿੰਗ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ ਬੱਗ ਫਿਕਸ ਕਰ ਰਹੇ ਹੋ, ਸਭ ਤੋਂ ਤੇਜ਼ ਮਾਡਲ ਅਕਸਰ مکمل ਰਸਤੇ ਤੱਕ ਤੇਜ਼ੀ ਨਹੀਂ ਲਿਜਾਂਦਾ। ਬੱਗ ਫਿਕਸ ਇਹੋ ਜ਼ਿਆਦатар ਪੜ੍ਹਨ-ਸਮੀਖਿਆ ਹੈ: ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ ਕੋਡ ਨੂੰ ਸਮਝਣਾ, ਉਸਨੂੰ ਐਰਰ ਨਾਲ ਜੋੜਨਾ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਤਬਦੀਲੀ ਕਰਨੀ ਹੁੰਦੀ ਹੈ।

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

ਇਕ ਉਪਯੋਗ ਜਵਾਬ ਲੈਣ ਲਈ ਮਾਡਲ ਨੂੰ ਸਹੀ ਇਨਪੁੱਟ ਦਿਓ। "ਇਹ crash ਕਰਦਾ ਹੈ" ਵਰਗਾ vague ਪ੍ਰਾਂਪਟ ਆਮ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨ ਬਣਾਉਂਦਾ ਹੈ।

• ਸਹੀ error text ਅਤੇ stack trace (ਪੂਰਾ, paraphrase ਨਾ ਕਰੋ)
• reproduce ਕਰਨ ਦੇ ਕਦਮ (click-by-click ਜਾਂ API ਕਾਲਜ਼)
• ਉਮੀਦ ਕੀਤੀ ਵਿਰੁੱਧ ਅਸਲ ਵਿਵਹਾਰ
• ਸਬੰਧਤ ਕੋਡ ਫਾਇਲਾਂ ਜਾਂ ਫੰਕਸ਼ਨ (ਅਤੇ config/env ਵੇਰਵੇ)
• ਤੁਸੀਂ ਪਹਿਲਾਂ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ (ਤਾਕਿ ਉਹ ਦੁਹਰਾਇਆ ਨਾ ਜਾਵੇ)

ਮਾਡਲ ਨੂੰ ਪਹਿਲਾਂ ਆਪਣੀ diagnosis ਸਮਝਾਉਣ ਲਈ ਕਹੋ ਫਿਰ ਕੋਡ ਸੋਧੇ। ਜੇ ਉਹ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਫੇਲ ਹੋਣ ਵਾਲੀ ਲਾਈਨ ਜਾਂ ਸ਼ਰਤ ਨੂੰ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਉਹ ਪੈਚ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ।

ਫਿਕਸ ਸੁਝਾਉਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਛੋਟੀ verification checklist ਮੰਗੋ। ਉਦਾਹਰਨ ਲਈ, ਜੇ React ਫਾਰਮ refactor ਤੋਂ ਬਾਅਦ ਦੋ ਵਾਰੀ submit ਕਰਦਾ ਸੀ, ਤਾਂ ਚੈਕਲਿਸਟ 'ਚ UI ਅਤੇ API ਦੋਹਾਂ ਸ਼ਾਮਿਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

• ਉਹੀ reproduce steps ਵਰਤਕੇ ਬੱਗ ਗੁਆਚ ਗਿਆ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ
• ਨੇੜਲੇ unit ਜਾਂ integration ਟੈਸਟ ਚਲਾਓ (ਜਾਂ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਜੋੜੋ)
• ਉਹਨਾਂ ਫਲੋਜ਼ ਨੂੰ ਚੈੱਕ ਕਰੋ ਜੋ ਉਹੀ ਕੋਡ ਪਾਥ ਸਾਂਝੇ ਕਰਦੇ ਹਨ
• ਲਾਗਜ਼ ਵਿੱਚ ਨਵੇਂ warning ਜਾਂ error ਚੈੱਕ ਕਰੋ
• ਇਕ ਏਜ-ਕੇਸ ਜੋ ਪਹਿਲਾਂ ਖਤਰਨਾਕ ਸੀ, ਟਰਾਈ ਕਰੋ

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ ਬਦਲਾਅ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ snapshot ਲਓ, ਫਿਰ verify ਕਰੋ ਅਤੇ ਜੇ ਫਿਕਸ ਕਿਸੇ ਨਵੇਂ ਮੁੱਦੇ ਦਾ ਕਾਰਨ ਬਣੇ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ rollback ਕਰੋ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ ਵਿਸ਼ੇਸ਼ ਟਾਸਕ ਲਈ ਕਿਵੇਂ ਮਾਡਲ ਚੁਣੀਏ

ਸਾਦਾ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕੰਮ ਦਾ ਲੇਬਲ ਲਗਾ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। “Write onboarding copy” ਵੱਖਰਾ ਹੈ “fix a flaky test” ਜਾਂ “refactor a React form” ਤੋਂ। ਲੇਬਲ ਮਹੱਤਵਪੂਰਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਆਉਟਪੁੱਟ ਕਿੰਨੀ ਸਖਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

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

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

• ਟਾਸਕ ਨੂੰ ਰਿਸ਼ਕ ਅਨੁਸਾਰ ਵਰਗੀਕਰਣ ਕਰੋ: ਨੀਵਾਂ ਰਿਸ਼ਕ (ਕਾਪੀ, ਲੇਬਲ), ਦਰਮਿਆਨਾ (ਨਵਾਂ UI ਕੰਪੋਨੈਂਟ), ਉੱਚ (SQL changes, auth, payments), ਜਾਂ “ਅਣਜਾਣ” (ਬੱਗਸ).
• ਅੱਜ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਰਹੇ ਹੋ ਫੈਸਲਾ ਕਰੋ: ਰਫ਼ਤਾਰ, ਲਾਗਤ, ਜਾਂ ਘੱਟ-ਬੈਕ-ਅਫ-ਫ਼ੌਰਥ ਲਈ correctness.
• ਪਹਿਲਾ ਯਤਨ budget ਮਾਡਲ ਨਾਲ ਚਲਾਓ, ਪਰ escalate ਕਰੋ ਜੇ ਤੁਸੀਂ ਵੇਖੋ: ਮਿਸਿੰਗ ਏਜ-ਕੇਸ, ਥਿਰ-ਥਿਰ ਅਨੁਮਾਨ, inconsistent formatting, ਜਾਂ ਦੁਹਰਾਈਆਂ ਛੋਟੀ ਗਲਤੀਆਂ.
• ਹਰ ਟਾਸਕ ਪ੍ਰਕਾਰ ਲਈ ਇੱਕ ਮਿਆਰੀ ਪ੍ਰਾਂਪਟ ਅਤੇ ਇੱਕ ਛੋਟੀ acceptance check ਰੱਖੋ (ਚੀਜ਼ਾਂ ਜੋ ਸਹੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਮਿਲਣੀਆਂ ਚਾਹੀਦੀਆਂ).
• ਜਿੱਤਣ ਵਾਲਾ ਨੋਟ ਕਰੋ: ਵਰਤੇ ਮਾਡਲ, ਪ੍ਰਾਂਪਟ, ਅਤੇ ਪਹਿਲਾਂ ਕੀ ਫੇਲ ਹੋਇਆ ਸੀ ਉਸਦਾ ਕਾਰਨ।

ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਨਵਾਂ “Profile Settings” React ਕੰਪੋਨੈਂਟ cheaper ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਇਹ controlled inputs ਭੁੱਲ ਜਾਂਦਾ ਹੈ, TypeScript types ਨੂੰ ਤੋੜਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ design system ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਗਲੇ ਪਾਸ ਲਈ ਇੱਕ stronger “code correctness” ਮਾਡਲ ਤੇ ਸਵਿੱਚ ਕਰੋ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਮਾਡਲ ਚੋਣ ਨੂੰ ਆਪਣੇ workflow 'ਚ routing rule ਵਾਂਗ ਵਰਤੋ: ਪਹਿਲਾ ਡਰਾਫਟ ਤੇਜ਼ੀ ਨਾਲ ਕਰੋ, ਫਿਰ Planning Mode ਅਤੇ ਇੱਕ ਸਖ਼ਤ acceptance check ਵਰਤ ਕੇ ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ 'ਤੇ ਜਾਓ ਜੋ ਪ੍ਰੋਡ 'ਤੇ ਟੁੱਟ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਚੰਗਾ ਰੂਟ ਲੱਭ ਲੈਂਦੇ ਹੋ, ਉਸਨੂੰ सेव ਕਰੋ ਤਾਂ ਕਿ ਅਗਲਾ ਬਣਾਉਣ ਜ਼ਿਆਦਾ ਤਿਆਰ ਹੋਵੇ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਸਮਾਂ ਅਤੇ ਕਰੈਡਿਟ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ

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

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

ਇਹ ਰੁਝਾਨੀਆਂ ਜੋ ਅਸਲ ਕੰਮ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਮਿਲਦੀਆਂ ਹਨ:

• ਸੌਖੇ ਕੰਮਾਂ (ਕਾਪੀ ਐਡਿਟ्स, ਸਧਾਰਨ React ਮਾਰਕਅਪ, JSON ਫਾਰਮੇਟ) ਲਈ ਟੌਪ-ਟੀਅਰ ਕੀਮਤਾਂ ਦੇਣਾ
• “ਇਹ ਬੱਗ ਸਹੀ ਕਰੋ” ਪੁੱਛਣ ਬਗੈਰ steps to reproduce, ਉਮੀਦ ਕੀਤੀ ਵਿਹਾਰ, ਅਤੇ ਅਸਲੀ error message
• verification ਛੱਡ ਦੇਣਾ (ਕੋਈ unit test ਨਹੀਂ ਚਲਾਇਆ, ਕੋਈ UI click-through ਨਹੀਂ, ਕੋਈ SQL EXPLAIN ਜਾਂ ਨਤੀਜੇ ਸਪੌਟ-ਚੈੱਕ ਨਹੀਂ)
• ਮਾਡਲ ਨੂੰ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਕਈ ਫਾਇਲਾਂ ਰੀਫੈਕਟਰ ਕਰਨ ਦੇਣਾ, ਜਿਸ ਨਾਲ ਸਮੀਖਿਆ ਧੀਮੀ ਅਤੇ rollback ਖਤਰਨਾਕ ਹੋ ਜਾਂਦਾ ਹੈ
• ਇੱਕੋ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਲੱਛੇ ਮਿਲਾਉਣਾ (ਨਵਾਂ ਕਾਪੀ + ਨਵਾਂ ਆਰਕੀਟੈਕਚਰ + ਨਵਾਂ ਕੋਡ), ਫਿਰ ਗੁੰਝਲਦਾਰ ਆਉਟਪੁੱਟ ਮਿਲਣਾ

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਉਦਾਹਰਨ: ਤੁਸੀਂ “ਚੈੱਕਆਉਟ ਪੇਜ ਬਿਹਤਰ ਕਰੋ” ਲਈ ਇੱਕ ਕੰਪੋਨੈਂਟ ਪੇਸਟ ਕਰਦੇ ਹੋ। ਮਾਡਲ UI ਸੱਦਦਾ ਹੈ, state management ਬਦਲਦਾ ਹੈ, ਕਾਪੀ ਸੰਪਾਦਨ ਕਰਦਾ ਹੈ, ਅਤੇ API ਕਾਲਾਂ ਠੀਕ ਕਰਦਾ ਹੈ। ਹੁਣ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਨਵਾਂ ਬੱਗ ਕਿੱਥੋਂ ਆਇਆ। ਇਕ ਸਸਤਾ ਤੇਜ਼ ਰਾਹ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਵੰਞ-ਵੰਞ ਵੰਡੋ: ਪਹਿਲਾਂ ਕਾਪੀ ਵੇਰਿਅੰਟ, ਫਿਰ ਛੋਟਾ React ਬਦਲਾਅ, ਫਿਰ ਅਲੱਗ ਬੱਗ ਫਿਕਸ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ ਵੱਡੇ ਸੋਧਾਂ ਤੋਂ ਪਹਿਲਾਂ snapshots ਵਰਤੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ rollback ਕਰ ਸਕੋ, ਅਤੇ ਵੱਡੇ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲਿਆਂ ਲਈ Planning Mode ਰੱਖੋ। ਇਸ ਆਦਤ ਨਾਲ ਤੁਸੀਂ "ਹਰ ਟਾਸਕ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ LLM" ਦੇ ਨ princípios ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕੋ ਮਾਡਲ ਨੂੰ ਹਰ ਚੀਜ਼ ਲਈ ਮਜ਼ਬੂਰ ਕਰੋ।

ਤੇਜ਼ ਚੈੱਕਲਿਸਟ, ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ ਅਤੇ ਅਗਲੇ ਕਦਮ

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

"ਚਲਾਉਣ" ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਇਹ ਆਖਰੀ-ਮਿੰਟ ਰੱਖਵਾਲੀ ਦੀ ਤਰ੍ਹਾਂ ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਮਾਂ ਅਤੇ ਕਰੈਡਿਟ ਨਾਬੁਦ ਨਾ ਕਰੋ:

• ਆਉਟਪੁੱਟ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕਾਪੀ, UI, SQL, ਜਾਂ ਫਿਕਸ (ਹਰ ਪ੍ਰਾਂਪਟ ਲਈ ਇੱਕ ਲਕੜੀ).
• ਰਿਸ਼ਕ ਮੁਤਾਬਕ ਮਾਡਲ ਚੁਣੋ: ਘੱਟ-ਰਿਸ਼ਕ ਡਰਾਫਟ ਤੇਜ਼ ਹੋ ਸਕਦੇ ਹਨ; ਡੇਟਾ ਅਤੇ ਲੌਜਿਕ ਲਈ ਧਿਆਨ-ਪੂਰਵਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.
• “diff-style changes” ਅਤੇ ਏਜ-ਕੇਸ (empty state, errors, loading) ਮੰਗੋ.
• ਡੇਟਾ ਕੰਮ ਲਈ ਇੱਕ ਸੁਰੱਖਿਆ ਚੈਕ ਸ਼ਾਮਿਲ ਕਰੋ (params, constraints, reversible migrations).
• ਜੇ ਨਤੀਜਾ ਅੱਜ ਸ਼ਿਪ ਹੋਵੇਗਾ ਤਾਂ ਇੱਕ stronger ਮਾਡਲ 'ਤੇ ਉਸੇ ਪ੍ਰਾਂਪਟ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ।

ਹਕੀਕਤੀ ਉਦਾਹਰਨ: Settings ਪੇਜ ਜੋੜਨਾ

ਮਾਨੋ ਤੁਹਾਨੂੰ ਇੱਕ ਨਵਾਂ Settings ਪੇਜ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ: (1) ਅਪਡੇਟ ਕੀਤੀ UI ਕਾਪੀ, (2) form ਸਟੇਟਾਂ ਵਾਲਾ React ਪੇਜ, ਅਤੇ (3) ਇੱਕ ਨਵਾਂ ਡੇਟਾਬੇਸ ਫੀਲਡ marketing_opt_in।

ਮਾਈਕ੍ਰੋ ਕਾਪੀ ਅਤੇ ਲੇਬਲ ਲਈ ਤੇਜ਼, ਘੱਟ-ਲਾਗਤ ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਫਿਰ React ਕੰਪੋਨੈਂਟ ਲਈ "correctness-first" ਮਾਡਲ 'ਤੇ ਸਵਿੱਚ ਕਰੋ: routing, form validation, loading ਤੇ error ਸਟੇਟ, ਅਤੇ ਬਚਤ ਸਮੇਂ ਦੌਰਾਨ disabled ਬਟਨ।

ਡੇਟਾਬੇਸ ਬਦਲਣ ਲਈ ਇੱਕ ਸਾਵਧਾਨ ਮਾਡਲ ਵਰਤੋ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਕਵੇਰੀ ਅਪਡੇਟ ਲਈ। ਮੰਗੋ: rollback ਯੋਜਨਾ, ਡੀਫੌਲਟ ਮੁੱਲ, ਅਤੇ ਜੇ ਮੌਜੂਦਾ ਰੋਜ਼ਾਂ ਲਈ backfill ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸੁਰੱਖਿਅਤ backfill ਕਦਮ।

ਸੁਰੱਖਿਆ ਲਈ acceptance checks: keyboard focus ਅਤੇ labels ਦੀ ਪੁਸ਼ਟੀ, empty ਅਤੇ error ਸਟੇਟ ਟੈਸਟ ਕਰੋ, ਕਵੇਰੀਜ਼ parameterized ਹਨ ਇਹ ਜਾਂਚੋ, ਅਤੇ user settings ਪੜਨ ਵਾਲੀਆਂ ਕੋਈ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਛੋਟੀ regression ਪਾਸ ਚਲਾਉ।

ਅਗਲੇ ਕਦਮ: Koder.ai ਵਿੱਚ OpenAI, Anthropic, ਅਤੇ Gemini ਮਾਡਲਾਂ ਨੂੰ ਹਰ ਟਾਸਕ ਤੇ ਟ੍ਰਾਇ ਕਰੋ ਬਜਾਏ ਇੱਕੋ ਮਾਡਲ ਨੂੰ ਹਰ ਚੀਜ਼ ਲਈ ਮਜਬੂਰ ਕਰਨ ਦੇ। ਉੱਚ-ਰਿਸਕ ਬਦਲਾਵਾਂ ਲਈ Planning Mode ਵਰਤੋ, ਅਤੇ ਅਨੁਭਵ ਵੇਲੇ snapshots ਅਤੇ rollback 'ਤੇ ਨਿਰਭਰ ਰਹੋ।