One-Off से Worker तक: Manufacturing को Handoff
1 Signal · 4 Promotions · 1 Fork
दो महीने पहले, इस track की शुरुआत में, Ana ने अपने Monday वाले task को देखा (हफ़्ते के customer messages को groups में sort करना और एक summary लिखना) और उसे दिखा कि इसका एक Mode 2 future है: एक ऐसा task जो वह हर हफ़्ते करती थी, उसी तरीके से, और जिसे एक बार build करना साफ़ तौर पर worth था। फ़िलहाल, हालाँकि, यह अब भी एक Mode 1 job था; वह इसे हर Monday, सात principles का इस्तेमाल करके, हाथ से solve करती रहती थी। यह हर बार काम करता था। और यह हर Monday की सुबह भी खा जाता था।
उसके colleague Diego के पास भी इसी तरह का weekly task है। वह भी इसे हर हफ़्ते, अच्छे से, हाथ से solve करता है। वह इसमें माहिर है।
एक साल बाद, Ana इस पर लगभग कोई Monday सुबह खर्च नहीं करती। वह cross कर गई: उसने अपने बार-बार दोहराए गए Mode 1 solution को एक ऐसे worker में बदल दिया जो routine को अपने आप संभालता है, और वह सिर्फ़ तब बीच में आती है जब worker कोई exception flag करता है। Diego ने अपने task पर लगभग पचास Monday (मोटे तौर पर सौ घंटे) लगाए हैं, और अगले साल पचास और लगाएगा। वही task, वही skill। फ़र्क सिर्फ़ इतना है कि Ana ने problem को solve करना बंद किया और solution को manufacture करना शुरू किया।
यह course वही crossing है। यह Mode 1 का आख़िरी पड़ाव है और Mode 2 में जाने का रास्ता।
यह किसके लिए है
हर उस व्यक्ति के लिए जिसके पास कोई ऐसा task है जिसे वह agent के साथ बार-बार, उसी तरीके से, solve करता रहता है, और जिसे अब लगने लगा है कि हर बार इसे हाथ से करना जीने का गलत तरीका है। यह course आपको दिखाता है कि इसे solve करना कब बंद करें और इसे एक permanent worker में बदल दें, और जब आप ऐसा करते हैं तो असल में क्या बदलता है।
यह किताब पूरी दुनिया में पढ़ी जाती है, ऐसे लोगों द्वारा जो कई अलग-अलग languages में काम और पढ़ाई करते हैं। यहाँ के examples साधारण भाषा और रोज़मर्रा की situations इस्तेमाल करते हैं जिनका मतलब हर जगह एक जैसा रहता है, चाहे आप कहीं भी रहते हों। नए शब्द (जैसे spec, eval, और runtime) पहली बार आने पर समझाए जाते हैं।
पहले Problem Solving with General Agents पूरा करें; यह course मानता है कि आप सात principles का इस्तेमाल करके एक ही session में किसी problem को अच्छे से solve कर सकते हैं। यह यह भी मानता है कि आपने Is This an Agent Problem? कर लिया है और जानते हैं कि Mode 1 (इसे एक बार solve करना) और Mode 2 (एक permanent worker बनाना) का मतलब क्या है।
📚 Teaching Aid
View Full Presentation: One-Off से Worker तक
एक line में rule
आप worker को scratch से नहीं बनाते। आप एक ऐसे solution को promote करते हैं जिसे आप पहले ही साबित कर चुके हैं।
लोग "एक AI worker बनाएँ" सुनते हैं और शून्य से शुरू करने की तस्वीर बना लेते हैं: एक blank screen, एक कठिन engineering project, हफ़्तों का काम। यह तस्वीर गलत है, और यही लोगों को उस सबसे क़ीमती काम से डराकर दूर कर देती है जो वे कर सकते थे। सच इसका उलटा है: जब तक कोई task worker बनने को तैयार होता है, तब तक आप ज़्यादातर काम कर चुके होते हैं। हर Monday जब Ana अपना task हाथ से solve करती थी, तब वह, बिना जाने, ठीक-ठीक यही पता लगा रही थी कि worker को क्या करना होगा। Manufacturing कोई आविष्कार नहीं है। यह एक ऐसे solution को लेना है जिसे आप पहले ही हाथ से साबित कर चुके हैं और उसे permanent बना देना है।
यही reframe पूरा course है। नीचे, आप वह एक signal देखेंगे जो बताता है कि कोई solution cross करने को तैयार है, आपके Mode 1 काम के वे चार हिस्से जो worker में promote होते हैं, और रास्ते का वह एक fork जहाँ आप चुनते हैं कि किस तरह का worker बनाना है।
छोटा version (चार bullets में)
- सिर्फ़ वही cross करें जिसे आप पहले ही साबित कर चुके हैं। आप worker सिर्फ़ ऐसे solution से manufacture कर सकते हैं जिसे आपने कई बार, हाथ से, साफ़-सुथरे ढंग से solve किया हो। यह दोहराव automate करने से पहले बरबाद किया गया समय नहीं है; यही वह तरीका है जिससे आप पता लगाते हैं कि worker को असल में क्या करना चाहिए।
- आप शुरू से शुरू नहीं कर रहे। चार चीज़ें जो आपने Mode 1 में पहले से हाथ से कीं (आपका brief, आपका check, वे steps जिन्हें आपने चलाया, और session ख़ुद) इनमें से हर एक एक permanent रूप में promote हो जाती है। यही पूरा build है।
- इसे permanent बनाना दो रास्तों में fork होता है। आप एक personal worker को own कर सकते हैं (हल्का, सिर्फ़ आपके लिए) या एक Digital FTE को manufacture कर सकते हैं (भारी, किसी organisation के लिए)। यह fork एक सवाल से तय होता है: worker किसके लिए है?
- असली फ़ायदा है task बनाम asset। हाथ से solve करना task के रूप में मेहनत है: आप हर बार घंटे खर्च करते हैं। Worker asset के रूप में मेहनत है: आप एक बार build करते हैं, और वह तब काम करता है जब आप सो रहे होते हैं।
Part 1 — Signal: क्या यह सच में cross करने को तैयार है?
यह किस गलती को रोकता है: "मैंने एक ऐसे task के लिए permanent worker बना दिया जिसे मैंने अभी ठीक से समझा ही नहीं था, तो मैंने गलत चीज़ बनाने में एक हफ़्ता लगा दिया, और फिर उसे दोबारा बनाना पड़ा।"
Is This an Agent Problem? में, Gate 2 ने आपको signal का पहला आधा हिस्सा पहले ही दे दिया था: कोई task तब Mode 2 होता है जब तीनों dials up हों, यानी आप इसे अक्सर करते हैं, इसका हर बार same shape होता है, और यह मेहनत के worth होता है। Trigger सीधा था: जब आप वही task उसी तरीके से तीसरी बार करें, रुकें और जाँचें।
लेकिन एक दूसरा आधा हिस्सा है जिसे Gate 2 जाँच नहीं सकता था, और यही वह है जिसे लोग छोड़ देते हैं: क्या आपने इसे सच में अच्छे से solve कर लिया है?
आप सिर्फ़ एक साबित किए हुए solution से ही manufacture कर सकते हैं। अगर आप ऐसे method से worker बनाते हैं जिसे आप अभी समझ ही रहे हैं, तो आप गलत worker बनाते हैं, और यह आपको तभी पता चलता है जब आप मेहनत लगा चुके होते हैं। तो cross करने के पूरे signal के दो हिस्से हैं:
- Gate 2 कहता है Mode 2 (अक्सर, same, worth it), और
- आपने task को Mode 1 में इतनी बार साफ़-सुथरे ढंग से solve कर लिया है कि method बदलना बंद हो गया है।
वह दूसरा हिस्सा ही असली test है। ख़ुद से पूछें: पिछली तीन बार जब मैंने यह किया, क्या मैंने इसे उसी तरीके से किया? अगर हाँ, तो shape stable है: आपको worker मिल गया। अगर आप अब भी इसे हर हफ़्ते थोड़ा अलग ढंग से solve करते हैं (अलग steps, अलग checks, नए सिरे से लिए गए decisions) तो आपको stable shape अभी नहीं मिला है। इसे Mode 1 में तब तक solve करते रहें जब तक यह जम न जाए। वे दोहराव आपका automate करने में नाकाम होना नहीं हैं। वे आपका वह research करना हैं जो worker को बताता है कि क्या करना है।
एक बार जब आप जान जाते हैं कि कोई task Mode 2 job है, तो उसे हाथ से करते रहना inefficient लगता है। ऐसा है नहीं। हर बार जब आप इसे solve करते हैं, आपको कोई edge case मिलता है, कोई बेहतर step order, कोई check जो मायने रखता है। पहले हफ़्ते बनाया गया worker यह सब चूक जाता। पाँचवें हफ़्ते बनाया गया worker पाँच हफ़्तों के मेहनत से कमाए गए ज्ञान पर बना होता है। तब cross करें जब सीखना धीमा पड़ जाए, उससे पहले नहीं।
Part 2 — Reframe: worker उसी काम में छिपा है
अब वह हिस्सा जो बदल देता है कि पूरी चीज़ कैसी महसूस होती है। हर बार जब आपने Mode 1 में task को अच्छे से solve किया, आपने एक निशान छोड़ा, और वही निशान worker का raw material है।
सोचिए कि एक अच्छे Mode 1 session ने असल में क्या produce किया। आपने एक brief लिखा (किस चीज़ पर काम करना है, आप क्या चाहते थे, "done" का मतलब क्या था)। आपने output एक साफ़ shape में माँगा। आपने यह पक्का करने के लिए एक check चलाया कि वह सही है। आपने result को एक file में save किया। इसमें से कुछ भी फेंकने लायक नहीं था। तो manufacturing scratch से बनाना नहीं, दो moves हैं: उन टुकड़ों को harvest करें, फिर हर एक को harden करें ताकि वह आपके बिना चल सके। उस दूसरे move के बारे में साफ़ नज़र रखें: hardening असली काम है। Exits design करना, एक ऐसा eval बनाना जो ख़ुद को grade करे, और एक runtime खड़ा करना सच्ची engineering है, सिर्फ़ वह लिखना नहीं जो आप पहले से करते हैं। Reframe आपको blank page से बचाता है; यह build को मामूली नहीं बना देता।
यहीं economics पलटती है, और यही पूरी किताब का दिल है। जब आप किसी task को हाथ से solve करते हैं, आपकी मेहनत एक task है: आप समय खर्च करते हैं, आपको एक result मिलता है, और वह समय चला गया। जब आप उस solution को एक worker में promote करते हैं, वही मेहनत एक asset बन जाती है: आप इसे build करने में एक बार समय खर्च करते हैं, और यह बार-बार results produce करता है, जबकि आप कुछ और करते हैं। यही Diego, जो साल में सौ घंटे खर्च करता है, और Ana, जिसने एक बार कुछ घंटे खर्च किए, के बीच का पूरा फ़र्क है।
Task के रूप में मेहनत आपको लागत देती रहती है। Asset के रूप में मेहनत एक बार लागत लेती है, फिर आपको वापस देती है। Lines लोगों की उम्मीद से जल्दी cross करती हैं।
Part 3 — चार promotions
Crossing एक बड़ा build नहीं है। यह चार ख़ास upgrades हैं, और इनमें से हर एक के लिए कठिन सोच-विचार आप Mode 1 में पहले ही कर चुके हैं। हर promotion कोई ऐसी चीज़ लेता है जिसे आप हाथ से करते थे और उसे कुछ ऐसा बना देता है जिसे worker अपने आप करता है। हर एक आपको उस Mode 2 course तक भी पहुँचा देता है जो इसे पूरी तरह सिखाता है।
आप चार नई चीज़ें नहीं जोड़ रहे। आप चार चीज़ों को upgrade कर रहे हैं जो आपके पास पहले से हैं।
Promotion 1 — आपका brief spec बन जाता है
Mode 1 में आप हर बार एक झटपट brief लिखते थे: किस पर काम करना है, आख़िर में क्या चाहिए, कब done माना जाए (Gate 3 की तीन lines)। यह आपके दिमाग़ में या किसी scratch note में रहता था, और आप इसे चलते-चलते adjust कर सकते थे।
Worker आपका मन नहीं पढ़ सकता और न ही पूछ सकता है कि आपका मतलब क्या था, इसलिए उस brief को एक spec बनना होगा (specification का छोटा रूप): एक लिखा हुआ document जिसे worker हर एक run पर पढ़ता है और जो ठीक-ठीक बताता है कि वह क्या करता है, किस पर करता है, और किस standard तक करता है। Spec वही तीन lines हैं जो आप पहले ही लिख चुके हैं, बस explicit, पूरी, और permanent बना दी गई हैं। इसे छोड़ दें, तो worker खाली जगहों को अनुमानों से भरता है, हर run पर थोड़ा अलग ढंग से।
इसे यहाँ सीखें: Spec-Driven Development.
Promotion 2 — आपका check eval बन जाता है
Mode 1 में आप output को ख़ुद verify करते थे (तीसरा principle): आप इसे पढ़ते थे, आप numbers को source के against जाँचते थे, आप इस पर भरोसा करते थे क्योंकि आपने देखा था।
Worker आपके देखे बिना चलता है, अक्सर दिन में कई बार। "हर बार आपका इसे पढ़ना" scale नहीं करता, और यह उस पल को नहीं पकड़ता जब worker चुपचाप चीज़ें गलत करने लगता है। तो आपका check एक eval बन जाता है (evaluation का छोटा रूप): example inputs का एक save किया हुआ set जो अपने known-good answers के साथ जोड़ा गया हो। (ज़्यादा धुँधले काम के लिए, "known-good answer" एक label, एक rubric score, या एक checklist हो सकता है जिसे output को पूरा करना चाहिए, हमेशा एक perfect text block नहीं।) Worker के results को इनके against अपने आप grade किया जाता है, तो जाँच आपके बिना होती है और जिस पल worker drift करना शुरू करता है उसी पल यह आपको चेता देती है। आपका एक-बार का पढ़ना एक ऐसा test बन जाता है जो हमेशा चलता रहता है। इसे छोड़ दें, तो drift चुपचाप होती है: आप इसके बारे में किसी नाख़ुश customer से सुनते हैं, किसी check से नहीं।
इसे यहाँ सीखें: Eval-Driven Development.
Promotion 3 — आप loop से बाहर निकलते हैं, और exits design करते हैं
Mode 1 में आप loop में थे (छठा और सातवाँ principle): आप हर step देखते थे, जब वह भटकता तो उसे फिर से दिशा देते थे, आगे बढ़ने से पहले approve करते थे। आप ही safety net थे।
Worker steps ख़ुद चलाता है, बिना किसी के देखे। अब वह हिस्सा जो लोग गलत समझते हैं: routine आसान हिस्सा है, आपका Mode 1 method इसे पहले से संभाल लेता है। मुश्किल हिस्सा हैं edges: असामान्य input, वह case जिससे आपके method को कभी निपटना ही नहीं पड़ा। आपको पहले से तय करना होगा कि जब worker किसी ऐसी चीज़ से टकराए जिसे वह संभाल नहीं सकता, तो वह क्या करता है। लगभग हमेशा जवाब यही होता है: रुकें और किसी इंसान को बुलाएँ। उन exits को design करना (कब escalate करें, किसके पास करें, किस जानकारी के साथ करें) इस promotion का असली काम है, और यही वह काम है जो worker को भरोसे लायक और सुरक्षित बनाए रखता है। और हर task के edges होते हैं, यहाँ तक कि वे भी जो आसान लगते हैं: code लिखने वाला worker रुककर आपसे पूछता है जब उसका change tests तोड़ देता है; invoices pay करने वाला worker किसी तय रकम से ऊपर की हर चीज़ को pay करने के बजाय flag करता है; documents file करने वाला worker उस एक को, जिसे वह भरोसे से sort नहीं कर सकता, अनुमान लगाने के बजाय अलग रख देता है। Shape कभी नहीं बदलता: routine संभालें, exception escalate करें। इसे छोड़ दें, तो worker देर-सबेर उस एक case को संभाल ही लेगा जिसे उसे flag करना चाहिए था: पूरे आत्मविश्वास के साथ, और गलत।
इसे यहाँ सीखें: Build AI Agents और Building a Digital FTE.
Promotion 4 — आपका session runtime बन जाता है
Mode 1 में काम एक ऐसे session में रहता था जिसे आप खोलते थे। आप laptop बंद करते और वह existence में रहना बंद कर देता। अगली बार के लिए कुछ भी save करना (पाँचवाँ principle) यानी आप, हाथ से, चीज़ों को files में रखना।
Worker को तब भी existence में बने रहना होता है जब आप वहाँ नहीं होते। इसके लिए एक runtime चाहिए (ऐसा software जो worker को ज़िंदा और अपने आप चलता हुआ रखे) और रहने के लिए कोई जगह ताकि वह पहुँच में और भरोसेमंद रहे। इसकी memory ख़ुद-ब-ख़ुद बनी रहती है, इसलिए नहीं कि आपको इसे save करना याद रहा। इसे छोड़ दें, तो कोई worker है ही नहीं: सिर्फ़ आप, हाथ से एक session खोलते हुए, जो ठीक वही जगह है जहाँ से आपने शुरू किया था।
इसे यहाँ सीखें: Deploy the Agent Harness. (अगर worker सिर्फ़ आपके लिए है, तो एक हल्का रास्ता है; नीचे fork देखें।)
एक नज़र में चार promotions:
| Mode 1 में आपके पास क्या था | Mode 2 में यह क्या बन जाता है | कहाँ सीखें |
|---|---|---|
| आपका brief (किस पर काम / आख़िर में क्या चाहिए / कब done) | एक spec जिसे worker हर run पर पढ़ता है | Spec-Driven Development |
| आपकी अपनी eyeball check | एक eval जो worker को अपने आप grade करता है | Eval-Driven Development |
| आपका देखना और दिशा देना | worker loop चलाता है और edges पर escalate करता है | Build AI Agents · Building a Digital FTE |
| एक session जिसे आप खोलते और बंद करते हैं | एक runtime जिस पर worker रहता है | Deploy the Agent Harness |
यही पूरी crossing है। चार upgrades, हर एक वह चीज़ जिसे आप हाथ से करके पहले ही समझ चुके हैं।
चार promotions वही हैं जो cross करते समय बदलते हैं। एक अहम चीज़ ज़्यादा नहीं बदलती: आपके plugins, यानी वे skills (packaged know-how जिसे agent दोबारा इस्तेमाल करता है) और connectors (आपके दूसरे apps और data से links) जिन्हें आप Mode 1 में solve करते समय पहले से इस्तेमाल कर चुके हैं। चूँकि ये open, cross-runtime formats पर बने होते हैं, वही skills और connectors claude.ai, उन general agents (Claude Code, OpenCode, Cowork, OpenWork) जिन्हें आपने चलाया, और personal harnesses के पार चलते हैं, और अक्सर सिर्फ़ हल्के से adaptation के साथ, उन workers में भी जिन्हें आप manufacture करते हैं। जब तक कोई plugin उन open formats से जुड़ा रहता है, वह crossing के पार काफ़ी हद तक जैसा-का-तैसा आ जाता है: एक और वजह कि worker बनाना ज़्यादातर promotion है, invention नहीं। इनमें नए हैं? Skills & Connectors देखें।
यह क्यों काम करता है (इसके पीछे की research) — optional
दो पुराने विचार समझाते हैं कि "promote करें, scratch से न बनाएँ" सही क्रम क्यों है।
पहला Fred Brooks का है, जिन्होंने 1960 के दशक के सबसे बड़े software projects में से एक का नेतृत्व किया और इसके बारे में The Mythical Man-Month (1975) में लिखा। उनकी मशहूर सलाह: एक को फेंकने की योजना बनाएँ; आप फेंकेंगे ही, वैसे भी। आप जो पहली चीज़ बनाते हैं वह आपको सिखाती है कि आपको क्या बनाना चाहिए था; रखने लायक version दूसरा होता है, जो आपने जो सीखा उससे बनता है। आपके बार-बार दोहराए Mode 1 solves ठीक वही फेंकने-वाली चीज़ें हैं। आप automate करने से पहले हफ़्ते बरबाद नहीं कर रहे; आप वह experiment चला रहे हैं जो आपको बताता है कि permanent worker कैसा होना चाहिए। पहले हफ़्ते worker बनाने का मतलब होता वह version बनाना जिसे आप हमेशा से फेंकने ही वाले थे।
दूसरा Lisanne Bainbridge के Ironies of Automation (1983) से है, जो काम को automate करने पर सबसे ज़्यादा cite किए गए papers में से एक है। उनकी खोज: जब आप किसी job के routine हिस्सों को automate करते हैं, तो आप इंसान को हटाते नहीं; आप इंसान को ठीक उन्हीं दुर्लभ, कठिन cases के लिए ज़िम्मेदार छोड़ देते हैं जिन्हें automation संभाल नहीं सकता, और automation जितना ज़्यादा भरोसेमंद होता है, वे दुर्लभ हस्तक्षेप उतने ही ज़्यादा अहम (और कठिन) हो जाते हैं। यही ठीक वजह है कि Promotion 3 exits design करने के बारे में है, routine के बारे में नहीं। Routine automate करने का आसान हिस्सा है; value और ख़तरा दोनों edges पर रहते हैं, इसलिए आप escalation को जानबूझकर design करते हैं, यह उम्मीद करने के बजाय कि यह कभी आएगा ही नहीं।
Sources: Brooks, F. P. (1975). The Mythical Man-Month. Addison-Wesley. Bainbridge, L. (1983). "Ironies of Automation," Automatica, 19(6), 775–779.
Part 4 — Fork: इसे permanent बनाने के दो रास्ते
एक बार जब आप cross करने का फ़ैसला कर लेते हैं, "एक durable worker बनाएँ" दो अलग रास्तों में fork हो जाता है। वे वही चार promotions इस्तेमाल करते हैं, लेकिन अलग-अलग लोगों के लिए बने होते हैं, और यह फ़र्क मायने रखता है।
वही साबित किया हुआ solution, दो मंज़िलें। तय करने वाला सवाल यह है कि worker पर कौन निर्भर करता है।
Own it — एक personal harness. अगर worker आपके लिए है (आपका inbox, आपका code, आपके छोटे-मोटे काम) तो हल्का रास्ता एक personal harness है (ऐसा software जिसे आप ख़ुद चलाते और own करते हैं और जो आपके लिए एक worker को ज़िंदा रखता है)। आप चारों promotions करते हैं, लेकिन हल्के ढंग से: spec आपके अपने notes हैं, eval आपके अपने कुछ examples हैं, escalation यानी worker का आपको message करना। वहाँ पहुँचने के लिए शायद आपको कभी पूरे Mode 2 track की ज़रूरत ही न पड़े। यही वह रास्ता है जो Personal Agent Harnesses section सिखाता है, OpenClaw और Hermes का इस्तेमाल करते हुए।
Manufacture it — एक Digital FTE. अगर worker किसी organisation के लिए है (कुछ ऐसा जिस पर दूसरे लोग निर्भर करेंगे, जिसे reliably चलना होगा, governed होना होगा, और scale करना होगा, और शायद बेचा भी जाएगा) तो वह एक Digital FTE है (एक "digital full-time employee"), और आप चारों promotions कड़ाई से करते हैं: spec shared और reviewed होता है, eval एक ऐसा gate है जिस पर पूरी team भरोसा करती है, escalation किसी नामित इंसान या team के पास जाती है, और runtime असली production infrastructure है। यही पूरा Mode 2 — Manufacturing track है।
तय करने वाला सवाल एक line का है: worker किसके लिए है, और इस पर कौन निर्भर करता है? सिर्फ़ आपके लिए → personal harness। किसी organisation के लिए → Digital FTE। वही crossing, rigour की दो गहराइयाँ।
आप किससे बनाते हैं। दो रास्ते स्थिर हैं; tools variable हैं, और वे अक्सर बदलते हैं। 2026 में यह variable जैसा खड़ा है: आप रास्ता पहले ही चुन चुके हैं, तो आपको सिर्फ़ उसी column की ज़रूरत है जो उससे मेल खाता है:
| रास्ता | आप किससे बनाते हैं (2026) | कहाँ सीखें |
|---|---|---|
| Own it — एक personal harness | OpenClaw या Hermes: open-source harnesses जिन्हें आप ख़ुद चलाते और own करते हैं | Personal Agent Harnesses |
| Manufacture it — एक Digital FTE | OpenAI Agents SDK, या एक managed Claude agent setup | Mode 2 track; Choosing Agentic Architectures आपको चुनने में मदद करता है |
वह general agent जिसे आप Mode 1 में चला रहे थे (Claude Code, OpenCode, Cowork, या OpenWork) यहाँ ग़ायब नहीं होता; किसी भी रास्ते पर यह वही tool है जिससे आप worker को build और install करते हैं। बस यह हर बार task करने वाली चीज़ होना बंद कर देता है, और वह चीज़ बन जाता है जो task करने वाली चीज़ बनाती है।
एक चीज़ जिसके लिए budget रखें। एक durable worker API पर चलता है, जहाँ हर model call metered होती है और उसका पैसा लगता है, और यह दोनों रास्तों पर सच है: एक personal harness (OpenClaw, Hermes) उतना ही API पर चलता है जितना एक manufactured Digital FTE। यह claude.ai, web app, के अंदर AI इस्तेमाल करने से अलग है, जहाँ किसी plugin की calls आपके subscription या free tier से निकलती हैं, बिना किसी अलग per-call bill के। तो crossing "सोचने" को आपके plan में बँधी हुई चीज़ से एक असली, per-call लागत में बदल देती है। यह एक और वजह है कि "worth it?" signal मायने रखता है: एक worker को सिर्फ़ आपका build time ही नहीं चुकाना होता, बल्कि वह model bill भी जो वह हर बार काम करते वक़्त चढ़ाएगा। (एक personal harness के लिए वह bill आप ख़ुद भरते हैं; एक Digital FTE के लिए आप या organisation भरते हैं, और अगर आप worker को बेचते हैं, तो वही per-call लागत वह आँकड़ा है जिसके इर्द-गिर्द आप अपनी pricing रखते हैं।)
एक personal harness को own करना कोई नया mode नहीं है जो Mode 1 और Mode 2 के बीच बैठा हो; यह वही "एक durable worker बनाएँ" वाली activity है, घटाकर एक व्यक्ति तक। Mode पूछता है कि आप एक बार solve करते हैं या टिकने के लिए build करते हैं; ownership पूछता है कि worker आपका है या किसी organisation का। दो अलग सवाल। आप अपने own किए हुए harness पर कोई भी mode चला सकते हैं।
Ana का blueprint, भरा हुआ
अपना खुद का करने से पहले, यहाँ Ana का Monday task है, crossed: वही चार promotions, भरे हुए। "done" ऐसा दिखता है, और ध्यान दें कि हर line बस वही चीज़ है जो वह दो महीने से पहले ही हाथ से करती आ रही थी।
- Brief → spec. हर Monday, Support folder में आए नए messages पढ़ें। हर एक को ठीक एक group में रखें (complaint, question, order, या other) और एक one-page summary लिखें जिसमें हर group की count और तीन सबसे आम complaints हों। (उसकी Gate 3 की तीन lines, पक्के तौर पर लिख दी गईं।)
- Check → eval. बारह पुराने messages जिन्हें वह पहले ही हाथ से sort कर चुकी थी, हर एक अपने सही group के साथ save किया हुआ। जब भी वह worker के instructions बदलती है, उसे पहले उन बारह के against चलाया जाता है; अगर वह एक से ज़्यादा को गलत sort करता है, तो वह असली mail को छूने से पहले ही इसे ठीक कर देती है।
- You → exits. अगर कोई message ऐसी language में है जिसे worker संभाल नहीं सकता, या किसी ऐसे refund की माँग करता है जो उसकी तय की हुई limit से बड़ा है, तो worker अनुमान नहीं लगाता: वह message को flag करता है और Ana को ping करता है। बाक़ी सब वह अकेले संभालता है।
- Session → runtime. worker हर Monday सुबह एक छोटी always-on machine पर चलता है और इसका अपना list रखता है कि वह पहले से क्या process कर चुका है, तो Ana न कुछ खोलती है और न कुछ याद रखती है।
इसमें से कुछ भी crossing वाले दिन ईजाद नहीं हुआ। यह दो महीने के Mondays हैं, permanent बना दिए गए।
अब आपकी बारी
कोई असली task लें जिसे आप पहले से agent के साथ, उसी तरीके से, एक से ज़्यादा बार solve करते हैं। इसे crossing में से गुज़ारें, नीचे दिए तीन steps भरते हुए।
अपने खुद के task के लिए तीन steps भरें। Grader जाँचता है कि task सच में proven है या नहीं, आपके चारों promotions concrete हैं या नहीं, और, सबसे अहम, आपका exit एक असली escalation case है या एक छोड़ा हुआ edge।
Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.
अगर आप तीनों steps भर सकते हैं, तो आप "किसी दिन शायद एक agent बनाने के बारे में सोच" नहीं रहे। आप एक के लिए blueprint थामे हुए हैं। Mode 2 track बस चार promotions हैं, असल में किए हुए।
यह आपको कहाँ सौंपता है
यही crossing है। Mode 1 task के रूप में मेहनत था: आप हर बार घंटे खर्च करते थे। Mode 2 asset के रूप में मेहनत है: आप एक बार build करते हैं, और वह तब काम करता है जब आप सो रहे होते हैं। यह course वह जगह है जहाँ एक दूसरा बन जाता है।
अब आप Mode 2 — Manufacturing track में एक blueprint के साथ दाख़िल होते हैं, blank page के साथ नहीं। वहाँ का हर course चार promotions में से एक को असल में बनाता है:
- Python in the AI Era: वह language जिसमें manufacturing बनती है (आप direct करते हैं; agent इसका ज़्यादातर हिस्सा लिखता है)।
- Build AI Agents: वह worker जो loop चलाता है और escalate करता है।
- Eval-Driven Development: वह eval जो इसे grade करता है।
- Building a Digital FTE: चारों promotions को एक ऐसे worker में जोड़ा हुआ जिस पर कोई organisation भरोसा कर सके।
- Deploy the Agent Harness: वह runtime जिस पर यह रहता है।
एक साबित किए हुए Mode 1 solution और एक भरे हुए blueprint के साथ अंदर आइए, और आप शून्य से शुरू नहीं कर रहे। आप किसी ऐसी चीज़ को promote कर रहे हैं जो पहले से काम करती है।
References
इस course के दावों के पीछे के विचार, उन सबके लिए जो असल स्रोत चाहते हैं।
- Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. "एक को फेंकने की योजना बनाएँ" वाला तर्क (कि आपके साबित किए हुए Mode 1 solves ही वह prototype हैं जिनसे असली worker बनता है) इसी नाम के chapter में है। (overview)
- Bainbridge, L. (1983). "Ironies of Automation." Automatica, 19(6), 775–779. doi:10.1016/0005-1098(83)90046-8. routine को automate करना इंसान को दुर्लभ, कठिन cases के लिए ज़िम्मेदार क्यों छोड़ देता है (यही वजह है कि Promotion 3 exits design करने के बारे में है, routine के बारे में नहीं)। (readable summary)
- Munroe, R. "Is It Worth the Time?" xkcd 1205. task-बनाम-asset chart के पीछे का break-even logic: कोई task कितनी बार दोहराता है यह तय करता है कि worker बनाना worth है या नहीं।
Flashcards से पढ़ाई में मदद
समझ की जाँच
अभी-अभी जिन विचारों से आप गुज़रे, उन पर एक झटपट gated self-check।