यह किताब जो roles train करती है
Market जितनी तेज़ी से titles बना रहा है, उतनी तेज़ी से उन्हें define नहीं कर पा रहा। इनमें से ज़्यादातर titles एक ही discipline की अलग-अलग depths हैं: वही discipline जो यह किताब सिखाती है। यहाँ पूरा map है, और यह किताब हर role की तरफ़ आपको ठीक कहाँ तक ले जाती है।
हर title के पीछे का सवाल
Historian Yuval Noah Harari ने modern education का सबसे कठिन सवाल रखा है: history में पहली बार हमें कोई अंदाज़ा नहीं कि 10 years बाद job market कैसा दिखेगा, इसलिए हम यह भी नहीं जानते कि आज young people को क्या सिखाएँ। पुराना जवाब सीधा था: उन्हें code करना सिखाएँ। वह जवाब टूट रहा है, क्योंकि AI code करना सीखता है और एक year के भीतर ज़्यादातर humans से बेहतर ज़्यादातर code लिख सकता है। Syntax सिखाने का मतलब वह skill सिखाना है जिसे machine real time में absorb कर रही है।
यह page Harari के सवाल का किताब वाला जवाब है। Syntax writers को train न करें; उन लोगों को train करें जो machine के ऊपर खड़े होते हैं: जो specify करते हैं कि क्या build करना है, उसे build करने वाले AI Workers को supervise करते हैं और वापस आए result को verify करते हैं। Syntax automate हो सकता है। Judgment, specification और deployment automate नहीं हो सकते; machine जैसे-जैसे ladder चढ़ती है, ये भी उसके ऊपर चले जाते हैं। नीचे का हर role उसी ladder की एक seat है, और इस page का demand data दिखाता है कि market इन्हीं capabilities के लिए पहले से pay कर रहा है। कारण यह है कि market भी Harari के सवाल का जवाब नहीं दे सकता, इसलिए वह उन लोगों को hire कर रहा है जो दे सकते हैं।
📚 शिक्षण में मदद
पूरा Presentation देखें: यह किताब जो roles train करती है
यहाँ नए agentic AI era के roles define किए गए हैं: वे jobs जो इसलिए exist करती हैं क्योंकि companies अब AI Workers manufacture, run और govern करती हैं। Entries उस तरह sorted हैं जिस तरह work सच में cluster होता है, और हर entry के साथ verdict एक honest scope line है: यह किताब आपको उस role की तरफ़ कितना आगे ले जाती है और कहाँ certification tracks संभालते हैं। Verdicts names से ज़्यादा important हैं। जहाँ किताब रुकती है, वह साफ़ कहती है। और क्योंकि कोई role उतना ही real है जितनी उसके पीछे demand, यह page उन सभी markets में demand track करता है जो इन्हें hire कर रहे हैं: AI labs, hyperscalers, consulting giants, independent services firms और open freelance market।
Map: three levels, one line। एक sentence इस पूरे page को जोड़ता है। यह किताब आपको AI Workers (Digital FTEs) build करना और उन Workers को ऐसी company में जोड़ना सिखाती है जो उन्हीं पर चलती है, यानी AI-Native Company। Job market के पास उस person के लिए एक hot नया नाम है जो यह सब कर सकता है: Forward Deployed Engineer (FDE)। इसलिए three levels हैं और हर level अगले को build करता है: person यानी आप, unit यानी आपका बनाया AI Worker, और enterprise यानी वह company जिसमें ये Workers जुड़ते हैं। इस page का हर role या तो इस line पर एक stop है, उसे support करता है या उस सीमा को दिखाता है जो किताब ईमानदारी से खींचती है। Map से पहले एक और बात: FDE बताता है कि आप कहाँ काम करते हैं, यह नहीं कि आप क्या जानते हैं। Client की company के भीतर काम करें तो market आपको FDE कहता है। वही company आपको hire कर ले तो वही skills आपको उसका AI-Native Company Architect बनाती हैं। Book skills train करती है, market नाम चुनता है।
यह definition सही भी है और अधूरी भी, क्योंकि address यह नहीं बताता कि आप door से क्या carry करके लाते हैं। Vendor का FDE vendor का platform लाता है। Vendor-neutral FDE क्या लाता है, यह कठिन सवाल है और इसका exact जवाब है: दो Systems of Record, एक जो उसे दिया गया और दूसरा जो उसने खुद बनाया। यह section नीचे FDE map के भीतर इसलिए आता है क्योंकि vendor का version देखे बिना जवाब समझ में नहीं आता।
हर कोई same Foundations से शुरू करता है, यानी browser skills जिनकी ज़रूरत किसी भी agent work से पहले हर reader को होती है। इसी floor पर general agent use के दो modes बैठे हैं। Mode 1 का मतलब है general agent से अपना काम तेज़ करना, यह हर reader की proficiency है, job title नहीं। Mode 2 का मतलब है AI Workers manufacture करना जो आपके लिए काम करते हैं, और वहीं job titles आते हैं। Map Foundations floor और Mode 1 Practitioner से शुरू होता है, फिर Mode 2 roles की तरफ जाता है, जो इसका लगभग पूरा हिस्सा हैं।
Vocabulary में नए हैं (Digital FTE, SKILL.md, Agent Factory)? पहले Thesis और Glossary से शुरू करें; यह page मानता है कि आप इन्हें जानते हैं.
एक discipline, दो settings: चार roles अपनी company में pipeline carry करते हैं; एक FDE client में वही line।
पूरा map एक नज़र में: core pipeline, उसे extend और support करने वाली चीज़ें, किताब कहाँ रुकती है, और उसके नीचे की baseline.
वह baseline जहाँ से हर कोई शुरू करता है
Foundations: floor, किसी भी mode से पहले। हर reader same तरह से 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 से अपना काम तेज़ करते हैं: reason करना, लिखना, code करना, analyze करना, plan करना, outcome ship करना और session close करना। यही Mode 1 है, और किताब इसे सबके लिए train करती है: engineers के लिए Claude Code या OpenCode के through, domain experts के लिए Claude Cowork या OpenWork के through, Seven Principles of General Agent Problem Solving के under। यह पहला mode है जो हर reader नीचे दिए Mode 2 roles से पहले run करता है, और यह आपको आपके existing 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 करता है। यह तय करता है कि Worker को क्या achieve करना चाहिए, वह spec लिखता है जो इसे साफ़ pin down करती है, तय करता है कि correct का मतलब क्या है और prioritize करता है कि कौन से Workers को build ही किया जाना चाहिए। Builder how का जवाब दे, उससे पहले यह human what और why का जवाब देता है। जहाँ Strategist track client-facing discovery और ROI own करता है, Outcome Architect internal Worker roadmap और उसके पीछे की specs own करता है। किताब इसे सीधे train करती है: spec-driven development अपने core में ऐसा intent लिखने की discipline है जिसके against Worker को accountable रखा जा सके।
Software history के ज़्यादातर हिस्से में slow part चीज़ को build करना था। Coding agents ने यह बदल दिया। अब एक engineer पहले से कई गुना ज़्यादा ship करता है, क्योंकि agent building करता है। लेकिन उस speed ने एक नया slow part दिखा दिया। अगर एक engineer एक साथ पाँच चीज़ें build कर सकता है, तब भी किसी को तय करना होगा कि कौन-सी पाँच चीज़ें build करने लायक हैं और हर चीज़ को इतना साफ़ लिखना होगा कि agent उसे execute कर सके। इस role में उसी deciding को intent कहा जाता है, और वह तेज़ नहीं हुआ।
यह shift एक number में दिखता है। Companies पहले लगभग हर आठ engineers पर एक product manager रखती थीं, यानी direction set करने वाला एक person। हर engineer का output multiply होने के बाद वही एक person effectively बीस लोगों के work को feed करता है।1 Building scale हुई, deciding नहीं। इसलिए deciding bottleneck बन गया: वह point जहाँ बाकी सब wait करता है।
Market इसे product managers की shortage मानता है। यह किताब इसे अलग तरह से पढ़ती है: यही वह moment है जब intent own करने वाला Outcome Architect company की सबसे important seat बनता है। AI workforce जितनी बड़ी होगी, उतनी ही वह उस human पर depend करेगी जो exact बता सके कि उसे क्या build करना है।
Agentic coding के साथ execution scale हुई; क्या build करना है यह तय करने वाला work scale नहीं हुआ। यही widening gap नया ratio मापता है, engineers की shortage नहीं।
इसे किताब पूरी तरह train करती है: यही वह discipline है जिस पर पूरा method टिका है।
Digital FTE Builder: unit product, end to end built। Market इसे AI Engineer कहता है, यानी ऐसा catch-all title जो AI components से applications build करने और AI coding agents drive करने वाले व्यक्ति के लिए use होता है। इस किताब का नाम sharper है, क्योंकि आप जो build करते हैं वह sharper है: Digital FTE, वह unit जिससे पूरी company assemble होती है। यह किताब का primary graduate है। यह full spine train करती है: spec-driven development, SKILL.md authoring, agent architecture, tool और MCP interfaces, evaluation और human oversight, deployment इतना कि आप ship कर सकें, और deeper production depth Cloud AI Engineer के लिए छोड़ती है। इसे end to end train करती है.
AI-Native Company Architect: company design करता है, single Worker नहीं। पूरी enterprise: Two-Layer Model, management layer, workforce, उनके बीच events carry करने वाला nervous system, और वह system of record जिसके against सब कुछ run होता है। Agent Factory वह process है जिसे यह architect practice करता है; AI-Native Company वह product है जो वह ship करता है। किताब इसका canonical source है। पाँच-quarter Certified Agentic AI Architect program इसकी credential है। पूरी तरह train; Architect track से certified.
Cloud AI Engineer: production में AI Worker और AI-Native Company run करने वाला person। Digital FTE build करना काम का आधा हिस्सा है; उसे reliably run करना दूसरा आधा है। उसी तरह पूरी 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 कर सकती है। Book production path train करती है; deeper scale और platform operations cloud track में हैं.
Forward Deployed Engineer (FDE): वह vendor-neutral version जो market को नहीं मिलता
ऊपर के चार core roles अपनी company के अंदर पूरी line चलाते हैं। वही line एक embedded engineer client की company में end to end ले जाए, तो market उसे Forward Deployed Engineer कहता है।
FDE असल में क्या करता है? ज़्यादातर software engineers headquarters में product build करते हैं और उसका उपयोग करने वाले customer से कभी नहीं मिलते। FDE इसका उल्टा करता है। वह customer के असली workplace जाता है, work करने वाले लोगों के साथ बैठता है, उनकी real problems समझता है और अपनी company के platform से वहीं on-site solution build करता है। Demo नहीं। Slide deck नहीं। Customer के real environment में चलने वाला working software।
इसे ऐसे समझें जैसे एक doctor दूसरे शहर से आपकी file पढ़ता है और दूसरा उसी room में बैठकर आपका examination करता है और तुरंत treatment शुरू कर देता है। FDE दूसरा doctor है।
Palantir, governments और large enterprises के लिए software बनाने वाली major data analytics company, ने early 2010s में यह role बनाया और शुरू में इन्हें Deltas कहा।2 लगभग 2016 तक Palantir के पास regular software engineers से ज़्यादा FDEs थे, क्योंकि उसके customers, government agencies और large traditional enterprises, को on-site ऐसे person की ज़रूरत थी जो startup mentality से internal bureaucracy काट सके। Palantir का difference सबसे साफ़ है: regular developer one capability, many customers पर focus करता है, यानी एक feature बनाकर सबको ship करता है; FDE one customer, many capabilities पर focus करता है, यानी एक client के साथ embed होकर उसकी जो भी need हो उसे solve करता है। Job की उनकी description इसका scope पकड़ती है: यह startup CTO जैसा दिखता है। High-stakes projects में आप start से finish तक सब own करते हैं। अब outside evidence भी lineage confirm करता है: 2026 में अपनी 6,000-person FDE unit launch करते हुए Microsoft ने publicly Palantir को title popularize करने का credit दिया।3
FDE 101: Palantir को यह role क्यों चाहिए था
यह account किसका है और क्यों मायने रखता है। Role क्यों exist करता है, इसका सबसे साफ़ account Kevin Bai की Forward Deployed Engineering 101 talk से आता है, जो mid-2026 AI Engineer World's Fair में उसी nine-session FDE track पर हुई जहाँ आगे इस page पर Brunet की talk भी हुई।4 उनकी career एक person के through role की short history है। उन्होंने job invent करने वाली company Palantir में उन institutions के लिए FDE engagements lead किए जिन्हें वे world की most important institutions कहते हैं। फिर वे वहाँ गए जहाँ function था ही नहीं: Rippling की FDE team के first person बने और एक year में team को लगभग 25 engineers तक बढ़ाया। यानी उन्होंने अंदर से वही किया जिसे यह page बाहर से describe करता है: किसी company में zero से FDE practice शुरू की और staff की। अब वे Anthropic Applied AI team में member of technical staff हैं, वही team जिसके role का title यहाँ Applied AI Engineer बताया गया है। उनका अपना background नीचे Venn diagram बनने से पहले ही उसके जैसा है: diplomacy, sales, business development, product management, customer success और software engineering, जिन्हें forward deployed engineering एक job में जोड़ता है।
Argument से पहले दो honest notes। उन्होंने discipline in general पर बात की और current work discuss करने से साफ़ मना किया, इसलिए यहाँ कुछ भी किसी frontier lab की internal practice describe नहीं करता। आगे practitioner framework और stage पर याद किए गए figures हैं, audited research नहीं। यह page इसे Aggarwal की arithmetic और Brunet के playbook जैसा status देता है: जिसने सच में function run किया है उसकी testimony, उसी label के साथ।
Problem कभी software नहीं था। पहले देखें Palantir सच में क्या बेचता है। Foundry किसी भी size की organization का data centralize करके ontology बनाता है: table one, table two और table three को proper nouns में बदलता है, ताकि warehouses वाली company के पास warehouses के बारे में truth बताने वाली एक table हो। उसके ऊपर customers applications build करते हैं।
अब इसे industry leader को दिखाएँ। Bai के version में जवाब है: आपने मेरा data organize कर दिया, इससे मेरे business को क्या मिला? केवल technology बेचना यहीं कम पड़ता है। इससे भी बुरा, vendor की success customer की software use करने की ability पर depend करती है, इसलिए customer दो बार pay करता है: एक बार platform के लिए, फिर अपने people को इतना train करने के लिए कि वे उस पर कुछ build कर सकें। Bai इसे terrible business कहते हैं और fix वही sentence है जिसके नाम पर इस page का पहला role है। Software बेचना बंद करें, hours बेचना बंद करें, outcome बेचें। ऐसे people भेजें जो customer के business की nature समझें, platform पर solution build करें और result hand over करें। Consumer goods executive shelf placement और sales throughput की चिंता करता है। Data कैसे organized है implementation detail है, और Bai कहते हैं उसे होना भी चाहिए।
किन buyers को यह चाहिए था और क्यों। Foundry app-building platform है, इसलिए Google, Meta और labs जैसी companies को इसमें interest नहीं था, क्योंकि उनके पास great engineers हैं और वे organization की need खुद build कर सकती हैं। इसे oil and gas वाली Fortune 500 चाहिए थी, जहाँ Bai के शब्दों में pipelines data pipelines नहीं हैं। Offer था engineers on loan: client को उन्हें hire, recruit, manage या retain नहीं करना; वे platform पर trained हैं और work के इतना close बैठते हैं कि real problem खोजकर उसके लिए build कर सकें।
Proof contract size में है। Fortune 500 serve करने वाली public SaaS companies को average contract value से मापें, यानी एक customer vendor पर कितना spend करता है, तो Bai Palantir को लगभग $4 million पर first, ServiceNow को $1.2 million, Workday को $600,000 और बाकी सभी public SaaS companies को half-million से नीचे रखते हैं।4 इन्हें उसी breath में बताए गए कुछ thousand headcount और आगे के market-cap figure के साथ पढ़ें। Outcomes बेचने की pricing seats बेचने से अलग है, और ACV वही number बताता है। Vendor side से आया यही इस किताब का Digital FTE claim भी है।
सबसे पहले test: क्या आपको सच में FDE चाहिए?
Bai का screen two-by-two है: जो चीज़ आप बेचते हैं वह कितनी technical है और उसे खरीदने वाला कितना technical है। चार में तीन cells को forward deployment बिल्कुल नहीं चाहिए।
- Technical product, technical buyer। GitHub, Datadog। Software complicated है, पर buyer CTO या CIO और user software engineer है; complexity absorb करना उनके job का हिस्सा है। Documentation और developer relations से serve करें।
- Configurable product, technical buyer। यहाँ भी कुछ special नहीं चाहिए। Technical buyer simple product को किसी के help के लिए fly किए बिना configure करता है। Self-serve या sales-led motion।
- Configurable product, non-technical buyer। Rippling, Jira, Slack। ये complex हो सकते हैं, पर इन पर development नहीं, configuration होती है। Traditional sales-led motion काम करता है।
- Technical product, non-technical buyer। केवल यही cell है जहाँ FDE आवश्यक है, और यही Palantir का market corner है।
Diagram पर उनकी discipline diagram से ज़्यादा important है। सवाल यह नहीं कि क्या मुझे FDE function चाहिए, क्योंकि fashionable चीज़ चाहना आसान है। सवाल है: क्या आपको technically complicated चीज़ ऐसे buyer तक ले जानी ही पड़ती है जो उसे implement नहीं कर सकता? अगर जवाब no है, वे साफ़ कहते हैं: forward deployment शायद सही fit नहीं, developer engagement या sales-led motion बेहतर serve करेगा।
बाकी सब से पहले Bai का screen: चार में तीन cells को FDE नहीं चाहिए, और agentic turn vendors को चौथे में push कर रहा है। यह उनका framework है, measurement नहीं।
दो matrices, दो अलग सवाल। Bai का square vendor का build-or-not decision है: क्या इस company को FDE function रखना भी चाहिए? आगे Brunet का matrix per-engagement सवाल है: क्या यह client FDE client है? इस किताब का reader तीसरी position से दोनों use करता है, क्योंकि वह अपना platform नहीं बेचता। Bai का square बताता है किन clients की तरफ़ चलना है, यानी जिनके पास ऐसी technical चीज़ है जिसे वे implement नहीं कर सकते; नीचे बताए shift के बाद इनमें लगभग सभी आते हैं। Brunet का matrix बताता है कि room में पहुँचने के बाद engagement कैसे scope करना है।
यह Solutions Architect या Sales Engineer जैसा नहीं है। Solutions Architect advise करता है: demo चलाता है, whiteboard पर solutions design करता है और sample data से proof-of-concept prototype बनाकर prospect को sign करने के लिए convince करता है। Deal close होने के बाद उसका involvement usually घट जाता है। FDE वहीं से शुरू करता है जहाँ Solutions Architect रुकता है। वह customer की infrastructure पर real data के साथ production code लिखता है और customer को real value मिलने तक रहता है। Simple test: role customer-specific work को production में सच में चलाने के लिए accountable है तो FDE के करीब है; product prove या explain करने के लिए accountable है तो Solutions Architect के करीब।
Real example OpenAI और लगभग 190-year-old farming company John Deere का work है। यह same deployment logic दिखाता है: See & Spray, customer success, dealer workflows और preseason recommendations के आसपास AI को real operational context में apply करना। John Deere See & Spray को chemical use में up to 70% कमी का credit देता है, और OpenAI case study setup, in-season recommendations, dealer support और ROI reporting में AI use दिखाती है।5 Work customer के planting calendar पर रहता है, product roadmap पर नहीं। यही FDE job one line में है: customer की world में built real production software, जब customer को सच में चाहिए तब shipped।
FDE वह जगह है जहाँ code, product और customer मिलते हैं: software engineer का build, platform engineer की product instincts और solutions architect का customer read, एक person में जो headquarters नहीं बल्कि customer की world में build करता है।
Bai उसी picture को two-condition hiring test में compress करते हैं: FDE customer-facing software engineer से ज़्यादा कुछ नहीं, यानी ऐसा person जिसे केवल engineering bar पर team में hire किया जा सके और customer के सामने भी trust किया जा सके।4 दोनों halves true होने चाहिए। पहला हटाएँ तो account manager मिलता है जो build नहीं कर सकता; दूसरा हटाएँ तो engineer मिलता है जिसे उन लोगों से दूर रखना पड़ता है जिनकी problem वह solve कर रहा है।
हर AI company अब FDE क्यों चाहती है? 2025 के पहले three quarters में FDE postings 800% से अधिक बढ़ीं।6 Salesforce ने Agentforce platform support करने के लिए dedicated FDE team बनाई।7 OpenAI ने Deployment Company बनाई, एक majority-owned subsidiary जिसे investor consortium से लगभग $4 billion मिले और जो largely enterprises में FDE staff करने के around बनी।8
Mid-2026 में model hyperscalers तक पहुँचा। AWS ने नई Forward Deployed Engineering unit को $1 billion commit किए, पाँच से छह engineers के pods को clients के पास roughly 45-day deployments पर भेजा और इसे thousands में staff करने की plan बनाई। यह bet लगाने वाला पहला major cloud provider था और OpenAI या Anthropic जैसी private-equity joint venture के बजाय अपने balance sheet से funded था।9 दो days बाद Microsoft ने largest commitment दिया: Microsoft Frontier Co., $2.5 billion backing और 6,000 people वाली नई operating unit, जिसमें existing Microsoft FDEs, technical consultants, support staff और industry-experienced salespeople सीधे clients के साथ embedded थे; early customers में Unilever और Novo Nordisk थे।3 एक week में two largest cloud providers ने same job title के पीछे combined $3.5 billion लगाया। Model sectors भी पार कर चुका है: McKinsey QuantumBlack सीधे Lead Forward-Deployed Engineers hire कर रहा है और eight-plus years hands-on engineering माँग रहा है, यानी consulting giant मान रहा है कि deployment के बिना advice नहीं बिकती।10
Microsoft की own announcement का एक detail याद रखें। वह platform install या models integrate करने का promise नहीं करती। वह ऐसी team promise करती है जो AI systems co-design, deploy और लगातार improve करे, और जिसे measurable business outcomes पर judge किया जाए।3 यह client का success test vendor charter में लिखा हुआ है, और आगे page पर vendor FDE lead delivery side से यही test देती है।
कारण simple है: MIT Media Lab की 2025 Project NANDA study ने पाया कि लगभग 95% custom enterprise AI pilots measurable return नहीं दिखाते।11 AI काम नहीं करता इसलिए नहीं, बल्कि उसे company के messy real-world systems में fit करना बहुत कठिन है। FDEs उसी gap को close करने के लिए exist करते हैं। यही एक कारण है कि Palantir late 2024 तक $136 billion market cap पार कर Lockheed Martin से आगे निकला,12 और अब हर AI company model copy करना चाहती है।
Same study survivors के बारे में भी बताती है। 95% failure समझाता है। उसी report का दूसरा finding exception समझाता है: outside partners के साथ चलने वाले initiatives लगभग 67% deployment तक पहुँचे, जबकि entirely in-house tools लगभग 33%।11 Numbers carefully पढ़ें क्योंकि वे different things measure करते हैं। 95% profit-and-loss impact के बारे में है; 67% deployment तक पहुँचने के बारे में। Together वे कहते हैं कि pilots weak models से नहीं मरते। वे उस integration work से मरते हैं जिसे करने के लिए कोई embedded नहीं था, और outside people लाने वाली companies ने लगभग twice as often ship किया।
उस number की दो limits हैं। Report कहती है outside partners और success का link cause prove नहीं करता, findings preliminary हैं और हर deployment केवल six months observe हुआ।11 और exact comparison देखें: vendor से buying बनाम अकेले building। Vendor-neutral तीसरा column है जिसे study ने sample नहीं किया, क्योंकि 2025 में वह मुश्किल से exist करता था। इसलिए finding reader को section के front door तक लाती है, आगे नहीं। Outside expertise अकेले जाने से बेहतर है। क्या expertise को one vendor platform से welded होना चाहिए, यह नीचे का सवाल है।
अब क्यों, 2012 में क्यों नहीं। Failure rate बताती है role pay क्यों करता है, timing नहीं। Palantir model decade से public, profitable और visible था, फिर भी लगभग किसी ने copy नहीं किया। Bai की hypothesis structural है और available best answer है: industry ने late notice नहीं किया कि Palantir right था; software business बदला। लगभग हर platform अब agentic है। Agentic का मतलब customizable। Customizable का मतलब customer अब नहीं जानता product क्या करता है या कितनी दूर push किया जा सकता है। इससे लगभग हर vendor square के उस single cell में आता है जिसे forward deployment चाहिए: technical चीज़ ऐसे buyer को बेचना जो implement नहीं कर सकता।4 Product success customer की implementation ability पर छोड़ें, वे warn करते हैं, तो न upmarket sell करेंगे, न new industry में expand।
दो findings साथ पढ़ें तो fit होती हैं। Bai cause बताते हैं: agentic platforms ने हर vendor को Palantir बनाया। MIT effect मापता है: pilots कहीं नहीं जाते क्योंकि implementation gap close करने वाला कोई embedded नहीं। Page का $4 billion, $1 billion और $2.5 billion industry का उसी gap को close करने का payment है।
Market क्या pay करता है: honestly पढ़ें। Viral posts role को up to $1M/year से lead करते हैं। Real numbers inflation के बिना strong हैं। Indeed ने April 2025 में 643 US FDE postings और year बाद 5,330 count कीं, 729% rise, typical bands $170,000 से $200,000-plus। Anthropic postings $200,000 से $300,000 हैं।10 Market median करीब $190,000 है, rough range $160,000 से $220,000।13 Frontier labs में senior और staff FDE $450,000 से $600,000 पार करते हैं और seven figures one lab engineering ladder के very top पर exist करते हैं, पर वह career ceiling है, entry door नहीं।14 Data के two details single figure से अधिक important हैं। First, postings nine months में 800% से अधिक बढ़ीं, candidate pool roughly 50%: supply gap, जहाँ salary pressure आता और trained reader enter करता है।6 Second, verified FDE roles की one review में किसी में sales quota नहीं था।14 Market FDE को engineer की तरह pay करता है, salesperson की तरह नहीं; ऊपर Sales Engineer difference price में दिखता है। Data last July 2026 verify हुआ। Role fast-moving है और durable point discipline है, कोई single band या hiring count नहीं।
Services industry दूसरी तरफ़ से वही math देखती है
ऊपर vendors FDE भेजते हैं। Outsourcing world के पास care करने का existential reason है, क्योंकि उसका model, thousands of people के human execution hours बेचना, वही layer है जिसे AI absorb करता है। AWS और Microsoft announcements के week में वह world FDE के around reposition होने लगा। India's BPO pioneer Daksh founder और Infosys के Nandan Nilekani के साथ Fundamentum co-founder Sanjeev Aggarwal ने CNBC-TV18 Young Turks Reloaded पर arithmetic plain रखी: FDE engineer, product manager और AI architect को one person में fuse करता है, almost unicorn और 10x engineer; इस fusion पर firm roughly 100 FDEs से $100 million business बना सकती है, जिसे traditional IT services model 2,000–2,500 people से staff करता, और gross margin वे 70–90% रखते हैं।15 Figures veteran projection हैं, measurement नहीं। पर देखें किसका projection है। Old model builder successor declare कर रहा है: pyramid के 25 heads one से replace, company scale पर pod-of-one compression। Conclusion geographic है, India world की FDE factory, IT delivery decades new discipline में convert। Claim आगे generalize होता है। Client messy systems में embed-and-ship muscle Karachi और Lahore में भी Bangalore जितनी है। Conversion geography नहीं, training है; book method किसी के भी work करने पर available है।
Aggarwal arithmetic scale पर: pod-of-one compression company scale पर। उनका projection, measurement नहीं।
Professional services firms अपने product को reprice कर रही हैं। Aggarwal project करते हैं; Big Four ship कर चुका है। March 2026 में PwC US CEO Paul Griggs ने Financial Times को कहा firm staff hours billing alternatives देगी और tax तथा consulting के हिस्सों को AI-powered tools में बदलेगी जिन्हें clients first steps में PwC professional के बिना directly use कर सकें, शायद annual subscription पर।16 PwC One platform six automated services के साथ ship हुआ, M&A due diligence से tax rules तक। Griggs blunt थे: senior people जो AI-first नहीं सोचते, सोचने वालों से replace होंगे; opt out मानने वाले firm में long नहीं रहेंगे।
इसे three things साथ पढ़ें।
यह Aggarwal arithmetic industry के दूसरे end से confirmed है। उन्होंने pyramid 25:1 compress project किया; PwC कुछ service first steps से human हटाता है, same compression product decision के रूप में। Indian IT services और Big Four same quarter में same place पहुँचे।
यह outcome-pricing claim है, उस firm के action में जिसकी economics opposite थी। Bai ACV figures कहते हैं outcomes seats से differently price होते हैं। Big Four का billable hour से हटना largest incumbent का own revenue model के against argument act करना है। Billable hour preference नहीं, पूरा business था।
यह नया cage है। PwC One platform है; deployed professional उस पर build करता और client बाद में वहीं run करता है। Structure vendor lock-in जैसा, consultancy vendor seat पर। इसलिए neutrality labs और hyperscalers से professional services तक पहुँचती है। Embedded professional work reader इस version की expect करे।
Griggs की warning अलग reason से यहाँ है: inefficient process पर AI layer करें तो more complicated process और fast report मिलती है कि process कितना खराब था। यह MIT failure buyer explain करता और FDE job client side से लिखता है: process rebuild करना है, decorate नहीं।
इसे one firm strategy समझें, industry measurement नहीं, Aggarwal projection और Bai figures की class में। Platform ship हुआ, projection नहीं।
Vendor के अंदर से playbook। Demand press और posting counts से थी; June 2026 में inside view आई। Ten years enterprise AI deployment के बाद Cursor global FDE team चलाने वाली Pauline Brunet ने AI Engineer World's Fair के first dedicated FDE track पर playbook दी।17 उन्होंने page जैसा read दिया: FDE को 2026 hottest job कहने वाले article का wait। Four rules paying side से job describe करती हैं।
पहला, fit test। Brunet हर engagement को दो axes पर score करती हैं: customer कितना digitally mature है, और product कितना customizable है। Mature customer और simple product को documentation चाहिए, FDE नहीं। Immature customer और simple product को traditional rollout चाहिए, FDE नहीं। FDE बीच के band में रहता है: जहाँ customer खुद work staff नहीं कर सकता वहाँ embedded transformation, और जहाँ customer capable है लेकिन build गहरा है वहाँ acceleration। Vendor-neutral reader के लिए lesson सीधा है: buyer पहले से इसी matrix के अनुसार सोचता है। Discovery call में जाते समय जानें कि आप किस cell में खड़े हैं।
Buyer side scope: FDE deep customization में, core वहाँ जहाँ client staff नहीं कर सकता। Brunet talk से redrawn। Framework, measurement नहीं।
दूसरा, staff-augmentation की सीमा। Client का यह कहना कि “हम understaffed हैं” उनका red flag है: यह capability transfer करने के बजाय hours rent करने की request है, और वह इसे decline करती हैं। उनका counter-move एक सवाल है: working team कौन होगी? अगर client उन लोगों के नाम नहीं बता सकता जो आपके साथ build करेंगे, तो engagement छिपी हुई body-shopping है। इस सवाल को अपने साथ रखें। यह इस page द्वारा FDE और services pyramid के बीच खींचे गए अंतर का field test है।
तीसरा, directional scope। वह open-ended engagements, जैसे “छह महीने के लिए दो FDEs ले लें,” और fixed waterfall promises, दोनों से इंकार करती हैं। उनका format है: problem का नाम दें, KPI baseline तय करें, जैसे “यह process तीन घंटे लेता है; success बीस मिनट है,” phased six-week directional plan की commitment दें, और client के real systems से जो सीखें उसके अनुसार pivot की अपेक्षा रखें। उनका बताया कारण इस book के readers पहचानेंगे: उन्होंने अभी customer का data, processes या systems नहीं देखा, इसलिए contact से पहले precision एक झूठ है। यह delivery side से बोला गया spec-driven development है: ground truth सामने आने पर spec सख्त होती जाती है।
इस rule को ध्यान से पढ़ें, क्योंकि इसे आसानी से इस argument की तरह गलत सुना जा सकता है कि बिना कुछ तैयार किए पहुँचना चाहिए। ऐसा नहीं है। Contact से पहले जो precise नहीं हो सकता, वह इस client का plan है: उसके systems, उसका data और उसका baseline number। जो पहले से मौजूद हो सकता है और होना चाहिए, वह profession का अपना governed knowledge है, जो client के साथ नहीं बदलता। Brunet की team Cursor का पहले से बना platform लेकर आती है। Vendor-neutral version पहले से governed profession लेकर आता है। दोनों में से कोई खाली हाथ नहीं आता, और कोई client के numbers जानने का दिखावा नहीं करता।
चौथा, ROI के तीन सवाल। हर engagement को कम से कम एक outcome पर समाप्त होना चाहिए: क्या हमने revenue बढ़ाया, costs घटाईं या risk कम किया? उनका example एक ऐसे client का है जो agent की $2,000 प्रतिदिन लागत से परेशान था, जब तक उन्होंने नहीं पूछा कि agent कर क्या रहा है: वह failing equipment के पास सही technician भेज रहा था। तब client ने माना कि agent सस्ता था। Client ने cost मापी थी, return कभी नहीं मापा। Strategist track यह framing सिखाता है। Brunet पुष्टि करती हैं कि buyer side पर यही framing चलती है।
उनके दो और disclosures को साफ़-साफ़ पढ़ना चाहिए। वह केवल पाँच या अधिक वर्षों के experience वाले engineers hire करती हैं और अभी early-career candidates hire नहीं करतीं। इसलिए salaried vendor door आज senior door है। यह book इसके विपरीत दिखावा नहीं करती। इसके बजाय यह वे doors देती है जो tenure नहीं देखते: portfolio, freelance market और pod of one, जहाँ credential résumé की line नहीं बल्कि deployed Worker और profession का governed slice है। उन्होंने एक ऐसी offering का भी नाम लिया जिसकी उन्होंने कभी planning नहीं की थी लेकिन clients की लगातार demand के कारण अब बना रही हैं: company को फिर से organize करने में मदद, किसे hire किया जाए, job descriptions में क्या लिखा हो और agents आने के बाद काम करने के तरीके कैसे बदलें। इसे ध्यान से पढ़ें। Vendor की FDE team से client side से Harari के सवाल का उत्तर माँगा जा रहा है। वह service यही page और इसके पीछे का Strategist track है।
एक आख़िरी detail वह बिना झिझक बताती हैं: उनकी team Cursor के cloud agents deploy करती है और client के codebase के भीतर Cursor SDK पर applications बनाती है। अगला paragraph पढ़ते समय इसे याद रखें।
Vendor lock-in की समस्या। यहाँ catch है। Palantir का हर FDE Palantir के platform पर build करता है। OpenAI का हर FDE OpenAI के models पर build करता है। Salesforce का हर FDE Salesforce के tools पर build करता है।7 Cursor का हर FDE Cursor के agents deploy करता है और Cursor SDK पर build करता है। Engineer client की company में गहराई तक जाता है, उस एक vendor के product को हर चीज़ से wire करता है और चला जाता है। बाद में switch करना painful और expensive होता है, ऐसे plumber की तरह जो केवल एक brand की pipes लगाता है: plumbing काम करती है, लेकिन walls तोड़े बिना आप कोई दूसरा plumber hire नहीं कर सकते। Andrew Ng ने The Batch में note किया कि clients के लिए किसी एक vendor से न बँधे FDE ढूँढना कठिन है, क्योंकि vendor के लिए इस role का उद्देश्य client को lock-in करना ही है।18 AWS का अपना launch trap को स्पष्ट करता है। उसने promise किया कि clients self-sufficient होकर निकलेंगे और अपने दम पर build करना जारी रख सकेंगे, और उसी breath में कहा कि उनके रखे agentic systems अपने AWS environment में चलेंगे। Self-sufficiency, लेकिन एक vendor के cloud पर। यह lock-in को feature की तरह दोबारा कहना है: आप build जारी रखने के लिए स्वतंत्र हैं, बशर्ते यहीं build करें। Microsoft के launch ने अलग ढंग से यही concession किया। Palantir comparison पर दबाव पड़ने पर Frontier चलाने वाले executive ने कहा कि Microsoft अपने rival से अधिक models, data connectors और open systems of record integrations support करता है।3 ध्यान दें कि यह defense क्या है: vendor अपने lock-in को दूसरे vendor के lock-in से मापकर ढीले cage को feature कह रहा है। इस book की objection vendor के अपने stage से concede हो गई।
यह book उस FDE को train करती है जिसे market बार-बार माँगता है लेकिन ढूँढ नहीं पाता। यहाँ का method किसी vendor से बँधा नहीं है। इस book का graduate client को किसी एक platform में lock किए बिना full pipeline, यानी intent spec करना, Worker build करना, system design करना और production में चलाना, client organization के भीतर ले जाता है। अगली quarter बेहतर model आए या अगले साल सस्ता runtime ship हो, तो आप switch कर सकते हैं। Client चुनने की freedom रखता है और आप वह discipline रखते हैं जो किसी भी stack पर काम करती है। एक honest tradeoff का नाम लेना चाहिए: vendor का FDE भारी subsidy पर, कभी free, मिलता है क्योंकि vendor lock-in से cost वापस कमाता है, जबकि vendor-neutral FDE को client या independent firm pay करती है। यही feature है, bug नहीं: client बाद में switching costs देने के बजाय अभी optionality खरीदता है। यह engineer जिस blueprint के भीतर operate करता है, वह FDE AF Model है: framework से customer तक पाँच layers, जिनमें हर layer पर FDE की earning भी दिखाई गई है।
बहुत कम programs इस role के vendor-neutral version को end to end train करते हैं। इस boast को exact रखने के लिए: book vendor-neutral FDE का technical core train करती है, वही आधा जिसे market ढूँढ नहीं पाता। दूसरा आधा, यानी client discovery, prioritization, ROI framing और unrealistic ask पर push back करने की discipline, Certified Agentic AI Business Strategist track का हिस्सा है। Technical core यहाँ train होता है। Consulting layer Strategist track में रहती है।
सबसे कठिन objection: platform के बिना आप dev shop हैं
ऊपर section ने platform को cage कहा। अब strongest reply लें और देखें कौन देता है: वही practitioner जिसने role exist करने का reason बताया।
Bai audience objection anticipate करते हैं: enterprise में FDE function survive नहीं कर सकता, क्योंकि every-customer custom build से dozens of unmaintainable repositories और उन्हें सीखने के बजाय quit करने वाले engineers मिलते हैं। वे one condition के साथ agree करते हैं। हर FDE scratch से build करे तो FDE function नहीं, dev shop है, profitable शायद, same business नहीं। FDE function में engineers scratch से software नहीं लिखते। Shared primitives exist करते हैं और engineer उन्हें arbitrarily valuable customer solution में assemble करता है। उनके बिना maintenance cost P&L खाएगी, अगर engineers पहले resign न कर दें।4 Primitive granularity का universal answer नहीं: some industries app 60% built, बाकी custom; others granular tools। AWS comparison: DynamoDB देता है ताकि broad customer set में कोई database invent न करे।
इसे seriously लें, क्योंकि यही vendor-neutrality का bill है। Vendor को हटाने पर आपने cage के साथ shared primitives भी हटा दिए। इसके लिए कुछ न करें तो pod of one, dev shop of one बन जाता है: हर client के लिए bespoke code, कुछ भी reuse नहीं, और हर engagement के साथ बढ़ता maintenance load, जो अंततः margin खा जाता है। Bai के अपने test को ईमानदारी से खुद पर लागू करें। क्या मेरे पास platform है, या क्या मैं एक platform बनाने में invest करने को तैयार हूँ?
उत्तर अगला section है, और अगला section इसी कारण मौजूद है। Vendor-neutral FDE shared primitives लेकर आती है। वे बस किसी vendor के ownership वाला code नहीं हैं।
pod में क्या भरता है: दो Systems of Record
ऊपर सब बताता है FDE कहाँ काम करती है, यह नहीं कि door से क्या लाती है; neutrality यही question force करती है।
पहले vendor के version से यह सवाल पूछें। Palantir engineer Palantir की ontology और tooling लेकर आता है, जिसे कोई और पहले ही बना चुका है। यह वास्तविक leverage है, और इसी कारण एक engineer अब कुछ weeks में वह कर सकता है जो पहले team को years में करना पड़ता था। यह ऊपर के section में बताया cage भी है: client build करना जारी रखने के लिए स्वतंत्र रहता है, बशर्ते वह वहीं build करता रहे।
अब vendor को हटा दें। क्या बचता है? अगर honest answer “उसके दिमाग में method” है, तो वह human execution के hours बेच रही है। यह वही services pyramid है जिसे उसे replace करना था, और “हम understaffed हैं” कहने वाला client ठीक वही चीज़ माँग रहा है। Pod of one hours पर survive नहीं कर सकता। वह उन assets पर survive करता है जो एक client से अगले client तक travel करते हैं।
दो assets travel करते हैं, दोनों Systems of Record। आप अपने साथ क्या लाते हैं full argument है; यह career-facing half।
पहला method है, उसने build नहीं किया। यह deep, governed book human website और agents के लिए MCP है। Outcome specify, Worker manufacture, loop run, checker trust, production prove। Every graduate same लेता; Karachi accounting firm और Chicago में identical, क्योंकि method domain से नहीं बदलता।
दूसरा profession है, उसने खुद build किया। One vertical, one jurisdiction, उसके governance और committed expert licence के साथ: law, standards, expert-derived procedures, invariants, decision map। One professional outcome fully covered से शुरू, engagement-by-engagement thick। किसी और के पास नहीं।
दोनों MCP बोलते हैं, agent साथ पढ़ता है: one how to build, other profession requirements। Integration नहीं, kernel pairing के लिए designed।
और यही dev shop objection का उत्तर है। Bai की condition shared primitives थी, ताकि engineer कभी scratch से शुरू न करे। दोनों Systems of Record को उस condition पर test करें तो दोनों pass होते हैं। Method इस बात की primitive layer है कि work कैसे build होता है: outcome specify करें, Worker manufacture करें, loop चलाएँ, checker पर trust करें और production में result prove करें। यह हर client पर identical है, जो ठीक वही property है जिसकी वह माँग करते हैं और dev shop में नहीं होती। Profession इस बात की primitive layer है कि work को क्या obey करना है, एक vertical और एक jurisdiction में। इनमें से कोई per-customer fork होने वाला code नहीं है, और यही उस maintenance curve को मोड़ता है जिसकी वह warning देते हैं: आप governed corpus maintain करते हैं और उसके आसपास का code सँभालते रहने के बजाय regenerate करते हैं। इससे दो बातें निकलती हैं और दोनों स्पष्ट कहनी चाहिए। पहली, उनकी condition vendor के बिना पूरी होती है, जो इस पूरे page को एक line में समेट देता है। दूसरी, cost गायब नहीं हुई, वह move हुई है। अब repositories के बजाय corpus maintain होता है, और first client के pay करने से पहले किसी को उसे fund करना होगा। इसी कारण नीचे order है: पहले build, फिर sell। इस दूसरे आधे को Aggarwal की arithmetic की तरह book की reasoning मानें। Bai की warning real teams पर maintenance costs उतरते एक दशक देखने से आती है। Governed corpus curve को flat करेगा, यह अभी claim है, measurement नहीं।
दूसरा System कैसे गहरा होता है। Bai यह rule भी बताते हैं कि vendor क्या रखता है: किसी एक customer के लिए bespoke और unique चीज़ केवल उसी customer के पास रहनी चाहिए, जबकि generalizable चीज़ को समय के साथ generalize करना चाहिए। इससे forward deployment scouting function बनता है, यानी vendor इसी तरह सीखता है कि product में आगे क्या build करना है।4 Vendor-neutral version यही rule अलग destination तक चलाता है। जो generalize होता है वह vendor platform में नहीं जाता। वह vertical System of Record में जाता है: वह standard जो एक के बजाय तीन clients को govern करता निकला, वह procedure जिसे expert ने एक बार लिखा और अब हर जगह sign off करता है, और वह invariant जो jurisdiction की हर firm में सही रहा। Engagement by engagement thick होने का mechanical अर्थ यही है, और इसी कारण second client को serve करना first से सस्ता पड़ता है।
और यही कारण है कि vendor-neutrality यह choice force करती है। Vendor का FDE platform के अनुसार specialize करता है। Platform हटाने पर specialization को कहीं और उतरना होगा, वरना आप reuse करने के लिए कुछ भी न रखने वाले generalist consultant हैं। पूछें कि client two से client three तक वास्तव में क्या travel करता है। Work का shape free में travel करता है, क्योंकि document को rule के विरुद्ध पढ़ना, rule cite करना और unclear चीज़ escalate करना method है, और वह पहले System of Record में पहले से है। इसके लिए कोई premium नहीं देता। Buyer उस हिस्से के लिए pay करता है जो generalize नहीं होता: कौन-सा standard इस question को govern करता है, इस period में कौन-सा version effective था, किस country का regulator इस rule का owner है और partner को व्यक्तिगत रूप से किस पर sign करना चाहिए। यह सब professional और jurisdictional है। Audit files से customs declarations पर जाने पर इनमें से कुछ भी नहीं बचता।
इसलिए axis profession है, और vendor-neutrality उसे वहीं रखती है। अपना vertical चुनना बताता है कि कौन-सा profession चुनना है, और Vertical System of Record design करना बताता है कि उसे कैसे बनाया जाए।
Side by side: vendor engineer platform लाता जो पीछे रहता। Neutral method given और profession built लाती है।
इससे एक order निकलता है, और वही तय करता है कि career कैसे शुरू होगा। पहले build करें, फिर sell करें। Slice वह step नहीं है जो customer की प्रतीक्षा करता है। वही step customer पैदा करता है। इस page ने कारण को नाम दिए बिना तीन बार बताया है: portfolio credential है, résumé shipped systems पर screen होता है, और जिसे कुछ दिखाया ही नहीं गया उस व्यक्ति को buyer अपना baseline number नहीं बताएगा। Mid-size firm में उसी firm के profession का एक governed page लेकर जाएँ, और अगला सवाल table के buyer वाले side से आएगा।
Client का सबसे fair question इस argument को पूरा करता है। Vendor का engineer आसानी से कह सकता है: मैं हमारा platform लाता हूँ, और leverage हमारे पास रहता है। आपका graduate अलग उत्तर देता है: मैं method और पहले से governed profession लाता हूँ, और मेरे जाने के बाद आपके पास chosen stack पर एक working system रहता है जिसे आप बदल सकते हैं, साथ ही मुझे सीधे hire करने का option भी। ध्यान दें कि यह answer क्या claim नहीं करता। Client vertical System of Record का owner बनकर नहीं निकलता। उसे engineer और उसके expert की domain startup hold करती है, उसमें expert का licensed material है और third-party sources अपनी terms पर हैं। इसलिए उसके system के भीतर किसी standard को serve करने का licence केवल offer करने से client का licence नहीं बन जाता। Client को वह freedom मिलती है जो vendor version नहीं दे सकता।
Salary section की spirit में एक honest label दें। Demand data measured है। Pod of one method से निकलता है। लेकिन अभी vendor-neutral graduates की कोई verified count मौजूद नहीं है जिन्होंने governed corpus को first client में बदला हो, क्योंकि category नई है और नीचे की shelf अभी खाली है। इस order को Aggarwal की arithmetic जैसी इस book की reasoning मानें: sound, लेकिन अभी measurement नहीं।
एक व्यक्ति का pod
देखें AWS client के पास क्या भेजता है: लगभग पैंतालीस दिनों के लिए on-site पाँच या छह engineers की pod। जब लोग अभी भी building हाथ से करते हैं, forward deployment ऐसा दिखता है: small team चाहिए। यह book बदलती है कि pod में कौन है। Graduate वही work client के भीतर अकेले ले जाता है। जो लोग पहले उसके साथ बैठते थे, अब Digital FTEs हैं, यानी वे Workers जिन्हें engineer build और run करता है। Job वही है। Pod को भरने वाली चीज़ बदल गई। Power अब अधिक लोग जोड़ने से नहीं आती। वह method और उससे पैदा होने वाले Workers से आती है। इसे ऊपर के section के साथ पढ़ें तो pod के दो halves हैं: Workers लोगों को replace करते हैं, और दो Systems of Record vendor platform को replace करते हैं। यह नए product-to-engineer ratio वाला वही shift दूसरी ओर से दिखाता है: हर person का output बढ़ता रहता है और लोगों की संख्या घटती है। Legacy pod से compressed pod और फिर pod of one तक का full arc ‘team इतनी छोटी कैसे हुई’ वाले lesson में trace किया गया है।
यह एक risk पैदा करता है, जिसका नाम उसे पुराने तरीके से staff करने वाला practitioner देता है। जब Bai से पूछा गया कि क्या एक project पर कई FDEs होने चाहिए, तो उन्होंने कहा यह अच्छा pattern है। उनका कारण यहाँ महत्वपूर्ण है: आप single point of failure नहीं चाहते, जहाँ एक व्यक्ति सारी information रखता हो, vacation पर चला जाए और engagement उसके पीछे रुक जाए।4 Pod of one उस risk का सबसे pure रूप है, और इससे इंकार करना dishonest होगा। Book का answer यह नहीं कि risk गायब हो जाता है, बल्कि यह है कि risk human के head से बाहर move होता है। Second engineer knowledge की redundancy देता है; इस method में knowledge पहले ही लिखी हुई है: spec, evals, governed corpus, deployed Worker और उसका runbook। Claim headcount के बजाय artifacts से redundancy का है, और इसके साथ एक test है जिसे आप खुद पर चला सकते हैं। अगर आप दो weeks तक unreachable हों, तो क्या इस book का दूसरा graduate केवल repository से आपकी engagement उठा सकता है? अगर नहीं, तो आपके पास pod of one नहीं है। आपके पास bus factor of one है।
तीसरा दरवाज़ा: freelance FDE
अब तक FDE के दो addresses थे: vendor payroll और independent firm। Third door open freelance market है। Upwork dedicated FDE category और published bands चलाता है: $2,000–5,000 first integration, $5,000–15,000 custom implementation, $15,000+ enterprise deployment, $4,000–10,000/month ongoing support, $150–250/hour strategic consulting।19 UK में mid £600–750/day, senior £750–1,200 और principal £1,200–2,000/day; specialist recruiter कहता है senior FDE permanent के ऊपर contract चुन रहे हैं।20 Fractional platforms dedicated matching और days में filled Fractional FDE Lead postings तक पहुँचे।21
अब honest reading करें, क्योंकि marketplace page को closely देखना उपयोगी है। Category मौजूद है। उसके नीचे supply मौजूद नहीं है। Upwork द्वारा Forward Deployed Engineers के रूप में listed profiles देखें तो capable generalists, full-stack developers, DevOps engineers और app builders मिलते हैं, लेकिन कोई FDE work, embedded delivery या end-to-end pipeline describe नहीं करता। Marketplace ने shelf उसके stock होने से पहले बना दी। यह marketplace layer पर इस page की opening line है: title training से पहले आ गया। अधिकतर job titles में empty shelf warning होती है। Trained reader के लिए यही opening है: demand side projects post कर रही है और published rates pay कर रही है, ऐसी category में जिसे supply side ने अभी भरना नहीं सीखा।
तीन चीज़ें इस door को बाकी दोनों से अलग बनाती हैं। पहली, यह vendor-neutral FDE का native market है। Vendor का FDE freelance कर ही नहीं सकता: उसका role केवल vendor payroll के भीतर मौजूद है और vendor platform से welded है। हर genuine freelance FDE construction से वही vendor-neutral kind है जिसे यह book train करती है। Open market में vendor-neutrality differentiator नहीं रहती, entry requirement बन जाती है। दूसरी, retainer tier maintenance work का disguise नहीं है। यह इस book द्वारा सिखाया Digital FTE subscription model है, जो company के बाहर से चलता है, और monthly fee आपको manufactured Workers operate करने के लिए pay करती है। यह pod of one को recurring revenue में बदलना है। तीसरी, और इस book के readers के लिए सबसे महत्वपूर्ण, इस door की कोई border नहीं है। Salaried FDE market largely US या European work address माँगता है। Freelance और fractional market portfolio और connection माँगता है। Aggarwal जो India के IT decades के लिए claim करते हैं वह इस channel से किसी के लिए भी चलता है: वही contract Karachi, Lagos या Bangalore से clear होता है।
दो constraints स्पष्ट कहें। Embedding job का essence है, और remote embedding remote coding से कठिन है। Freelance FDE over-communicate करके, client-timezone hours रखकर और occasional on-site presence को premium price का हिस्सा मानकर जीतता है। Premium केवल list नहीं किया जाता, earn किया जाता है। Unproven marketplace profiles generalist rates के पास शुरू होती हैं, और engineer को ऊपर के bands तक demonstrated outcomes ले जाते हैं, जो ठीक वही चीज़ है जो इस book के capstones बनाते हैं। Deployed Worker, shipped plugin, live connector app और profession का एक governed slice: इस market में यही credentials हैं। Book delivery train करती है। Client discovery और pricing discipline Strategist track में रहते हैं। Reputation आपको एक contract करके बनानी है।
FDE को सीधे hire करें और title गायब हो जाता है। “FDE” कभी engineer या उसकी skills का description नहीं था। यह बताता है कि वह कहाँ काम करता है: outsider के रूप में client की company में embedded होकर पूरी line end to end carry करता है। इसलिए deciding question सरल है: वह किसकी company में build कर रहा है? अपनी company के भीतर build करे तो work चार core roles है। Client के भीतर build करे तो वही work FDE कहलाता है। अब उस engineer को सीधे hire कर लें। Client की company उसकी अपनी company बन जाती है। वह अब forward deployed नहीं, केवल deployed है। Work में कुछ नहीं बदला। केवल address बदला। इसलिए FDE title हट जाता है और वह फिर internal core बनता है: उसे hire करने वाली company में एक person पूरी pipeline own करता है। इसका single name AI-Native Company Architect है, जो enterprise design करता है और अक्सर उसे Cloud AI Engineer की तरह run भी करता है।
यह freedom केवल vendor-neutral FDE के पास है: वह company को outright join कर सकता है। Client आपके graduate को full employee hire कर सकता है, और engineer अगली morning ठीक वही work करता रहता है, क्योंकि discipline person में रहती है, किसी vendor platform में नहीं। वह उसके साथ door से भीतर आती है। Vendor का FDE ऐसा नहीं कर सकता। जिस दिन वह Palantir या OpenAI छोड़ता है, उस पूरे job का आधार platform पीछे रह जाता है। बाहर निकलने वाला engineer talented रहता है, लेकिन leverage vendor के पास रहता है। इसलिए vendor का FDE permanent loan पर है: embedded रहते उपयोगी, vendor relationship समाप्त होते ही चला गया। हमारा graduate हमेशा के लिए hire किया जा सकता है। Client उसे FDE की तरह rent कर सकता है, फिर AI-Native Company Architect के रूप में in-house ला सकता है, बिना एक step खोए। Vendor-neutrality यही खरीदती है: ऐसा engineer जिसे company वास्तव में own कर सकती है, केवल borrow नहीं।
इस यात्रा में एक asymmetry बचती है और उसका नाम लेना चाहिए। दोनों में पहला, Agent Factory System of Record, उसके साथ भीतर जाता है और जहाँ वह जाए वहाँ उपलब्ध रहता है, क्योंकि वह ecosystem का है और open है। दूसरा बस travel नहीं करता। उसकी domain startup उसे hold करती है और वह expert के licence तथा third-party terms पर खड़ा है, इसलिए direct hire उस business के बारे में conversation है, automatic transfer नहीं। Discipline हमेशा portable है। Asset का owner होता है।
Direct-hire path: client पर FDE, hire पर core AI-Native Company Architect। केवल neutral FDE trip करती है।
Job हासिल करना अपनी अलग discipline है। FDE résumé को software engineer के résumé से अलग signals पर screen किया जाता है, और FDE interview उस round के लिए प्रसिद्ध है जिसमें अधिकतर strong engineers fail होते हैं। दोनों नीचे Appendix A और Appendix B में हैं, और Appendix C इस book के courses को हर interview round से map करती है।
Skill लेखक के रूप में विषय-विशेषज्ञ
Subject Matter Expert as Skill Author: market-unnamed role। Accountant, lawyer या supply-chain expert judgment को SKILL.md, agent-loadable plain-text skill file, में encode करके Digital FTE knowledge engine बनता है। Concrete work: unthinking tacit rule, seasoned auditor transaction flag या adjuster borderline case, इतना precise लिखें कि agent execute; calls अपने से match test करें; SKILL.md match तक revise। Market engineering-only picture से miss करता है। Book domain judgment को author/test/deploy कराती है। Almost untrained neutral FDE जैसा role। Full train: judgment in, working agent out।
ध्यान दें कि ये दो unnamed roles केवल similar नहीं हैं। उन्हें एक-दूसरे की ज़रूरत है। Vendor-neutral FDE का दूसरा System of Record author के बिना मौजूद नहीं हो सकता, क्योंकि उसके भीतर procedures practitioner की voice में लिखी और practitioner की real files से derived होती हैं। Skill Author को भी ऐसा व्यक्ति चाहिए जो उसके judgment का governed home बनाए। दोनों में से कोई junior partner नहीं है। Expert बीस वर्षों का experience और licence लाता है। Engineer method और build लाता है। यही pairing वह unit है जिसे FDE AF Model vertical कहता है, और इसी कारण अपना vertical चुनना committed expert के बिना vertical launch करने से इंकार करता है।
Market ने अभी इस role पर price print किया है। Mid-2026 में Business Insider ने Google account executive Yousuf Imran को profile किया, जिनकी sales commissions ने $170,000 base को लगभग $986,000 सालाना तक पहुँचा दिया था। April में उन्होंने salespeople के लिए sales tools बनाने वाली AI product lab Mangosteen Studio शुरू करने के लिए job छोड़ दी।22 Headline number से आगे देखें और ध्यान दें कि वह क्या नहीं हैं: software engineer। उनका stated asset salespeople की problems सीखने में लगाए बीस वर्ष थे, और उनकी bet है कि उनके ownership वाले AI products में encoded यह judgment, salary पर rent करने से अधिक valuable है। उन्होंने decision को ownership की terms में frame किया: अगर इस era की upside equity में है, तो equity उनकी अपनी बनाई company में होनी चाहिए। यही Skill Author की wager है, market द्वारा अब तक publish किए गए सबसे visible price पर। Aggarwal की arithmetic की तरह यह भी एक व्यक्ति की bet है, statistic नहीं बल्कि signal। Headline कहती है कि एक person $986,000 छोड़ गया। Mechanism कहता है कि domain expertise manufacturing input बन गई और expert ने factory अपने पास रखी।
Connector और Plugin Engineer
Connector and Plugin Engineer: उन agent hosts को extend करता है जिन्हें लोग पहले से चला रहे हैं। अपना loop own करने वाला Worker build करने से पहले भी एक पूरी discipline है: वे चीज़ें बनाना जिन तक agent हाथ बढ़ाता है। Market इसे एक साथ पाँच नाम दे रहा है: MCP engineer, integrations engineer, connector developer, plugin developer और agent-tooling engineer। यह एक job है जो दो addresses पर रहती है। Connector-native app end users के लिए chat app, यानी claude.ai, extend करती है: आप remote MCP server, tools, stored state, real sign-in और fail-closed session gate ship करते हैं, जिसे stranger एक pasted URL से add कर सकता है; उसके बाद model खुद आपका customer होता है। Plugin builders के लिए coding agent, जैसे Claude Code और OpenCode, extend करता है: एक install के पीछे skills, subagents, hooks और MCP servers, जहाँ deterministic hook उस advice के बीच line है जिसे model skip कर सकता है और उस rule के बीच जो हर बार चलता है। Same move, two hosts, और दोनों के नीचे same artifact, MCP server, रहता है; इसलिए book इन्हें back to back सिखाती है। Through-line thesis की एक idea है: आप unit ship करते हैं जिसे host load करता है, extension आपकी होती है और loop host का। दोनों end to end deployed artifact तक train होते हैं। Identity issue करना, यानी agents के लिए अपना sign-in server और identity बनाना, AI Identity course है, और runtime खुद build करना scope से बाहर रहता है, जैसा “किताब कहाँ रुकती है” में बताया है।
सहायक भूमिकाएँ
हर pipeline को ऐसे लोग चाहिए जो work check करें, rules set करें और responsibility लें। ये तीन roles वही करते हैं।
Evals Engineer: वह person जो AI Workers को live जाने से पहले crash-test करता है। आप बिना crash-test के car ship नहीं करेंगे। आप बिना clinical trials के medicine release नहीं करेंगे। एक AI Worker जो real people और real money को affect करने वाले decisions लेता है, उसे भी वही discipline चाहिए। Evals Engineer ये tests design करता है: क्या Worker सही answer देता है? जब उसे ऐसा कुछ मिलता है जो उसने पहले कभी नहीं देखा, तो क्या वह gracefully fail करता है? क्या वह दिए गए boundaries के अंदर रहता है? यह अंत में bolt-on किया गया afterthought नहीं है। यह हर chapter में built in है। Core curriculum, add-on नहीं.
AI Governance Officer: तय करता है कि AI क्या कर सकता है। Company में हर employee की limits होती हैं। Junior accountant $500 तक expenses approve कर सकता है, उससे ऊपर manager signature चाहिए। Bank teller deposit process कर सकता है, loan approve नहीं कर सकता। AI Workers को भी वही structure चाहिए। Governance Officer company level पर ये rules लिखता है: AI अपने आप क्या decide कर सकता है, क्या human approval के लिए जाना चाहिए, और AI को क्या कभी touch नहीं करना चाहिए। वह company की regulations से mapping भी handle करता है: bank में fair lending rules, hospital में patient privacy, Europe में data residency laws। AI-Native Company Architect वह system build करता है जो ये rules enforce करता है; Governance Officer decide करता है कि rules में क्या लिखा होना चाहिए। किताब यह framework discipline सीधे train करती है; आपकी industry की specific regulations वह inputs हैं जो आप लाते हैं। Governance framework train करती है; आपकी jurisdiction के rules आप supply करते हैं.
Digital FTE Supervisor: वह human जिसका नाम line पर है। जब AI Worker claim process करता है, contract draft करता है या transaction flag करता है, तो किसी को accountable होना पड़ता है। वही Supervisor है। वे human-in-the-loop हैं: reviewer जो work check करता है, manager जो output approve करता है, वह नाम जिसकी तरफ audit trail इशारा करती है जब कुछ गलत होता है। यह Worker build करने वाला person नहीं है। यह वह person है जो उसे day to day run करता है, जैसे shift manager team run करता है। इसे train करती है.
जहाँ किताब जान-बूझकर रुकती है
LLMOps Engineer: model तक, model itself नहीं। Production में agents run करना Cloud AI Engineer का job है, और किताब इसे train करती है। किताब fine-tuning hands-on भी train करती है, लेकिन last resort के रूप में, default नहीं। Fine-tune आपके system को एक model snapshot से bind करता है और उस optionality की cost लगाता है जिसे पूरा method protect करता है, इसलिए आप इसे तभी use करते हैं जब prompting, context, tools और retrieval सच में कम पड़ जाएँ। Hard stop model itself build करना है: foundation model को scratch से pre-train करना scope से बाहर रहता है, क्योंकि वह capability commoditize हो रही है। Fine-tuning और model के आसपास ops train करती है, foundation models build करना नहीं.
Harness Engineer: वह runtime जिसे आप use करते हैं, वह नहीं जिसे आप build करते हैं। Harness agent runtime है: OpenAI Agents SDK, Claude के managed agents और ऐसी चीज़ें, जो agent loop run करती हैं, state manage करती हैं और tool calls execute करती हैं। किताब आपको इन्हें fluently use करना और इनके बीच portable रहना train करती है, क्योंकि आपकी discipline किसी भी winning runtime से ज़्यादा long-lived है। Runtime itself build करना job नहीं है। किसी भी runtime का use करने वाले operator को train करती है, उसे build करने वाले engineer को नहीं.
AI Data Engineer: agent-facing data layer। System-of-record work agent-facing data layer को touch करता है: Postgres, pgvector और MCP वह spine हैं जिससे agent read करता है। Classic pipeline और warehouse engineering adjacent हैं, central नहीं। Agent-facing data layer train करती है, general data engineering नहीं.
दूसरी axis: आपका type, केवल seat नहीं
ऊपर map work location बताता है, आपकी fit seat नहीं। June 2026 में Claude Code creator Boris Cherny ने अपनी team देखकर पूछा engineering, product, design और data science new role में melt हों तो roles क्या बनते हैं।23 Answer five archetypes, job functions नहीं। Prototyper brand-new ideas churn करता, mostly never ship। Builder prototype को fast production-grade product/infrastructure। Sweeper system simplify, UI clean, unship, optimize। Grower built product को product-market fit। Maintainer mature system secure, reliable, fast, efficient at scale रखता है।
Cherny के five archetypes और map seats के rhymes: loud, one-to-one नहीं।
उनके दो observations यहाँ पूरा काम करते हैं। पहला, archetypes titles से tied नहीं हैं। Anthropic में कुछ designers Prototypers हैं, कुछ Builders और कुछ Sweepers, और यही spread engineers, PMs और data scientists में भी है। इससे इस page की opening claim, कि title अब work को describe नहीं करता, lab के भीतर से confirm होती है। दूसरा, अधिकतर people दो archetypes span करते हैं, कभी तीन, और team को चाहिए mix product phase के साथ बदलता है: pre-PMF product पहले तीन पर झुकता है, mature product अंतिम तीन पर। इस map के साथ पढ़ने पर rhymes स्पष्ट हैं लेकिन one-to-one नहीं। Outcome Architect Prototyper की seat है। Digital FTE Builder Builder की। Evals Engineer Sweeper की। Cloud AI Engineer और Supervisor Maintainer की seats हैं। Archetypes span करना भीतर से देखा pod of one है: Workers tasks absorb करते हैं, जबकि human के दो या तीन archetypes तय करते हैं कि वह सच में कौन-सी seats hold कर सकता है और किन supporting disciplines को fake करने के बजाय borrow करना होगा, जैसे Sweeper की subtraction के लिए evals और Maintainer की caution के लिए governance। Cherny claim पर नहीं बल्कि question पर समाप्त करते हैं: शायद future के product roles उनकी पाँच types जैसे दिखें और आज के domain roles जैसे कम। यह page उस question का एक answer है। Roles बताते हैं work कहाँ बैठता है। आपके archetypes बताते हैं कि उनमें से कौन-सी seats आपको लेनी चाहिए।
Pattern signal है। Agent era work को कई roles में फैलाता है: Workers build, run और govern करना, और उन्हें judgment सिखाना। देखें आप कहाँ खड़े हैं, कौन-से archetypes span करते हैं, और book आपको कितना आगे ले जाती है।
Appendix A: FDE résumé के छह signals
Interview और screening तेजी से बदलते हैं। यह appendix और अगला mid-2026 sources से verify किए गए।
Recruiters FDE profile को software engineer के profile की तरह नहीं पढ़ते। Real screening practice का analysis छह signals पर converge करता है, और जो profile इन्हें छिपाती है वह technical bar test होने से पहले reject हो जाती है।24 पहले तीन पूछते हैं कि क्या आपने वास्तव में deliver किया है: shipped production systems, team backlog के features नहीं; quantifiable impact, केवल “feature X बनाया” नहीं बल्कि numbers में customer को क्या मिला; और direct customer exposure, यानी आप stakeholder के साथ बैठे, product manager के पीछे नहीं। दूसरे तीन पूछते हैं कि आप deliver कैसे करते हैं: messy-data work, क्योंकि real client environments कभी clean नहीं होते; ambiguity में ownership, यानी जब किसी ने project define नहीं किया तब आपने उसे चलाया; और AI/LLM depth, जिसमें RAG, agents और evals शामिल हैं, वही कारण जिसके लिए role मौजूद है।
इन signals से तीन rewrites निकलते हैं। पहली, हर bullet को activity से outcome में reframe करें: “ETL pipeline बनाई” को “ऐसी pipeline ship की जिसने client का month-end close पाँच दिन से घटाकर दो दिन किया” बनाएँ। दूसरी, “we” नहीं, “I” लिखें। FDE screeners “we” को “दूसरों ने इसे carry किया” की तरह पढ़ते हैं और hiring-manager round में इसकी जाँच करते हैं। तीसरी, competitive-programming awards हटा दें। Data-structure puzzles solve करने का prize गलत interview की preparation signal करता है। उसकी जगह portfolio आता है। ऊपर freelance section rule बता चुका है: portfolio credential है। Deployed Worker, shipped plugin और live connector app, हर एक के साथ one-line outcome। इस book का हर capstone ठीक वही line बनने के लिए design है।
उस list में एक item बाकी से अलग है, और vendor-neutral candidate को उसी से lead करना चाहिए: profession का governed slice, जो human readers और agents दोनों के लिए publish हो। Deployed Worker prove करता है कि आप build कर सकते हैं। Governed slice prove करता है कि आप ऐसी चीज़ own करते हैं जो किसी employer ने आपको नहीं दी, और page पर यही वह line है जिसे screener ने लगभग निश्चित रूप से पहले कभी नहीं देखा होगा।
Appendix B: FDE interview, loop और trap
Loop three-to-six weeks में five-to-eight stages: recruiter, hiring manager, practical coding, system design, decomposition, client simulation, behavioral, some labs API take-home।24 Two rounds outcome तय, neither engineers-prepared one।
Decomposition round filter है। आपको vague, real enterprise problem दी जाती है: “एक major city emergency response time घटाना चाहता है; उसके पास call data, traffic data और ambulance GPS है; आपके पास साठ minutes हैं।” सबसे common rejection उसी problem का answer दे देना है। जो candidate “मैं XGBoost से predictive model बनाऊँगा” से शुरू करता है वह पहले ही fail हो चुका है, क्योंकि उसने scope से पहले solve किया। Score करने वाला sequence यह है: actual goal clarify करें, stakeholders और success metric का नाम लें, available data और उसके owners map करें, risk के अनुसार sequenced subproblems में decompose करें, और सबसे पतला end-to-end skeleton पहले propose करें। Assumptions aloud कहें, failure modes बिना prompt के surface करें और thinking लगातार narrate करें। इस book के readers sequence पहचानेंगे: यह verbally किया गया spec-driven development है। Round यह test नहीं करता कि आपको answer पता है या नहीं; यह test करता है कि किसी human या agent को execute करने देने से पहले आप spec लिखते हैं या नहीं।
Client simulation दूसरा filter है। Interviewer customer की role-play करता है, कभी frustrated और कभी non-technical, और आपको bad news deliver करनी होती है, governance compromise करने वाली request पर push back करना होता है या समझाना होता है कि system 100 प्रतिशत accuracy promise क्यों नहीं कर सकता। यह सब jargon के बिना और ऐसी promise किए बिना करना होता है जिसे आप निभा नहीं सकते। Sources में interviewers द्वारा बताए पाँच red flags consistent हैं: clarify करने से पहले solve करना, cost और constraints ignore करना, thin deployment stories जिनमें production API fail होने पर क्या हुआ इसका account नहीं, regulated domains में zero compliance vocabulary, और customer instinct का न होना।24
एक और format फैल रहा है और अपनी line deserve करता है: live build। एक documented loop तीन घंटे चला: तीस minutes vague use case को cross-examination के तहत requirements में बदलने के लिए; नब्बे minutes AI coding assistant से working solution build करने, हर suggestion validate करने और live debug करने के लिए; और साठ minutes role-played stakeholder को pure business language में result present करने के लिए।25 किसी stage पर LeetCode नहीं था। बीच का round observation के तहत किया इस book का Mode 1 discipline है: agent को direct करें, उसकी हर output verify करें और loop narrate करें।
Company flavor margins पर matter करता है। Palantir data engineering, ontology thinking और अपने invented decomposition round पर झुकता है। OpenAI अपने APIs के विरुद्ध systems build और evaluate करने पर झुकता है, जहाँ differentiator question होता है: “आप कैसे जानते हैं कि यह सच में काम कर रहा है?” Anthropic, जो role को Applied AI Engineer कहता है, production LLM systems, evals और mission alignment पर झुकता है।24 लेकिन ऊपर के fundamentals हर जगह loop हैं, और preparation four-to-six-week discipline है: पहले fundamentals और stories, फिर system design, उसके बाद partner के साथ timed और recorded decomposition practice, क्योंकि अधिकतर candidates देखकर हैरान होते हैं कि वे कितनी जल्दी solutions पर jump करते हैं, और company-specific tuning सबसे अंत में।
Appendix C: इस book से FDE की तैयारी
Interview इस book के आसपास design नहीं किया गया था, लेकिन ऐसा लगता है जैसे किया गया हो। हर round उस material से map होता है जो आपको पहले ही assign किया जा चुका है:
| Interview round | क्या test होता है | Book कहाँ train करती है |
|---|---|---|
| Decomposition case | Solve से पहले scope, verbal spec discipline | Spec-Driven Development, How to Think in the AI Era |
| Practical coding | Agent के साथ verified engineering | Python in the AI Era; Code You Never Write; Seven Principles |
| AI-specific depth | RAG, agents, evals, “कैसे जानते हैं कि works?” | Give Your AI Searchable Context, Build AI Agents, Eval-Driven Development |
| System design | Constraints में enterprise deployment | Thesis invariants; Choosing Agentic Architectures; Deploy the Agent Harness |
| Client simulation | Trust, pushback, business language | Human-Agent Teams; Strategist track |
| Live build | Observation में agent direct करना | Claude Code और OpenCode; Agentic Engineering Fundamentals |
| Portfolio | Shipped demonstrable outcomes | हर capstone: Worker, plugin, connector-native app, governed slice |
Table को bottom-up पढ़ें तो एक ध्यान देने योग्य बात सामने आती है: interview के सबसे कठिन rounds, decomposition, live build और eval question, curriculum पर जोड़ा गया extra material नहीं हैं। वे curriculum ही हैं, जिन्हें examine किया जा रहा है। जिसने spec discipline के तहत वास्तव में Worker manufacture किया है वह decomposition round में दर्जनों rehearsals के बाद जाता है, क्योंकि ऐसा intent लिखना जिसके लिए Worker को accountable ठहराया जा सके और vague enterprise problem को aloud scope करना, अलग volume पर वही skill है।