Spec-Driven Development نے اصل مسئلہ حل نہیں کیا

Spec-driven development (SDD) اے آئی (AI) ایجنٹس کی جانب سے غلط کوڈ لکھنے کے مسئلے کا نیا حل ہے۔

اس کا طریقہ کار سادہ ہے۔ آپ ایک منظم سپیک (spec) لکھتے ہیں۔ ایک ایجنٹ اس منصوبے پر عمل کرتا ہے۔ آپ نتیجے کا جائزہ لیتے ہیں۔ GitHub Spec Kit، OpenSpec، اور Kiro جیسے ٹولز اس تبدیلی کی قیادت کر رہے ہیں۔

یہ طریقہ کار سادہ پرومپٹنگ (raw prompting) کے مقابلے میں بہتر کام کرتا ہے۔ لیکن اس میں ایک بہت بڑا نقص ہے۔

یہ اس بات پر انحصار کرتا ہے کہ سپیک ہی حقیقت کا واحد ذریعہ (source of truth) رہے۔ یہ ایک جھوٹ ہے۔

20 سالوں سے، ہم نے دستاویزات (docs) کو کوڈ کے ساتھ ہم آہنگ رکھنے کی کوشش کی۔ ڈیزائن ڈاکومنٹس، وکی (wikis)، اور READMEs، سب ناکام رہے۔ کیوں؟ کیونکہ کوڈ میں ترمیم کرنا تیز ہے اور اس سے فوری فائدہ ملتا ہے۔ دستاویز میں ترمیم کرنا سست ہے اور اس سے کچھ بھی ظاہری طور پر نظر نہیں آتا۔ دستاویز سازی (documentation) ہمیشہ رفتار کے سامنے ہار جاتی ہے۔

SDD کو بھی اسی مسئلے کا سامنا ہے۔

ایک ایجنٹ کسی رکاوٹ کا سامنا کرتا ہے۔ وہ اسے کام کرنے کے قابل بنانے کے لیے کوڈ کو درست کرتا ہے۔ اب کوڈ اور سپیک ایک دوسرے سے مطابقت نہیں رکھتے۔ چند ہی دنوں میں سپیک بے کار ہو جاتا ہے۔ زیادہ تر فریم ورکس اس مسئلے کو حل کرنے کے لیے "ڈسپلن" (discipline) استعمال کرنے کا مشورہ دیتے ہیں۔ ڈسپلن ہمیں پہلے بھی ہر بار ناکام کر چکا ہے۔

کوڈنگ سے پہلے مکمل سپیک لکھنا یہ فرض کر لیتا ہے کہ آپ عمل درآمد (implementation) کے دوران کچھ نہیں سیکھیں گے۔ یہ فیڈ بیک لوپ (feedback loop) کو توڑ دیتا ہے۔ یہ ایجائل ڈویلپمنٹ (agile development) کو ایک بھاری اور ابتدائی مرحلے پر مبنی عمل میں بدل دیتا ہے۔

ایک ڈویلپر نے SDD کا استعمال کرتے ہوئے کئی ماہ پر محیط ایک پروجیکٹ چلایا۔ ایجنٹ نے ہر سپیک کی مکمل طور پر پیروی کی۔ اس کے باوجود سسٹم ناکام ہو گیا۔ سپیک اس علم کو محفوظ نہیں کر سکا جو صرف تعمیر کے دوران سامنے آتا ہے۔ انفراسٹرکچر (infra) میں ایک چھوٹی سی تبدیلی نے پورے سپیک گراف کو تباہ کر دیا۔

ایک اور ٹیم نے SDD آزمایا اور پایا کہ یہ 10 گنا زیادہ سست تھا۔ ان کے پاس رسمی کارروائی (ceremony) زیادہ تھی لیکن بگ (bugs) کی تعداد وہی رہی۔

مقصد مزید دستاویزات بنانا نہیں ہونا چاہیے۔

اصل مسئلہ یہ ہے کہ سپیکس (specs) کو کیسے زندہ رکھا جائے۔ ہمیں ایسے سپیکس کی ضرورت ہے جو خود کو اپ ڈیٹ کریں۔ ہمیں ایسے ٹولز کی ضرورت ہے جو کوڈ اور چلتے ہوئے سسٹم سے سپیک کا اندازہ لگا سکیں۔ اسے ایک lockfile کی طرح کام کرنا چاہیے۔ یہ خودکار (automatic) ہونا چاہیے۔

میں یقین سے نہیں کہہ سکتا کہ آیا یہ ابھی ممکن ہے یا نہیں۔ میں ان لوگوں سے سننا چاہتا ہوں جو پروڈکشن (production) میں کام کر رہے ہیں۔

  • کیا آپ کا سپیک تیسرے ہفتے کے بعد بھی برقرار رہتا ہے؟
  • جب اس میں فرق (drift) آتا ہے، تو اس کی وجہ کیا ہوتی ہے؟
  • کیا آپ نے کوڈ یا ٹیلی میٹری (telemetry) سے سپیکس تیار کرنے کی کوشش کی ہے؟
  • کیا یہ سختی (rigor) کوئی قدر پیدا کرتی ہے یا صرف رسمی کارروائی ہے؟

Source: https://dev.to/sam_curatedmcp/spec-driven-development-renamed-an-old-problem-it-didnt-solve-it-tags-ai-productivity-347a

Optional learning community: https://t.me/GyaanSetuAi