2026 ਦੇ ਇੱਕ Sonar ਸਰਵੇਖਣ ਅਨੁਸਾਰ 88% ਡਿਵੈਲਪਰਾਂ ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ AI-ਨਿਰਮਿਤ ਕੋਡ ਤਕਨੀਕੀ ਕਰਜ਼ੇ (technical debt) ਨੂੰ ਵਧਾ ਰਿਹਾ ਹੈ, ਅਤੇ spec-driven development ਦੇ ਸਮਰਥਕਾਂ ਦਾ ਤਰਕ ਹੈ ਕਿ ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ ਸਪੈਸੀਫਿਕੇਸ਼ਨ (specification) ਕਦਮ ਇਸ ਭਟਕਾਅ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।
ਇਹ ਸਮੱਸਿਆ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਜਦੋਂ ਕਿਸੇ ਇਨਸਾਨ ਨੂੰ ਕੋਈ ਅਸਪਸ਼ਟ ਟਿਕਟ ਮਿਲਦੀ ਹੈ, ਤਾਂ ਉਹ ਸਪਸ਼ਟੀਕਰਨ ਲਈ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ। ਇਸਦੇ ਉਲਟ, ਇੱਕ AI agent ਆਪਣੀ ਸਭ ਤੋਂ ਵਧੀਆ ਅੰਦਾਜ਼ੇ ਨਾਲ ਖਾਲੀ ਥਾਵਾਂ ਨੂੰ ਭਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਅਜਿਹਾ ਕੋਡ ਸੌਂਪ ਦਿੰਦਾ ਹੈ ਜੋ ਦੇਖਣ ਵਿੱਚ ਸਹੀ ਲੱਗਦਾ ਹੈ। ਸਹੀ ਹੋਣ ਦਾ ਇਹ ਭਰਮ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ: ਉਹੀ Sonar ਪੋਲ ਦੱਸਦਾ ਹੈ ਕਿ ਅੱਧੇ ਤੋਂ ਵੱਧ ਉੱਤਰਦਾਤਾਵਾਂ ਨੇ ਅਜਿਹਾ ਕੋਡ ਦੇਖਿਆ ਹੈ ਜੋ ਬੁਨਿਆਦੀ ਚੈੱਕਾਂ ਵਿੱਚੋਂ ਤਾਂ ਲੰਘ ਜਾਂਦਾ ਹੈ ਪਰ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਨੁਕਸ ਰੱਖਦਾ ਹੈ। ਉਹ ਨੁਕਸ ਤਕਨੀਕੀ ਕਰਜ਼ੇ (technical debt) ਵਜੋਂ ਜਮ੍ਹਾਂ ਹੁੰਦੇ ਰਹਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਬਾਅਦ ਵਿੱਚ refactors ਕਰਨੇ ਪੈਂਦੇ ਹਨ, ਫੀਚਰ ਡਿਲੀਵਰੀ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਰੱਖ-ਰਖਾਅ (maintenance) ਦਾ ਬਜਟ ਵਧ ਜਾਂਦਾ ਹੈ।
Spec-driven development ਕਿਹੋ ਜਿਹਾ ਹੁੰਦਾ ਹੈ
Spec-driven development (SDD) ਮੌਜੂਦਾ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਲਟਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਸੰਖੇਪ user story ਨਾਲ AI ਮਾਡਲ ਨੂੰ prompt ਦੇਣ ਦੀ ਬਜਾਏ, ਟੀਮ ਇੱਕ ਵਿਸਤ੍ਰਿਤ, agent-executable specification ਲਿਖਦੀ ਹੈ ਜੋ ਕੋਡ ਦੇ ਨਾਲ ਹੀ ਉਸੇ version-control system ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। ਇਹ spec ਸੱਚ ਦਾ ਇੱਕੋ-ਇੱਕ ਸਰੋਤ (single source of truth) ਬਣ ਜਾਂਦਾ ਹੈ—ਇਹ ਇਰਾਦੇ (intent), edge cases, ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਉਮੀਦਾਂ, ਅਤੇ ਉਹਨਾਂ ਸਾਰੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਇੱਕ AI ਮਾਡਲ ਨੂੰ ਪਾਲਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇਹ ਪ੍ਰਕਿਰਿਆ ਮਨੁੱਖੀ ਡਿਜ਼ਾਈਨ ਕੰਮ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੀ; ਇਹ ਇਸਨੂੰ ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਲਿਖਦੀ (codifies) ਹੈ। ਫੈਸਲਿਆਂ ਨੂੰ ਡਿਵੈਲਪਰ ਦੀ ਯਾਦਦਾਸ਼ਤ ਤੋਂ ਇੱਕ ਪੱਕੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਲਿਆ ਕੇ, ਇਨਸਾਨ ਅਤੇ ਭਵਿੱਖ ਦੇ AI agents ਦੋਵੇਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹਨ ਕਿ ਕੋਡ ਦਾ ਇੱਕ ਹਿੱਸਾ ਕਿਸੇ ਖਾਸ ਤਰੀਕੇ ਨਾਲ ਕਿਉਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਇੱਕ spec ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਸ਼ੁਰੂ ਵਿੱਚ ਮਿਹਨਤ ਲੱਗਦੀ ਹੈ, ਪਰ ਅਸਪਸ਼ਟ AI ਆਉਟਪੁੱਟ ਨੂੰ debug ਕਰਨ ਦੀ ਕੀਮਤ ਬਾਅਦ ਵਿੱਚ ਕਿਤੇ ਜ਼ਿਆਦਾ ਹੁੰਦੀ ਹੈ।
ਵਰਕਫਲੋ (workflow) ਨੂੰ ਬਦਲਣਾ
Product backlog – ਆਈਟਮਾਂ ਨੂੰ ਸੰਖੇਪ ਰੱਖੋ, ਸਿਰਫ਼ ਇਰਾਦੇ (intent) ਅਤੇ ਉੱਚ-ਪੱਧਰੀ acceptance criteria ਨੂੰ ਹੀ ਦਰਜ ਕਰੋ। ਇਹ ਸੂਚੀ ਪਹਿਲ (prioritization) ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੀ ਹੈ।
Sprint planning – ਟੀਮਾਂ ਮੁੱਖ ਟੀਚੇ ਬਾਰੇ ਚਰਚਾ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ Sprint Goal 'ਤੇ ਸਹਿਮਤ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਵਿਸਤ੍ਰਿਤ implementation ਨੂੰ ਉਦੋਂ ਤੱਕ ਰੋਕ ਕੇ ਰੱਖਦੀਆਂ ਹਨ ਜਦੋਂ ਤੱਕ spec ਤਿਆਰ ਨਹੀਂ ਹੋ ਜਾਂਦਾ।
ਸਪ੍ਰਿੰਟ ਦੌਰਾਨ (During the sprint) – ਟਾਸਕ ਲੈਣ ਵਾਲਾ ਵਿਅਕਤੀ ਇੱਕ ਸਹੀ ਅਤੇ machine-readable spec ਲਿਖਦਾ ਹੈ। Spec ਵਿੱਚ input formats, ਉਮੀਦ ਕੀਤੇ ਗਏ outputs, error handling, ਅਤੇ ਕੋਈ ਵੀ non-functional requirements ਦਰਜ ਹੁੰਦੀਆਂ ਹਨ। ਕਿਉਂਕਿ spec version-controlled ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ reviewers ਕੋਡ ਵਾਂਗ ਹੀ comment ਕਰ ਸਕਦੇ ਹਨ, ਸੋਧਾਂ ਦਾ ਸੁਝਾਅ ਦੇ ਸਕਦੇ ਹਨ, ਅਤੇ ਤਬਦੀਲੀਆਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦੇ ਹਨ।
Definition of Done – Quality gate ਵਿੱਚ “Spec reviewed and approved” ਜੋੜੋ। ਕੋਈ ਵੀ ਕੋਡ ਉਦੋਂ ਤੱਕ ਪੂਰਾ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ ਜਦੋਂ ਤੱਕ spec implementation ਦੇ ਸਮਾਨ ਰਿਵਿਊ ਮਿਆਰਾਂ ਨੂੰ ਪਾਰ ਨਹੀਂ ਕਰ ਲੈਂਦਾ।
Kanban adaptation – ਦੋ ਨਵੇਂ ਕਾਲਮ ਜੋੜੋ: “Spec Drafted” ਅਤੇ “Spec Approved.” ਹੁਣ ਕੰਮ ਦੇ ਆਈਟਮਾਂ ਦਾ ਵਹਾਅ backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done ਵਾਂਗ ਹੋਵੇਗਾ। ਇਹ ਵਿਜ਼ੂਅਲ ਤਬਦੀਲੀ ਪਹਿਲਾਂ ਅਦਿੱਖ ਰਹਿਣ ਵਾਲੇ ਤਾਲਮੇਲ (coordination) ਦੇ ਕਦਮ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾ ਦਿੰਦੀ ਹੈ।
ਉਹ ਟੂਲ ਜੋ ਪਹਿਲਾਂ ਹੀ specs ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ
GitHub Spec Kit ਅਤੇ AWS Kiro ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ ਨੇ ਅਜਿਹੇ gates ਜੋੜ ਦਿੱਤੇ ਹਨ ਜੋ ਕਿਸੇ ਵੀ AI code generation ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ requirements document ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ। ਉਹ AI ਮਾਡਲ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੇ; ਉਹ ਸ਼ਾਬਦਿਕ (literal-minded) agents ਨੂੰ ਮਨੁੱਖੀ ਇਰਾਦੇ ਨਾਲ ਜੋੜਦੇ ਹਨ। Spec ਨੂੰ ਇੱਕ ਪੂਰਵ-ਸ਼ਰਤ (prerequisite) ਬਣਾ ਕੇ, ਇਹ ਟੂਲ ਮੌਜੂਦਾ CI/CD pipelines ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਇਸ ਤਬਦੀਲੀ ਨੂੰ ਆਟੋਮੇਟ ਕਰਦੇ ਹਨ।
ਸੰਭਾਵੀ ਵਿਰੋਧ
ਆਲੋਚਕਾਂ ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ spec ਲਿਖਣ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਤੇਜ਼ ਰਫ਼ਤਾਰ ਵਾਲੀ agile cadence ਵਿੱਚ ਰੁਕਾਵਟ ਆਉਂਦੀ ਹੈ। ਇਸਦਾ ਉਲਟ ਤਰਕ ਇਹ ਹੈ: spec ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਲੱਗਿਆ ਸਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਅਸਪਸ਼ਟ prompt ਤੋਂ ਪੈਦਾ ਹੋਏ AI-ਨਿਰਮਿਤ ਕੋਡ ਨੂੰ debug ਕਰਨ ਵਿੱਚ ਲੱਗਣ ਵਾਲੇ ਸਮੇਂ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਹੋਰ ਚਿੰਤਾ ਇਹ ਹੈ ਕਿ ਜਿਵੇਂ-ਜਿਵੇਂ requirements ਬਦਲਦੀਆਂ ਹਨ, specifications ਪੁਰਾਣੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। Version-control integration ਇਸਦਾ ਹੱਲ ਕਰਦਾ ਹੈ: spec ਵਿੱਚ ਕੋਈ ਵੀ ਤਬਦੀਲੀ ਇੱਕ ਨਵਾਂ commit ਬਣਾਉਂਦੀ ਹੈ, ਇੱਕ review ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਅਤੇ ਟੀਮ ਨੂੰ ਸਬੰਧਤ ਕੋਡ ਦਾ ਮੁੜ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ, specs ਨੂੰ ਕੋਡ ਵਾਂਗ ਮੰਨਣ ਨਾਲ ਦਸਤਾਵੇਜ਼ (documentation) ਹਮੇਸ਼ਾ ਅਪ-ਟੂ-ਡੇਟ ਰਹਿੰਦਾ ਹੈ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
ਇਸ ਨੂੰ ਅਪਣਾਉਣ ਦਾ ਕਾਰਜ ਅਜੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਹੈ, ਪਰ ਇਸਦੀ ਰਫ਼ਤਾਰ ਸਾਫ਼ ਦਿਖਾਈ ਦੇ ਰਹੀ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ AI code generators ਵਧੇਰੇ ਸਮਰੱਥ ਬਣਦੇ ਜਾਣਗੇ, ਸਹੀ ਅਤੇ machine-readable ਇਰਾਦੇ (intent) ਦੀ ਲੋੜ ਹੋਰ ਵੀ ਵਧੇਗੀ।
ਸਾਰ (Bottom line): ਅਸਪਸ਼ਟ prompts ਨੂੰ ਪੱਕੀਆਂ ਅਤੇ ਰਿਵਿਊ ਕੀਤੀਆਂ specifications ਵਿੱਚ ਬਦਲਣਾ ਇੱਕ ਵਾਧੂ ਕਦਮ ਵਾਂਗ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਅੰਦਾਜ਼ੇ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਜ਼ਿੰਮੇਵਾਰ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।