وہ کردار جن کی یہ کتاب تربیت دیتی ہے
مارکیٹ عہدوں کے نام اتنی تیزی سے ایجاد کر رہی ہے کہ ان کی تعریف پیچھے رہ گئی ہے۔ ان میں سے زیادہ تر نام ایک ہی نظم کی مختلف گہرائیاں ہیں: وہی نظم جس کی یہ کتاب تربیت دیتی ہے۔ یہاں نقشہ ہے، اور یہ بھی کہ کتاب آپ کو ہر کردار کی طرف ٹھیک کہاں تک لے جاتی ہے۔
ہر عہدے کے پیچھے سوال
مورخ یوال نوح ہراری نے جدید تعلیم کا مشکل ترین سوال اٹھایا ہے: تاریخ میں پہلی بار ہمیں کچھ اندازہ نہیں کہ 10 سال بعد روزگار کی منڈی کیسی ہوگی، اس لیے ہم یہ بھی نہیں جانتے کہ آج نوجوانوں کو کیا سکھایا جائے۔ پرانا جواب سادہ تھا: انہیں کوڈ لکھنا سکھائیں۔ وہ جواب ٹوٹ رہا ہے، کیونکہ مصنوعی ذہانت کوڈ لکھنا سیکھ رہی ہے، اور ایک سال کے اندر ممکن ہے کہ وہ بیشتر انسانوں سے زیادہ اور بہتر کوڈ لکھے۔ صرف syntax سکھانا ایسی مہارت سکھانا ہے جسے مشین اسی وقت اپنے اندر جذب کر رہی ہے۔
یہ صفحہ ہراری کے سوال پر کتاب کا جواب ہے۔ syntax لکھنے والے افراد تیار نہ کریں؛ ایسے لوگ تیار کریں جو مشین سے اوپر کھڑے ہوں: جو بتائیں کہ کیا بننا چاہیے، اسے بنانے والے مصنوعی ذہانت کے کارکنوں کی نگرانی کریں، اور واپس آنے والے نتیجے کی تصدیق کریں۔ syntax خودکار ہو سکتی ہے۔ فیصلہ، تفصیلات اور تعیناتی خودکار نہیں ہو سکتے: مشین جوں جوں سیڑھی چڑھتی ہے، یہ کام اگلی سطح پر منتقل ہو جاتے ہیں۔ نیچے ہر کردار اسی سیڑھی کی ایک نشست ہے، اور اس صفحے کے طلب کے اعداد دکھاتے ہیں کہ بازار ابھی سے اسی کام کی قیمت ادا کر رہا ہے، کیونکہ وہ بھی ہراری کے سوال کا جواب نہیں دے سکتا اور جواب دینے والوں کو ملازمت دے رہا ہے۔
📚 تدریسی معاونت
مکمل پریزنٹیشن دیکھیں، وہ کردار جن کی یہ کتاب تربیت دیتی ہے
یہاں ہم مصنوعی ذہانت کے نئے وکیلی دور کے کردار بیان کرتے ہیں: وہ ملازمتیں جو اس لیے وجود میں آئی ہیں کہ کمپنیاں اب مصنوعی ذہانت کے کارکن بناتی، چلاتی اور ان پر حکمرانی کرتی ہیں۔ اندراجات اس ترتیب سے ہیں جس میں کام حقیقت میں اکٹھا ہوتا ہے، اور ہر کردار کے ساتھ فیصلہ اس کے دائرے کی دیانت دار حد ہے: یہ کتاب آپ کو اس کردار کی طرف کہاں تک لے جاتی ہے، اور کہاں سند کے راستے آگے سنبھالتے ہیں۔ فیصلے ناموں سے زیادہ اہم ہیں۔ جہاں کتاب رکتی ہے، وہ صاف کہتی ہے۔ اور چونکہ کوئی کردار اتنا ہی حقیقی ہے جتنی اس کے پیچھے طلب، یہ صفحہ اس طلب کو ہر اس بازار میں دیکھتا ہے جو اب ان کرداروں کے لیے بھرتی کر رہا ہے: مصنوعی ذہانت کی تجربہ گاہیں، بڑی cloud کمپنیاں، مشاورت کے بڑے ادارے، آزاد خدماتی کمپنیاں اور کھلی آزاد منڈی۔
نقشہ: تین درجے، ایک خط۔ ایک جملہ اس پورے صفحے کو جوڑتا ہے۔ یہ کتاب آپ کو مصنوعی ذہانت کے کارکن، یعنی Digital FTEs، بنانا اور ان کارکنوں کو ایسی کمپنی میں یکجا کرنا سکھاتی ہے جو انہی پر چلتی ہے۔ روزگار کی منڈی اس شخص کے لیے ایک گرم نیا نام رکھتی ہے جو یہ سب کر سکتا ہے: Forward Deployed Engineer یا FDE۔ یوں تین درجے ہیں اور ہر درجہ اگلا بناتا ہے: شخص، یعنی آپ؛ اکائی، یعنی آپ کا بنایا ہوا مصنوعی ذہانت کا کارکن؛ اور ادارہ، یعنی وہ کمپنی جو ان کارکنوں کے مجموعے سے بنتی ہے۔ اس صفحے کا ہر کردار یا تو اس خط کی ایک منزل ہے، یا اسے سہارا دیتا ہے، یا اس کے گرد کتاب کی دیانت دار حد ہے۔ نقشے سے پہلے ایک اور بات: FDE یہ بتاتا ہے کہ آپ کہاں کام کرتے ہیں، یہ نہیں کہ آپ کیا جانتے ہیں۔ گاہک کی کمپنی کے اندر کام کریں تو بازار آپ کو FDE کہتا ہے۔ وہی کمپنی آپ کو ملازم رکھ لے تو یہی مہارتیں اس کے AI-Native Company Architect کی مہارتیں بن جاتی ہیں۔ کتاب مہارتوں کی تربیت دیتی ہے؛ بازار نام چنتا ہے۔
یہ تعریف درست بھی ہے اور نامکمل بھی، کیونکہ پتہ یہ نہیں بتاتا کہ آپ دروازے سے کیا لے کر داخل ہوتے ہیں۔ کسی vendor کا FDE اس vendor کا پلیٹ فارم لاتا ہے۔ vendor-neutral انجینئر کیا لاتا ہے، یہ مشکل سوال ہے، اور اس کا ایک ٹھیک جواب ہے: دو Systems of Record، ایک اسے ملتا ہے اور دوسرا وہ خود بناتا ہے۔ وہ حصہ نیچے FDE کے نقشے میں ہے، کیونکہ vendor کی صورت دیکھے بغیر جواب پوری طرح واضح نہیں ہوتا۔
ہر کوئی ایک ہی Foundations سے شروع کرتا ہے، یعنی browser کی وہ مہارتیں جو کسی وکیلی کام سے پہلے ہر قاری کو چاہییں۔ اسی منزل پر عام agent کے استعمال کے دو طریقے ہیں۔ Mode 1 عام agent سے اپنا کام تیز کرنا ہے، ایسی قابلیت جو ہر قاری کو چاہیے، ملازمت کا نام نہیں۔ Mode 2 مصنوعی ذہانت کے ایسے کارکن بنانا ہے جو آپ کے لیے کام کریں، اور ملازمتوں کے نام وہیں پیدا ہوتے ہیں۔ نقشہ Foundations اور Mode 1 Practitioner سے شروع ہوتا ہے، پھر Mode 2 کے کرداروں کی طرف جاتا ہے، جو اس کا تقریباً سارا حصہ ہیں۔
اگر Digital FTE، SKILL.md اور Agent Factory کی اصطلاحات نئی ہیں تو پہلے Thesis اور لغت پڑھیں، کیونکہ یہ صفحہ انہیں معلوم سمجھتا ہے۔
ایک ہی نظم، دو جگہیں: چار کردار اپنے ادارے میں پائپ لائن چلاتے ہیں؛ ایک FDE گاہک کے ادارے میں یہی پائپ لائن لے جاتا ہے۔
پورا map ایک نظر میں: core pipeline، اسے extend اور support کرنے والی چیزیں، کتاب کہاں رکتی ہے، اور نیچے کی baseline۔
وہ baseline جہاں سے سب شروع کرتے ہیں
Foundations: floor، دونوں modes سے پہلے۔ ہر reader ایک ہی طرح شروع کرتا ہے، browser tab میں، Foundations پر: prompting کیسے کرنی ہے، agentic work کی دو document languages، وہ code کیسے commission کرنا ہے جو آپ خود کبھی نہیں لکھتے، skills اور connectors، اور AI era میں کیسے سوچنا ہے۔ کوئی mode نہیں، کوئی role نہیں، install کرنے کو کچھ نہیں۔ یہی وہ floor ہے جس پر پورا map کھڑا ہے۔ جہاں سب شروع کرتے ہیں، title نہیں۔
Mode 1 Practitioner: title نہیں، proficiency ہے۔ اسی floor پر آپ general agent کو اپنا کام تیز کرنے کے لیے use کرتے ہیں: reason کرنا، لکھنا، code کرنا، analyze کرنا، plan کرنا، outcome ship کرنا، اور session close کرنا۔ یہ Mode 1 ہے، اور کتاب اسے سب کے لیے train کرتی ہے: engineers کے لیے Claude Code یا OpenCode کے ذریعے، domain experts کے لیے Claude Cowork یا OpenWork کے ذریعے، Seven Principles of General Agent Problem Solving کے تحت۔ یہ پہلا mode ہے جو ہر reader نیچے دیے گئے Mode 2 roles سے پہلے run کرتا ہے، اور یہ آپ کو موجودہ job میں sharper بناتا ہے، نیا title نہیں دیتا۔ پہلا mode جو سب run کرتے ہیں، title نہیں۔
عمومی بنیادی کردار
یہ core roles ایک single pipeline کی طرح چلتے ہیں، intent سے production تک: Outcome Architect (کیا) -> Digital FTE Builder (build) -> AI-Native Company Architect (system) -> Cloud AI Engineer (run)۔ اسے اپنی company کے اندر چلائیں تو یہ چار roles ہیں؛ اسے client کی company کے اندر چلائیں، end to end ایک embedded، vendor-neutral engineer اسے carry کرے، تو یہ Forward Deployed Engineer ہے۔ Map پر باقی سب کچھ اسی line کو support، extend، یا bound کرتا ہے۔
چار roles آپ کی اپنی company کے اندر line run کرتے ہیں؛ ایک embedded engineer وہی line client کی company کے اندر carry کرتا ہے۔
Outcome Architect: intent own کرتا ہے، execution نہیں۔ Agent era میں work تین حصوں میں split ہوتا ہے: intent، execution، verification۔ Worker execution own کرتا ہے؛ یہ role intent own کرتا ہے۔ یہ decide کرتا ہے کہ Worker کیا achieve کرے، spec لکھتا ہے جو اسے pin down کرتی ہے، "correct" کا مطلب set کرتا ہے، اور prioritize کرتا ہے کہ کون سے Workers بننے بھی چاہییں۔ Builder کیسے کا جواب دیتا ہے؛ اس سے پہلے یہ human کیا اور کیوں کا جواب دیتا ہے۔ جہاں Strategist track client-facing discovery اور ROI own کرتا ہے، Outcome Architect internal Worker roadmap اور اس کے پیچھے specs own کرتا ہے۔ کتاب اسے directly train کرتی ہے: spec-driven development اصل میں یہی discipline ہے کہ intent اتنا clear لکھا جائے کہ Worker کو اس کے against hold کیا جا سکے۔
سافٹ ویئر کی history میں slow حصہ چیز build کرنا تھا۔ Coding agents نے یہ توڑ دیا۔ ایک engineer اب پہلے سے کئی گنا زیادہ ship کرتا ہے، کیونکہ agent building کرتا ہے۔ مگر اس speed نے ایک نیا slow part expose کیا۔ اگر ایک engineer پانچ چیزیں ایک ساتھ build کر سکتا ہے تو کسی کو پھر بھی decide کرنا ہے کہ کون سی پانچ چیزیں build کرنے کے قابل ہیں، اور ہر ایک کو اتنا clearly لکھنا ہے کہ agent execute کر سکے۔ یہ deciding اس role میں intent کہلاتی ہے، اور یہ fast نہیں ہوئی۔
ایک number میں shift دیکھیں۔ Companies پہلے تقریباً ایک product manager، یعنی direction set کرنے والا ایک شخص، ہر آٹھ engineers پر چلاتی تھیں۔ جب ہر engineer کا output multiply ہوا، وہی ایک person اب تقریباً بیس engineers کے work کو feed کر رہا ہے۔1 Building scale ہوئی۔ Deciding scale نہیں ہوئی۔ اس لیے deciding bottleneck بن گئی، وہ point جس پر باقی سب wait کرتا ہے۔
بازار اسے دیکھ کر conclude کرتا ہے کہ product managers کم ہیں۔ یہ کتاب اسے مختلف پڑھتی ہے: یہ وہ moment ہے جب Outcome Architect، intent کا مالک، company کی سب سے important seat بن جاتا ہے۔ AI workforce جتنی بڑی ہوتی ہے، اتنا ہی وہ ایسے human پر depend کرتی ہے جو precisely کہہ سکے کہ اسے کیا build کرنا چاہیے۔
عملی output agentic coding کے ساتھ scale ہوا؛ کیا build کرنا ہے یہ decide کرنے کا work نہیں ہوا۔ بڑھتا ہوا gap، engineers کی shortage نہیں، وہ چیز ہے جسے نیا ratio measure کرتا ہے۔
اسے مکمل train کرتی ہے: وہ discipline جس پر پورا method rests کرتا ہے۔
Digital FTE Builder: unit product، end to end built۔ Market اسے AI Engineer کہتا ہے، ایک catch-all title اس شخص کے لیے جو AI components سے applications بناتا ہے اور AI coding agents drive کرتا ہے۔ اس کتاب کا نام sharper ہے، کیونکہ جو چیز آپ build کرتے ہیں وہ sharper ہے: Digital FTE، وہ unit جس سے پوری company assemble ہوتی ہے۔ یہی کتاب کا primary graduate ہے۔ یہ full spine train کرتی ہے: spec-driven development، SKILL.md authoring، agent architecture، tool اور MCP interfaces (MCP وہ standard طریقہ ہے جس سے agent outside tools اور data میں plug ہوتا ہے)، evaluation، اور human oversight، deployment اتنی کہ ship ہو سکے، اور deeper production Cloud AI Engineer کے لیے چھوڑتی ہے۔ اسے end to end train کرتی ہے۔
AI-Native Company Architect: company design کرتا ہے، single Worker نہیں۔ پوری enterprise: Two-Layer Model، management layer، workforce، nervous system جو ان کے درمیان events carry کرتا ہے، اور system of record جس کے against یہ سب run ہوتا ہے۔ Agent Factory وہ process ہے جو یہ architect practice کرتا ہے؛ AI-Native Company وہ product ہے جو وہ ship کرتا ہے۔ کتاب اس کا canonical source ہے۔ پانچ-quarter Certified Agentic AI Architect program اس کی credential ہے۔ مکمل training؛ Architect track سے certified۔
Cloud AI Engineer: production میں AI Worker اور AI-Native Company run کرنے والا۔ Digital FTE build کرنا half ہے؛ اسے reliably run کرنا دوسرا half ہے، اور پوری AI-Native company کو run کرنا بھی۔ جہاں AI-Native Company Architect enterprise design کرتا ہے، یہ role اسے operate کرتا ہے: Workers، management layer، اور nervous system کو real cloud infrastructure پر deploy اور scale کرنا، ship کے لیے Azure Container Apps، durable execution کے لیے Inngest، اور scale کے لیے Dapr اور Kubernetes۔ یہ وہ جگہ ہے جہاں system prototype سے ایسی company بنتا ہے جس پر organization depend کر سکتی ہے۔ Production path train کرتی ہے؛ deeper scale اور platform operations cloud track میں ہیں۔
مارکیٹ کو مطلوب vendor-neutral Forward Deployed Engineer (FDE)
اوپر کے چار بنیادی کردار آپ کی اپنی کمپنی کے اندر یہ خط چلاتے ہیں۔ اسی خط کو گاہک کی کمپنی میں لے جائیں، ایک اندر بیٹھا انجینئر اسے ابتدا سے انتہا تک چلائے، تو اس کا ایک نام ہے جسے بازار اب تیزی سے بھرتی کر رہا ہے۔
ایک Forward Deployed Engineer حقیقت میں کیا کرتا ہے؟ زیادہ تر software engineers صدر دفتر میں product بناتے ہیں اور اسے استعمال کرنے والے گاہک سے کبھی نہیں ملتے۔ FDE اس کے برعکس کرتا ہے۔ وہ گاہک کے اصل کام کی جگہ جاتا ہے، کام کرنے والوں کے ساتھ بیٹھتا ہے، ان کی حقیقی مشکلات سمجھتا ہے، اور وہیں اپنی کمپنی کے platform سے حل بناتا ہے۔ یہ demo نہیں، slide deck نہیں، بلکہ ایسا چلتا ہوا software ہے جو گاہک کے حقیقی ماحول میں کام کرتا ہے۔
فرق یوں سمجھیں جیسے ایک doctor دوسرے شہر سے آپ کا chart پڑھے اور دوسرا کمرے میں بیٹھ کر معائنہ کرے اور وہیں علاج شروع کر دے۔ FDE دوسرا doctor ہے۔
بڑی data analytics کمپنی Palantir، جو حکومتوں اور بڑے اداروں کے لیے software بناتی ہے، نے 2010 کی دہائی کے آغاز میں یہ کردار بنایا اور پہلے اسے «Deltas» کہا۔2 2016 کے قریب تک Palantir میں عام software engineers سے زیادہ FDEs تھے، کیونکہ سرکاری اداروں اور بڑی روایتی کمپنیوں کو موقع پر ایسا شخص چاہیے تھا جو startup جیسی ذہنیت سے اندرونی رکاوٹیں کاٹ سکے۔ Palantir کا فرق سب سے صاف ہے: عام developer ایک صلاحیت اور بہت سے گاہکوں پر کام کرتا ہے، یعنی ایک feature بنا کر سب کو دیتا ہے؛ FDE ایک گاہک اور بہت سی صلاحیتوں پر، یعنی ایک ادارے کے اندر جا کر جو چاہیے حل کرتا ہے۔ اس کے اپنے بیان کے مطابق کام کا دائرہ startup CTO جیسا ہے: اہم منصوبوں پر ابتدا سے انتہا تک ہر چیز کی ملکیت۔ اور اب یہ نسبت باہر سے بھی ثابت ہے: 2026 میں اپنی 6000 افراد کی unit بناتے ہوئے Microsoft نے عوامی طور پر Palantir کو اس نام کو مقبول بنانے کا سہرا دیا۔3
طریقہ FDE 101: Palantir کو اس کردار کی ضرورت کیوں پڑی
یہ بیان کون دے رہا ہے، اور اس کی بات کیوں اہم ہے۔ کردار کی ضرورت کا سب سے صاف بیان Kevin Bai کی 2026 کے وسط میں AI Engineer World's Fair کی نو نشستوں والی FDE track پر دی گئی گفتگو «Forward Deployed Engineering 101» میں ملتا ہے۔4 ان کا کیریئر ایک شخص میں اس کردار کی مختصر تاریخ ہے۔ انہوں نے اس کام کو ایجاد کرنے والی Palantir میں دنیا کے اہم اداروں کے ساتھ FDE منصوبے چلائے۔ پھر وہ Rippling گئے، جہاں یہ کام موجود نہیں تھا، پہلے FDE بنے اور ایک سال میں ٹیم کو تقریباً 25 انجینئرز تک بڑھایا۔ یوں انہوں نے اندر سے وہی کیا جو یہ صفحہ باہر سے بیان کرتا ہے: صفر سے FDE کام شروع کیا اور ٹیم بنائی۔ اب وہ Anthropic کی Applied AI ٹیم میں member of technical staff ہیں، وہی ٹیم جس کے عنوان Applied AI Engineer کو یہ صفحہ کردار کا ایک نام بتاتا ہے۔ ان کا پس منظر بھی نیچے کے Venn diagram جیسا ہے: سفارت کاری، فروخت، business development، product management، customer success اور software engineering، جنہیں FDE ایک کردار میں جوڑتا ہے۔
دلیل سے پہلے دو صاف باتیں۔ Bai نے عمومی شعبے پر بات کی اور اپنے موجودہ کام پر گفتگو سے واضح انکار کیا، اس لیے یہاں کسی frontier lab کی اندرونی practice بیان نہیں ہوتی۔ اور آگے کا خاکہ ایک practitioner کا framework ہے، اسٹیج پر یاد سے بتائے گئے اعداد کے ساتھ، audited research نہیں۔ یہ صفحہ اسے Aggarwal کے حساب اور Brunet کی playbook جیسی حیثیت دیتا ہے: کام خود چلانے والے شخص کی گواہی، اسی نام کے ساتھ۔
مسئلہ کبھی software نہیں تھا۔ پہلے دیکھیں Palantir بیچتی کیا ہے۔ Foundry کسی بھی ادارے کو data ایک جگہ جمع کر کے ontology بنانے دیتی ہے: table 1، table 2 اور table 3 کو proper nouns میں بدلتی ہے، تاکہ warehouses والی کمپنی کے پاس warehouses کی حقیقت بتانے والا ایک table ہو۔ اس کے اوپر گاہک applications بناتے ہیں۔
اب یہ صنعت کے قائد کو دکھائیں۔ Bai کے مطابق اس کا جواب یوں ہے: آپ نے میرا data منظم کر دیا، اس سے میرے business کو کیا ملا؟ یہیں صرف technology بیچنا کم پڑتا ہے۔ مزید یہ کہ vendor کی کامیابی اب گاہک کی software استعمال کرنے کی صلاحیت پر ہے، اس لیے گاہک دو بار ادائیگی کرتا ہے: platform کی، اور پھر اپنے لوگوں کو اتنا سکھانے کی کہ وہ اس سے کچھ بنا سکیں۔ Bai اسے business کا برا طریقہ کہتے ہیں، اور ان کا حل وہ جملہ ہے جس پر صفحے کا پہلا کردار بنا ہے۔ software بیچنا چھوڑیں، گھنٹے بیچنا چھوڑیں، outcome بیچیں۔ ایسے لوگ بھیجیں جو گاہک کے business کی نوعیت سمجھیں، platform پر حل بنائیں اور نتیجہ حوالے کریں۔ consumer goods کا executive shelf placement اور sales throughput کی پروا کرتا ہے۔ data کیسے منظم ہے ایک implementation detail ہے، اور Bai کے مطابق اسے ایسا ہی رہنا چاہیے۔
کن خریداروں کو اس کی ضرورت تھی، اور کیوں۔ Foundry application بنانے کا platform ہے، اس لیے Google، Meta اور labs جیسی بہترین engineers والی کمپنیوں کے لیے دلچسپ نہیں تھا، کیونکہ وہ جو چاہیں خود بنا سکتی ہیں۔ اسے Fortune 500 کی oil and gas کمپنیوں نے چاہا، جہاں Bai کے الفاظ میں pipelines، data pipelines نہیں۔ پیشکش ادھار کے engineers تھی: ایسے لوگ جنہیں گاہک کو بھرتی، تلاش، manage یا برقرار نہ رکھنا پڑے، جو platform پر تربیت یافتہ ہوں، اور کام کے اتنے قریب بیٹھیں کہ اصل مسئلہ ڈھونڈ کر اس کے لیے بنائیں۔
ثبوت contract size میں ہے۔ Fortune 500 کو خدمت دینے والی public SaaS کمپنیوں کو average contract value سے ناپیں، یعنی ایک گاہک vendor کے پاس کتنا خرچ کرتا ہے، تو Bai کے مطابق Palantir تقریبا $4 million کے ساتھ پہلے، ServiceNow $1.2 million، Workday $600,000، اور کوئی دوسرا public SaaS vendor نصف million سے اوپر نہیں۔4 ان اعداد کو چند ہزار افراد کے headcount اور آگے کی market capitalization کے ساتھ پڑھیں۔ outcome بیچنے کی قیمت seat بیچنے سے مختلف ہوتی ہے، اور average contract value یہی بتاتی ہے۔ یہ Digital FTEs کے بارے میں کتاب کا دعویٰ ہے، مگر میز کی vendor والی طرف سے۔
سب سے پہلے امتحان: کیا واقعی FDE درکار ہے؟
Bai کا امتحان دو در دو matrix ہے: آپ جو چیز بیچتے ہیں وہ کتنی technical ہے، اور اسے خریدنے والا کتنا technical۔ چار میں سے تین خانوں کو forward deployment بالکل نہیں چاہیے۔
- تکنیکی product، تکنیکی buyer۔ GitHub اور Datadog۔ software پیچیدہ ہے، مگر خریدار CTO یا CIO اور صارف software engineer ہے، اور اس پیچیدگی کو سمجھنا اس کے کام کا حصہ ہے۔ documentation اور developer relations سے خدمت کریں۔
- قابل ترتیب product، تکنیکی buyer۔ یہاں بھی کچھ خاص نہیں چاہیے۔ technical خریدار سادہ product خود ترتیب دے لیتا ہے۔ self-service یا sales-led طریقہ کافی ہے۔
- قابل ترتیب product، غیر تکنیکی buyer۔ Rippling، Jira اور Slack۔ یہ پیچیدہ ہو سکتے ہیں، مگر ان پر development نہیں بلکہ configuration ہوتی ہے۔ روایتی sales-led طریقہ چلتا ہے۔
- تکنیکی product، غیر تکنیکی buyer۔ یہی واحد خانہ ہے جہاں FDE ضروری ہے، اور یہی Palantir کی market تھی۔
اس diagram سے زیادہ اہم اسے پڑھنے کا انضباط ہے۔ سوال یہ نہیں کہ کیا میں FDE function چاہتا ہوں، کیونکہ مقبول چیز چاہنا آسان ہے۔ سوال یہ ہے کہ کیا مجھے تکنیکی طور پر پیچیدہ چیز ایسے خریدار کو دینی ہے جو اسے نافذ نہیں کر سکتا۔ اگر جواب نہیں ہے تو Bai صاف کہتے ہیں کہ forward deployment شاید درست نہیں، developer engagement یا sales-led طریقہ بہتر ہوگا۔
Bai کا پہلا امتحان: چار میں تین خانوں کو FDE نہیں چاہیے، اور agentic تبدیلی vendors کو چوتھے میں دھکیل رہی ہے۔ یہ ان کا framework ہے، measurement نہیں۔
دو matrix، دو سوال۔ Bai کا مربع vendor کا build-or-not فیصلہ ہے: کیا اس کمپنی کو FDE function بنانا چاہیے؟ آگے Brunet کا matrix ہر engagement کا فیصلہ ہے: کیا یہ گاہک FDE گاہک ہے؟ کتاب کا قاری تیسرے مقام سے دونوں استعمال کرتا ہے، کیونکہ اس کا اپنا platform نہیں۔ Bai اسے ان clients کی طرف لے جاتا ہے جن کے پاس technical چیز ہے مگر اسے نافذ نہیں کر سکتے، اور نیچے بیان کی گئی تبدیلی کے بعد تقریباً سب اسی صورت میں آ گئے ہیں۔ Brunet اندر پہنچنے کے بعد engagement کا scope بتاتی ہیں۔
یہ Solutions Architect یا Sales Engineer جیسا نہیں۔ Solutions Architect مشورہ دیتا ہے: demos چلاتا ہے، whiteboard پر حل بناتا ہے، sample data سے proof-of-concept بنا کر prospect کو sign کرنے پر آمادہ کرتا ہے۔ deal کے بعد اس کا حصہ کم ہوتا ہے۔ FDE وہاں سے شروع کرتا ہے: گاہک کی infrastructure پر real data کے ساتھ production code لکھتا ہے اور حقیقی قدر ملنے تک رہتا ہے۔ امتحان سادہ ہے: اگر کردار customer-specific کام کو production میں چلانے کا ذمہ دار ہے تو FDE کے قریب ہے؛ اگر product ثابت یا سمجھانے کا ذمہ دار ہے تو Solutions Architect کے قریب۔
ادارے OpenAI کا John Deere کے ساتھ کام یہی منطق دکھاتا ہے: See & Spray، customer success، dealer workflows اور موسم سے پہلے سفارشات کے حقیقی operational context میں AI۔ John Deere نے See & Spray کو chemical use میں 70% تک کمی کا credit دیا، اور case study setup، in-season سفارشات، dealer support اور ROI reporting میں AI دکھاتی ہے۔5 کام product roadmap پر نہیں، گاہک کے planting calendar پر رہتا ہے۔ یہی FDE job ایک سطر میں ہے: حقیقی production software، گاہک کی دنیا میں بنا اور اس وقت ship ہوا جب اسے ضرورت تھی۔
یہ وہ جگہ ہے جہاں code، product اور customer ملتے ہیں: software engineer کی build، platform engineer کی product سمجھ اور solutions architect کی customer read، ایک شخص میں جو headquarters نہیں بلکہ گاہک کی دنیا میں بناتا ہے۔
Bai اسی تصویر کو دو شرطوں والے hiring test میں سمیٹتے ہیں: FDE ایک customer-facing software engineer ہے، یعنی ایسا شخص جسے آپ صرف engineering معیار پر team میں رکھیں اور گاہک کے سامنے بھی اعتماد سے بھیجیں۔4 دونوں شرطیں لازم ہیں۔ پہلی ہٹائیں تو ایسا account manager ملتا ہے جو بنا نہیں سکتا۔ دوسری ہٹائیں تو ایسا engineer جسے مسئلے کے مالکوں سے دور رکھنا پڑے۔
ہر AI company اب FDEs کیوں چاہتی ہے؟ 2025 کے پہلے تین quarters میں postings 800% سے زیادہ بڑھیں۔6 Salesforce نے Agentforce کے لیے مخصوص ٹیم بنائی۔7 OpenAI نے تقریبا $4 billion کی investor backing والی majority-owned «Deployment Company» بنائی، بڑی حد تک enterprises کو FDEs دینے کے لیے۔8
2026 کے وسط میں model hyperscalers تک پہنچا۔ AWS نے $1 billion کی unit بنائی، 5–6 engineers کے pods تقریبا 45 دن کے لیے clients کو بھیجنے اور ہزاروں افراد رکھنے کے منصوبے کے ساتھ۔ یہ داؤ لگانے والا پہلا بڑا cloud provider تھا، اور اس نے OpenAI یا Anthropic کی طرح private-equity joint venture کے بجائے اپنی balance sheet سے پوری رقم دی۔9 دو دن بعد Microsoft Frontier Co. نے $2.5 billion اور 6000 افراد کے ساتھ جواب دیا: موجود FDEs، technical consultants، support اور industry salespeople، clients کے اندر، پہلے customers میں Unilever اور Novo Nordisk۔3 ایک ہفتے میں دونوں نے $3.5 billion ایک ہی نام پر لگا دیا۔ model sector بھی پار کر گیا: McKinsey QuantumBlack اب 8+ سال hands-on engineering والے Lead FDEs رکھ رہا ہے، یعنی consulting giant مانتا ہے کہ deployment کے بغیر advice نہیں بکتی۔10
کمپنی Microsoft کے اعلان کی ایک بات محفوظ رکھنے کے قابل ہے۔ وہ platform install یا models integrate کرنے کا وعدہ نہیں کرتا، بلکہ ایسی team کا جو AI systems co-design، deploy اور مسلسل بہتر کرے، اور جسے measurable business outcomes پر پرکھا جائے۔3 یہ گاہک کا success test vendor کے charter میں لکھا ہے، اور یہی test آگے delivery side کی FDE lead بتاتی ہیں۔
وجہ سادہ ہے: 2025 MIT Media Lab کے Project NANDA نے پایا کہ custom enterprise AI pilots میں تقریبا 95% قابل پیمائش return نہیں دکھاتے۔11 اس لیے نہیں کہ AI کام نہیں کرتا، بلکہ اسے کمپنی کے messy حقیقی systems میں fit کرنا مشکل ہے۔ FDE اسی gap کو بند کرتا ہے۔ یہی وجہ ہے کہ Palantir late 2024 میں $136 billion market cap پار کر کے Lockheed Martin سے آگے نکلا،12 اور ہر AI company model نقل کرنا چاہتی ہے۔
یہی study بتاتی ہے کہ بچنے والوں نے کیا کیا۔ 95% failure سمجھاتا ہے؛ اسی report کی دوسری finding استثنا: outside partners والے initiatives تقریبا 67% دفعہ deployment تک پہنچے، مکمل in-house tools تقریبا 33%۔11 اعداد مختلف چیزیں ناپتے ہیں: 95% profit-and-loss impact، 67% صرف deployment تک پہنچنا۔ مل کر کہتے ہیں pilots کمزور models سے نہیں، integration work سے مرتے ہیں جس کے لیے کوئی embedded نہیں، اور باہر کے لوگوں کے ساتھ کمپنیوں نے دوگنا ship کیا۔
اس number کی دو حدیں ہیں۔ report خود کہتی ہے outside partner اور success کا تعلق cause ثابت نہیں کرتا، findings preliminary ہیں، اور ہر deployment صرف 6 ماہ دیکھا گیا۔11 اور comparison vendor سے خریدنے اور اکیلے بنانے کے بیچ تھا۔ vendor-neutral تیسرا column تھا ہی نہیں، کیونکہ 2025 میں category نئی تھی۔ نتیجہ صرف یہاں تک لاتا ہے: باہر کی expertise اکیلے کام سے بہتر ہے۔ کیا expertise ایک vendor platform سے جڑی ہونی چاہیے، یہ اگلا سوال ہے۔
اب کیوں، 2012 میں کیوں نہیں؟ failure rate قیمت سمجھاتا ہے، timing نہیں۔ Palantir کا model ایک دہائی public اور profitable تھا مگر نقل کم ہوئی۔ Bai کی structural hypothesis بہتر جواب ہے: industry نے اچانک Palantir کو درست نہیں سمجھا، software business بدلا۔ تقریبا ہر platform agentic ہے؛ agentic یعنی customizable؛ customizable یعنی گاہک نہیں جانتا product کیا کرتا یا کتنی دور جا سکتا ہے۔ یوں ہر vendor اس ایک خانے میں جاتا ہے جہاں technical چیز non-technical buyer کو دینی ہے۔4 اگر success گاہک کی implementation پر چھوڑیں تو نہ upmarket بیچیں گے نہ نئی industry میں جائیں گے۔
دونوں findings ساتھ پڑھیں: Bai cause بتاتے ہیں، agentic platforms نے ہر vendor کو Palantir بنا دیا؛ MIT effect ناپتا ہے، pilots اس لیے رکتے ہیں کہ integration gap بند کرنے والا embedded شخص نہیں۔ $4 billion، $1 billion اور $2.5 billion اسی gap کو بند کرنے کی قیمت ہے۔
بازار کیا دیتا ہے، دیانت سے پڑھیں۔ viral posts «up to $1M» کہتے ہیں۔ اصل اعداد بغیر inflation کافی مضبوط ہیں۔ Indeed نے April 2025 میں 643 US postings اور ایک سال بعد 5330 گنیں، 729% اضافہ، عام bands $170,000 سے $200,000-plus؛ Anthropic کی postings $200,000–$300,000۔10 median تقریبا $190,000، range $160,000–$220,000۔13 frontier labs کے senior/staff $450,000–$600,000، seven figures ladder کی چوٹی پر موجود مگر دروازہ نہیں۔14 دو باتیں زیادہ اہم ہیں: postings 800%+ بڑھی، candidate pool تقریبا 50%، یعنی supply gap؛ اور verified roles کی review میں sales quota ایک بھی نہیں، یعنی market انہیں engineers کی طرح قیمت دیتا ہے، salespeople کی طرح نہیں۔ data July 2026 میں verify ہوا؛ کردار تیز بدلتا ہے، مستقل چیز discipline ہے، کوئی ایک salary band نہیں۔
خدمات کی صنعت بھی یہی حساب دوسری طرف سے دیکھتی ہے
اوپر والے vendors FDEs باہر بھیجتے ہیں؛ outsourcing world کے پاس اس سے بھی زیادہ existential reason ہے، کیونکہ اس کا model، ہزاروں لوگوں کے human execution hours بیچنا، وہی layer ہے جسے AI absorb کرتا ہے۔ AWS اور Microsoft announcements کے ایک week کے اندر وہ دنیا FDE کے around reposition ہونے لگی۔ Sanjeev Aggarwal، جنہوں نے Infosys کے Nandan Nilekani کے ساتھ Fundamentum co-found کرنے سے پہلے Daksh، India کی BPO industry کے pioneers میں سے ایک، build کیا، نے CNBC-TV18 کے Young Turks Reloaded میں arithmetic صاف رکھی: FDE engineer، product manager، اور AI architect کو ایک person میں fuse کرتا ہے، "almost like a unicorn... a 10x engineer"، اور اس fusion پر ایک firm roughly 100 FDEs کے ساتھ $100 million business build کر سکتی ہے، وہ work جس کے لیے traditional IT services model 2,000 سے 2,500 people لگاتا تھا، 70 سے 90 percent gross margins کے ساتھ۔15 Figures کو veteran projection سمجھیں، measurement نہیں؛ مگر دیکھیں یہ projection کس کی ہے۔ Old model build کرنے والا شخص اس کے successor کا اعلان کر رہا ہے: pyramid کے پچیس heads ایک سے replace، pod-of-one compression company scale پر۔ اس کی conclusion geographic ہے، "India can be the FDE factory for the world"۔ Claim اس سے زیادہ general ہے۔ IT-services decades نے South Asia کو client کے messy systems میں embed ہو کر ship کرنا سکھایا؛ یہ muscle Karachi اور Lahore میں بھی اتنا ہی ہے جتنا Bangalore میں۔ اسے new role میں convert کرنے والی چیز geography نہیں، training ہے، اور اس کتاب کا method وہ conversion ہے۔
Aggarwal کا حساب scale کے مطابق تصویر میں: ایک شخص کے پوڈ کی compression، company scale پر۔ یہ ان کی projection ہے، measurement نہیں۔
اور professional services firms اپنے product کی قیمت بدل رہی ہیں۔ Aggarwal projection دیتے ہیں؛ Big Four نے ship کیا ہے۔ March 2026 میں PwC US کے CEO Paul Griggs نے Financial Times کو بتایا کہ firm عملے کے گھنٹوں کے حساب سے billing کے alternatives دے گی، اور tax اور consulting کے حصوں کو ایسے AI tools میں بدلے گی جو clients شروع کے مراحل میں PwC professional کے بغیر براہ راست استعمال کر سکیں، ممکنہ annual subscription کے ساتھ۔16 platform PwC One کے نام سے ship ہوا، چھ automated services کے ساتھ، M&A due diligence سے tax rules تک۔ Griggs اندرونی مطلب پر صاف تھے: senior لوگ جو AI-first نہیں سوچتے ان کی جگہ سوچنے والے آئیں گے، اور جو سمجھتے ہیں کہ وہ opt out کر سکتے ہیں زیادہ دیر firm میں نہیں رہیں گے۔
اسے تین چیزیں ایک ساتھ پڑھیں، کیونکہ یہ تینوں ہے۔
یہ Aggarwal کا حساب industry کی دوسری طرف سے confirm ہوا۔ انہوں نے pyramid کے 25-to-1 compression کی projection دی۔ PwC کچھ services کے پہلے مراحل سے انسان مکمل نکال رہی ہے، یعنی وہی compression staffing ratio نہیں، product decision کی زبان میں۔ Indian IT services اور Big Four کی دو مختلف firms اسی quarter میں اسی مقام پر پہنچیں۔
یہ outcome pricing کا دعویٰ ہے، ایسی firm کی طرف سے جس کی معیشت اس کے برعکس پر تھی۔ Bai کے contract value figures کہتے ہیں outcomes کی قیمت seats سے مختلف ہے۔ Big Four کا billable hour سے ہٹنا اسی argument کو سب سے بڑے incumbent کا اپنے revenue model کے خلاف عمل میں لانا ہے۔ billable hour محض pricing preference نہیں تھا؛ پورا business تھا۔
اور یہ نیا cage ہے۔ PwC One platform ہے۔ client کے اندر PwC professional اسی پر بناتا ہے، اور اس کے بعد client جو رکھتا ہے وہ اسی پر چلتا ہے۔ structure اگلے حصے کے vendor lock-in جیسا ہے، بس consultancy vendor کی seat پر ہے۔ اس لیے vendor-neutrality کی دلیل labs اور hyperscalers پر نہیں رکتی؛ professional services تک پہنچتی ہے۔
Griggs کی ایک اور سطر مختلف وجہ سے اہم ہے۔ ناکارہ process پر AI لگائیں تو زیادہ پیچیدہ process اور جلدی report ملتی ہے کہ process ہمیشہ کتنا برا تھا۔ یہ MIT failure rate کو buyer کی زبان میں سمجھاتا ہے، اور FDE کا job description client side سے: کسی کو process دوبارہ بنانا ہے، سجانا نہیں۔
اسے ایک firm کی strategy سمجھیں، industry measurement نہیں، Aggarwal projection اور Bai کے یاد کیے figures کی category میں۔ platform projection نہیں؛ وہ ship ہو چکا ہے۔
اب vendor کے اندر سے playbook۔ اوپر demand figures press releases اور posting counts سے ہیں۔ June 2026 میں اندر کا منظر آیا: Pauline Brunet، جو 10 سال enterprise AI deployment کے بعد Cursor کی global FDE team چلاتی ہیں، AI Engineer World's Fair کے پہلے dedicated FDE track پر اپنی playbook لائیں۔17 انہوں نے اسی بات سے آغاز کیا جس سے صفحہ: وہ اس article کی منتظر ہیں جو FDE کو 2026 کی hottest job کہے۔ ان کی چار rules قاری کے لیے اہم ہیں، کیونکہ وہ کام کو ادائیگی کرنے والی طرف سے بیان کرتی ہیں۔
پہلا fit test۔ Brunet ہر engagement کو دو axes پر رکھتی ہیں: client کی digital maturity اور product کی customization۔ mature client اور simple product کو documentation چاہیے، FDE نہیں۔ immature client اور simple product کو traditional rollout۔ FDE بیچ کی high-customization band میں ہے: embedded transformation جہاں client خود staff نہیں کر سکتا، اور acceleration جہاں client capable مگر build deep ہے۔ vendor-neutral قاری کے لیے سبق سیدھا ہے: buyer اسی matrix سے سوچتا ہے؛ discovery call میں جانیں کس cell میں ہیں۔
buyer side role یوں scope کرتی ہے: FDE deep customization میں رہتا ہے، خاص طور پر جہاں client کام staff نہیں کر سکتا۔ Brunet کی گفتگو سے دوبارہ بنایا گیا framework، measurement نہیں۔
دوسرا staff-augmentation line۔ ان کی red flag client کا «ہم understaffed ہیں» کہنا ہے: یہ capability transfer نہیں، hours rent کرنے کی درخواست ہے، اور وہ انکار کرتی ہیں۔ ان کا counter-question: working team کون ہوگی؟ اگر client ساتھ بنانے والوں کے نام نہیں دے سکتا تو engagement body-shopping ہے۔ یہ سوال اپنے ساتھ لے جائیں؛ یہی FDE اور services pyramid کے فرق کا field test ہے۔
تیسرا directional scope۔ وہ open-ended «دو FDE چھ ماہ» اور fixed waterfall promise دونوں رد کرتی ہیں۔ format: مسئلہ نام دیں، KPI baseline نام دیں، مثلا process 3 hours اور success 20 minutes، phased 6-week directional plan دیں، اور client کے systems کے مطابق pivot کی توقع رکھیں۔ وجہ: data، processes اور systems ابھی نہیں دیکھے، اس لیے contact سے پہلے precision جھوٹ ہے۔ یہ delivery side کی spec-driven development ہے: ground truth کے ساتھ spec hard ہوتی ہے۔
اسے پہلے سے کچھ تیار نہ رکھنے کی دلیل نہ سمجھیں۔ جو پہلے precise نہیں ہو سکتا وہ اس client کا plan، systems، data اور baseline ہے۔ profession کی governed knowledge پہلے موجود ہونی چاہیے۔ Brunet کی team Cursor platform کے ساتھ آتی ہے؛ vendor-neutral صورت governed profession کے ساتھ۔ کوئی خالی نہیں آتا، کوئی client numbers جاننے کا دعویٰ نہیں کرتا۔
چوتھا ROI کے تین سوال۔ ہر engagement کم از کم ایک پر ختم ہو: revenue بڑھا، costs کم ہوئیں، یا risk گھٹا؟ ان کی مثال: client گھبرایا کہ agent $2000/day ہے، پھر معلوم ہوا صحیح technician failing equipment کو بھیجتا ہے، تو client نے مانا سستا ہے۔ client نے cost ناپی تھی، return نہیں۔ Strategist track یہی framing سکھاتا ہے؛ Brunet بتاتی ہیں buyer side یہی چلاتی ہے۔
دو disclosures بھی صاف پڑھیں۔ وہ صرف 5+ years experience والے engineers رکھتی ہیں اور early-career نہیں؛ آج salaried vendor door senior door ہے۔ کتاب اس کے برعکس دعویٰ نہیں کرتی۔ اس کے بدلے portfolio، freelance market اور pod-of-one کے doors ہیں جہاں credential deployed Worker اور governed profession slice ہے، résumé tenure نہیں۔ اور انہوں نے ایک offering نام دی جو plan نہیں تھی مگر clients مانگ رہے ہیں: company reorganize کرنے میں مدد، کس کو hire کریں، job descriptions کیا ہوں، agents آنے پر work کیسے بدلے۔ vendor FDE team سے client Harari کا سوال حل کرا رہا ہے۔ یہی service یہ page اور Strategist track ہیں۔
آخر میں وہ صاف کہتی ہیں: team Cursor کے cloud agents deploy اور Cursor SDK پر client codebase کے اندر applications بناتی ہے۔ اگلی paragraph پڑھتے وقت یہ یاد رکھیں۔
vendor lock-in کا مسئلہ۔ اصل پکڑ یہ ہے۔ Palantir کا ہر FDE Palantir platform پر، OpenAI کا اپنے models پر، Salesforce کا اپنے tools پر، اور Cursor کا اپنے agents اور SDK پر بناتا ہے۔ engineer client کے اندر گہرا جاتا ہے، ایک vendor کا product ہر چیز سے جوڑتا ہے اور چلا جاتا ہے۔ بعد میں switch دردناک اور مہنگا ہے، جیسے plumber صرف ایک brand کے pipes لگائے: plumbing چلتی ہے، مگر دوسرے plumber کے لیے دیواریں توڑنی پڑتی ہیں۔ Andrew Ng نے The Batch میں لکھا کہ clients single vendor سے آزاد FDEs نہیں ڈھونڈ پاتے، کیونکہ vendor کے لیے کردار کا مقصد lock-in ہے۔18
AWS کا launch trap واضح کرتا ہے۔ وعدہ تھا clients self-sufficient ہو کر خود بناتے رہیں گے، اور اسی سانس میں کہ systems ان کی AWS environment میں چلیں گے۔ خود کفالت، ایک vendor cloud پر: آپ آزاد ہیں، بس یہاں بناتے رہیں۔ Microsoft نے وہی concession دوسری زبان میں دیا۔ Palantir comparison پر Frontier executive نے کہا Microsoft زیادہ models، data connectors اور open Systems of Record integrations دیتی ہے۔3 دفاع کیا ہے؟ vendor اپنے lock-in کو دوسرے سے ناپ کر looser cage کو feature کہہ رہا ہے۔ کتاب کا objection vendor stage سے مان لیا گیا۔
یہ کتاب وہ FDE سکھاتی ہے جسے market مانگتا مگر پاتا نہیں۔ method کسی vendor سے bound نہیں۔ graduate پوری pipeline، intent کی spec، Worker build، system design اور production run، client کے اندر لے جاتا ہے، single platform lock-in کے بغیر۔ اگلے quarter بہتر model یا اگلے سال cheaper runtime آئے تو switch۔ client choice رکھتا ہے، آپ stack-independent discipline۔ دیانت دار tradeoff: vendor FDE heavily subsidized، کبھی free، کیونکہ vendor lock-in سے کماتا ہے؛ vendor-neutral FDE client یا independent firm سے paid۔ یہی feature ہے: client optionality ابھی خریدتا ہے، switching cost بعد میں نہیں۔ یہ engineer FDE AF Model کے پانچ layers میں کام کرتا ہے، framework سے customer تک، اور ہر layer میں earning کی جگہ سمیت۔
بہت کم پروگرام اس کردار کے vendor-neutral version کی مکمل تربیت دیتے ہیں۔ درست دعویٰ یہ ہے: کتاب vendor-neutral FDE کا technical core train کرتی ہے، وہ half جو market کو نہیں ملتا۔ دوسرا half، client discovery، prioritization، ROI framing، اور unrealistic ask پر push back کرنے کی discipline، Certified Agentic AI Business Strategist track کا ہے۔ Technical core train کرتی ہے؛ consulting layer Strategist track میں رہتی ہے۔
سب سے سخت اعتراض: پلیٹ فارم کے بغیر یہ dev shop ہے
اوپر کے حصے نے کہا platform cage ہے۔ اب سب سے مضبوط جواب لیں، اور دیکھیں کون دیتا ہے: وہی practitioner جس نے کردار کی ضرورت سمجھائی۔
Bai اس اعتراض کو پہلے پکڑتے ہیں کہ ہر customer کے لیے custom چیز بنانے سے درجنوں unmaintainable repositories اور انہیں سیکھنے سے انکار کرتے engineers رہ جاتے ہیں۔ وہ ایک شرط کے ساتھ مانتے ہیں۔ اگر ہر FDE scratch سے بناتا ہے تو FDE function نہیں، dev shop ہے: ممکن ہے profitable ہو، مگر business مختلف ہے۔ FDE کبھی scratch سے software نہیں لکھتا؛ shared primitives پہلے موجود ہوتے ہیں اور engineer انہیں arbitrarily valuable customer solution میں جوڑتا ہے۔ ورنہ maintenance profit-and-loss کھا جائے گی، اگر engineers پہلے استعفا نہ دیں۔4 primitives کتنے granular ہوں، اس کا universal جواب نہیں: کہیں application 60% ready، کہیں domain granular tools مانگتا ہے۔ useful comparison AWS ہے جو DynamoDB دیتی ہے تاکہ کوئی database دوبارہ نہ بنائے، کیونکہ customers بہت وسیع ہیں۔
اسے سنجیدہ لیں، یہی vendor-neutrality کا bill ہے۔ vendor ہٹائیں تو cage کے ساتھ shared primitives بھی نکلتے ہیں۔ کچھ نہ کریں تو pod-of-one، dev-shop-of-one ہے: ہر client کا bespoke code، reuse نہیں، maintenance ہر engagement کے ساتھ margin کھاتی ہے۔ Bai کا test خود پر لگائیں: کیا میرے پاس platform ہے، یا میں اسے بنانے میں invest کروں گا؟
جواب اگلا حصہ ہے۔ vendor-neutral FDE shared primitives لاتا ہے، مگر vendor-owned code نہیں۔
پوڈ میں کیا ہوتا ہے: دو Systems of Record
اوپر سب کچھ بتاتا ہے FDE کہاں کام کرتا ہے؛ ابھی یہ نہیں کہ دروازے سے کیا لاتا ہے، اور vendor-neutrality یہی سوال مجبور کرتی ہے۔
پہلے vendor صورت سے پوچھیں۔ Palantir engineer، Palantir ontology اور وہ tooling لاتا ہے جو کسی اور نے پہلے ہی بنا دی ہے۔ یہی حقیقی leverage ہے اور اسی لیے ایک engineer ہفتوں میں وہ کرتا ہے جو team برسوں میں کرتی۔ یہی پچھلے حصے کا cage بھی ہے: client آزاد ہے کہ بناتا رہے، بشرطیکہ وہ وہیں بناتا رہے۔
کسی vendor کو نکالیں۔ کیا بچا؟ اگر جواب «method، اس کے سر میں» ہے تو وہ human execution کے hours بیچ رہا ہے، وہی services pyramid جسے بدلنا تھا، اور «ہم understaffed ہیں» والا client یہی مانگتا ہے۔ pod-of-one hours پر نہیں، client سے client سفر کرنے والے assets پر قائم ہے۔
دو assets سفر کرتے ہیں، دونوں Systems of Record۔ آپ اپنے ساتھ کیا لاتے ہیں پوری دلیل دیتا ہے؛ یہ اس کا career-facing نصف ہے۔
پہلا method ہے، اور اس نے نہیں بنایا۔ یہی گہری، governed کتاب، humans کے لیے website اور agents کے لیے MCP پر۔ outcome specify کرنا، Worker manufacture کرنا، loop چلانا، checker پر اعتماد اور production result ثابت کرنا۔ ہر graduate یہی لاتا ہے؛ Karachi accounting firm اور Chicago میں ایک، کیونکہ method domain سے نہیں بدلتا۔
دوسرا profession ہے، اور اس نے خود بنایا۔ ایک vertical، ایک jurisdiction، اس کی governance اور committed domain expert کا licence: law، standards، expert-derived procedures، invariants اور decision map۔ ایک professional outcome کی مکمل coverage سے شروع اور engagement by engagement موٹا ہوتا ہے۔ دوسرا کوئی اسے نہیں رکھتا۔
دونوں MCP بولتے ہیں، agent دونوں ایک ساتھ پڑھتا ہے: ایک source بتاتا ہے Worker کیسے بنے، دوسرا profession کیا مانگتا ہے۔ integration work نہیں، کیونکہ ecosystem kernel اسی pairing کے لیے ہے۔
یہ dev shop objection کا جواب ہے۔ Bai کی شرط shared primitives تھی تاکہ engineer scratch سے شروع نہ کرے۔ دونوں Systems اسے پورا کرتے ہیں۔ method، کام کیسے بنتا ہے، کی primitive layer ہے: outcome، Worker، loop، checker، production proof؛ ہر client پر یکساں، dev shop میں یہی نہیں۔ profession، کام کو کیا obey کرنا ہے، کی primitive layer ہے، ایک vertical/jurisdiction میں۔ کوئی per-client code fork نہیں، اس لیے maintenance curve بدلتی ہے: governed corpus maintain ہوتا ہے، code regenerate، nurse نہیں۔ دو صاف نتائج: شرط vendor کے بغیر پوری؛ cost غائب نہیں، منتقل ہوئی۔ repositories کے بجائے corpus، جسے پہلے client سے پہلے fund کرنا ہے، اسی لیے build first sell second۔ Bai کا warning real teams کی decade-long maintenance سے ہے؛ governed corpus curve flat کرتا ہے، یہ کتاب کا claim ہے، measurement ابھی نہیں۔
دوسرا system کیسے موٹا ہوتا ہے۔ Bai کی vendor rule: customer-unique چیز صرف اس customer کے لیے، generalizable چیز وقت کے ساتھ generalize، یوں deployment product scouting ہے۔4 vendor-neutral شکل یہی rule دوسری منزل تک چلاتی ہے۔ general چیز vendor platform میں نہیں، vertical System میں جاتی ہے: تین clients پر چلنے والا standard، expert کا ایک بار لکھا procedure جس پر ہر جگہ sign، jurisdiction کی ہر firm میں قائم invariant۔ یہی engagement by engagement thickening، اور دوسرے client کی کم cost۔
vendor-neutrality انتخاب کیوں مجبور کرتی ہے۔ vendor FDE platform سے specialize کرتا ہے۔ platform ہٹائیں تو specialization کہیں اترے، ورنہ reuse کے بغیر generalist consultant۔ client 2 سے 3 کیا سفر کرتا ہے؟ work shape مفت سفر کرتا ہے، کیونکہ document کو rule کے خلاف پڑھنا، cite کرنا اور unclear escalate کرنا method ہے، System 1 میں۔ premium اس پر نہیں۔ buyer اس پر دیتا ہے جو generalize نہیں: کون سا standard، کس period کا version، کس ملک کا regulator، کس partner کا signature۔ سب professional/jurisdictional؛ audit files سے customs declarations تک نہیں جاتا۔
اس لیے axis profession ہے، اور vendor-neutrality اسے وہاں رکھتی ہے۔ اپنا vertical منتخب کریں selection method، Vertical System of Record بنائیں build method ہے۔
دونوں جواب ساتھ: vendor engineer platform لاتا ہے جو پیچھے رہتا؛ neutral engineer دیا ہوا method اور بنایا profession۔
ایک ترتیب نکلتی ہے، career اسی سے شروع۔ پہلے بنائیں، پھر بیچیں۔ slice customer کا انتظار نہیں، customer پیدا کرتا ہے۔ صفحہ تین بار وجہ دے چکا: portfolio credential، résumé shipped systems پر screen، اور جس buyer کو کچھ دکھایا نہیں وہ baseline نہیں بتاتا۔ mid-size firm میں اس کے profession کا ایک governed page لے جائیں، اگلا سوال میز کی اس طرف سے آئے گا۔
client کا منصفانہ سوال اختتام ہے۔ vendor engineer: platform لاتا ہوں، leverage ہمارے پاس۔ neutral: method اور governed profession، میرے جانے کے بعد working system جسے آپ منتخب stack پر بدل سکتے ہیں اور مجھے hire کر سکتے ہیں۔ مگر client vertical System کا مالک نہیں بنتا۔ domain startup اسے رکھتی ہے، expert material licence اور third-party terms کے ساتھ۔ کسی standard کو system میں serve کرنے کا licence client licence نہیں بنتا۔ client وہ آزادی رکھتا ہے جو vendor صورت نہیں دے سکتی۔
دیانت دار label: demand data measured ہے، pod-of-one method سے۔ مگر governed corpus سے first client بنانے والے vendor-neutral graduates کی verified count نہیں، category نئی اور shelf خالی۔ order کتاب کی reasoning ہے، Aggarwal arithmetic جیسی: مضبوط، measurement ابھی نہیں۔
ایک شخص کا پوڈ
دیکھیں AWS کیا بھیجتا ہے: 5–6 engineers کا pod، site پر تقریبا 45 دن۔ جب humans ہاتھ سے build کریں تو forward deployment ایک چھوٹی team مانگتا ہے۔ کتاب pod کے لوگ بدلتی ہے۔ graduate وہی work client کے اندر اکیلا لاتا ہے؛ ساتھ بیٹھنے والے اب Digital FTEs، اس کے بنائے اور چلائے Workers ہیں۔ 5–6 کی team ایک human اور اس کی Worker workforce بن جاتی ہے۔ job وہی، pod کا مواد مختلف۔ طاقت people add کرنے سے نہیں، method اور Workers سے۔ پچھلے حصے کے ساتھ پڑھیں تو pod کے دو halves ہیں: Workers people کی جگہ، دو Systems vendor platform کی جگہ۔ یہی product-to-engineer ratio کا دوسرا رخ ہے: ہر person کا output بڑھتا، people کم۔ مکمل arc، legacy pod سے compressed pod اور pod-of-one، «How the team got this small» میں ہے۔
اس خطرے کو پرانے طریقے سے team بنانے والے نے نام دیا۔ Bai سے پوچھا گیا کئی FDE ایک project پر ہوں تو انہوں نے اچھا pattern کہا: single point of failure نہ ہو، ایک شخص تمام information لے کر vacation جائے اور engagement رک جائے۔4 pod-of-one یہی risk خالص صورت میں ہے۔ کتاب risk غائب نہیں کہتی، اسے human head سے باہر منتقل کرتی ہے۔ دوسرا engineer knowledge redundancy دیتا ہے؛ یہاں knowledge لکھی ہے: spec، evals، governed corpus، deployed Worker اور runbook۔ headcount کی بجائے artifacts کی redundancy دعویٰ ہے، اور test: اگر آپ 2 ہفتے unavailable ہوں تو کیا دوسرا graduate repository سے engagement اٹھا سکتا ہے؟ نہیں تو pod-of-one نہیں، bus factor one ہے۔
تیسرا دروازہ: آزاد FDE
اب تک FDE کے دو address تھے: vendor payroll اور independent firm۔ تیسرا کھل گیا: open freelance market۔ Upwork کی dedicated category میں bands ہیں: first integration $2,000–$5,000، custom implementation $5,000–$15,000، enterprise deployment $15,000+، ongoing support $4,000–$10,000 ماہانہ، strategic consulting $150–$250/hour۔19 UK contracts mid £600–£750/day، senior £750–£1,200، principal £1,200–£2,000؛ specialist recruiter کہتا ہے seniors permanent پر contract چنتے ہیں۔20 fractional matching اور جلد fill ہونے والی «Fractional FDE Lead» posts بھی آ چکی ہیں۔21
اب دیانت دار reading۔ category موجود، supply نہیں۔ Upwork profiles میں capable generalists، full-stack، DevOps اور app builders ہیں، مگر FDE work، embedded delivery یا end-to-end pipeline بیان نہیں کرتے۔ marketplace نے shelf stock سے پہلے بنائی۔ title training سے پہلے پہنچا۔ اکثر jobs میں empty shelf warning؛ trained reader کے لیے opening: demand projects اور rates دے رہی ہے، supply نے بھرنا نہیں سیکھا۔
تین فرق۔ اول، یہی vendor-neutral FDE کی native market ہے۔ vendor FDE freelance نہیں کر سکتا، کردار payroll/platform کے اندر ہے؛ اس لیے genuine freelancer neutral ہے، neutrality differentiator نہیں entry requirement۔ دوم، retainer disguised maintenance نہیں؛ manufactured Workers چلانے کی monthly fee، باہر سے Digital FTE subscription، pod-of-one recurring revenue۔ سوم، اس door کی border نہیں۔ salaried market اکثر US/Europe work address، freelance/fractional portfolio اور connection۔ Aggarwal کی India والی صلاحیت اس channel سے Karachi، Lagos یا Bangalore سب کے لیے چلتی ہے۔
دو constraints صاف۔ embedding essence ہے اور remote embedding، remote coding سے مشکل: over-communicate، client timezone، occasional on-site کو premium price کا حصہ۔ premium listed نہیں، earned ہے؛ unproven profiles generalist rates کے قریب، demonstrated outcomes bands اوپر لے جاتے ہیں۔ deployed Worker، shipped plugin، live connector app، governed profession slice یہی credential۔ کتاب delivery، Strategist discovery/pricing، reputation آپ contract by contract بناتے ہیں۔
FDE کو direct hire کریں، title غائب۔ FDE skills نہیں address بتاتا ہے: outsider کے طور پر client company کے اندر پوری line۔ سوال: کس کی company میں build؟ اپنی میں چار core roles، client میں FDE۔ اسے ملازم رکھیں تو client company اس کی اپنی، forward deployed نہیں، بس deployed۔ کام وہی، address بدلا۔ title گرتا اور وہ internal core میں AI-Native Company Architect، عموما Cloud AI Engineer بھی۔
یہ آزادی صرف vendor-neutral کو ہے۔ client graduate کو employee رکھ کر اگلی صبح وہی work جاری رکھ سکتا ہے، کیونکہ discipline person میں، vendor platform میں نہیں۔ Palantir/OpenAI چھوڑنے پر vendor engineer talent لے جاتا، leverage platform کے پاس۔ vendor FDE permanent loan؛ relationship ختم تو leverage gone۔ ہمارا graduate hire-for-keeps: پہلے rent FDE، پھر in-house architect، بغیر step کھوئے۔ یہی neutrality ہے: company engineer own کر سکتی ہے، borrow نہیں۔
ایک asymmetry رہتی ہے۔ Agent Factory System of Record اس کے ساتھ اور ہر جگہ available، ecosystem کا open asset۔ دوسرا خود travel نہیں کرتا؛ domain startup رکھتی ہے، expert licence اور third-party terms پر۔ direct hire اس business کی conversation ہے، automatic transfer نہیں۔ discipline portable؛ asset کا owner۔
direct-hire path: client پر deploy ہوں تو FDE؛ direct hire ہوں تو core میں AI-Native Company Architect۔ یہ trip صرف vendor-neutral FDE۔
یہ job حاصل کرنا اپنی discipline ہے۔ FDE résumé software engineer سے مختلف signals پر screen اور interview ایسے round کے لیے مشہور جس میں strong engineers fail۔ Appendix A/B، اور C میں courses-to-round map نیچے ہیں۔
شعبہ جاتی ماہر بطور Skill Author
Subject Matter Expert as Skill Author: وہ role جسے market نے ابھی نام نہیں دیا۔ Accountant، lawyer، یا supply-chain expert جو judgment کو SKILL.md میں encode کرتا ہے، یعنی ایک plain-text file جو agent کے load اور follow کرنے کے لیے skill package کرتی ہے، اور Digital FTE کا knowledge engine بنتا ہے۔ Work concrete ہے: وہ tacit rule لیں جو آپ بغیر سوچے apply کرتے ہیں، جیسے experienced auditor transactions flag کرنے کا فیصلہ کیسے کرتا ہے، یا claims adjuster borderline case کیسے پڑھتا ہے، اسے اتنا precisely لکھیں کہ agent execute کر سکے، پھر test کریں کہ agent کی calls آپ کی calls سے match کرتی ہیں یا نہیں، اور SKILL.md revise کریں جب تک match نہ ہو۔ Market lists اسے miss کرتی ہیں کیونکہ وہ AI work کو engineering-only سمجھتی ہیں۔ یہ کتاب domain judgment کو author، test، deploy کرنے والی چیز سمجھتی ہے۔ Vendor-neutral FDE کی طرح، یہ بھی role ہے جسے تقریباً کوئی اور train نہیں کرتا۔ اسے full train کرتی ہے: judgment in، working agent out۔
دیکھیں یہ دو بے نام کردار صرف ملتے جلتے نہیں، ایک دوسرے کو چاہتے ہیں۔ vendor-neutral FDE کا دوسرا System مؤلف کے بغیر نہیں بن سکتا، کیونکہ procedures practitioner کی آواز اور حقیقی files سے نکلتے ہیں۔ Skill Author کو کوئی چاہیے جو judgment کا governed گھر بنائے۔ کوئی junior partner نہیں: expert 20 سال اور licence، engineer method اور build۔ یہی pairing FDE AF Model میں vertical ہے، اور اپنا vertical منتخب کریں committed expert کے بغیر launch نہیں کرتا۔
بازار نے اس کردار پر قیمت چھاپ دی۔ 2026 کے وسط میں Business Insider نے Yousuf Imran کا profile دیا، Google account executive جن کی sales commissions نے $170,000 base کو تقریبا $986,000/year بنایا۔ April میں انہوں نے Mangosteen Studio بنائی، salespeople کے لیے AI sales tools۔22 headline سے آگے دیکھیں: وہ software engineer نہیں۔ asset 20 سال sales problems کی سمجھ، bet کہ اپنے AI products میں encoded judgment اسے تقریبا million salary پر rent کرنے سے زیادہ۔ ownership framing: اگر era کا upside equity ہے تو equity اپنی company میں۔ یہ Skill Author کا wager ہے، market کے واضح ترین price پر، مگر ایک شخص کا signal، statistic نہیں۔ headline کہتی ہے $986,000 چھوڑے؛ mechanism کہتا domain expertise manufacturing input بنی اور expert نے factory رکھی۔
انجینئر برائے Connector اور Plugin
Connector and Plugin Engineer: ان agent hosts کو وسیع کرتا ہے جو لوگ پہلے سے چلاتے ہیں۔ اپنی loop والے Worker سے پہلے پورا discipline ہے: agent جن چیزوں تک پہنچتا ہے انہیں بنانا۔ market اسے MCP engineer، integration engineer، connector developer، plugin developer، agent-tooling engineer پانچ نام دیتی ہے۔ ایک job، دو addresses۔ connector-native app end users کے chat app، claude.ai، کو بڑھاتی ہے: remote MCP server، tools، stored state، real sign-in اور fail-closed session gate، جسے stranger ایک URL paste کر کے add کرے، پھر model خود customer۔ plugin builders کے coding agent، Claude Code/OpenCode، کو skills، subagents، hooks اور MCP servers کی one install سے بڑھاتا ہے؛ deterministic hook skippable advice اور ہر بار چلنے والے rule کی line ہے۔ move ایک، hosts دو، نیچے artifact ایک MCP server، اسی لیے back-to-back۔ thesis کی through-line: آپ host کے load کرنے کی unit ship کرتے ہیں؛ extension آپ کی، loop host کی۔ دونوں end-to-end deployed artifact تک؛ اپنی sign-in server اور agent identity AI Identity میں، runtime بنانا scope سے باہر۔
سہارا دینے والے کردار
ہر pipeline کو ایسے لوگ چاہییں جو work check کریں، rules set کریں، اور responsibility لیں۔
Evals Engineer: وہ شخص جو AI Workers کو live جانے سے پہلے crash-test کرتا ہے۔ car crash-test اور medicine clinical trials کے بغیر ship نہیں ہوتے۔ real people اور money کے فیصلے والے Worker کو یہی discipline چاہیے۔ tests: کیا صحیح answer؟ unseen چیز پر gracefully fail؟ دی ہوئی lines کے اندر؟ یہ آخر میں لگا afterthought نہیں، ہر chapter میں built۔ core curriculum، add-on نہیں۔
AI Governance Officer: فیصلہ کرتا ہے AI کو کیا allowed ہے۔ ہر employee کی limits: junior accountant $500 تک expense approve، اوپر manager؛ bank teller deposit، loan نہیں۔ Workers کو وہی structure۔ officer company-level rules لکھتا ہے: خود کیا decide، human approval کیا، کبھی touch نہ کرنا کیا۔ regulations mapping بھی: bank fair lending، hospital privacy، Europe data residency۔ AI-Native Company Architect enforcement system بناتا؛ Governance Officer rules کا متن۔ framework discipline train، industry regulations آپ کی input۔ framework کتاب کا، jurisdiction rules آپ کے۔
Digital FTE Supervisor: وہ human جس کا نام line پر ہے۔ Worker claim process، contract draft یا transaction flag کرے تو accountability کسی کی۔ Supervisor human-in-loop: reviewer، output approver، error پر audit trail کا نام۔ یہ builder نہیں؛ day-to-day operator، جیسے shift manager team چلاتا ہے۔ اسے کتاب train کرتی ہے۔
جہاں کتاب جان بوجھ کر رکتی ہے
LLMOps Engineer: model تک، model itself نہیں۔ production agents Cloud AI Engineer کا کام، کتاب train۔ fine-tuning hands-on بھی، مگر last resort، default نہیں۔ fine-tune system کو ایک model snapshot سے باندھ اور method کی optionality کھو دیتا ہے؛ صرف جب prompting، context، tools اور retrieval واقعی کم پڑیں۔ hard stop foundation model scratch سے pre-train کرنا، کیونکہ capability commodity بن رہی ہے۔ fine-tuning اور model-around ops train، foundation models build نہیں۔
Harness Engineer: runtime جو آپ use کرتے ہیں، وہ نہیں جو build کرتے ہیں۔ harness agent runtime، OpenAI Agents SDK، Claude managed agents وغیرہ، loop چلاتا، state manage اور tool calls execute۔ کتاب fluent use اور portability train، کیونکہ discipline winning runtime سے طویل۔ runtime itself build کرنا job نہیں۔ any-runtime operator train، runtime builder نہیں۔
AI Data Engineer: agent-facing data layer۔ System-of-record work Postgres، pgvector اور MCP کو agent-read spine کے طور پر چھوتا ہے۔ classic pipeline/warehouse engineering adjacent، central نہیں۔ agent-facing layer train، general data engineering نہیں۔
دوسرا محور: آپ کی نوع، صرف نشست نہیں
اوپر کا map بتاتا ہے work کہاں ہے، یہ نہیں کون سی seat آپ کے لیے۔ June 2026 میں Boris Cherny، Claude Code کے creator اور execution explosion کے اہم سبب، نے team کو دیکھ کر پوچھا engineering، product، design اور data science «melt into a new kind of role» ہوں تو roles کیا بنتے ہیں۔23 جواب پانچ archetypes، کوئی job function نہیں۔ Prototyper نئی ideas نکالتا، اکثر ship نہیں۔ Builder prototype کو production product/infrastructure تیزی سے بناتا۔ Sweeper system simplify، UI clean، unship، optimize۔ Grower built product کو product-market fit کی طرف iterate۔ Maintainer mature system کو scale پر secure، reliable، fast، efficient رکھتا۔
Cherny کے پانچ archetypes اور map کی seats سے ان کا rhyme: واضح، مگر one-to-one نہیں۔
دو observations کام کرتی ہیں۔ اول types titles سے tied نہیں: Anthropic میں designers، engineers، PMs، data scientists سب میں مختلف spread، یعنی title work نہیں بتاتا، lab کے اندر سے تصدیق۔ دوم اکثر لوگ 2، کبھی 3 types؛ mix product phase سے بدلتا: pre-PMF پہلے 3، mature آخری 3۔ map پر rhymes: Outcome Architect، Prototyper؛ Digital FTE Builder، Builder؛ Evals Engineer، Sweeper؛ Cloud AI Engineer/Supervisor، Maintainer۔ spanning اندر سے pod-of-one ہے: Workers tasks absorb، human کے 2–3 types بتاتے کون سی seats واقعی، کون سی support disciplines borrow کریں، fake نہیں، Sweeper کے subtraction کے لیے evals، Maintainer caution کے لیے governance۔ Cherny claim نہیں، سوال پر ختم: future product roles شاید types جیسے، domain roles سے کم۔ page کا جواب: roles work کا مقام، types آپ کی seat۔
pattern ہی نشان ہے۔ agent era work کو ایک نہیں کئی roles میں پھیلاتا ہے: Workers build، run، govern، judgment سکھانا۔ map point: آپ کہاں ہیں، کون سے archetypes span، کتاب کہاں تک لے جاتی ہے۔
ضمیمہ A: FDE résumé کے چھ signals
یہ interview اور screening practices تیزی سے بدلتی ہیں؛ یہ appendix اور اگلا mid-2026 sources کے against verify کیے گئے۔
بھرتی کرنے والے FDE profile کو software engineer profile کی طرح نہیں پڑھتے۔ حقیقی screening practice چھ signals پر متفق ہوتی ہے، اور جو profile انہیں دبا دے وہ technical bar جانچے جانے سے پہلے ہی رد ہو جاتی ہے۔24 پہلے تین پوچھتے ہیں کہ آپ نے واقعی deliver کیا یا نہیں: shipped production systems، یعنی حقیقی deployments، نہ کہ team backlog میں features؛ quantifiable impact، یعنی صرف «feature X بنایا» نہیں بلکہ گاہک کو اعداد میں کیا فائدہ ہوا؛ اور direct customer exposure، یعنی آپ stakeholder کے ساتھ بیٹھے، product manager کے پیچھے نہیں۔ دوسرے تین پوچھتے ہیں کہ آپ deliver کیسے کرتے ہیں: messy-data work، کیونکہ حقیقی client environments کبھی صاف نہیں ہوتے؛ ownership under ambiguity، یعنی جب کسی نے project define نہیں کیا تب بھی آپ نے اسے چلایا؛ اور AI/LLM depth، یعنی RAG، agents اور evals، وہ وجہ جس سے یہ کردار وجود میں آیا۔
اس سے تین تبدیلیاں نکلتی ہیں۔ ہر نکتے کو سرگرمی سے نتیجے میں بدلیں: "ETL pipeline built" نہیں، "client month-end close پانچ دن سے دو دن پر آیا"۔ "We" نہیں "I" لکھیں، کیونکہ FDE screeners "we" کو دوسروں کے سہارے کیا گیا کام سمجھتے ہیں۔ Competitive-programming awards ہٹا دیں۔ Data-structure puzzles حل کرنے کا انعام غلط interview کی تیاری دکھاتا ہے۔ اس کی جگہ portfolio ہے: deployed Worker، shipped plugin، live connector app، ہر ایک کے ساتھ one-line outcome۔ اس کتاب کا ہر capstone اسی line کے لیے design ہے۔
اس list میں ایک item مختلف ہے اور vendor-neutral candidate کو اس سے شروع کرنا چاہیے: profession کا governed slice، دونوں readers کے لیے published۔ deployed Worker ثابت کرتا ہے آپ build کر سکتے؛ governed slice ثابت کرتا ہے آپ ایسی چیز own کرتے ہیں جو employer نے نہیں دی، اور screener نے غالبا یہ line پہلے نہیں دیکھی۔
ضمیمہ B: FDE interview کا loop اور trap
یہ loop تین سے چھ weeks میں پانچ سے آٹھ stages چلاتا ہے: recruiter screen، hiring-manager screen، practical coding، system design، decomposition case study، client simulation، behavioral round، اور کچھ AI labs APIs پر take-home بھی دیتی ہیں۔24 دو rounds outcome decide کرتے ہیں، اور دونوں وہ نہیں جن کے لیے engineers عام طور پر prepare کرتے ہیں۔
Decomposition round filter ہے۔ آپ کو ایک مبہم، حقیقی enterprise problem ملتا ہے، مثلاً ایک بڑا شہر emergency response time کم کرنا چاہتا ہے؛ call data، traffic data اور ambulance GPS موجود ہیں؛ آپ کے پاس 60 منٹ ہیں۔ سب سے عام وجۂ رد سوال کا فوراً جواب دینا ہے۔ جو امیدوار ابتدا ہی میں کہتا ہے «میں XGBoost سے predictive model بناؤں گا» وہ ناکام ہو چکا، کیونکہ اس نے scope مقرر کرنے سے پہلے حل پیش کیا۔ جو sequence score کرتا ہے وہ یہ ہے: اصل مقصد واضح کریں، stakeholders اور success metric نام دیں، موجود data اور اس کے مالک کا نقشہ بنائیں، subproblems کو خطرے کے لحاظ سے ترتیب دیں، اور سب سے باریک end-to-end skeleton پہلے پیش کریں؛ مفروضے بلند آواز سے کہیں، failure modes خود سامنے لائیں، اور اپنی سوچ مسلسل بیان کریں۔ اس کتاب کے قارئین اسے پہچانیں گے: یہ زبانی spec-driven development ہے۔ round یہ نہیں جانچتا کہ آپ جواب جانتے ہیں یا نہیں؛ یہ جانچتا ہے کہ کسی انسان یا agent کو کام شروع کرنے دینے سے پہلے آپ spec لکھتے ہیں یا نہیں۔
Client simulation دوسرا filter ہے۔ Interviewer frustrated یا non-technical customer role-play کرتا ہے، اور آپ bad news deliver کرتے ہیں، governance-compromising request پر push back کرتے ہیں، یا explain کرتے ہیں کہ system 100% accuracy promise کیوں نہیں کر سکتا، jargon کے بغیر۔ Red flags consistent ہیں: clarify کرنے سے پہلے solve کرنا، cost اور constraints ignore کرنا، thin deployment stories، regulated domains میں zero compliance vocabulary، اور customer instinct کا نہ ہونا۔
یہ live build بھی پھیل رہا ہے: ایک documented loop تین hours کا تھا، thirty minutes vague use case کو requirements میں بدلنا، ninety minutes AI coding assistant کے ساتھ working solution build کرنا while validating every suggestion، اور sixty minutes result کو business language میں stakeholder کو present کرنا۔25 LeetCode کہیں نہیں آیا۔ Middle round اس کتاب کا Mode 1 discipline observation کے تحت ہے: agent direct کرو، ہر output verify کرو، loop narrate کرو۔
ہر company کا flavor حاشیے پر اہم ہے: Palantir data engineering، ontology thinking اور اپنی decomposition round؛ OpenAI اپنی APIs کے خلاف systems build/evaluate، فرق کا سوال «کیسے جانتے ہیں واقعی کام؟»؛ Anthropic، جو Applied AI Engineer کہتی ہے، production LLM systems، evals اور mission alignment۔24 مگر fundamentals ہر جگہ یہی loop۔ preparation 4–6 weeks: fundamentals/stories، پھر system design، پھر partner کے ساتھ timed recorded decomposition، کیونکہ candidates جلد solution پر jump کر کے حیران، آخر company-specific tuning۔
ضمیمہ C: اس کتاب سے FDE کی تیاری
یہ interview اس کتاب کے around design نہیں ہوا، مگر ہو سکتا تھا۔ ہر round material سے map ہوتا ہے:
| Interview round | کیا test کرتا ہے | کتاب کہاں train کرتی ہے |
|---|---|---|
| Decomposition case study | Solve سے پہلے scope؛ spec discipline loud | Spec-Driven Development؛ AI Era میں کیسے سوچیں |
| Practical coding | Agent کے ساتھ verified engineering | Python in the AI Era؛ Code You Never Write؛ Problem Solving اصول |
| AI-specific depth | RAG، agents، evals | Searchable Context؛ Build AI Agents؛ Eval-Driven Development |
| System design | Enterprise deployment constraints | Thesis؛ Choosing Agentic Architectures؛ Deploy the Agent Harness |
| Client simulation | Trust، pushback، business language | Human-Agent Teams؛ Strategist track |
| Live build | Agent کو observation کے تحت direct کرنا | Claude Code and OpenCode؛ Agentic Engineering Fundamentals |
| Portfolio | Shipped, demonstrable outcomes | ہر capstone: deployed Worker، plugin، connector-native app، اور profession کا governed slice |
یہ table نیچے سے اوپر پڑھیں تو بات واضح ہے: hardest rounds، decomposition، live build، eval question، curriculum پر bolted-on extras نہیں؛ curriculum ہی examined ہے۔ spec discipline کے تحت Worker بنانے والا decomposition درجنوں بار کر چکا، کیونکہ Worker کے لیے قابل جواب intent لکھنا اور vague enterprise problem loud scope کرنا ایک skill کی دو آوازیں ہیں۔
حواشی
کئی secondary accounts، Fortune سمیت، internal-build number کو "one-third as often" کہتے ہیں، جس سے تقریبا 22% بنتا ہے؛ report کا figure 33% ہے، یعنی تقریبا half as often، one-third نہیں۔ report خود کہتی ہے external partnership اور success کا تعلق causation ثابت نہیں کرتا، findings preliminary ہیں، اور observation window 6 months ہے۔