2026 کے ایک Sonar سروے کے مطابق 88% ڈویلپرز کا کہنا ہے کہ AI سے تیار کردہ کوڈ تکنیکی قرض (technical debt) میں اضافہ کر رہا ہے، اور اسپیسیفیکیشن پر مبنی ڈویلپمنٹ (spec-driven development) کے حامیوں کا کہنا ہے کہ ایک منظم اسپیسیفیکیشن کا مرحلہ اس رجحان کو روک سکتا ہے۔
یہ مسئلہ کیوں اہم ہے
جب کسی انسان کو کوئی مبہم ticket ملتا ہے، تو وہ وضاحت کے لیے سوالات پوچھتا ہے۔ اس کے برعکس، ایک AI ایجنٹ خالی جگہوں کو اپنے بہترین اندازے سے بھر دیتا ہے اور ایسا کوڈ فراہم کرتا ہے جو دیکھنے میں درست معلوم ہوتا ہے۔ درست ہونے کا یہ دھوکہ مہنگا پڑ سکتا ہے: اسی Sonar پول کے مطابق آدھے سے زیادہ شرکاء نے ایسا کوڈ دیکھا ہے جو بنیادی چیک پاس کر لیتا ہے لیکن اس میں باریک نقائص چھپے ہوتے ہیں۔ یہ نقائص تکنیکی قرض (technical debt) کے طور پر جمع ہوتے رہتے ہیں، جس سے بعد میں refactors کی ضرورت پڑتی ہے، فیچرز کی فراہمی سست ہو جاتی ہے، اور maintenance کے بجٹ میں اضافہ ہوتا ہے۔
اسپیسیفیکیشن پر مبنی ڈویلپمنٹ (spec-driven development) کیسی دکھتی ہے
Spec-driven development (SDD) موجودہ ترتیب کو الٹ دیتی ہے۔ ایک مختصر user story کے ساتھ AI ماڈل کو prompt دینے کے بجائے، ٹیم ایک تفصیلی، agent-executable اسپیسیفیکیشن لکھتی ہے جو کوڈ کے ساتھ ہی اسی version-control سسٹم میں موجود ہوتی ہے۔ یہ spec حقیقت کا واحد ذریعہ (single source of truth) بن جاتی ہے—یہ مقصد، edge cases، کارکردگی کی توقعات، اور کسی بھی ایسی پابندیوں کو ریکارڈ کرتی ہے جن پر AI ماڈل کو عمل کرنا ضروری ہے۔
یہ عمل انسانی ڈیزائن کے کام کو ختم نہیں کرتا، بلکہ اسے کوڈ کی شکل میں محفوظ کرتا ہے۔ فیصلوں کو ڈویلپر کی یادداشت سے نکال کر ایک ٹھوس دستاویز میں منتقل کر کے، انسان اور مستقبل کے AI ایجنٹس دونوں یہ جان سکتے ہیں کہ کوڈ کا ایک حصہ ایک خاص طریقے سے کیوں کام کر رہا ہے۔ ایک spec کا مسودہ تیار کرنے میں شروع میں محنت لگتی ہے، لیکن مبہم AI output کو debug کرنے کی قیمت بعد میں کہیں زیادہ ہوتی ہے۔
ورک فلو (workflow) میں تبدیلی
Product backlog – آئٹمز کو مختصر رکھیں، صرف مقصد اور اعلیٰ سطح کے acceptance criteria کو شامل کریں۔ یہ فہرست ترجیحات طے کرنے کے لیے استعمال ہوتی رہے گی۔
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 بالکل کوڈ کی طرح اس پر تبصرہ کر سکتے ہیں، ترمیم تجویز کر سکتے ہیں اور تبدیلیوں کی منظوری دے سکتے ہیں۔
Definition of Done – کوالٹی گیٹ میں "Spec reviewed and approved" کا اضافہ کریں۔ کوئی بھی کوڈ اس وقت تک مکمل نہیں سمجھا جاتا جب تک spec عمل درآمد کے معیار کے مطابق review پاس نہ کر لے۔
Kanban adaptation – دو نئے کالم شامل کریں: "Spec Drafted" اور "Spec Approved"۔ اب کام کے آئٹمز اس ترتیب سے چلیں گے: backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done۔ یہ بصری تبدیلی پہلے سے غیر مرئی کوآرڈینیشن کے مرحلے کو واضح کر دیتی ہے۔
وہ ٹولز جو پہلے سے specs پر عمل درآمد کرتے ہیں
GitHub Spec Kit اور AWS Kiro جیسے پلیٹ فارمز نے ایسے گیٹس (gates) شامل کیے ہیں جو کسی بھی AI کوڈ جنریشن کے شروع ہونے سے پہلے ایک requirements document کا مطالبہ کرتے ہیں۔ وہ AI ماڈل کا متبادل نہیں ہیں؛ بلکہ وہ لفظی طور پر کام کرنے والے ایجنٹس کو انسانی مقصد کے مطابق ڈھالتے ہیں۔ اسپیسیفیکیشن کو ایک لازمی شرط بنا کر، یہ ٹولز موجودہ CI/CD pipelines کو خراب کیے بغیر اس تبدیلی کو خودکار بنا دیتے ہیں۔
ممکنہ مخالفت
ناقدین کا کہنا ہے کہ spec لکھنا پہلے سے تیز رفتار agile cadence میں رکاوٹ پیدا کرتا ہے۔ اس کا جواب یہ ہے کہ spec تیار کرنے میں لگنے والا وقت عام طور پر مبہم prompt سے پیدا ہونے والے AI کوڈ کو debug کرنے میں لگنے والے وقت کا ایک چھوٹا سا حصہ ہوتا ہے۔
ایک اور تشویش یہ ہے کہ ضروریات کے بدلنے کے ساتھ specifications پرانی ہو سکتی ہیں۔ Version-control کا انضمام اس کا حل ہے: spec میں کوئی بھی تبدیلی ایک نیا commit تخلیق کرتی ہے، review کا عمل شروع کرتی ہے، اور ٹیم کو متعلقہ کوڈ کا دوبارہ جائزہ لینے پر مجبور کرتی ہے۔ عملی طور پر، specs کو کوڈ کی طرح سمجھنا دستاویزات کو اپ ٹو ڈیٹ رکھتا ہے۔
آگے کیا نظر آئے گا
اس کا اطلاق ابھی ابتدائی مراحل میں ہے، لیکن اس کا رجحان واضح ہے۔ جیسے جیسے AI code generators زیادہ باصلاحیت ہوتے جائیں گے، درست اور machine-readable مقصد کی ضرورت مزید بڑھتی جائے گی۔
Bottom line: مبہم prompts کو ٹھوس اور ریویو شدہ specifications میں تبدیل کرنا ایک اضافی مرحلہ محسوس ہو سکتا ہے، لیکن یہ اندازوں کو ذمہ دارانہ فیصلوں میں بدل دیتا ہے۔