برسوں تک، مصنوعی ذہانت (AI) ایڈیٹر میں آپ کے ساتھ بیٹھی رہی اور اندازہ لگاتی رہی کہ آگے کیا آئے گا۔ آپ نے ایک لائن لکھی؛ اس نے اگلی لائن تجویز کی۔ آرکیٹیکچر، ڈی بگنگ اور سنٹیکس پر اب بھی آپ کا اختیار تھا۔ وہ دور ختم ہو چکا ہے۔

ہم Intent-Driven Development کی طرف بڑھ رہے ہیں۔ اب آپ لوپس (loops) اور کنڈیشنلز (conditionals) ٹائپ کرنا بند کر دیں گے۔ اس کے بجائے، آپ اس نتیجے کی وضاحت کریں گے جس کی آپ کو ضرورت ہے۔ ایک ایجنٹ اس مقصد کو سمجھتا ہے، مراحل کی منصوبہ بندی کرتا ہے، کوڈ لکھتا ہے، ٹیسٹ چلاتا ہے، اور اس سے پہلے کہ آپ نتیجہ دیکھیں، اپنی غلطیوں کو خود ہی ٹھیک کر لیتا ہے۔ اب کی بورڈ بنیادی ٹول نہیں رہا، بلکہ واضح سوچ (clear thinking) اصل ہتھیار ہے۔

لائن بہ لائن کوڈنگ کا خاتمہ

پرانے طریقہ کار میں آپ کو ہر ارادے کو ایک مخصوص زبان میں منتقل کرنا پڑتا تھا جسے کمپائلر سمجھ سکے۔ آپ کاروباری ضرورت کو اپنے ذہن میں رکھتے تھے، پھر اسے دستی طور پر فنکشنز، امپورٹس، ایرر ہینڈلنگ اور ٹیسٹ کیسز میں تقسیم کرتے تھے۔ Intent-Driven Development اس ترجمے کے مرحلے کو ختم کر دیتا ہے۔

فرض کریں آپ کو ایک پیمنٹ ویب ہک (payment webhook) کو انٹیگریٹ کرنے کی ضرورت ہے۔ پہلے، آپ روٹ ہینڈلر لکھتے، پے لوڈ (payload) کو پارس کرتے، سگنیچر کی تصدیق کرتے، ٹرانزیکشن کے اندر ڈیٹا بیس کو اپ ڈیٹ کرتے، اور رسید کا ای میل کیو (queue) میں ڈالتے۔ اب آپ ضرورت بیان کرتے ہیں: “آنے والے Stripe webhook کی تصدیق کریں، ایونٹ کو idempotently ریکارڈ کریں، اور رسید کے عمل کو شروع کریں۔ اگر ڈیٹا بیس میں لکھائی (write) ناکام ہو جائے تو رول بیک کر دیں۔” ایجنٹ ہینڈلر لکھتا ہے، پارسنگ کی حکمت عملی کا انتخاب کرتا ہے، ری ٹرائی لاجک (retry logic) کو ترتیب دیتا ہے، اور ٹیسٹ تیار کرتا ہے۔ آپ کا کردار مصنف (author) سے ڈائریکٹر (director) میں بدل جاتا ہے۔

یہ صرف اس لیے کام کرتا ہے کیونکہ ایجنٹ صرف کوڈ بنانے پر نہیں رکتا۔ وہ ایک لوپ (loop) میں داخل ہو جاتا ہے۔

ایجنٹ لوپ کے اندر

بنیادی کام اب انسان کا ٹائپ کرنا یا دستی ڈی بگنگ نہیں ہے۔ یہ جنریشن (generation) اور ویلیڈیشن (validation) کے درمیان ایک تیز رفتار چکر ہے۔ ایجنٹ کوڈ تیار کرتا ہے، اسے آپ کے ٹیسٹ سویٹ کے خلاف چلاتا ہے، آؤٹ پٹ پڑھتا ہے، اور خود ہی ناکامیوں کو ٹھیک کرتا ہے۔ ایک مسنگ امپورٹ، ٹائپ کا فرق، یا کوئی فیل ہونے والا اسسرشن (assertion) — ایجنٹ اسٹیک ٹریس (stack trace) دیکھتا ہے، فائل میں ترمیم کرتا ہے، اور سویٹ کو دوبارہ چلاتا ہے۔ آپ اس لوپ میں شامل نہیں ہوتے۔ یہ چکر مشین کی رفتار سے چلتا ہے۔

آپ اس وقت مداخلت کرتے ہیں جب خود لوپ ٹوٹ جاتا ہے۔ شاید ایجنٹ دو ڈیپینڈینسیز (dependencies) کے درمیان تنازع کو حل نہیں کر پاتا، یا وہ ایسا کوڈ تیار کرتا رہتا ہے جو یونٹ ٹیسٹ تو پاس کر لیتا ہے لیکن اعلیٰ سطح کے کاروباری اصولوں کی خلاف ورزی کرتا ہے۔ وہ حدود وہ جگہ ہیں جہاں انسانی فیصلے کی اب بھی اہمیت ہے۔

آپ کا اصل کام: Constraint Designer اور Edge-Case Hunter

اگر مشین فنکشنز لکھتی ہے، تو آپ کے لیے کیا بچا ہے؟ دو چیزیں، اور وہ سنٹیکس ٹائپ کرنے سے زیادہ مشکل ہیں۔

پہلا، آپ وہ حدود (constraints) لکھتے ہیں جو ایجنٹ کو صحیح راستے پر رکھتی ہیں۔ ایجنٹ کے پاس وسیع علم ہوتا ہے لیکن آپ کے مخصوص ماحول کی سمجھ نہیں ہوتی۔ آپ کو اسے بتانا ہوگا: “صرف انٹرنل بلنگ API استعمال کریں، کبھی بھی خام را (raw) کارڈ ٹوکنز لاگ نہ کریں، اور رسپانس لیٹنسی (latency) کو دو سو ملی سیکنڈ سے کم رکھیں۔” یہ حدود محض عام پرامپٹس (prompts) نہیں ہیں۔ یہ وہ تفصیلات (specifications) ہیں جو کامیابی یا ناکامی کا تعین کرتی ہیں۔

دوسرا، آپ ان دس فیصد کیسز کو پکڑتے ہیں جہاں ایجنٹ ناکام ہو جاتا ہے۔ ایجنٹس عام راستوں کو اچھی طرح سنبھال لیتے ہیں۔ وہ باریک ریئس کنڈیشنز (race conditions)، مبہم کاروباری منطق کے ایج کیسز (edge cases)، اور ان سیکیورٹی مفروضوں پر لڑکھڑا جاتے ہیں جو ان کے ٹریننگ ڈیٹا میں شامل ہوتے ہیں۔ آپ کی مہارت ویب ہک ہینڈلر اور ری فنڈ کرون جاب (refund cron job) کے درمیان ہونے والی ریس (race) کو پکڑنے، یا یہ پہچاننے میں آتی ہے کہ تیار کردہ ری ٹرائی لاجک چارجز کو ڈپلیکیٹ کر سکتا ہے۔ مشین عام مسائل حل کرتی ہے۔ آپ خطرناک استثنا (exception) کو پکڑتے ہیں۔

کوڈ ریویو کی جگہ Verification Harness کا استعمال کریں

جب ایک ایجنٹ راتوں رات پچاس فائلیں تیار کر سکتا ہے، تو آپ انہیں صرف یہ دیکھنے کے لیے کہ آیا وہ “ٹھیک لگ رہی ہیں” اسکین نہیں کر سکتے۔ فائلوں کی کثرت انسانی نظر سے جائزہ لینے کو ناممکن بنا دیتی ہے۔ آپ کو ایک ایسے ہارسنس (harness) کی ضرورت ہے جو کوڈ آپ تک پہنچنے سے پہلے غلطیوں کو پکڑ لے۔

یہ ہارسنس تین ستونوں پر قائم ہے۔

Durable execution. ایجنٹ کے ٹاسک اکثر ایک سنگل ریکوسٹ ٹائم آؤٹ سے زیادہ دیر تک چلتے ہیں۔ اگر کوئی مرحلہ عارضی نیٹ ورک کی خرابی کی وجہ سے ناکام ہو جاتا ہے، تو ہارسنس اسے روک دیتا ہے، دوبارہ کوشش کرتا ہے، اور اسٹیٹ (state) کو خراب کیے بغیر دوبارہ شروع کر دیتا ہے۔ کام تعطل کے باوجود برقرار رہتا ہے۔

Structured outputs. اس امید کے بجائے کہ ایجنٹ ایک درست کنفیگریشن فائل واپس کرے گا، آپ پہلے سے ہی معاہدے (contract) کو نافذ کرتے ہیں۔ JSON Schema جیسے ٹولز فوری طور پر آؤٹ پٹ کی تصدیق کرتے ہیں۔ اگر ایجنٹ کوئی مطلوبہ فیلڈ چھوڑ دیتا ہے یا غلط ڈیٹا ٹائپ استعمال کرتا ہے، تو ہارسنس اسے اس سے پہلے مسترد کر دیتا ہے کہ کوڈ آپ کے ریپوزٹری (repository) تک پہنچے۔

Dynamic guardrails. ایجنٹ کو سیکرٹس (secrets) پڑھنے یا پروڈکشن ڈیٹا بیس میں لکھنے کی مکمل آزادی نہیں ہونی چاہیے۔ ہارسنس ڈائنامک طریقے سے اجازتوں (permissions) کو کنٹرول کرتا ہے، ایجنٹ کو سینڈ باکس (sandbox) میں رکھتا ہے تاکہ وہ صرف نامزد کردہ ٹیسٹ ڈیٹا بیس اور انٹرنل اینڈ پوائنٹس تک ہی رسائی حاصل کر سکے۔ آپ ہر لائن کا جائزہ نہیں لے رہے ہوتے۔ آپ ایجنٹ کے گرد لگی باڑ کا آڈٹ کر رہے ہوتے ہیں۔

جب کوڈ کام کرے لیکن پروڈکٹ ناکام ہو جائے

یہاں ایک تضاد ہے۔ ہارسنس (harness) خراب کوڈ کو پکڑ لیتا ہے، لیکن یہ خراب ارادے (intent) کو نہیں پکڑ سکتا۔

اگر آپ کی سپیسیفیکیشن (specification) کہتی ہے، "ہر نئے صارف کو ویلکم ای میل بھیجیں،" تو ایجنٹ ایسا صاف ستھرا اور ٹیسٹ شدہ کوڈ لکھے گا جو وہ ای میل بھیج دے گا۔ اسے یہ معلوم نہیں ہوگا کہ آپ کا مطلب یہ تھا، "ویلکم ای میل صرف تب بھیجیں جب صارف نے اپنا پتہ تصدیق کر لیا ہو، مارکیٹنگ کے لیے رضامندی ظاہر کی ہو، اور اپنے مقامی ٹائم زون میں کاروباری اوقات کے دوران سائن اپ کیا ہو۔" کوڈ تکنیکی طور پر بے عیب ہے لیکن تجارتی طور پر خطرناک ہے۔

Intent-Driven Development میں اصل خطرہ مبہم سپیسیفیکیشن (ambiguous specification) ہے۔ غیر واضح ارادہ ایسا سافٹ ویئر پیدا کرتا ہے جو کتابی مہارت کے ساتھ غلط مسئلے کو حل کرتا ہے۔ یہی وجہ ہے کہ آپ کو اپنی سپیسیفیکیشنز کو حقیقی اثاثوں کے طور پر لینا چاہیے۔ ان کے ورژنز (versions) بنائیں۔ اسٹیک ہولڈرز (stakeholders) کے ساتھ ان کا جائزہ لیں۔ ایجنٹ کے تعمیر شروع کرنے سے پہلے انہیں اصل ورک فلو (workflows) کے مطابق درست ثابت کریں۔ چیٹ باکس میں لکھ دیا گیا ایک پرامپٹ (prompt) سپیسیفیکیشن نہیں ہے۔ یہ ایک ذمہ داری (liability) ہے۔

انجینئرنگ ججمنٹ اب اپ اسٹریم (upstream) منتقل ہو رہی ہے

انجینئرنگ ججمنٹ ختم نہیں ہو رہی، بلکہ یہ ایک بلند مقام کی طرف منتقل ہو رہی ہے۔

اب آپ اپنی ذہنی توانائی اس بات پر صرف نہیں کرتے کہ میپ (map) کو کیسے دہرایا جائے یا کلاس ہائیرارکی (class hierarchy) کو کیسے ترتیب دیا جائے۔ اب آپ اسے اس بات پر صرف کرتے ہیں کہ ناکامی کی صورت میں سسٹم کو کیا کرنا چاہیے، اسے کون سا ڈیٹا کبھی ظاہر نہیں کرنا چاہیے، اور کون سے انوئیریئنٹ (invariants) تقسیم شدہ سروسز (distributed services) میں برقرار رہنے چاہئیں۔ کوڈنگ کا ہنر اب ضروریات (requirements) کے ہنر میں بدل رہا ہے۔

اس کا مطلب ہے کہ آپ کی سپیسیفیکیشنز کو اسی سختی کی ضرورت ہے جو آپ کبھی اپنے کوڈ پر لاگو کرتے تھے۔ اپنی پابندیوں (constraints) کا درست نام لیں۔ ناکامی کے طریقوں (failure modes) کی واضح وضاحت کریں۔ کاروباری اصولوں کو اتنی ہی وضاحت سے بیان کریں جتنی وضاحت سے آپ کبھی اپنے ٹائپس (types) کا اعلان کرتے تھے۔ ایجنٹ امپلیمنٹیشن (implementation) سنبھال لے گا۔ آپ کو اس بات کی ضمانت دینی ہوگی کہ وہ امپلیمنٹیشن بنانے کے قابل ہو۔

معیار کا معیار (quality bar) پل ریکویسٹ (pull request) سے ہٹا کر پرامپٹ (prompt) پر لے آئیں۔ پہلے ہارسنس (harness) بنائیں۔ دوسرا سپیسیفیکیشن لکھیں۔ پھر مشین کو سنٹیکس (syntax) سنبھالنے دیں جبکہ آپ اس بات پر توجہ دیں کہ آیا مسئلہ درست طریقے سے بیان کیا گیا ہے اور حدود کو حفاظت سے طے کیا گیا ہے۔

اگر آپ اس تبدیلی کے پیچھے موجود خیالات کو مزید گہرائی سے سمجھنا چاہتے ہیں، تو Intent-Driven Development پر اصل بحث یہاں دستیاب ہے۔ AI-native انجینئرنگ کے بارے میں جاری گفتگو کے لیے، آپ GyaanSetu community میں بھی شامل ہو سکتے ہیں۔