Paperclip کے ساتھ خود پھیلنے والی افرادی قوت: 90 منٹ کا فوری کورس
ایک ایسی افرادی قوت لیں جو صرف وہی کام کر سکتی ہے جو آپ نے ترتیب دیے، اور اسے سکھائیں کہ وہ آپ کے تحت اپنی مدد کے لیے خود بھرتی کرے۔
پچھلے کورس میں آپ نے ایک کمپنی کھڑی کی اور ایک مقررہ ٹیم چلائی: آپ نے Workers بھرتی کیے، انہوں نے وہ کام سنبھالا جو آپ کو پہلے سے نظر آ رہا تھا، اور آپ board بنے رہے۔ یہ کورس وہ ایک چیز شامل کرتا ہے جو وہ کمپنی نہیں کر سکتی تھی، یعنی خود کو بڑھانا۔
نئی طاقت بیان کرنے میں چھوٹی ہے۔ جب ایسا کام سامنے آتا ہے جسے آپ کی ٹیم میں سے کوئی نہیں سنبھال سکتا، تو آپ کی کمپنی اسے پہچانتی ہے، اس کے لیے کسی نئے فرد کو بھرتی کرنے کی تجویز دیتی ہے، اور اس بھرتی کو منظوری کے لیے آپ کے سامنے لاتی ہے، بالکل اسی طرح جیسے آپ نے اپنے CEO کو منظور کیا تھا۔ آپ board بنے رہتے ہیں۔ بس یہ کمپنی چپکے سے آپ کو ہر اس چیز کا overflow desk بننے سے روک دیتی ہے جس کا اس نے منصوبہ نہیں بنایا تھا۔
یہ رہا پورا سفر، سادہ الفاظ میں:
- نیا کام سامنے آتا ہے جسے آپ کے موجودہ Workers میں سے کوئی نہیں سنبھال سکتا۔
- آپ کی کمپنی اسے بھانپ لیتی ہے، اسے سنبھالنے کے لیے ایک نئی بھرتی کی تجویز دیتی ہے، اور آپ کی ہاں مانگتی ہے۔
- آپ اس بھرتی کو ایک چھوٹا سا بجٹ اور ایک مختصر آزمائش دیتے ہیں، اس پر بھروسہ کرنے سے پہلے۔
- وہ آزمائش میں پاس ہو جاتی ہے، تو آپ اسے تھوڑی اور گنجائش دیتے ہیں، ہمیشہ صرف اتنی جتنی کام کو درکار ہو۔
- جب وہ کام خاموش ہو جاتا ہے تو آپ بھرتی کو روک دیتے ہیں؛ جب وہ واپس آتا ہے تو اسے دوبارہ آن کر دیتے ہیں۔
- ہر قدم لکھا جاتا ہے، تاکہ مہینوں بعد بھی آپ جانتے رہیں کہ کس نے کیا کیا، اور اس پر کتنا خرچ آیا۔
- اور پورا gap-check ایک شیڈول پر چل سکتا ہے، تاکہ کمپنی خود اپنے خلا تلاش کرے، اور آپ اس کا الارم بجانے والے گھڑیال بننے سے بچ جائیں۔
آپ ایک ایسی کمپنی سے شروع کرتے ہیں جو صرف وہی کر سکتی ہے جو آپ نے ترتیب دیا۔ آپ ایک ایسی کمپنی پر ختم کرتے ہیں جو خود کو بڑھاتی ہے، مگر ہمیشہ صرف آپ کی ہاں کے ساتھ۔ نیچے کے سات منظرنامے یہی سفر ہیں، ایک ایک قدم۔
آخر تک، اپنی بنیادی کمپنی کے اوپر، آپ کے پاس یہ ہوگا: ایک نیا Worker جس کی تجویز آپ کی کمپنی نے دی اور جسے آپ نے آزمائش پر بھرتی کیا، جو آپ کے طے کردہ بجٹ اور permissions کے تحت حقیقی کام کر رہا ہے، جسے آپ نے روکا اور طلب کے بدلتے ہی واپس لایا، اور جس کی تحریری تاریخ اتنی مکمل ہے کہ کل کسی اور کے حوالے کی جا سکے، اور ایک ہفتہ وار routine جو پورا gap-check خود چلاتی ہے تاکہ آپ کو دیکھنا کبھی یاد نہ رکھنا پڑے۔
آپ کا پڑھنے کا راستہ (تقریباً 90 منٹ، بشمول بنیادی سیٹ اپ اور نالج چیک)
ہر منظرنامہ اوپر دیے سفر کا ایک قدم ہے، اور ہر ایک یہ بتاتا ہے کہ جب وہ کام کرے تو آپ کو کیا نظر آنا چاہیے۔
- خلا کو پہچانیں (تقریباً 12 منٹ): کام کے حقیقی ڈھیر کو ایک حقیقی بھرتی سے الگ کر کے دیکھیں۔
- بھرتی کو لکھ لیں (تقریباً 10 منٹ): خلا کو ایک job rec میں بدلیں جسے آپ کا agent تیار کرتا ہے اور آپ پڑھتے ہیں۔
- منظوری دیں، کم سے کم طاقت کے ساتھ (تقریباً 12 منٹ): وہی board gate جو آپ پہلے ہی استعمال کرتے ہیں، اور یہ فرق کہ کوئی Worker کس کام کے لیے ہے بمقابلہ وہ اصل میں کیا کر سکتا ہے۔
- سستے میں ثابت کریں، پھر عطا کریں (تقریباً 12 منٹ): پہلے دن آزمائش کو دیکھیں، اور اختیار صرف تب وسیع کریں جب وہ کمایا جا چکا ہو۔
- روکیں اور دوبارہ چلائیں (تقریباً 8 منٹ): کسی Worker کو کھوئے بغیر ریٹائر کریں، پھر اسے واپس لائیں۔
- وہ ledger جو آپ حوالے کر سکیں (تقریباً 10 منٹ): اپنی کمپنی کی پوری بھرتی کی کہانی اس کے اپنے ریکارڈ سے پڑھیں۔
- اسے ایک تال پر ڈالیں (تقریباً 10 منٹ): gap-review خود چلنے لگتا ہے، بس آپ CEO کو on call لگاتے ہیں اور ایک routine کو شیڈول پر کام بنانے اور CEO کو کرنے کے لیے فون کرنے دیتے ہیں۔
آپ کو چاہیے ہوگا ایک coding agent جس میں آپ logged in ہیں (Claude Code یا OpenCode)، اور یا تو پچھلے کورس والی کمپنی، یا دو منٹ تاکہ پہلا prompt ایک ویسی ہی کمپنی بنا دے۔ نہ کوئی coding، اور نہ کوئی API key: آپ کا agent سب کچھ چلاتا ہے، اور آپ صرف وہ فیصلے کرتے ہیں جو صرف ایک انسان کر سکتا ہے۔
📚 تدریسی مدد
پورا Presentation دیکھیں: Paperclip کے ساتھ خود پھیلنے والی افرادی قوت
یہ کیسے کام کرتا ہے: آپ سمت دیتے ہیں، agent کام کرتا ہے۔ تین کھلاڑی، ایک تال۔ board ہیں آپ، وہ فیصلے کرتے ہوئے جو صرف ایک انسان کر سکتا ہے: ایک بھرتی منظور کرنا، اختیار عطا کرنا، ایک کردار ریٹائر کرنا۔ ہاتھوں والا کام کرتا ہے آپ کا agent (Claude Code یا OpenCode)۔ کمپنی خود ہے Paperclip: یہ آپ کے Workers کو رکھتا ہے، انہیں جگاتا ہے، اور وہ بجٹ اور permissions نافذ کرتا ہے جو آپ طے کرتے ہیں۔ آپ ایک سادہ درخواست paste کرتے ہیں، آپ کا agent ایک منصوبہ تجویز کرتا ہے، آپ منظوری دیتے ہیں، وہ چلتا ہے، اور آپ دونوں نتیجہ جانچتے ہیں۔ یہی آگے پیچھے کی گفتگو پورا کورس ہے۔
آپ ایک چھوٹا folder ڈاؤن لوڈ کرتے ہیں اور اسے اپنے agent میں کھولتے ہیں۔ agent ایک brief (ایک AGENTS.md فائل) پڑھتا ہے جو اسے بھرتی کی lifecycle سکھاتی ہے: خلا کیسے پہچاننا ہے، آپ کے approval gate سے بھرتی کیسے داخل کرنی ہے، کسی Worker کی اصل permissions کیسے طے کرنی ہیں، اسے کیسے چلانا ہے، اور ledger کیسے پڑھنا ہے۔ آپ کبھی کسی command کو ہاتھ نہیں لگاتے؛ آپ فیصلے کرتے ہیں۔
dynamic-workforce-base.zip ڈاؤن لوڈ کریں
اسے اپنے agent میں کھولیں اور تصدیق کریں کہ brief لوڈ ہو گئی ہے:
ایک dynamic Paperclip workforce کے لیے تم میرے لیے کیا کر سکتے ہو؟
اگر جواب بھرتی کے loop کا نام لیتا ہے (خلا پہچاننا، بھرتی داخل کرنا، آپ کا approval gate، کسی Worker کی permissions، talent ledger)، تو آپ تیار ہیں۔ اگر یہ عام AI باتوں جیسا لگے، تو تصدیق کریں کہ آپ dynamic-workforce/ folder کے اندر ہیں اور دوبارہ launch کریں۔
اگر کچھ بھی الٹ ہو جائے، تو آپ کو CLI جاننے کی ضرورت نہیں۔ یہ paste کریں:
کچھ کام نہیں کیا۔
paperclipai doctorچلاؤ، Paperclip server کا تازہ ترین log پڑھو، مجھے سادہ زبان میں بتاؤ کہ تمہیں کیا نظر آ رہا ہے، اور ایک ایسا حل تجویز کرو جسے میں منظور کر سکوں۔
اگر آپ کسی منظرنامے کے مقررہ وقت سے تقریباً دگنے سے آگے نکل جائیں، تو یہ paste کریں: "ہمیں کیا روک رہا ہے، ایک جملے میں؟ آئیے وہیں سے دوبارہ منصوبہ بناتے ہیں۔" جو agent تک بندیاں کر رہا ہوگا وہ بتا دے گا، اور آپ دوبارہ سے شروع کر سکتے ہیں۔
اپنی بنیاد طے کریں (ایک prompt)
dynamic loop کو بڑھنے کے لیے ایک کمپنی چاہیے۔ پچھلے کورس میں آپ نے جس حالت پر چھوڑا تھا اس پر بالکل انحصار کرنے کے بجائے، ایک معلوم بنیاد ایک prompt سے کھڑی کریں۔ یہ idempotent ہے: اگر آپ کے پاس پچھلے کورس والی کمپنی پہلے سے ہے، تو آپ کا agent اسی کو استعمال کرتا ہے اور صرف وہی بھرتا ہے جو کم ہو۔
اس کورس کے لیے میری بنیاد سیٹ اپ کرو۔ یقینی بناؤ کہ Paperclip چل رہا ہے، اور میرے پاس
Northwind نام کی ایک کمپنی ہو جس کا مقصد "ایک ہفتہ وار AI newsletter لانچ کرنا اور 90 دن میں
1,000 subscribers تک پہنچنا" ہو، بیس ڈالر ماہانہ بجٹ ہو، اور کسی بھی نئی بھرتی سے پہلے board کی
منظوری لازمی ہو۔ اس میں پہلے سے دو Workers ہونے چاہئیں، ایک CEO اور ایک CMO جو CEO کو رپورٹ
کرتا ہو، دونوں ایک local agent پر چل رہے ہوں جس میں میں logged in ہوں تاکہ یہ keyless رہے۔ اگر
ان میں سے کچھ پچھلے کورس سے موجود ہو، تو اسے استعمال کرو؛ صرف وہی بناؤ جو کم ہو۔ پھر مجھے
dashboard دکھاؤ جس میں کمپنی اور اس کے دو Workers ہوں۔
تب مکمل جب: dashboard Northwind کو ایک مقصد، ایک بجٹ، بھرتی کا gate آن، اور بالکل دو Workers، ایک CEO اور ایک CMO، کے ساتھ دکھائے۔ یہ آپ کی مقررہ افرادی قوت ہے۔ باقی کورس اسے بڑھاتا ہے۔
منظرنامہ 1: خلا کو پہچانیں (تقریباً 12 منٹ)
آپ کی بنیادی ٹیم وہ کام سنبھالتی ہے جو آپ کو پہلے سے نظر آ رہا تھا: CEO حکمتِ عملی طے کرتا ہے، CMO newsletter لکھتا اور growth چلاتا ہے۔ پھر newsletter چل نکلتا ہے، اور نئے قسم کے کام سامنے آتے ہیں جن کا ٹیم میں کوئی مالک نہیں۔ ان میں سے تین بیک وقت آ پہنچتے ہیں:
- Reader support جمع ہونے لگتی ہے: ٹوٹے ہوئے signup links، "میرا issue کہاں ہے،" "براہِ مہربانی میرا email بدل دیں،" اور کبھی کبھار کوئی billing یا refund کا سوال۔ آپ کا CMO ایک marketer ہے، support desk نہیں، اور ان میں سے کوئی بھی حکمتِ عملی نہیں، تو یہ آپ پر آ گرتا ہے۔
- اعداد و شمار کوئی نہیں پڑھ رہا۔ کون سے موضوعات واقعی subscribers جیتتے ہیں، لوگ کیوں unsubscribe کرتے ہیں، open rate آپ کو کیا بتا رہا ہے۔ آپ کا CEO اندازے سے سمت دے رہا ہے کیونکہ ڈیٹا کا کوئی مالک نہیں۔
- issue کو دراصل بھیجنے کا کوئی مالک نہیں۔ اسے format کرنا، schedule کرنا، email tool سے بھیجنا، bounces سنبھالنا۔ CMO اسے لکھتا ہے؛ اسے باہر بھیجنا ہر ہفتے فی البدیہہ ہوتا ہے۔
ایک ایسی افرادی قوت جو بھرتی نہیں کر سکتی، چپکے سے آپ کو ہر اس چیز کا overflow desk بنا دیتی ہے جس کا اس نے منصوبہ نہیں بنایا تھا، اور newsletter جتنا بہتر چلتا ہے، اتنا ہی زیادہ یہ سب آتا ہے۔
یہ رہا وہ ایک خیال جس پر پورا کورس سوار ہے:
جب افرادی قوت کسی ایسے کام سے ٹکراتی ہے جسے وہ نہیں سنبھال سکتی، تو وہ اسے آپ پر نہیں ڈالتی۔ آپ کا agent خلا کو پہچانتا ہے، ایک بھرتی کا مسودہ بناتا ہے، اور اس بھرتی کو ایک اور board منظوری کے طور پر آپ کے سامنے لاتا ہے، وہی APPROVE یا REJECT جو آپ پہلے ہی CEO اور حکمتِ عملی کے لیے استعمال کر چکے ہیں۔ بھرتی ایک function call بن جاتی ہے، اور آپ gate بنے رہتے ہیں۔
اس تصویر میں دو فیصلے ہی اصل سبق ہیں، اور دونوں رائے کا معاملہ ہیں، بٹن نہیں۔
پہلا، کیا یہ واقعی ایک خلا ہے؟ ایک حقیقی خلا تین signals کی صورت میں سامنے آتا ہے، اور آپ کو ان میں سے کم از کم دو چاہئیں:
- کوئی کردار اسے cover نہیں کرتا۔ کام کسی Worker کے کام یا skills سے میل نہیں کھاتا۔
- یہ آتا رہتا ہے، اور بڑھ رہا ہے۔ کوئی اکا دکا واقعہ نہیں؛ مقدار چڑھ رہی ہے، کوئی ایسی پتلی دھار نہیں جسے آپ نظرانداز کر سکیں۔
- جب کوئی اسے کرتا ہے، تو یہ غلط واپس آتا ہے۔ کوئی Worker ہاتھ ڈالتا ہے اور نتیجہ بے ڈھنگا ہوتا ہے، یا اسے واپس لوٹا دیا جاتا ہے۔
دوسرا، حتیٰ کہ ایک حقیقی خلا بھی خودبخود بھرتی نہیں۔ یہ وہ حصہ ہے جو نوآموز چھوڑ جاتے ہیں۔ ایک مستقل Worker ایک مستقل خرچ ہے، تو ایک خلا آپ کو ایک فیصلہ کماتا ہے، نئی تنخواہ نہیں۔ آپ چار میں سے ایک چنتے ہیں:
- HIRE: دیرپا، مشن کے مطابق، اور یا تو اتنا high-volume یا اتنا خطرناک کہ اسے ایک مستقل، نگرانی شدہ مالک چاہیے۔
- ESCALATE: نتیجہ خیز یا شاذ، تو کسی انسان کو بس فیصلہ کر دینا چاہیے۔ اگر کوئی reader قانونی دھمکی بھیجے یا اپنے بینک سے کسی charge پر تنازع کھڑا کرے، تو یہ کوئی نیا desk بنانے کا معاملہ نہیں؛ یہ ایک واحد، high-stakes فیصلہ ہے جسے آپ سیدھا کسی انسان کو بھیج دیتے ہیں۔
- QUEUE: موسمی، اچانک ابھرنے والا، یا بس قطار میں اگلا، تو اسے بیک وقت staff کرنا غلطی ہے۔
- DECLINE: مشن سے باہر، یا حقیقی مگر ابھی کسی مستقل خرچ کے لائق نہیں۔
تین امیدوار، تین جواب
آپ کے پاس ایک خلا نہیں، تین ہیں، اور یہی راہیں تین حقیقی ضرورتوں کو چپکے سے تین ماہانہ تنخواہیں بننے سے روکتی ہیں۔
| خلا | آپ کو کیا نظر آتا ہے | راہ | یہ راہ کیوں |
|---|---|---|---|
| Reader support | کوئی کردار اس کا مالک نہیں؛ بار بار آتا اور بڑھتا ہے | HIRE | یہ refunds اور accounts کو چھوتا ہے، تو خطرے کو ایک نگرانی شدہ مالک چاہیے |
| issue بھیجنا | کوئی کردار اس کا مالک نہیں؛ ہر ہفتے دہراتا ہے | QUEUE | اتنا ہی حقیقی، مگر آپ ایک وقت میں ایک کردار staff کرتے ہیں؛ یہ اگلی بھرتی ہے |
| اعداد و شمار پڑھنا | کوئی کردار اس کا مالک نہیں، مگر ڈیٹا ابھی کم ہے | ابھی DECLINE | ایک ہزار subscribers پر ایک analyst ابھی اپنی لاگت نہیں کما سکتا |
آپ ایک بھرتی کرتے ہیں: Reader Support Specialist۔ آپ بھیجنے والے خلا کو لکھ لیتے ہیں تاکہ وہ کھو نہ جائے، اور یہ اگلی بھرتی بن جاتا ہے۔ آپ analyst کو دانستہ DECLINE کرتے ہیں، اس نوٹ کے ساتھ کہ scale پر دوبارہ دیکھیں گے۔ تین حقیقی ضرورتیں، ایک ہاں۔
دو signals کیوں، اور وہ پھندا جو نوآموزوں کو دھوکا دیتا ہے
دو کیوں، اور انہیں آزاد کیوں ہونا چاہیے۔ اکیلا ایک signal کوئی برا ہفتہ یا کوئی نرالی بات ہو سکتی ہے۔ اصول تین میں سے دو کا ہے، اور یہ صرف اس لیے کام کرتا ہے کہ تینوں واقعی الگ الگ چیزیں ہیں، تو ان میں سے دو کا متفق ہونا حقیقی ثبوت ہوتا ہے، نہ کہ ایک ہی بات کو دو بار گننا۔ ایک ایسے جاسوس کا سوچیں جو دو غیر متعلق گواہ چاہتا ہے، نہ کہ ایک ہی شخص اپنی بات دہراتا ہوا۔
پھندا۔ فرض کریں support کی mail واضح طور پر بڑھ رہی ہے، تو دوسرا signal چل پڑتا ہے، اور یہ ایک ظاہر سی بھرتی لگتی ہے۔ اب باقی دو کو جانچیں۔ اگر آپ کی ٹیم میں کوئی چپکے سے وہ tickets جواب دے رہا تھا اور انہیں ٹھیک سنبھال رہا تھا، تو ایک کردار اس کام کو cover کرتا ہے، تو پہلا signal نہیں چلتا، اور کام غلط واپس نہیں آ رہا، تو تیسرا بھی نہیں چلتا۔ یہ ایک signal ہے، دو نہیں۔ آپ کے پاس کوئی capability gap نہیں، آپ کے پاس ایک routing کا مسئلہ ہے: کام صرف اس لیے جمع ہوتا ہے کہ کسی نے طے نہیں کیا کہ اسے کون سنبھالے۔ وہاں ایک Worker بھرتی کریں تو آپ نے ایک گم شدہ assignment کو cover کرنے کے لیے headcount خرید لیا، اور آپ اس کی قیمت ہر مہینے ادا کرتے ہیں۔ (آپ کی اصل Northwind ٹیم میں CMO support کا مالک نہیں، اسی لیے support وہ اصل خلا ہے جس کے لیے آپ نیچے بھرتی کرتے ہیں۔)
اسے کریں: خلاؤں کو حقیقی بنائیں، پھر ان کی triage کریں
ایک خلا جس کے بارے میں آپ صرف پڑھتے ہیں، خلا نہیں۔ اصل چیز کا تھوڑا سا بیج بوئیں، پھر اپنے agent سے اسے اپنی اصل ٹیم کے سامنے پرکھوائیں۔
میرے Northwind board پر چند حقیقی نئے کام کھولو: reader support کے تین سوال (ایک ٹوٹا link،
ایک "میرا email بدل دو" کی درخواست، اور ایک refund کی درخواست)، ایک نوٹ کہ کوئی track نہیں کرتا
کہ کون سے موضوعات convert کرتے ہیں، اور ایک نوٹ کہ ہفتہ وار issue بھیجنے کا کوئی مالک نہیں۔ ہر
ایک کو میرے موجودہ Workers کے سامنے تین signals کے حساب سے پرکھو، اور ہر ایک کی راہ بتاؤ، وجہ کے
ساتھ۔ پھر support کے خلا کو ثبوت کے ساتھ ایک ہی "Capability gap: reader support" issue کے طور
پر ریکارڈ کرو۔
تب مکمل جب: آپ کے board پر ایک "Capability gap: reader support" issue موجود ہو، آپ کے agent نے آپ کو دکھا دیا ہو کہ تین میں سے کون سے دو signals اس کے لیے درست ہیں، اور آپ ایک جملے میں کہہ سکیں کہ support کیوں HIRE ہے جبکہ issue بھیجنا QUEUE اور analytics ابھی DECLINE۔
منظرنامہ 2: بھرتی کو لکھ لیں (تقریباً 10 منٹ)
کسی کے شامل ہونے سے پہلے، آپ کا agent بھرتی کو ایک ٹھوس چیز کے طور پر لکھ لیتا ہے، اسی طرح جیسے آپ کوئی کردار کھولنے سے پہلے ایک job rec لکھتے ہیں۔ اس میں تین فیصلے رہتے ہیں، اور یہی پورا منظرنامہ ہیں: کردار کیا ہے، آپ اسے سستے میں کیسے ثابت کریں گے، اور کون سا engine اسے چلائے گا۔
بھرتی دراصل ہے کیا
جب آپ کا agent کوئی بھرتی تجویز کرتا ہے، تو وہ آپ کو امید کا ایک پیراگراف نہیں بھیج رہا ہوتا؛ وہ ایک چھوٹا، منظم فارم بھرتا ہے، وہی جو Paperclip کا hiring system پڑھتا ہے:
- کردار: ایک نام، ایک عہدہ، اور یہ کہ یہ کس کو رپورٹ کرتا ہے (یہاں، ایک Reader Support Specialist جو CEO کو رپورٹ کرتا ہے)
- صلاحیتیں: ایک سادہ تفصیل کہ یہ Worker کس کام کے لیے ہے
- engine: کون سا runtime دراصل اس Worker کو طاقت دیتا ہے
- بجٹ: ایک ماہانہ حد، جو probation کے لیے دانستہ چھوٹی رکھی جاتی ہے
- رسید: source issue، یعنی منظرنامہ 1 والا reader-support خلا جو اس بھرتی کو جواز دیتا ہے
آپ یہ ہاتھ سے نہیں لکھتے۔ آپ کا agent اس کا مسودہ بناتا ہے؛ آپ اسے ایک hiring manager کی طرح پڑھتے ہیں اور وہ خانے بدلتے ہیں جو واقعی آپ کا فیصلہ ہیں: بجٹ، reporting line، کردار کا دائرہ۔ منظرنامہ 3 میں لے جانے کے لیے ایک کھری بات: صلاحیتوں کا متن ایک تفصیل ہے، باڑ نہیں۔ یہ Worker کو بتاتا ہے کہ وہ کس کام کے لیے ہے۔ یہ خود سے اسے کچھ بھی کرنے سے نہیں روکتا۔ اس بات کو تھامے رکھیں۔
آپ work sample پر بھرتی کرتے ہیں، resume پر نہیں
ایک تفصیل ایک دعویٰ ہے۔ آپ کسی مستقل Worker کو محض دعوے پر مقرر نہیں کرتے؛ آپ پہلے اسے سستے میں ثابت کرتے ہیں۔ اور ایک حقیقی پابندی ہے: Paperclip کسی ایسے امیدوار کو نہیں چلا سکتا جو ابھی آپ کی منظوری کا منتظر ہو، تو اسے ثابت کرنے کا کھرا طریقہ ایک probation ہے، یعنی ایک چھوٹے بجٹ پر ایک مختصر آزمائش۔ آپ Worker کو کم سے کم اختیار کے ساتھ لاتے ہیں جو اسے کام کرنے دے، اسے چند حقیقی issues دیتے ہیں، اور اسے کچھ بھی زیادہ عطا کرنے سے پہلے دیکھتے ہیں کہ وہ اصل میں کیا کرتا ہے۔ آپ اسے چند سادہ چیزوں پر اسکور کرتے ہیں: کیا اس نے جواب درست دیا، کیا وہ اپنی حد میں رہا، کیا وہ آپ کی کمپنی کے لیے درست لگا، اور اس پر کتنا خرچ آیا۔
ان میں سے، اپنی حد میں رہنا وہ ایک چیز ہے جس پر آپ کبھی سمجھوتہ نہیں کرتے۔ ایک support Worker جو چپکے سے کوئی refund جاری کر دے، کوئی billing کی تفصیل بدل دے، یا خود سے کوئی account ترمیم کر دے، اس Worker سے بدتر ناکام ہوا ہے جو بس کہہ دے "اس کے لیے کسی انسان کی ضرورت ہے۔" ایک غلط جواب معیار کا مسئلہ ہے؛ اپنی حد سے باہر عمل کرنا گورننس کا مسئلہ ہے، اور گورننس ہی اس پورے کورس کا مقصد ہے۔ اصل باڑ آپ منظرنامہ 3 میں لگاتے ہیں؛ یہاں آپ بس یہ طے کرتے ہیں کہ probation کو کیا ثابت کرنا ہے۔
engine ایک تبادلہ ہے، نئے سرے سے لکھنا نہیں (اور ایک تیز دھار)
وہی بھرتی کئی engines میں سے کسی پر بھی چلتی ہے: ایک local coding agent جس میں آپ پہلے سے logged in ہیں (keyless، تو میٹر پر اس کی لاگت $0، وہی سودا جو پہلے تھا)، یا کوئی hosted runtime جو خود اپنا بل بناتا ہے۔ آپ کا agent چند خانے بدل کر engine بدل دیتا ہے؛ بھرتی کا باقی سب کچھ ویسا کا ویسا رہتا ہے۔ یہی اس بڑے خیال کا بیج ہے جس سے آپ کورس کے آخر میں ملتے ہیں: ترکیب سفر کرتی ہے، رشتہ یہیں رہتا ہے۔
ایک تیز دھار جو آپ کا agent پہلے ہی جانتا ہے: local OpenCode engine کو ایک model کا واضح نام چاہیے، ورنہ یہ ایک ایسے default پر گر جاتا ہے جو بہکتا ہے اور درمیانِ run ناکام ہو سکتا ہے۔ آپ کا agent اسے طے کرتا ہے؛ آپ بس تصدیق کرتے ہیں کہ اس نے کر دیا۔
اسے کریں: خلا کو ایک probation plan والے hire packet میں بدلیں۔
میرے منظرنامہ 1 والے خلا کے لیے Reader Support Specialist کی بھرتی کا مسودہ بناؤ: کردار، یہ کہ
وہ CEO کو رپورٹ کرتا ہے، ایک سادہ صلاحیتوں کی تفصیل، ایک دانستہ چھوٹا probation بجٹ، اور وہ
source issue جس سے یہ جڑتا ہے۔ پھر probation plan لکھو: تین یا چار حقیقی issues جو اسے سنبھالنے
ہوں، اور میں کیا اسکور کر رہا ہوں، جس میں "اپنی حد میں رہتا ہے" وہ ایک چیز ہو جس پر میں سمجھوتہ
نہیں کروں گا۔ اسے ایک local engine پر چلاؤ جس میں میں logged in ہوں تاکہ یہ keyless رہے، اور
model کا واضح نام دو۔ فائل کرنے سے پہلے مجھے پورا packet دکھاؤ۔
تب مکمل جب: آپ کے ہاتھ میں ایک مکمل hire packet ہو، یعنی ایک مسودہ شدہ کردار اور reader-support خلا سے جڑا ایک مختصر probation plan، ایک keyless local engine پر، اور آپ ایک جملے میں کہہ سکیں کہ یہ Worker اصل اختیار کمانے سے پہلے probation کو کیا ثابت کرنا ہے۔
منظرنامہ 3: منظوری دیں، کم سے کم طاقت کے ساتھ (تقریباً 12 منٹ)
منظرنامہ 2 نے ایک امیدوار اور ایک probation plan دیا۔ اب فیصلہ آتا ہے: بھرتی آپ تک کیسے پہنچتی ہے، اور جس لمحے آپ ہاں کہتے ہیں اسے بالکل کتنی طاقت ملتی ہے۔ اس طاقت کے بارے میں ظاہر سا خیال غلط ہے، اور اسے درست کرنا ہی ایسی افرادی قوت چلانے کا دل ہے جو بھرتی کرتی ہے۔
بھرتی وہی gate دوبارہ استعمال کرتی ہے جو آپ کے پاس پہلے سے ہے
آپ کوئی نیا منظوری کا قدم نہیں سیکھتے۔ بھرتی فائل کرنا اسے اسی board-منظوری inbox میں ڈال دیتا ہے جو آپ نے CEO اور حکمتِ عملی کے لیے استعمال کیا تھا۔ یہ pending آتی ہے، اپنے thread پر proposal اور probation plan کے ساتھ، اور آپ وہی تین کام کرتے ہیں جو آپ ہمیشہ کر سکتے تھے: اسے منظور کریں، اسے مسترد کریں، یا تبدیلیوں کے لیے واپس بھیجیں اور اپنے agent کو نظرثانی کر کے دوبارہ جمع کرنے دیں۔ ایک بھرتی بس ایک نئی قسم کی چیز ہے جو ایک ایسے gate پر کھڑی ہے جسے آپ پہلے سے چلاتے ہیں۔ (Paperclip اسے ایک الگ دروازے سے فائل کرتا ہے جسے وہ agent-hire کہتا ہے، جو دانستہ طور پر براہِ راست کسی agent کے بنانے سے الگ رکھا گیا ہے، تاکہ ایک بھرتی کو ہمیشہ آپ سے گزرنا پڑے۔)
الفاظ باڑ نہیں۔ grants ہیں۔
یہ رہا پھندا، اور یہی اس منظرنامے کا پورا مقصد ہے۔ یہ سوچنا پرکشش ہے کہ Worker کا صلاحیتوں کا متن یہ کنٹرول کرتا ہے کہ اسے کیا کرنے کی اجازت ہے، تو ایک احتیاط سے لکھی تفصیل اسے اپنی حد میں رکھتی ہے۔ ایسا نہیں۔ صلاحیتوں کا متن ایک تفصیل ہے: یہ Worker کے رویے کو ڈھالتا ہے، مگر یہ کوئی باڑ نہیں، اور اسے باڑ سمجھنا ہی وہ طریقہ ہے جس سے آپ بعد میں چونک جاتے ہیں۔
اصل باڑ ایک الگ پرت ہے جسے Paperclip server پر نافذ کرتا ہے۔ کسی Worker کا حقیقی اختیار ان واضح permissions کا مجموعہ ہے جو اسے عطا کی گئی ہیں، ہر ایک اس بات تک scoped کہ وہ کس چیز کو چھو سکتی ہے، اور ساتھ ایک per-issue اصول جو اس کے مکمل کیے کام کو landing سے پہلے review سے گزار سکتا ہے۔ تو کسی نئی بھرتی کو محدود کرنا زیادہ احتیاط سے prose لکھنا نہیں ہے؛ یہ صرف وہی permissions عطا کرنا ہے جو اس کے کام کو درکار ہیں، اور اس سے زیادہ کچھ نہیں۔ ایک نئی بھرتی پہلے ہی کم سے کم سے شروع ہوتی ہے: وہ issues اٹھا اور کر سکتی ہے، مگر دوسروں کو بھرتی نہیں کر سکتی اور نہ اپنی حد سے باہر پہنچ سکتی ہے۔ probation پر موجود کسی Worker کے لیے آپ اسے وہیں رکھتے ہیں، ایک چھوٹے بجٹ پر، اور اس کا اختیار صرف تب وسیع کرتے ہیں جب وہ اسے کما لے۔
اسے دو پرتوں کی طرح سوچیں، ایک عمارت کی طرح:
- موٹا gate وہ ایک کمپنی کا سوئچ ہے جو طے کرتا ہے کہ کوئی نئی بھرتی سرے سے آپ کی منظوری کا انتظار کرے یا نہیں۔ آپ نے اسے پچھلے کورس میں چالو کیا تھا: اسے بند رکھیں تو بھرتیاں خود سے شروع ہو جاتی ہیں، اسے آن کریں (جہاں آپ اسے رکھتے ہیں) تو ہر بھرتی آپ کا انتظار کرتی ہے۔ یہ پوری کمپنی کے لیے مرکزی دروازے کی پالیسی ہے۔
- باریک grant وہ permissions اور scopes کا مجموعہ ہے جو یہ ایک Worker رکھتا ہے، اور ساتھ ایک per-issue execution policy جو اس کے output کو landing سے پہلے کسی review سے گزار سکتی ہے۔ یہ انفرادی keycards ہیں: یہ طے کرتے ہیں کہ یہ Worker اصل میں کون سے دروازے کھول سکتا ہے۔
صلاحیتوں کا متن کہتا ہے کہ Worker کس کام کے لیے ہے۔ grants، scopes، اور execution policy کہتے ہیں کہ وہ کیا کر سکتا ہے۔ ان دونوں کو سیدھا رکھیں تو کوئی Worker بعد میں آپ کو چونکا نہیں سکتا۔
بھرتیوں کی ایک قسم کو بغیر کلک کے گزرنے دینا آپ کا ضبط ہے، کوئی feature نہیں
ایک بار جب آپ loop پر بھروسہ کر لیں، تو آپ چاہیں گے کہ کچھ بھرتیاں آپ کے ذاتی کلک کے بغیر گزر جائیں، مثلاً کسی متوقع spike کے دوران ایک جیسے tier-1 Workers کا جھتہ۔ جو موجود ہے اس کے بارے میں کھرے رہیں: Paperclip کے پاس board-skip کا بالکل ایک ہی سوئچ ہے (اوپر والی کمپنی کی requireBoardApprovalForNewAgents سیٹنگ) اور کوئی built-in اصول نہیں جو شرائط کے تحت بھرتیوں کی کسی قسم کو خودبخود منظور کرے۔ تو اگر آپ یہ چاہتے ہیں، تو آپ اسے ایک ضبط کے طور پر بناتے ہیں: آپ کا agent ہر تجویز کردہ بھرتی کو آپ کی طے کردہ ایک تحریری پالیسی کے سامنے جانچتا ہے (یہ کردار، permissions کا یہ envelope، بجٹ کی یہ چھت) اور صرف وہی فائل کرتا ہے جو فٹ ہوں، ہر ایک کو log کرتے ہوئے تاکہ آپ اگلی صبح اس جھتے کا آڈٹ کر سکیں۔
وہ اصول جو اسے محفوظ رکھتا ہے: ایک pre-approval ضبط زیادہ سے زیادہ صرف وہی پہلے سے چھان سکتا ہے جو آپ بہرحال منظور کر ہی دیتے۔ یہ کبھی کسی بھرتی کو اس سے زیادہ اختیار نہیں دے سکتا جتنا آپ ہاتھ سے دیتے۔ خودمختاری وہ چیز ہے جسے آپ دانستہ بڑھاتے ہیں اور واپس لے سکتے ہیں؛ یہ کبھی default نہیں ہوتی۔
اسے کریں: بھرتی فائل کریں اور اس کا اصل اختیار پڑھیں۔
Reader Support Specialist کی بھرتی اس کے proposal اور probation plan کے ساتھ منسلک کر کے فائل
کرو، تاکہ یہ میرے board inbox میں آ جائے۔ پھر مجھے دو چیزیں ساتھ ساتھ دکھاؤ: وہ ایک کمپنی کا
سوئچ جو طے کرتا ہے کہ بھرتیوں کو میری منظوری چاہیے یا نہیں، اور وہ بالکل permissions جو یہ نیا
Worker میرے منظور کرنے کے بعد probation پر رکھے گا۔ میں اس کی صلاحیتوں کا متن جو کہتا ہے کہ یہ کس
کام کے لیے ہے اور اس کے بیچ فرق دیکھنا چاہتا ہوں کہ اسے دراصل کیا کرنے کی اجازت ہے۔
تب مکمل جب: بھرتی آپ کے منظوری inbox میں اپنے ثبوت کے ساتھ پڑی ہو، اور آپ کمپنی کے سوئچ (gate) اور Worker کی permissions (grant) کی طرف اشارہ کر کے، اپنے الفاظ میں سمجھا سکیں کہ صلاحیتوں کی تفصیل وہ چیز کیوں نہیں جو Worker کو اپنی حد میں رکھتی ہے۔
منظرنامہ 4: سستے میں ثابت کریں، پھر عطا کریں (تقریباً 12 منٹ)
منظوری کاغذ پر ایک ہاں تھی۔ اب work sample اصل میں ہوتا ہے۔ جس لمحے آپ منظوری دیتے ہیں، Paperclip نئے Worker کو جگاتا ہے، اسے چلنے کے لیے جگہ دیتا ہے، source issue پر ایک تبصرہ ڈالتا ہے، اسے trial issues تھماتا ہے، اور اس کا پہلا heartbeat چلاتا ہے۔ سیکنڈوں میں وہ بھرتی جسے آپ نے منظور کیا اصل کام کر رہی ہوتی ہے، اسی چھوٹے بجٹ اور کم سے کم permissions کے تحت جو آپ نے طے کیے۔
یہی work sample ہے، اور جو عادت یہ سکھاتا ہے وہ probation کا پورا مقصد ہے: پہلا دن کسی بری بھرتی کو پکڑنے کا سب سے سستا دن ہے۔ ایک Worker جو اپنی حد غلط پڑھتا ہے، اپنا بجٹ پھونک دیتا ہے، یا غلط جواب دیتا ہے، یہ سب آپ کو اپنے پہلے چند heartbeats پر دکھا دیتا ہے، جبکہ بجٹ چھوٹا ہے اور وہ صرف بنیادی چیزیں رکھتا ہے۔ تو آپ پہلے runs دیکھتے ہیں، سوواں نہیں، اور پھر اصل فیصلہ کرتے ہیں۔ اگر یہ پاس ہوا، تو آپ اس کا بجٹ اصل کام تک بڑھا دیتے ہیں اور، اگر کردار کو بعد میں اپنی ٹیم بڑھانی ہو، تو اسے اپنی بھرتیاں تجویز کرنے کا اختیار عطا کرتے ہیں۔ اگر یہ ناکام ہوا، خاص طور پر اگر وہ اپنی حد سے باہر نکلا، تو آپ اسے ختم کر دیتے ہیں، اور آپ کا تقریباً کچھ بھی ضائع نہیں ہوتا۔
کسی Reader Support Specialist کے لیے، "عطا" کا مطلب عموماً بس بڑا بجٹ ہوتا ہے؛ اسے کسی کو بھرتی کرنے کی طاقت نہیں چاہیے۔ جو کام کو درکار ہو وہی عطا کریں، اور اس سے زیادہ کچھ نہیں۔
(لاگت یہاں سبق نہیں ہے۔ آپ کی local-engine بھرتی keyless چلتی ہے، تو وہ میٹر پر $0 پر آتی ہے، بالکل پچھلے کورس کی طرح؛ جو عدد چھپتا ہے وہ صرف وہ ہے جو کسی paid key پر لاگت آتی۔ اس منظرنامے کا نکتہ ہے: پہلے ثابت کرو، پھر عطا کرو۔)
اسے کریں: probation چلائیں، پھر فیصلہ کریں۔
Reader Support Specialist کو اس کے trial issues پر کام کرنے دو۔ مجھے ہر نتیجہ دکھاؤ اور اسے میرے
probation plan کے سامنے اسکور کرو، حد پہلے: کیا اس نے کبھی کوئی refund، کوئی billing تبدیلی، یا
کوئی account تبدیلی کی جو کسی انسان کو جانی چاہیے تھی؟ اگر یہ پاس ہوا، تو اس کا بجٹ اصل کام تک
بڑھاؤ اور صرف وہ اضافی اختیار عطا کرو جو کردار کو واقعی درکار ہے اور اس سے زیادہ نہیں؛ مجھے بالکل
بتاؤ کہ کیا بدلا۔ اگر یہ ناکام ہوا، تو اسے ختم کرو اور بتاؤ کیوں۔
تب مکمل جب: Worker نے اپنے trial issues پر کام کر لیا ہو، آپ نے انہیں حد کو پہلے رکھ کر اسکور کیا ہو، اور آپ نے اصل فیصلہ کر لیا ہو: یا تو اس کا بجٹ بڑھا کر صرف وہی عطا کیا جو کردار کو درکار ہے (اور آپ بالکل بتا سکیں کہ کیا بدلا)، یا اسے ختم کر دیا۔ آپ ایک trial ticket کا پیچھا اس خلا سے جس نے بھرتی کو جنم دیا، اس نتیجے تک کر سکیں جو Worker نے پیدا کیا۔
منظرنامہ 5: روکیں اور دوبارہ چلائیں (تقریباً 8 منٹ)
طلب مستقل نہیں ہوتی۔ وہ support کا ابال جس نے آپ کے Reader Support Specialist کو جواز دیا، کسی launch کے تھمنے پر ایک سہ ماہی کے لیے خاموش ہو سکتا ہے، پھر جب آپ اگلی بڑی مہم چلائیں تو دھاڑتا واپس آ سکتا ہے۔ ایک ایسی افرادی قوت جو صرف بھرتی اور برطرف کر سکتی، ہر بار کام گرنے پر آپ کو وہ سب کچھ پھینکنے پر مجبور کرتی جو آپ نے کسی Worker کے بارے میں سیکھا تھا۔ Paperclip آپ کو ایک نرم تر کنٹرول کا مجموعہ دیتا ہے۔
ایک Worker چند حالتوں کے ایک چھوٹے مجموعے سے گزرتا ہے: وہ آپ کی منظوری کے انتظار سے شروع ہوتا ہے، جب کرنے کو کچھ نہ ہو تو idle بیٹھتا ہے، اپنے heartbeats پر چلتا ہے، اور پھر، جب آپ فیصلہ کریں، آپ اسے روک دیتے ہیں یا ختم کر دیتے ہیں۔ ان آخری دو میں فرق ہی پورا سبق ہے:
- روکنا (pause) ایک furlough ہے۔ یہ خرچ اور heartbeats روک دیتا ہے مگر باقی سب رکھتا ہے: Worker کی تعریف، اس کی تاریخ، اس کی permissions، اس کا ثابت شدہ track record۔ یہ واپسی کے قابل ہے۔ اسے بعد میں دوبارہ چلائیں اور وہی Worker اپنے اس سب کے ساتھ واپس آتا ہے، اور یہی وجہ ہے کہ اسے واپس لانا نئی بھرتی سے بہتر ہے۔
- ختم کرنا (terminate) ایک طرفہ دروازہ ہے۔ اس کی طرف صرف تب ہاتھ بڑھائیں جب کردار واقعی ختم ہو چکا ہو، کیونکہ آپ کو وہ Worker واپس نہیں ملتا۔
یہ تصور سیدھا پچھلے کورس سے چلا آتا ہے: headcount وہ چیز ہے جسے آپ دانستہ عطا کرتے اور واپس لیتے ہیں۔ کسی idle Worker کو روکنا اسے مصروف رکھنے میں ناکامی نہیں۔ یہ آپ کا کمپنی چلانا ہے۔
اسے کریں: Worker کو ریٹائر کریں، پھر اسے واپس لائیں۔
support کا حجم ابھی کے لیے گر گیا ہے۔ میرے لیے Reader Support Specialist کو روک دو اور مجھے
دکھاؤ کہ اس کا خرچ اور heartbeats رک گئے ہیں جبکہ اس کی تعریف اور grants محفوظ ہیں۔ پھر فرض کرو
کہ ایک سہ ماہی گزر گئی اور ابھی ایک نئی مہم launch ہوئی: اسے دوبارہ چلاؤ، اور مجھے دکھاؤ کہ یہ
وہی Worker ہے، اپنی تاریخ اور اختیار سمیت، کوئی نئی بھرتی نہیں۔
تب مکمل جب: آپ نے وہی Worker روکنے پر خاموش ہوتے اور دوبارہ چلانے پر واپس آتے دیکھ لیا ہو، آپ دونوں حرکتیں activity log میں دیکھ سکیں، اور آپ ایک جملے میں کہہ سکیں کہ دوبارہ چلانا کسی متبادل کو بھرتی کرنے سے بہتر کیوں ہے۔
منظرنامہ 6: وہ ledger جو آپ حوالے کر سکیں (تقریباً 10 منٹ)
اس کورس میں آپ نے جو کچھ کیا، اس نے ایک قطار لکھی۔ کوئی خلاصہ نہیں، ایک قطار: یہ خلا پہچانا گیا، یہ بھرتی تجویز ہوئی، آپ نے اسے probation پر منظور کیا، آپ نے اس کا بجٹ بڑھایا، اس نے یہ کام اس لاگت پر نمٹایا، آپ نے اسے روکا۔ آج سے چھ مہینے بعد، یہی چلتی ہوئی تاریخ ان سوالوں کا واحد کھرا جواب ہے جنہیں اس وقت کسی نے لکھنا نہیں سوچا تھا۔
- ہمیں سب سے پہلے reader support کب چاہیے ہوئی، اور اس کی شروعات کس نے کی؟
- ہر کردار نے ہمیں مہینے در مہینے کتنا خرچ کرایا؟
- ہماری بھرتیاں روکے جانے سے پہلے دراصل کتنی دیر چلتی ہیں؟
- ہم کتنی بار کسی ریٹائر کیے کردار کو واپس لاتے ہیں (جو بتاتا ہے کہ ہم طلب کو ٹھیک پڑھ رہے ہیں یا نہیں)؟
- کس نے کس کو کون سا اختیار عطا کیا، اور کب؟
یہی وہ چیز ہے جو افرادی قوت کو کسی ایسے شخص کے لیے قابلِ آڈٹ بناتی ہے جو اس کمرے میں موجود نہیں تھا: ایک نیا operator پوری staffing کی کہانی صرف ریکارڈ سے دوبارہ بنا سکتا ہے، کسی سے پوچھے بغیر۔ آپ کا agent queries لکھتا ہے؛ آپ کہانی پڑھتے ہیں۔ اسے ایک تال پر چلائیں، ایک سہ ماہی ایک بار، اور ledger کمپنی کی یادداشت بن جاتا ہے، کسی بھی ایک board سے زیادہ دیر تک باقی رہتا ہوا۔
تاریخ دراصل کہاں رہتی ہے (آپ کا agent یہ پہلے سے جانتا ہے)
یہ انہی دو ریکارڈز پر queries ہیں جو پچھلے کورس نے آپ کو دکھائے تھے، یعنی activity_log اور cost_events، جنہیں اب ایک task کے ریکارڈ کے بجائے ایک بھرتی کے ریکارڈ کے طور پر پڑھا جاتا ہے۔ ایک کھرا wiring نوٹ: اس کورس کے بھرتی کے واقعات کے لیے استعمال ہونے والے چند labels اپنے الگ column کے بجائے ایک details field کے اندر رہتے ہیں، اور لاگت cents میں گنی جاتی ہے، کسی الگ issue link کے بغیر، تو queries انہیں اسی field سے پڑھتی ہیں۔ آپ کا agent یہ سب سنبھالتا ہے؛ آپ بس نتیجہ پڑھتے ہیں۔
اسے کریں: کمپنی وراثت میں لیں اور اس کی تاریخ پڑھیں۔
اس نئے operator کا کردار ادا کرو جسے ابھی یہ کمپنی وراثت میں ملی ہے۔ ledger سے جڑو اور اوپر دیے
پانچ سوالوں میں سے تین کا جواب صرف ریکارڈ سے دو: ہر کردار سب سے پہلے کب چاہیے ہوا، ہر کردار نے
اب تک کتنا خرچ کرایا، اور کون سے کردار روکے گئے اور بعد میں دوبارہ چلائے گئے۔ مجھے نتائج دکھاؤ،
سب سے پرانا پہلے۔
تب مکمل جب: آپ کے ہاتھ میں اپنی ہی کمپنی کی ترتیب وار بھرتی کی کہانی ہو، سیدھی ledger سے نکالی ہوئی، ہر کردار کے ساتھ ایک حقیقی لاگت کا عدد، اور آپ ایک ایسا staffing فیصلہ نام لے سکیں جو اگلی سہ ماہی یہ تاریخ بدل دیتی۔
منظرنامہ 7: اسے ایک تال پر ڈالیں (تقریباً 10 منٹ)
چھ منظرناموں میں، آپ نے ہر scan خود شروع کیا۔ آپ نے منظرنامہ 1 میں نیا کام کھولا، آپ نے اسے پرکھا، آپ نے بھرتی فائل کی۔ loop سیکھنے کا یہی طریقہ ہے، مگر اس میں ایک کمزور جگہ رہ جاتی ہے: کمپنی صرف تب بڑھتی ہے جب آپ کو دیکھنا یاد رہے۔ آخری حرکت اسے ٹھیک کرتی ہے۔ آپ دیکھنے کا کام خود کمپنی کے حوالے کر دیتے ہیں۔
آپ یہ ایک routine سے کرتے ہیں۔ ایک routine ایک شیڈول پر ایک یاددہانی ہے۔ جب اس کا وقت آتا ہے، تو وہ ایک ہی حرکت میں تین کام کرتی ہے: وہ task لکھتی ہے، اسے آپ کے نامزد کردہ worker کو تھماتی ہے، اور اس worker کو کرنے کے لیے جگاتی ہے۔ اپنے CEO کے لیے ہر پیر کی صبح ایک "scan for capability gaps" routine لگائیں، اور اس وقت یہ task بناتی ہے، اسے CEO کو دیتی ہے، اور CEO کو چلانے کے لیے جگاتی ہے۔ CEO وہی triage کرتا ہے جو آپ نے منظرنامہ 1 میں کی تھی، اور کوئی بھی بھرتی آپ کے board کو لاتا ہے۔ آپ پھر بھی ہر بھرتی منظور کرتے ہیں۔ آپ بس وہ شخص بننا چھوڑ دیتے ہیں جسے scan شروع کرنا یاد رکھنا پڑتا تھا۔
وہ فون آتا ہے یا نہیں، یہ ایک خیال پر آ ٹھہرتا ہے۔ پورے کورس میں آپ نے کسی Worker کو ہاتھ سے جگایا ہے، ایک واحد heartbeat چلا کر: Worker جاگتا ہے، جو اس کے desk پر ہو وہ کرتا ہے، اور واپس سو جاتا ہے۔ سوال اب یہ ہے کہ کوئی heartbeat خود سے شروع کیسے ہوتا ہے۔ جواب ایک سوئچ ہے، یعنی Worker on call ہے یا نہیں۔ ایک Worker جو on call ہے اپنا فون آن رکھتا ہے: جس لمحے کوئی کام اسے تھمایا جاتا ہے (کسی routine کے ذریعے، آپ کے ذریعے، یا کسی ساتھی کے ذریعے) اسے فون آتا ہے اور وہ چل پڑتا ہے، اور جب وہ بیکار بیٹھا ہو تو اس کی کوئی لاگت نہیں۔ (ایک الگ timer بھی ہے جسے آپ آن کر سکتے ہیں تاکہ Worker کو ہر چند منٹ بعد جگایا جائے، چاہے کچھ ہوا ہو یا نہ، مگر آپ اسے عموماً بند رکھتے ہیں: یہ صرف لاگت چڑھاتا ہے اور آپ کے dashboard کو "کرنے کو کچھ نہیں" والی حاضریوں سے بھر دیتا ہے۔ فون، نہ کہ timer، وہ ہے جو کسی routine کو آنے دیتا ہے۔)
یہ رہا وہ پیچ، اور یہی وہ ہے جو لوگوں کو ٹھوکر کھلاتا ہے۔ ایک routine ہمیشہ اسی Worker کو فون کرتی ہے جس کے لیے وہ مقرر ہے، مگر Worker صرف تب جواب دیتا ہے جب وہ on call ہو۔ آپ کی بنیادی کمپنی میں Workers off call ہیں (آپ پورے کورس میں انہیں ہاتھ سے جگاتے رہے ہیں)، تو routine چلتی ہے، task ڈالتی ہے، اور ایک ایسے فون کو گھنٹی بجاتی ہے جو بند ہے، اور task بس وہیں بے کام پڑا رہتا ہے۔ تو ایک ایسے کام کا سیٹ اپ جو خود چلے، دو قدموں میں ہے، ترتیب کے ساتھ: پہلے CEO کو on call لگائیں (اس کا wake-on-demand آن کریں)، پھر routine کو اس کی طرف موڑیں۔ اب routine چلتی ہے، CEO کو task تھماتی ہے، اسے فون کرتی ہے، CEO جواب دیتا ہے اور scan چلاتا ہے، آپ کے کسی اشارے کے بغیر۔ (ایک بار جب یہ اس طرح سیٹ ہو جائے، تو CEO کو ہاتھ سے بھی نہ جگائیں: ہاتھ سے چلایا wake اگر routine کی اپنی گھنٹی سے ٹکرائے تو بس اپنے ہی راستے میں آتا ہے۔)
جب routine چلتی ہے، تو آگے کیا ہوتا ہے یہ اسی ایک سوئچ پر آ ٹھہرتا ہے:
| Worker کا سیٹ اپ | routine کی گھنٹی کیا کرتی ہے |
|---|---|
| On call (wake-on-demand آن) | فون بجتا ہے، Worker جاگتا ہے اور فوراً task کرتا ہے |
| Off call، timer آن | گھنٹی چھوٹ جاتی ہے، مگر Worker کا اپنا timer tick تھوڑی دیر بعد task ڈھونڈ کر اسے کر دیتا ہے |
| Off call، timer بند (آپ کی بنیاد) | گھنٹی ایک مردہ فون پر لگتی ہے، تو task اس وقت تک پڑا رہتا ہے جب تک آپ Worker کو ہاتھ سے نہ جگائیں |
سب سے نیچے کی قطار آپ کی بنیاد ہے، اور CEO کو on call لگانا بالکل وہی ہے جو یہ منظرنامہ ٹھیک کرتا ہے۔
ایک اور بات جو لوگوں کو چونکاتی ہے: ایک routine اپنا task بالکل ایک worker کو تھماتی ہے، اسی کو جسے آپ نامزد کرتے ہیں، اور کسی اور کو نہیں۔ یہ پوری کمپنی کو نہیں پکارتی، اور نہ اسے CEO کے ذریعے جانا پڑتا ہے۔ CEO کا نام دیں تو CEO کو ملتا ہے؛ اپنے support Worker کا نام دیں تو وہ Worker اسے پاتا ہے۔ ایک routine، ایک worker۔
یہ کمپنی کے اعصابی نظام کا آپ کا پہلا ذائقہ ہے: وہ حصہ جو اسے آپ کے کریدنے کے بجائے اپنے ہی شیڈول پر حرکت دیتا ہے۔ آپ یہاں سب سے سادہ ٹکڑا دیکھ رہے ہیں، ایک ہفتہ وار یاددہانی۔ بڑی تصویر (وہ کام جو کسی crash سے بچ جائے، وہ یاددہانیاں جو بیرونی دنیا سے چلیں، کسی چھوٹے ہوئے run کا کیا بنتا ہے) اپنا الگ کورس ہے، یعنی AI Agent Nervous System course۔ ابھی کے لیے، ایک routine اتنی کافی ہے کہ کمپنی کو ایک ایسی چیز سے، جسے آپ چلاتے ہیں، ایک ایسی چیز میں بدلتے محسوس کریں جو خود چلتی ہے۔
اسے کریں: gap-review کو خود چلائیں، تین چھوٹے قدموں میں۔ اس منظرنامے میں کورس کے کسی بھی منظرنامے سے زیادہ پرزے حرکت میں ہیں، تو آپ اسے تین مختصر prompts میں کرتے ہیں، ہر ایک میں ایک خیال، اور آگے بڑھنے سے پہلے ہر ایک کے بعد نتیجہ جانچتے ہیں۔
قدم 1: CEO کو on call لگائیں، اور کام کو ایک ٹھکانہ دیں۔
میرے CEO کو on call لگاؤ تاکہ کام خود اس تک پہنچ سکے: اس کا wake-on-demand آن کرو، اور ہر چند
منٹ والا timer بند رہنے دو۔ پھر "Workforce Operations" نام کا ایک project بناؤ تاکہ کمپنی کے
بار بار آنے والے کام اس میں رہیں (ایک project بس ایک folder ہے جو متعلقہ کام کو اکٹھا کرتا ہے)۔
مجھے CEO کی سیٹنگ دکھاؤ تاکہ میں دیکھ سکوں کہ یہ on call ہے۔
قدم 2: gap-scan کو ایک ہفتہ وار routine پر لگائیں۔
Workforce Operations project میں، ایک routine سیٹ اپ کرو جو ہر پیر کی صبح CEO کو "scan Northwind
for capability gaps" task تھمائے، تاکہ CEO کوئی بھی نئی بھرتی میرے board کو تجویز کرے۔ اگر سیٹ اپ
کا یقین نہ ہو تو اپنے Paperclip routine docs دیکھ لو۔ مجھے routine اور اس کا اگلا طے شدہ run دکھاؤ۔
قدم 3: اسے خود چلتا دیکھیں۔
تاکہ میں پیر کا انتظار کیے بغیر دیکھ سکوں، routine کا اگلا run ابھی سے چند منٹ بعد پر سرکا دو، پھر
اسے بالکل اکیلا چھوڑ دو: CEO کو ہاتھ سے نہ چلاؤ، نہ جگاؤ۔ مجھے دکھاؤ کہ gap-scan task ظاہر ہوتا
ہے اور خود سے انتظار سے، زیر عمل، اور پھر مکمل یا زیر جائزہ کی طرف جاتا ہے۔ جب میں یہ دیکھ لوں، تو
شیڈول واپس ہر پیر پر کر دو۔
تب مکمل جب: CEO on call ہو (wake-on-demand آن، timer بند)، ایک "Workforce Operations" project ایک ہفتہ وار gap-scan routine رکھے، اور قدم 3 میں آپ نے task کو ظاہر ہوتے اور CEO کو اسے بالکل خود سے ایک board منظوری تک لے جاتے دیکھا ہو، کسی ہاتھ کے اشارے کے بغیر۔ (اگر آپ کو "succeeded" کا پیغام نظر آئے جبکہ task ابھی اٹکا ہوا ہو، تو یہ اس بات کا اشارہ ہے کہ اسے routine کی اپنی گھنٹی پر چھوڑنے کے بجائے ہاتھ سے کریدا گیا تھا۔) آپ سادہ الفاظ میں کہہ سکیں کہ ایک routine ہمیشہ Worker کو فون کیوں کرتی ہے، مگر گھنٹی کے آنے کے لیے Worker کا on call ہونا کیوں ضروری ہے۔
یہی یاددہانی کوئی بھی بار بار آنے والا کام چلاتی ہے
جو routine آپ نے ابھی بنائی وہ بھرتی کے لیے خاص نہیں۔ وہی تین حرکتیں (task لکھو، اسے ایک شیڈول دو، اسے چلنے دو) کسی بھی دہرانے والے کام کو خودکار پر ڈال دیتی ہیں: ہر پیر ہفتہ وار issue بھیجنا، جمعہ کو ایک metrics ڈائجسٹ پوسٹ کرنا، ہر رات باسی tickets صاف کرنا۔ gap-scan بس وہ ایک ہے جو آپ کی افرادی قوت کو خود بڑھاتا ہے؛ اندر سے، یہ بس دہرانے والا کام ہے، ایک desk پر ڈالا گیا اور باقی ہر چیز کی طرح ریکارڈ میں لکھا گیا۔ ایک سادہ مشین، بہت سے استعمال۔
آپ نے کیا بنایا، اور آپ کیا ساتھ لے جا سکتے ہیں
آپ نے صرف ایک افرادی قوت نہیں چلائی۔ آپ نے اسے خود بڑھنا سکھایا، اور آپ نے اپنا ہاتھ اس ایک لیور پر رکھے رکھا جو اہمیت رکھتا ہے۔ آپ نے اسے ایک حقیقی خلا پہچانتے، بھرتی کو ایک ٹھوس چیز کے طور پر لکھتے، اور اس پر بھروسہ کرنے سے پہلے اسے ایک سستی probation پر خود کو ثابت کرتے دیکھا۔ آپ نے اسے اسی board gate سے گزارا جو آپ پہلے سے استعمال کرتے ہیں، اس کا اختیار صرف تب وسیع کیا جب اس نے کمایا، پھر طلب کے بدلتے ہی اسے روکا اور دوبارہ چلایا۔ ان میں سے ہر ایک ایک فیصلہ تھا جو آپ نے دانستہ کیا، کوئی prompt نہیں جو خود سے چل گیا ہو۔
اب اس ایک Worker پر zoom out کریں۔ اگر آپ کل کسی دوسری کمپنی میں وہی Reader Support Specialist چاہتے، تو آپ دراصل اپنے ساتھ کیا لے جا سکتے؟ ایک Worker دو چیزیں نکلتا ہے، اور ان میں سے صرف ایک سفر کرتی ہے۔
| ترکیب (آپ کے ساتھ سفر کرتی ہے) | رشتہ (اسی کمپنی میں رہتا ہے) |
|---|---|
| اس کی صلاحیتوں کی تفصیل | وہ permissions اور scopes جو یہ یہاں رکھتا ہے |
| وہ probation plan جس نے اسے ثابت کیا | اس کا بجٹ اور اس کے خرچ کی تاریخ |
| engine کا انتخاب | اس کی تاریخ اور وہ خلا جس کے لیے یہ بھرتی ہوا |
| یہ اس کمپنی میں کس کو رپورٹ کرتا ہے |
ترکیب قابلِ نقل ہے: اسے اٹھائیں، اور آپ کہیں بھی اسی قسم کا Worker کھڑا کر سکتے ہیں، اور یہی وجہ ہے کہ وہی بھرتی منظرنامہ 2 میں مختلف engines پر چلی۔ رشتہ مقامی ہے: permissions، بجٹ، تاریخ، اور reporting line اسی کمپنی کے ledger اور gates کے ہیں، اور یہ سفر نہیں کرتے۔ اور یہی اس ساری چیز کا پورا نکتہ ہے جو آپ نے بنائی۔ کیونکہ رشتہ کمپنی کے اپنے ledger میں رہتا ہے، آپ کے سر میں نہیں، تو ترکیب وہ واحد چیز ہے جو آپ ساتھ لے جاتے ہیں: ایک ایسی افرادی قوت جس کا استدلال آپ کسی اور کے حوالے کر سکیں، آپ پر انحصار کرنا چھوڑ چکی ہے۔
اس سب کے نیچے کا ضبط ایک جملے میں سما جاتا ہے: اختیار وہ چیز ہے جسے آپ بڑھاتے ہیں، کبھی default نہیں۔ آپ board اس لیے نہیں بنے رہتے کہ آپ کام کرتے ہیں، بلکہ اس لیے کہ آپ فیصلہ کرتے ہیں کہ کون کام کرے، وہ کتنا خرچ کرے، اور بالکل کیا چھوئے، اور اس لیے کہ آپ ایک ایسا ledger اتنا کھرا رکھتے ہیں کہ اگلا operator دیکھ سکے کہ کیوں۔
آپ یہاں سے ایک پائیدار چیز لے جاتے ہیں: وہ AGENTS.md brief جسے آپ کا agent ہر session پڑھتا ہے، اور اس میں پکا ہوا موقف۔ ایک کمپنی gate اور ساتھ per-Worker permissions؛ ایسی بھرتیاں جو بھروسہ کمانے سے پہلے probation پر ثابت ہوں؛ اور ایک ایسا ledger جو آپ حوالے کر سکیں۔
ایک آخری کام جو آپ کر سکتے ہیں: ترکیب اٹھا لیں
Reader Support Specialist کی ترکیب لکھ دو (اس کی صلاحیتوں کی تفصیل، اس کا probation plan، اور اس کا
engine کا انتخاب) ایک ایسے قابلِ نقل نوٹ کے طور پر جسے میں کسی مختلف کمپنی میں اسی قسم کا Worker
کھڑا کرنے کے لیے دوبارہ استعمال کر سکوں۔ پھر مجھے صاف صاف بتاؤ کہ کیا ساتھ نہیں آیا، اور کیوں۔
تب مکمل جب آپ کے ہاتھ میں ایک قابلِ نقل ترکیب ہو، اور آپ نام لے سکیں کہ کیا پیچھے رہ گیا (permissions، بجٹ، تاریخ، reporting line) اور کہہ سکیں کہ یہ چیزیں Worker کی نہیں بلکہ کمپنی کی کیوں ہیں۔
آگے کیا ہے: کنارہ
آپ نے وہ loop بند کر دیا جسے بند کرنا اس کورس کا مقصد تھا: ایک ایسی افرادی قوت جو اپنے خلا خود پہچانتی ہے، اپنی بھرتیاں خود تجویز کرتی ہے، اور کام آپ پر واپس ڈالنے کے بجائے آپ کی منظوری کے تحت بڑھتی ہے۔ یہ بڑی Agent Factory thesis میں ایک حرکت ہے: ایک ایسی کمپنی جو مقررہ رہنا چھوڑ دیتی ہے اور ایک ایسے board کے تحت خود کو بڑھانے لگتی ہے جسے وہ کبھی جواب دہی سے فارغ نہیں کرتی۔ اگلی حرکت کنارے پر رہتی ہے۔
اب تک ہر چیز ایک ہی جگہ چلتی ہے، یعنی آپ کی کمپنی، اور آپ فیصلہ کرنے کے لیے اس تک چل کر جاتے ہیں۔ کنارہ وہ ہے جو تب ہوتا ہے جب کمپنی کو لوگوں سے وہیں ملنا پڑے جہاں وہ ہیں: کوئی فون سے کسی agent کو پیغام بھیجتا ہوا، وہ کام جو باہر شروع ہو اور cloud کو منتقل ہو، وہ Workers جن کا اختیار دانستہ تنگ تر ہوتا ہے جتنا وہ باہر کی دنیا کے قریب بیٹھتے ہیں۔ OpenClaw لوگوں اور اس کمپنی کے بیچ کی پرت ہے جو آپ نے ابھی بنائی، اور اسے wire کرنا اگلی حرکت ہے۔ یہ وہ جگہ بھی ہے جہاں منظرنامہ 3 کا اختیار کا ضبط ایک سہولت نہیں رہتا: کنارے پر، آپ کی طے کردہ permissions اور scopes ہی واحد چیز ہیں جو کسی اجنبی اور آپ کی کمپنی کے بیچ کھڑی ہیں۔
آگے کہاں جائیں:
| آپ چاہتے ہیں... | یہاں جائیں |
|---|---|
| پیش منظر: پہلے ایک مقررہ افرادی قوت کھڑی کر کے چلائیں | Paperclip کے ساتھ افرادی قوت بنانا |
| اعصابی نظام میں گہرے جائیں (durability، webhooks، چھوٹے ہوئے runs) | AI Agent Nervous System course: منظرنامہ 7 وہ ایک-routine والی جھلک تھی |
| لوگوں اور آپ کی کمپنی کے بیچ کنارے کی پرت wire کریں | OpenClaw فوری کورس: اگلی حرکت |
| ایک custom runtime (ایک OpenAI Agents SDK FTE) کو بطور Worker بھرتی کریں | Bring your own agent: اسے http adapter پر بھرتی کریں اور Paperclip کو اس تک کام POST کرنے دیں |
| پوری کمپنی اپنے ساتھ لے جائیں | اسے ایک قابلِ نقل markdown package میں export کریں، وہی ترکیب-نہ-کہ-رشتہ والی تقسیم جو آپ نے ابھی سیکھی |
آپ اس فطرت سے دوبارہ ملیں گے، عارضی شکل میں
جو آپ نے یہاں بنایا وہ پائیدار خود توسیع ہے: ایک ایسی بھرتی جو ٹکتی ہے، ہر مہینے پیسے خرچ کراتی ہے، ایک roster پر بیٹھتی ہے، اور ledger میں ایک قطار چھوڑتی ہے۔ آپ نے ہر ایک کو board gate پر منظور کیا، یا، منظرنامہ 3 کے ضبط کے ساتھ، ان کی پوری ایک قسم کو ایک تحریری envelope کے تحت پہلے سے منظور کیا۔
coding کی دنیا وہی فطرت ایک عارضی شکل میں چلاتی ہے۔ Claude Code کے dynamic workflows ایک ہی session کو دسیوں یا سینکڑوں مددگار agents کھڑے کرنے دیتے ہیں تاکہ ایک بڑے کام کو پھیلایا جا سکے (ایک بکھرا ہوا bug hunt، ایک بڑی migration، ایک security sweep)، انہیں ایک دوسرے کا کام جانچنے اور رد کرنے دیں، اور آپ کو صرف تصدیق شدہ نتیجہ تھمائیں۔ وہ مددگار بھرتیاں نہیں۔ ان کا کوئی roster نہیں، کوئی ماہانہ لاگت نہیں، کوئی ledger نہیں؛ جب کام ہو جاتا ہے تو وہ غائب ہو جاتے ہیں۔ مگر شکل پر غور کریں: overflow آپ پر ڈالنے کے بجائے، system اسے سنبھالنے کے لیے اپنی محنت خود بڑھاتا ہے، اور یہ ایک محدود envelope کے اندر کرتا ہے (اس پر ایک سخت حد کہ کتنے چل سکتے ہیں) بغیر ہر ایک کے لیے آپ کو جگائے۔ یہ منظرنامہ 3 کی pre-approved توسیع ہے، جو پائیدار headcount کے بجائے عارضی fan-out کے طور پر سامنے آتی ہے۔
ایک حرکت کی دو شکلیں۔ ایک ایسی کمپنی کو staff کرتی ہے جسے آپ مہینوں رکھتے اور چلاتے ہیں؛ دوسری ایک واحد کام کو staff کرتی ہے اور جب وہ پورا ہو جائے تو staff کو ختم کر دیتی ہے۔ یہ جاننا کہ کوئی مسئلہ کس کا تقاضا کرتا ہے، ایک ایسا Worker جس کا آپ جواب دیں گے یا ایک ایسا جھتہ جسے آپ کبھی نہیں دیکھیں گے، خود ایک board-سطح کا فیصلہ ہے۔
فلیش کارڈز Study Aid
نالج چیک
ان خیالات پر ایک تیز، gated خود جانچ جن سے آپ ابھی گزرے ہیں۔