اے آئی کوڈنگ ایجنٹ ترمیمی لوپ کو کیسے توڑا جائے۔

آپ نے شاید یہ فلم پہلے دیکھی ہوگی۔ ایسا تب ہوتا ہے جب AI کوڈنگ ایجنٹس کے ساتھ بنی ایپس میں مسائل پیدا ہوتے ہیں۔ اسے ٹھیک کرنے کے لیے کسی مشیر سے پوچھیں۔ یہ اسے "ٹھیک” کرتا ہے۔ لیکن بگ اب بھی موجود ہے یا دوسرا بگ ظاہر ہوتا ہے۔

تو آپ کہتے ہیں، "یہ ابھی کام نہیں کرتا ہے۔” ایجنٹ دوبارہ کوشش کرے گا۔ 20 منٹ کے بعد، آپ کے پاس زیادہ ٹوٹا ہوا کوڈ، کم کریڈٹ، اور کام پر واپس جانے کا کوئی واضح راستہ نہیں ہے۔

لوگ اسے ایسے فقروں کے ساتھ تلاش کرتے ہیں جیسے "AI مسلسل کیڑے خراب کرتا ہے” یا "Agent is stuck in a fix loop.” یہ صرف ایک مصنوعات کی خصوصیت نہیں ہے۔ لوویبل، ریپلٹ، کرسر، کلاڈ کوڈ، بیس 44 اور اسی طرح کے ٹولز سب ایک ہی پیٹرن میں آتے ہیں کیونکہ ان کی ناکامیاں ساختی ہیں۔

یہ ٹیوٹوریل بتاتا ہے کہ لوپس کیوں ہوتے ہیں اور مخصوص ترتیب فراہم کرتا ہے جسے آپ ٹول میں لوپس کو توڑنے کے لیے استعمال کر سکتے ہیں۔

یہاں ہم کیا احاطہ کریں گے:

جو آپ سیکھیں گے۔

• AI اصلاحی لوپس کو جلد پہچاننے کا طریقہ

• مبہم دوبارہ کوششیں کیوں اگلی کوشش کو بدتر بناتی ہیں۔

• روکنے، واپس لوٹنے، دوبارہ درست کرنے، الگ کرنے اور تصدیق کرنے کے لیے پانچ قدمی ترتیب

• ایک فکس پرامپٹ کیسے لکھیں جو آپ کے ایجنٹ کے کامیاب ہونے کے لیے کافی معلومات فراہم کرے۔

شرطیں

آپ کو ایک پیشہ ور انجینئر بننے کی ضرورت نہیں ہے۔ لیکن آپ کے پاس ہونا ضروری ہے:

• اے آئی کوڈنگ ایجنٹس (جیسے کرسر، کلاڈ کوڈ، ریپلٹ ایجنٹ، پیارے، وغیرہ) کا استعمال کرتے ہوئے بنائے جانے والے ایپس

• غلط تبدیلیوں کو کالعدم کرنے کے لیے ورژن کی سرگزشت، چیک پوائنٹس، یا Git تک رسائی حاصل کریں۔

• ایپ کو کیسے چلائیں یا اس کا براہ راست جائزہ لیں (براؤزر کا پیش نظارہ، مقامی سرور، تعینات یو آر ایل)

ایک ترمیم شدہ لوپ کیسا لگتا ہے۔

مصنوعات کی برانڈنگ کو ہٹانا یقینی بناتا ہے کہ لوپ ہر جگہ ایک جیسا نظر آئے۔

1. آپ جس ایپ کو چلا رہے ہیں اس میں ایک مسئلہ ہے۔

2. ایجنٹ سے ایک مختصر پیغام ("یہ ٹوٹ گیا ہے”، "براہ کرم دوبارہ کوشش کریں” یا ایک کلک "اسے ٹھیک کرنے کی کوشش کریں”) کے ساتھ مسئلہ حل کرنے کو کہیں۔

3. ایجنٹ ایسی تبدیلیاں کرتے ہیں جو پر اعتماد دکھائی دیتی ہیں۔

4. یا تو اصل مسئلہ باقی رہ جاتا ہے یا پھر محلے والے رکاوٹ بن جاتے ہیں۔

5. اسی طرح کے مبہم تاثرات کے ساتھ دوبارہ کوشش کریں۔

6. ہر ناکام کوشش کو گفتگو کے سیاق و سباق میں برقرار رکھا جاتا ہے، اس لیے بعد کی کوششیں شور پیدا کریں گی۔

مختلف ٹولز اسے مختلف UIs کے سامنے لاتے ہیں۔ کچھ کے پاس لفظی طور پر دوبارہ کوشش کرنے کا بٹن ہوتا ہے۔ کچھ لوگ "خیالات” پر لٹ جاتے ہیں۔ کچھ خاموشی سے وہ تبدیلیاں جو وہ پہلے ہی دیکھ چکے ہیں۔ سطحیں مختلف ہیں، لیکن میکانزم نہیں ہیں۔

لوپس کیوں ہوتے ہیں۔

چار قوتیں تقریباً اس ترتیب میں یکجا ہیں:

1. جیسے جیسے سیشن بڑھتے ہیں، سیاق و سباق میں کمی آتی ہے۔

ہر پیغام، فرق، اور "نہیں، وہ نہیں” ٹوکن میں شامل کیا جاتا ہے جسے ایجنٹ کے پاس رکھنا ضروری ہے۔ سیشن کے آغاز میں، ایجنٹ کا ایپ ماڈل نسبتاً واضح ہے۔ 20 تبادلوں کے بعد، یہ غلط موڑ سمیت ہر چیز کی دھندلی اوسط کی بنیاد پر کام کرتا ہے۔

2. مبہم دوبارہ کوششیں معلومات کے بجائے شور ڈالتی ہیں۔

"یہ اب بھی ٹوٹا ہوا ہے۔” "دوبارہ کوشش کریں۔” "یہ بات نہیں ہے۔” یہ آپ کے تاثرات کی طرح محسوس ہوتا ہے۔ ایجنٹوں کے لیے، رہنمائی چند نئے سگنل پیش کرتی ہے۔ وہ یہ نہیں کہتے کہ ابھی تک کیا خراب ہے، کون سی فائلیں شامل ہیں، یا "درست” کیا ہے۔

ایجنٹ عام طور پر اپنے سابقہ ​​اندازے کو تھوڑا سا تبدیل کرتے ہیں۔ یہی وجہ ہے کہ لوپس اکثر بدلنے کی بجائے دو تقریباً ایک جیسی غلط اصلاحات کے درمیان متبادل ہوتے ہیں۔

3. ایجنٹ آپ کی ایپ کو اس طرح نہیں دیکھ سکتے جس طرح آپ دیکھ سکتے ہیں۔

آپ پیش کردہ صفحہ کو دیکھ رہے ہیں اور بہاؤ پر کلک کر رہے ہیں۔ ایجنٹ آپ نے جو کچھ دیکھا ہے اس کے کوڈ اور متنی وضاحتوں کا اندازہ لگا رہا ہے۔

UI بگز کو الفاظ میں بیان کرنا نقصان ہے۔ اگر تفصیل اور اصل UI مماثل نہیں ہیں، تو ایجنٹ غلط مسئلے کے لیے قابل فہم حل کے لیے بہتر بناتا ہے۔

4. ایک ناکام کوشش اگلی کوشش کو روکتی ہے۔

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

خلاصہ یہ کہ، طویل سیشن درستگی کو کم کرتے ہیں کیونکہ پیغامات بالکل اسی وقت مبہم ہو جاتے ہیں جب ایجنٹوں کو سب سے زیادہ واضح، مخصوص سگنلز کی ضرورت ہوتی ہے۔

شیطانی چکر کو کیسے توڑا جائے۔

اس قدم کے لیے تبادلوں کے ٹولز کی ضرورت نہیں ہے۔ وہ میکانزم کو نشانہ بناتے ہیں۔

مرحلہ 1: لوپ سپلائی بند کریں۔

"براہ کرم دوبارہ کوشش کریں” یا "یہ ابھی تک ٹوٹا ہوا ہے” کے پیغامات لگاتار دو بار مت بھیجیں۔ مسئلہ یہ ہے کہ اگر پہلی دوبارہ کوشش ناکام ہوجاتی ہے، تو ایجنٹ کو ایک اور اندھی کوشش کرنی ہوگی۔ آپ کی ہدایات میں آپ کا جواب تبدیل کرنے کے لیے کافی معلومات نہیں ہیں۔ تیسرا، کم معلوماتی اشارہ صرف مزید شور پیدا کرتا ہے۔

اگر آپ وہی شکایت دوبارہ درج کرنے کی کوشش کر رہے ہیں، تو براہ کرم ٹائپ کرنا بند کر دیں۔ مرحلہ 2 پر جائیں۔

مرحلہ 2: آخری معلوم اچھی حالت پر واپس جائیں۔

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

ہر وہ چیز استعمال کریں جو اس آلے کو پیش کرنا ہے۔

• خوش ہونا: git checkout -- path/to/file یا git restoreیا ایک قابل اعتماد کمٹ پر دوبارہ سیٹ کریں۔

• کرسر/سیڈو IDE: مقامی تاریخ یا فائلوں کی ٹائم لائن

• Replit، پیارا اور اسی طرح کے بلڈرز: چیک پوائنٹ یا ورژن کی تاریخ اور پھر آخری اچھی حالت میں بحال کریں۔

ایپ کے قابل شناخت حالت میں واپس آنے کے بعد ہی آپ کو ترمیم کی نئی درخواست داخل کرنی چاہیے۔

مرحلہ 3: درست دائرہ کار کا استعمال کرتے ہوئے شروع سے مسئلہ کو دوبارہ بیان کریں۔

یہ سب سے زیادہ بیعانہ اقدام ہے۔ اگر آپ کا ٹول اجازت دیتا ہے تو نئی بات چیت یا کلین تھریڈز کو ترجیح دیں۔ ایک پرامپٹ لکھیں جس میں درج ذیل تینوں شامل ہوں:

1. عین مطابق فائل یا جزو کا نام (لفظی راستہ، بصری وضاحت نہیں)

2. ایک ٹھوس قابل مشاہدہ حقیقت کے طور پر، مسئلہ کیا ہے؟

3. "صحیح چیز” کیسی دکھتی ہے اس کے بارے میں یکساں طور پر مخصوص رہیں۔

کمزور اشارہ:

یہ اب بھی ٹوٹا ہوا ہے۔ براہ کرم اپنا جمع کروائیں بٹن ٹھیک کریں۔

طاقتور اشارہ:

میں CheckoutForm.tsxجمع کرانے کے بٹن پر کال کریں۔ handleSubmitتاہم، اگر درخواست ناکام ہوجاتی ہے تو لوڈ کی حالت دوبارہ ترتیب نہیں دی جاتی ہے۔ ایک ناکام جمع کرانے کے بعد، بٹن غیر فعال رہتا ہے اور کوئی غلطی کا پیغام ظاہر نہیں ہوتا ہے۔ اسے دوبارہ فعال کر دیا جائے گا اور بٹن کے نیچے سرور کی خرابی کا سٹرنگ دکھایا جائے گا۔

دوسرا پرامپٹ ایجنٹ کو فائل، کارروائی اور کامیابی کے حالات فراہم کرتا ہے۔ اندازہ لگائے بغیر عمل کرنے کے لیے کافی ہے۔

مرحلہ 4: ایک وقت میں ایک تبدیلی کریں۔

اپنے بگ فکس پیغام میں "براہ کرم ہیڈرز کو بھی ٹھیک کریں جب آپ اس پر ہوں” شامل نہ کریں۔ یہ ایجنٹوں کو ایک سیاق و سباق کے بجٹ کے ساتھ دو مسائل پیش کرتا ہے۔ اگر آپ مسئلہ A کو صاف طور پر حل کرتے ہیں، تو مسئلہ B خاموشی سے دوبارہ پیدا ہو سکتا ہے۔

اپنا ٹھیک بھیجیں۔ اسے چیک کریں۔ پھر اگلے شمارے کے لیے علیحدہ درخواست جمع کروائیں۔

مرحلہ 5: اصل ایپ سے چیک کریں، نہ کہ ایجنٹ کیا کہتا ہے۔

چونکہ ایجنٹ اپنے استدلال کی جانچ کر رہے ہیں، نہ کہ چلنے والی مصنوعات کی، انہیں یقین ہے کہ ان کی اصلاحات کام کرتی ہیں اور اکثر غلط ہوتی ہیں۔

لوپ کو بند کرنے سے پہلے:

1. براہ کرم پیش منظر کو ریفریش کریں یا صفحہ کو دوبارہ لوڈ کریں۔

2. ناکام ہونے والے حقیقی صارف کے بہاؤ پر کلک کریں۔

3. اگر بگ ڈیٹا یا API کے بارے میں ہے، تو ڈیٹا بیس کی قطاریں، نیٹ ورک ٹیبز، اور لاگز کو چیک کریں۔

4. کامیابی کے جو حالات آپ نے مرحلہ 3 میں بنائے ہیں ان کو چیک کریں۔

تبھی کیس کو بند سمجھیں۔

مکمل واک تھرو: ڈبل بلنگ

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

ایجنٹ کا لکھا ہوا کوڈ:

// checkout.js
export function createCheckout({ chargeCard, saveOrder }) {
  async function handleCheckout(req) {
    const { cartId, amount } = req.body;

    const charge = await chargeCard(amount);
    const order = await saveOrder({ cartId, chargeId: charge.id, amount });

    return { status: 201, body: { orderId: order.id } };
  }

  return { handleCheckout };
}

جب براؤزر کا وقت ختم ہو جاتا ہے اور صارف دوبارہ "ادائیگی” پر کلک کرتا ہے، تو سرور چلتا ہے۔ handleCheckout دوسرا، اپنا کارڈ ری چارج کریں۔

لوپ

ایجنٹ سے کہو، "گاہک کو دو بار بل دیا جا رہا ہے۔ براہ کرم اسے ٹھیک کریں۔”

1 کی کوشش کریں۔ ایجنٹ آپ سے چارج لینے سے پہلے آپ کے موجودہ آرڈر کی تصدیق کرے گا۔

const existing = await findOrder(cartId);
if (existing) {
  return { status: 200, body: { orderId: existing.id } };
}

چند سیکنڈ کے علاوہ ادائیگی کریں پر ڈبل کلک کر کے ٹیسٹ کریں۔ یہ کام کرتا ہے۔ تاہم، اگر دونوں درخواستیں ایک ہی وقت میں پہنچیں تو یہ کام نہیں کرتا۔ اس کی وجہ یہ ہے کہ جب دوسری درخواست کی تصدیق ہوتی ہے تو کسی بھی درخواست نے ابھی تک آرڈر کو محفوظ نہیں کیا ہے۔ "میں اب بھی کبھی کبھی ڈبل چارجز دیکھ رہا ہوں،” آپ نے رپورٹ کیا۔

کوشش 2۔ ایجنٹ پہلے کلک کے بعد ادائیگی کے بٹن کو غیر فعال کر دیتا ہے۔ چونکہ یہ کلائنٹ کی طرف سے تبدیلی ہے، اس لیے یہ وقت ختم ہونے والی درخواستوں یا دوسرے براؤزر ٹیب کی وجہ سے دوبارہ کوششوں کو نہیں روک سکتا۔ آپ نے اطلاع دی کہ "یہ اب بھی ہو رہا ہے۔”

کوشش 3۔ ایجنٹ آپ کے دعوے کو حتمی شکل دے گا۔ try/catch اگر کوئی غلطی ہوتی ہے، تو یہ ایک دوستانہ پیغام لوٹاتا ہے۔ بگ اب پرسکون ہے، لیکن میرا کارڈ اب بھی دو بار چارج ہو جاتا ہے۔ یہ روکنے کا نقطہ ہے۔

مرحلہ 1 اور 2: رکیں اور واپس جائیں۔

براہ کرم چوتھا "ابھی تک ٹوٹا ہوا” پیغام نہ بھیجیں۔ اصل کو بحال کریں۔ checkout.js گٹ میں (git restore checkout.js) تو آپ 4 کی بجائے 1 بگ کو ڈیبگ کر رہے ہیں۔

مرحلہ 3: درست کرنے کی درخواست کرنے سے پہلے ایک ناکام ٹیسٹ لکھیں۔

سب سے مفید بیان جو آپ اپنے ایجنٹ کو دے سکتے ہیں وہ ایک ٹیسٹ ہے جو صحیح وجوہات کی بناء پر ناکام ہوتا ہے۔ یہاں تین ٹیسٹ ہیں: پہلے دو بگ کی وضاحت کرتے ہیں اور تیسرا معمول کے رویے کی حفاظت کرتا ہے۔

// checkout.test.js
import { test } from "node:test";
import assert from "node:assert/strict";
import { createCheckout } from "./checkout.js";
import { createFakes } from "./fakes.js";

const req = (key) => ({
  headers: { "idempotency-key": key },
  body: { cartId: "cart_1", amount: 4900 },
});

test("a retried request charges the card only once", async () => {
  const fakes = createFakes();
  const { handleCheckout } = createCheckout(fakes);

  const first = await handleCheckout(req("key-1"));
  const retry = await handleCheckout(req("key-1")); // client timed out and retried

  assert.equal(fakes.charges.length, 1);
  assert.equal(fakes.orders.length, 1);
  assert.deepEqual(retry.body, first.body);
});

test("two requests sent at the same moment still charge once", async () => {
  const fakes = createFakes();
  const { handleCheckout } = createCheckout(fakes);

  await Promise.all([handleCheckout(req("key-2")), handleCheckout(req("key-2"))]);

  assert.equal(fakes.charges.length, 1);
});

test("different keys are different purchases", async () => {
  const fakes = createFakes();
  const { handleCheckout } = createCheckout(fakes);

  await handleCheckout(req("key-3"));
  await handleCheckout(req("key-4"));

  assert.equal(fakes.charges.length, 2);
});

ٹیسٹ ملی سیکنڈ میں چلتے ہیں کیونکہ وہ ادائیگی فراہم کرنے والے اور ڈیٹا بیس کے لیے میموری میں موجود چھوٹے جعلی استعمال کرتے ہیں۔

// fakes.js
export function createFakes() {
  const charges = [];
  const orders = [];

  return {
    charges,
    orders,
    async chargeCard(amount) {
      await new Promise((r) => setTimeout(r, 10)); // simulate a slow provider
      const charge = { id: `ch_\${charges.length + 1}`, amount };
      charges.push(charge);
      return charge;
    },
    async saveOrder(data) {
      const order = { id: `ord_\${orders.length + 1}`, ...data };
      orders.push(order);
      return order;
    },
  };
}

چلائیں node --test. پہلے دو ٹیسٹ ناکام ہوئے اور یہ ایک بگ کا ثبوت ہے۔

not ok 1 - a retried request charges the card only once
not ok 2 - two requests sent at the same moment still charge once
ok 3 - different keys are different purchases

دوسرا ٹیسٹ بالکل وہی بیان کرتا ہے جو 1 چھوٹ گئے تھے۔ ایجنٹ کیسز نہیں دیکھ سکتے، لیکن ٹیسٹ کر سکتے ہیں۔

مرحلہ 3 اور 4: ایجنٹوں کو درست اشارے دینے کے لیے ایک تبدیلی کریں۔

ایک نئی چیٹ شروع کریں اور درج ذیل کو پیسٹ کریں:

میں checkout.js، handleCheckout چونکہ ہر بار کال کرنے پر کارڈ چارج کیا جاتا ہے، اس لیے صارف صارف کو دو بار دوبارہ چارج کرنا چاہتا ہے۔ اس کا استعمال کرکے اسے کمزور بنائیں: Idempotency-Key درخواست ہیڈر: یہاں تک کہ اگر ایک ہی کلید کے ساتھ دو درخواستیں ایک ہی وقت میں آتی ہیں، ایک ہی کلید کے نتیجے میں ایک چارج اور ایک آرڈر ہونا چاہیے، اور انہیں ایک ہی جوابی باڈی واپس کرنی چاہیے۔ کلید کے بغیر درخواست کو اسٹیٹس 400 لوٹنا چاہیے۔ اسے تبدیل نہ کریں۔ fakes.js یا ٹیسٹ۔ چلائیں node --test براہ کرم مجھے آؤٹ پٹ دکھائیں۔

یہ پرامپٹ فائل اور فنکشن کا نام دیتا ہے، غلط اور درست رویے کی وضاحت کرتا ہے، سمورتی کیسز شامل کرتا ہے، اور ایک تبدیلی کی درخواست کرتا ہے۔

ٹھیک کرتا ہے۔

// checkout.js
export function createCheckout({ chargeCard, saveOrder }) {
  const requests = new Map(); // idempotency key -> Promise of the response

  async function process(req) {
    const { cartId, amount } = req.body;

    const charge = await chargeCard(amount);
    const order = await saveOrder({ cartId, chargeId: charge.id, amount });

    return { status: 201, body: { orderId: order.id } };
  }

  async function handleCheckout(req) {
    const key = req.headers["idempotency-key"];
    if (!key) {
      return { status: 400, body: { error: "Idempotency-Key header is required" } };
    }

    if (!requests.has(key)) {
      const promise = process(req);
      requests.set(key, promise);
      promise.catch(() => requests.delete(key)); // a failed attempt may be retried
    }

    return requests.get(key);
  }

  return { handleCheckout };
}

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

مرحلہ 5: تصدیق کریں۔

ok 1 - a retried request charges the card only once
ok 2 - two requests sent at the same moment still charge once
ok 3 - different keys are different purchases
# tests 3
# pass 3
# fail 0

اس کے بعد اصل صورتحال کو بھی چیک کریں۔ ایک ہی درخواست دو بار بھیجیں۔ curl اور ایک ہی Idempotency-Keyکلک کریں اور دیکھیں کہ آیا آپ کو اپنے ادائیگی فراہم کنندہ کے ڈیش بورڈ میں ایک چارج نظر آتا ہے۔

ایک انتباہ: یہ ورژن کلید کو میموری میں رکھتا ہے، لہذا یہ صرف ایک سرور کے عمل کی حفاظت کرتا ہے۔ پیداوار میں، ایک ڈیٹا بیس یا Redis میں میعاد ختم ہونے والی چابیاں اسٹور کریں۔ چونکہ ٹیسٹ میں کوئی تبدیلی نہیں آئے گی، آپ ایجنٹ سے اگلی بار ایک علیحدہ درخواست میں یہ تبدیلی کرنے کے لیے کہہ سکتے ہیں۔

ورزش سے کیا پتہ چلتا ہے۔

ترمیم بذات خود 12 لائنوں کی تھی۔ یہ زیادہ ہوشیار اشارہ نہیں تھا جس نے لوپ کو توڑ دیا۔ ناکام ہونے والے ٹیسٹ نے "بعض اوقات دو بار چارج کرنے” کو اس نتیجے میں بدل دیا کہ ایجنٹ تمام مبہم دوبارہ کوششوں میں چھوٹ جانے والے کیسوں کو پڑھ سکتا ہے اور پکڑ سکتا ہے۔

دوبارہ قابل استعمال چیک لسٹ

اگلے ایونٹ کے لیے اسے کاپی کریں:

• [ ] ایک ناکام مبہم دوبارہ کوشش کے بعد روک دیا گیا۔

• [ ] معلوم اچھی حالت میں واپس آیا۔

• [ ] آپ نے درست فائل یا اجزاء کا نام بتا دیا ہے۔

• [ ] میں نے غلط کام کو ایک قابل مشاہدہ حقیقت کے طور پر بیان کیا۔

• [ ] میں نے صحیح رویے کو ایک قابل مشاہدہ حقیقت کے طور پر بیان کیا ہے۔

• [ ] میں نے ان سے صرف ایک چیز بدلنے کو کہا۔

• [ ] میں نے اسے براہ راست اصل UI/data/log میں چیک کیا۔

نتیجہ

AI کوڈنگ ایجنٹ آپ کی ایپ کا پہلا ورژن بنانے کے لیے طاقتور ہیں۔ ٹھیک کرنے کی اچھی درخواستوں کے لیے درستگی کی ضرورت ہوتی ہے کہ مایوس کن "ابھی تک ٹوٹا ہوا” مواد بیان نہیں کر سکتا، اور اس کو دہرانا مشکل ہے کیونکہ ایجنٹ اسکرین کو اس طرح نہیں دیکھ سکتے جس طرح آپ اسے دیکھتے ہیں۔

اصلاحی لوپ اس بات کا ثبوت نہیں ہے کہ آپ گہری سطح پر "آل کو غلط استعمال کر رہے ہیں”۔ یہ اس بات کی علامت ہے کہ پرامپٹ کو "دوبارہ کوشش کریں” سے زیادہ معلومات درکار ہیں۔

اگلی بار آپ کے پاس بغیر لینڈنگ کے مسئلے کو حل کرنے کی تین کوششیں ہوں گی۔ درست دائرہ کار کا استعمال کرتے ہوئے شروع سے روکیں، واپس کریں اور دوبارہ بیان کریں۔ یہ سب سے پہلے سست محسوس ہوتا ہے. لیکن یہ ایک لوپ سے زیادہ تیز ہے۔

اگر آپ مخصوص ٹولز میں اس پیٹرن کا مختصر فیلڈ گائیڈ ورژن چاہتے ہیں، تو میں نے Vibe Coder Daily پر ایک عملی مضمون بھی شائع کیا ہے۔