آپ کا Repo کبھی بھی پوری کہانی نہیں تھا

کسی feature کے ship ہونے کے چھ ماہ بعد repository کھولیں تو آپ بہت کچھ دوبارہ جوڑ سکتے ہیں۔ آپ architecture کا سراغ لگا سکتے ہیں، schema کا جائزہ لے سکتے ہیں، tests پڑھ سکتے ہیں، اور بالکل دیکھ سکتے ہیں کہ کون سی lines بدلی تھیں۔

لیکن جو چیز آپ عموماً دوبارہ نہیں جوڑ پاتے، وہ وہ گفتگو ہے جس نے ان lines کو ضروری بنایا تھا۔

کوڈ آپ کو یہ نہیں بتائے گا کہ کوئی validation rule اس لیے موجود ہے کیونکہ ایک customer خراب exports بھیجتا ہے۔ یہ یہ بھی نہیں سمجھائے گا کہ ایک عجیب retry policy کسی downstream system میں duplicate transactions کو روکتی ہے۔ یہ نہیں دکھائے گا کہ accessibility test کے بعد زیادہ صاف interface مسترد کر دیا گیا تھا، یا یہ کہ کسی service boundary کی وجہ engineering ترجیح نہیں بلکہ ایک contractual restriction ہے۔

Git کوڈ کی history محفوظ رکھنے میں بہترین ہے۔ مگر intent تبھی محفوظ رہتا ہے جب کوئی team جان بوجھ کر اسے لکھے اور implementation کے ساتھ جوڑے رکھے۔

یہ خلا ہمیشہ سے software engineering کا حصہ رہا ہے۔ AI coding tools نے اسے زیادہ نمایاں کر دیا ہے۔ کوئی system repository کی ہر file پڑھ سکتا ہے، ہر symbol کو follow کر سکتا ہے، اور ایک تکنیکی طور پر قائل کرنے والا patch بھی بنا سکتا ہے، پھر بھی غلط مسئلہ حل کر رہا ہوتا ہے۔

مسئلہ یہ نہیں کہ کوڈ گمراہ کن ہے۔ کوڈ بس ایک زیادہ محدود سوال کا جواب دے رہا ہوتا ہے۔

engineering کی حقیقت کی پانچ تہیں

زیادہ تر معنی خیز software changes ثبوت کی پانچ مختلف تہوں پر منحصر ہوتی ہیں۔

1. Intent — user، customer، یا business کس نتیجے کا مطالبہ کر رہا ہے؟ یہ کسی specification، ticket، support conversation، یا meeting note میں ہو سکتا ہے۔
2. Constraints — کیا چیز نہیں ٹوٹنی چاہیے؟ compatibility promises، security boundaries، regulations، contracts، budgets، اور deadlines اکثر repository سے باہر ہوتے ہیں۔
3. Implementation — system آج کیسے کام کرتا ہے؟ code، tests، schemas، dependencies، اور deployment configuration یہ تہہ فراہم کرتے ہیں۔
4. Runtime evidence — حقیقی system میں کیا ہو رہا ہے؟ logs، traces، metrics، production data، اور incident reports ان مفروضوں کی تردید کر سکتے ہیں جو کوڈ میں معقول لگتے ہیں۔
5. Decision history — موجودہ approach کیوں چنی گئی؟ pull requests، design discussions، مسترد کیے گئے alternatives، اور پچھلے incidents اس کا جواب رکھتے ہیں۔

repository تیسری تہہ میں سب سے مضبوط ہوتی ہے۔ اس میں باقی تہوں کے کچھ حصے ہوتے ہیں، مگر شاذ ہی اتنے کہ انہیں مکمل طور پر پیش کر سکے۔

یہ اس لیے اہم ہے کیونکہ software failures اکثر تہوں کے درمیان سرحدوں پر ظاہر ہوتے ہیں۔ implementation کسی پرانی specification سے میل کھاتی ہے۔ fix ticket کو تو پورا کر دیتی ہے مگر کسی operational constraint کی خلاف ورزی کرتی ہے۔ tests اس لیے pass ہو جاتے ہیں کیونکہ وہ کل کے assumptions کو encode کرتے ہیں۔ کوڈ اندرونی طور پر consistent ہوتا ہے جبکہ production data ایک ایسے pattern پر چل رہا ہوتا ہے جسے کسی نے document نہیں کیا۔

مقامی طور پر درست patch بھی پھر بھی غلط تبدیلی ہو سکتی ہے۔

repository اپنے طور پر کس چیز کا جواب نہیں دے سکتی

ایک ایسے صارف کا تصور کریں جو کسی دستاویز میں ترمیم کرتا ہے اور پھر تازہ کاری شدہ جملہ تلاش کرتا ہے، مگر نتائج میں اسے پرانا ورژن نظر آتا ہے۔ “Make search update immediately” ایک واضح درخواست لگتی ہے۔ repository آغاز کے لیے کئی ممکنہ جگہیں دکھا سکتی ہے، لیکن وہ اپنے طور پر درست حل متعین نہیں کر سکتی۔

Search code یہ سمجھا سکتی ہے کہ نتائج کیسے واپس کیے جاتے ہیں۔ یہ آپ کو یہ نہیں بتا سکتی کہ اصل defect synchronization delay ہے، stale extraction ہے، cache invalidation ہے، permission propagation ہے، یا پھر ایسی توقع ہے جس کی تعریف پروڈکٹ نے کبھی کی ہی نہیں۔

بالغ نظاموں میں یہ فرق اور بھی اہم ہو جاتا ہے۔ کوئی field جو متروک دکھائی دیتی ہو، اب بھی کسی legacy client کو سہارا دے رہی ہو سکتی ہے۔ کوئی service جو بظاہر duplicate لگتی ہو، مختلف permission requirements والے data کو الگ رکھنے کے لیے ہو سکتی ہے۔ کوئی check جو حد سے زیادہ معلوم ہو، دراصل production incident کا code-level پر واحد نشان ہو سکتا ہے جسے موجودہ ٹیم نے کبھی دیکھا ہی نہ ہو۔

پیچیدگی کو حذف کرنا قیمتی ہے۔ مگر تاریخ کو، جو پیچیدگی کے بھیس میں ہو، حذف کرنا مہنگا پڑتا ہے۔

زیادہ context بھی پھر بھی غلط جواب دے سکتا ہے

ظاہر حل یہ ہے کہ AI کو مزید مواد دے دیا جائے: پوری repository، ہر ticket، ہر document، ہر message، اور ہر log۔

اس سے رسائی پیدا ہوتی ہے، سمجھ نہیں۔

ماخذ پرانے، متضاد، قیاسی، یا مختلف سامعین کے لیے لکھے گئے ہو سکتے ہیں۔ کسی brainstorm کو منظور شدہ specification پر فوقیت نہیں ملنی چاہیے۔ چھ ماہ پرانی requirement کو کل کے product decision کو خاموشی سے override نہیں کرنا چاہیے۔ کسی production log کو اس release، environment، اور code path سے جوڑا جانا چاہیے جس نے اسے پیدا کیا۔ کسی customer request کو scope چیک کیے بغیر آفاقی requirement نہیں سمجھنا چاہیے۔

اس لیے ایک سنجیدہ context system کو محض retrieval سے زیادہ کی ضرورت ہوتی ہے۔ اسے ان باتوں پر غور کرنے کا طریقہ چاہیے:

• Authority: requirement کی تعریف کرنے کا اختیار کس ماخذ کو ہے؟
• Recency: کون سی معلومات موجودہ ہیں، اور کس چیز کی جگہ نئی چیز آ چکی ہے؟
• Provenance: ہر دعویٰ، constraint، یا نتیجہ کہاں سے آیا؟
• Relationships: کون سا issue، release، customer، dataset، اور code path ایک دوسرے سے متعلق ہیں؟
• Permissions: اس کام کے لیے کون سے ماخذ استعمال کیے جا سکتے ہیں اور اس شخص کو دکھائے جا سکتے ہیں؟

Context محض tokens کا ڈھیر نہیں ہے۔ یہ وقت، authority، اور حدود کے ساتھ ایک graph ہے۔

زیادہ context سے زیادہ evidence پیدا ہونا چاہیے، evidence کے بغیر زیادہ confidence نہیں۔

کام کی اصل اکائی change ہے

Editors اور coding tools files کے گرد منظم ہوتے ہیں کیونکہ ہم ترمیم files ہی میں کرتے ہیں۔ Engineering teams changes کے گرد منظم ہوتی ہیں۔

ایک change کی شروعات ایک وجہ سے ہوتی ہے۔ وہ requirement بنتی ہے، code اور data کو چھوتی ہے، review سے گزرتی ہے، production تک پہنچتی ہے، اور نیا evidence پیدا کرتی ہے۔ اگر یہ مراحل ایک دوسرے سے کٹے رہیں، تو ہر آئندہ کام archaeology کے ایک اور دور سے شروع ہوتا ہے۔

حقیقی software پر کام کرنے والے AI system کو اسی lifecycle کی پیروی کرنی چاہیے۔

Implementation سے پہلے، اسے request، متعلقہ constraints، اور کسی بھی متضاد ماخذ کی نشاندہی کرنی چاہیے۔ اسے معلوم ہونا چاہیے کہ آیا وہ کسی defect کو ٹھیک کر رہا ہے، متوقع behavior بدل رہا ہے، یا کوئی نیا contract متعارف کرا رہا ہے۔

Implementation کے دوران، اسے ہر بامعنی انتخاب کو evidence سے جوڑنا چاہیے۔ یہ module کیوں؟ یہ migration strategy کیوں؟ اس branch کو برقرار کیوں رکھا جائے؟ وضاحت اس chat سے آگے بھی باقی رہنی چاہیے جس نے code پیدا کیا۔

نفاذ کے بعد، اسے تصدیق کے نتائج، جائزے کے فیصلے، اور نئی دریافت ہونے والی پابندیوں کو اس تبدیلی کے ساتھ منسلک کرنا چاہیے۔ ورنہ اگلے شخص—یا اگلے AI سیشن—کو انہیں دوبارہ دریافت کرنا پڑے گا۔

یہ اس فرق کو واضح کرتا ہے جو ایک ایسے ٹول میں ہے جو repository میں ترمیم کر سکتا ہے، اور ایک ایسے نظام میں جو انجینئرنگ کے کام میں حصہ لے سکتا ہے۔

AI کو ازسرِنو تشکیل کا بوجھ کم کرنا چاہیے، فیصلہ سازی ختم نہیں کرنی چاہیے

بہتر context کو کبھی کبھی خودمختار سافٹ ویئر ڈویلپمنٹ کی راہ کے طور پر پیش کیا جاتا ہے۔ اس کی فوری قدر اس سے کم ڈرامائی مگر زیادہ مفید ہے: تبدیلی کرنے سے پہلے حقیقت کو ازسرِنو تشکیل دینے کی لاگت کم کرنا۔

AI اصل requirement کو متعلقہ code کے ساتھ لا سکتا ہے۔ یہ اس incident کو سامنے لا سکتا ہے جو کسی غیر معمولی حفاظتی اقدام کی وجہ واضح کرتا ہو۔ یہ کسی ناکام metric کو اس release سے جوڑ سکتا ہے جس نے اسے بدلا تھا۔ یہ implementation شروع ہونے سے پہلے دکھا سکتا ہے کہ دو مستند ذرائع آپس میں اختلاف رکھتے ہیں۔

یہ صلاحیتیں انجینئرنگ کے فیصلے کو ختم نہیں کرتیں۔ یہ اسے زیادہ باخبر بناتی ہیں۔

اب بھی ایک انسان کو یہ طے کرنا ہوتا ہے کہ کون سا tradeoff قابلِ قبول ہے، آیا requirement مکمل ہے، اور ایک release کتنا risk اٹھا سکتی ہے۔ نظام کو شواہد کو نمایاں اور استدلال کو قابلِ جانچ بنانا چاہیے۔ اسے ایک چمکدار patch کے پیچھے غیر یقینی کو نہیں چھپانا چاہیے۔

معیار یہ نہیں ہے کہ “کیا یہ code generate کر سکتا ہے؟”

معیار یہ ہے کہ “کیا یہ وضاحت کر سکتا ہے کہ اس وقت یہی درست تبدیلی کیوں ہے؟”

repository-aware سے work-aware تک

Coding assistants سب سے پہلے اس وقت مفید بنے جب وہ developer کے سامنے موجود file کو سمجھنے لگے۔ repository awareness اگلا بڑا قدم تھا: متعلقہ code تلاش کرنا، symbols کا سراغ لگانا، اور پورے project میں تبدیلیاں نافذ کرنا۔

اگلا قدم repository کے اردگرد ہونے والے کام سے باخبر ہونا ہے۔

اس کا مطلب ہے code کو اس specification سے جوڑنا جس نے اس کی درخواست کی، اس گفتگو سے جس نے اسے واضح کیا، اس production evidence سے جس نے اسے چیلنج کیا، اور اس فیصلے سے جسے بعد میں یاد رکھا جانا چاہیے۔ اس کا یہ مطلب بھی ہے کہ ایسے context کو خارج کیا جائے جو غیر متعلق ہو، پرانا ہو، یا صارف کی permissions سے باہر ہو۔

Dvina بناتے ہوئے، یہ ان خیالات میں سے ایک ہے جن کی طرف ہم بار بار لوٹتے ہیں۔ کام کسی ایک file، application، یا conversation کے اندر نہیں ہوتا۔ معنی ان کے درمیان موجود روابط میں رہتے ہیں، اور اس میں بھی کہ وقت کے ساتھ وہ روابط کیسے بدلتے ہیں۔

repository بدستور بنیادی اہمیت رکھتی ہے۔ یہ نظام کے رویّے کے لیے executable source of truth ہے۔ بس یہ product intent، operational reality، یا organizational memory کے لیے مکمل source of truth نہیں ہے۔

پوری کہانی یہ بدل دیتی ہے کہ آخر کیا بنایا جاتا ہے

صرف code کے ساتھ، فطری سوال یہ ہوتا ہے:

اس system کے لیے کون سی تبدیلی موزوں ہے؟

وسیع تر context کے ساتھ، سوال یہ بن جاتا ہے:

اس system، اس requirement، اس history، اور اس لمحے کے لیے کون سی تبدیلی موزوں ہے؟

وہ دوسرا سوال پابندیوں کو ریگریشن بننے سے پہلے ہی سامنے لے آتا ہے۔ یہ ریویورز کو امپلیمنٹیشن کے پیچھے کی منطق سمجھاتا ہے۔ یہ ٹیم کے نئے ارکان کو یہ سمجھنے میں مدد دیتا ہے کہ سسٹم کی ساخت ایسی کیوں ہے۔ یہ AI کو ایک مضبوط کردار دیتا ہے: ایڈیٹر کے اندر کسی غیبی مرجع کے طور پر نہیں، بلکہ ایک ایسے شریک کے طور پر جو کام کے مختلف حصوں سے شواہد اکٹھے کر سکے۔

آپ کی repo کبھی بھی پوری کہانی نہیں تھی۔

اصل موقع یہ ہے کہ ایسے سسٹمز بنائے جائیں جو اس کے باقی حصے کو بھی پڑھ سکیں—اور اپنا کام بھی دکھا سکیں۔