- कई AI agents (claude/o3/sonnet आदि) का उपयोग करके code generation से validation तक automation करने वाला एक personal "AI factory" workflow चलाया जा रहा है
- समस्या होने पर code (Output) को सीधे ठीक करने के बजाय plan, prompt, agent configuration जैसे input को बेहतर बनाकर automation का स्तर बढ़ाना इसका मुख्य सिद्धांत है
- इस तरह input को बार-बार बेहतर करने से agents लगातार विकसित होते हैं और दोहराए जाने वाले कामों की productivity अधिकतम होती है
- हर agent की भूमिका अलग: planning (o3/sonnet4), execution (sonnet3.7/4), validation (o3/sonnet4) आदि में बाँटकर parallel processing और automated feedback loop लागू किया जाता है
- code error या style issues को भी plan template में शामिल किया जाता है ताकि अगली generation से ही सुधार हो, और बार-बार input सुधारने से फैक्टरी खुद विकसित होती रहती है
AI फैक्टरी का अवलोकन और मुख्य सिद्धांत
- कई claude code विंडो को अलग-अलग git-worktree पर खोलकर अलग-अलग work environment बनाए रखे जाते हैं
- o3 और sonnet 4 का उपयोग plan बनाने के लिए, sonnet 3.7 या sonnet 4 का execution के लिए, और o3 का result evaluation के लिए किया जाता है
- planning, execution, validation को अलग-अलग agents में parallel बाँटकर efficiency बढ़ाई जाती है
मुख्य सिद्धांत – "Output को बदलने के बजाय Input को ही बेहतर बनाओ"
- समस्या आने पर generated code को सीधे patch नहीं किया जाता, बल्कि plan, prompt और agent mix ratio को समायोजित करके automated improvement हासिल की जाती है
- Factorio गेम की तरह, अपने-आप बढ़ने वाला factory-style AI agent network बनाने का यह concept है
- इस संरचना में planning-coding-validation-improvement का loop लगातार चलता रहता है, जिससे AI agents खुद code बनाते/validate/सुधारते हैं
दैनिक workflow – फैक्टरी की संरचना
- main interface claude code है, और local environment में mcp, Goose (Azure OpenAI model connection के लिए), o3 आदि का उपयोग होता है
चरण 1: Planning
- claude code में high-level task इनपुट → o3 अतिरिक्त सवाल पूछकर plan draft (
<task>-plan.md) बनाता है
- plan draft में मूल request और implementation plan शामिल होते हैं
चरण 2: Execution
- sonnet 4 plan की समीक्षा करके उसे task list में बदलता है
- claude code task को execute करता है, और task की complexity के अनुसार sonnet 3.7 या 4 का उपयोग करता है
- claude हर step पर commit history छोड़ता है, इसलिए समस्या आने पर rollback आसान होता है
चरण 3: Validation और Feedback
- sonnet 4 generated code को plan के अनुसार initial validation देता है
- इसके बाद o3 plan और शुरुआती requirements से तुलना करके अधिक सख्ती से validation करता है
- o3 अनावश्यक code (जैसे lint ignore flag) या पुराने ढाँचे को सख्ती से इंगित करता है
- validation में मिले मुद्दों को code में सीधे ठीक करने के बजाय plan template सुधार के रूप में शामिल किया जाता है
- git worktree का उपयोग कर कई claude code instances को parallel चलाया जाता है, जिससे एक साथ कई काम संभव होते हैं
"Input" "Output" से अधिक महत्वपूर्ण क्यों है
- Output को फेंका जा सकता है, लेकिन plan/prompt (input) लगातार जमा और बेहतर होने वाली एक संचित संपत्ति है
- input layer (plan, prompt) में debugging करने से उसका लाभ आगे के सभी कामों तक फैलता है
- इससे agents केवल generator नहीं रहते, बल्कि खुद सीखने और सहयोग करने वाले entities बन जाते हैं
- उदाहरण: पूरे CSV को memory में लोड करने वाले code को stream processing में बदलवाया गया, और बाद में उसी pattern को plan में शामिल कर दिया गया ताकि आगे सभी CSV tasks में automatic validation संभव हो सके
फैक्टरी का विस्तार और agent collaboration
- MCP के जरिए specialized agents को अलग-अलग कामों के लिए assign कर parallel चलाया जाता है
- उदाहरण: पूरे Clojure code को इकट्ठा करके local style rules लागू करने वाला dedicated agent चलाना, ताकि claude lint/test/debug cycle में बनने वाली style समस्याओं को ठीक कर सके
- internal library code में भी पुराने retry और
Thread/sleep उपयोग को अपनी retry library से बदलकर productivity और consistency बढ़ाई जाती है
- छोटे unit agents कई बनाए जाते हैं, जिन्हें अलग-अलग subtask के हिसाब से जोड़कर complex workflow भी automate किया जा सकता है
- उदाहरण: API spec और business case से agent combination के जरिए integration, testing, documentation तक automatic processing
- मुख्य बात: input को लगातार बदलते हुए बार-बार चलाना, और failure/stall/context gap होने पर अगली कोशिश में feedback शामिल करके सुधार करना
- code खुद एक consumable है, असली asset है instructions (input) और agent configuration
- failure, stall, context की कमी जैसी हर सीख को अगले input में शामिल करके factory loop पूरा किया जाता है
अगले चरण और भविष्य की दिशा
- agents के बीच overall coordination को और मजबूत कर पूरे workflow tracking और automation को बढ़ाने की योजना है
- business documents और agent information को बेहतर तरीके से जोड़कर, high-level abstraction information को केंद्र में रखकर अधिक प्रभावी उपयोग की दिशा में सुधार किया जा रहा है
- और अधिक जटिल workflows लागू करने की कोशिश है, और agents के बीच collaboration तथा complex interaction बढ़ाए जा रहे हैं
- कई providers की token quota का अधिकतम उपयोग करने और आसानी से switch करने के तरीके भी खोजे जा रहे हैं, खासकर bedrock sonnet 4 की token limit को ध्यान में रखते हुए
निष्कर्ष
- फिलहाल AI फैक्टरी में automatic code generation और validation रोजमर्रा की प्रक्रिया बन चुकी है, और एक कप कॉफी के दौरान भी code deploy हो सकता है
- अभी यह पूरी तरह automated stage में नहीं पहुँची है, लेकिन "Output सुधारने के बजाय Input सुधारना" इसका मूल सिद्धांत बन चुका है
1 टिप्पणियां
Hacker News राय
मुझे लगता है कि यह लेख उन लोगों के लिए लगभग समझना मुश्किल होगा जिन्होंने Claude Code के साथ वह 'aha' पल महसूस नहीं किया है
अगर आप
claude --dangerously-skip-permissionsसे permission restrictions हटा दें और उसे कोई जटिल समस्या सौंप दें, तो आप देख सकते हैं कि Claude तरह-तरह के tools का खुलकर इस्तेमाल करते हुए समस्या हल करता हैआज मैंने उससे Docker का इस्तेमाल करके 486 assembly में बना Mandelbrot fractal generator खुद compile, run और debug करवाया
इसने यह काम सचमुच बहुत शानदार तरीके से किया
gist लिंक
मुझे लगता है कि इस तरह का उदाहरण इन IDEs या LLMs के लिए काफी आसान है
assembly उनके training dataset में भी भरपूर है, और Docker भी
मैंने Cursor को भी अपने codebase में खुलकर घूमने दिया है
मुझे उम्मीद है कि नए tools किसी दिन सचमुच उस स्तर तक पहुंचेंगे, लेकिन अभी मुझे नहीं लगता कि हम वहां तक पहुंचे हैं
Dagger (और Docker के संस्थापक) की AI Engineer conference में दी गई यह वीडियो भी मैं अतिरिक्त रूप से recommend करना चाहूंगा
यह वीडियो भी कुछ लोगों को थोड़ा कठिन लग सकता है
शायद यह मददगार हो, इसलिए लिख रहा हूं
मैं Claude max से pro पर downgrade हो गया हूं और 20 डॉलर महीने में usage limits मेरे लिए काफी उदार हैं
लगता है कि Gemini CLI से competition है, इसलिए अब कम पैसे देने में खुशी है
मेरा मानना है कि इस स्तर के examples या context को लगभग सभी LLMs बिना किसी खास कठिनाई के संभाल सकते हैं
मैं इससे कहीं अधिक जटिल Rust dependency upgrades 30 से ज्यादा बार दोहरा चुका हूं, और custom wasm code के साथ उन्हें संभाला है
Claude context7 और mcp-lsp जैसे कई tools जोड़कर details इकट्ठा करता है
लेकिन इसे लगातार इस्तेमाल करते रहें तो आखिर इसकी limits सामने आ जाती हैं; जैसे-जैसे आप इसे और ज्यादा सटीक और कठिन काम की ओर धकेलते हैं, इसकी कमजोरियां दिखने लगती हैं
उस बात पर कि
claude --dangerously-skip-permissionsके साथ जटिल समस्या सौंपने पर यह कई tools इस्तेमाल करके समस्या हल करता हैमैंने Claude को एक घंटे से ज्यादा समय तक गलत तरीके से code ठीक करने की कोशिश करते देखा है
आखिर में मुझे खुद दखल देकर कहना पड़ा, "पहले unit tests लिखो, फिर tests pass होने पर code लिखकर वापस बताओ"
Claude Code सचमुच एक शानदार tool है, लेकिन हकीकत यह है कि आपको इसे बार-बार बुनियादी architecture map देते रहना पड़ता है
यह जाने बिना कि code का नतीजा वास्तव में कैसे इस्तेमाल होगा, ऐसे setups का आकलन करना मुश्किल है
अगर यह किसी personal vibe coding app के लिए है, तो ऐसी बातों पर यकीन करना आसान है,
लेकिन किसी जटिल production environment में high-quality code लिखने की बात आसानी से हजम नहीं होती
पूरी तरह सहमत
मैं Claude Code से अपनी coding speed काफी बढ़ा लेता हूं, लेकिन हर code change को मैं खुद हमेशा check करता हूं कि सबसे अच्छा system बन रहा है या नहीं
कुछ बार जब मैंने इसे बस चलने दिया, तो इसने users तक bugs पहुंचाए
सच कहूं तो इस लेख में बताए गए workflow या concepts मुझे ठीक से समझ नहीं आ रहे
शायद इसलिए कि समझाना थोड़ा vague है
मैं रोजमर्रा में ऐसे setups इस्तेमाल करता हूं जहां कई agents आपस में बात करते हैं, asynchronous agents होते हैं, git work tree जैसी चीजें होती हैं, और इनके जरिए complex production systems संभालता हूं
मैं outputs को कभी भी अछूता नहीं छोड़ता, लेकिन जब मनचाहा नतीजा नहीं मिलता तो उसे अपने workflow को बेहतर करने का signal मानता हूं
मैं भी ऐसा ही workflow आजमा रहा हूं, इसलिए अपना अनुभव साझा करना चाहता हूं
जिस Go codebase पर मैं काम करता हूं वह कई लाख lines का है, और उसे वास्तव में दसियों हजार से लेकर लाखों B2C users इस्तेमाल करते हैं
performance में काफी headroom है, लेकिन accuracy और reliability finance domain में बेहद अहम हैं
मैं OpenAI key-only environment में हूं, इसलिए codex-cli और कुछ साधारण scripts से ही repo cloning, agent setup, prompt execution जैसी basic setup चीजें करता हूं
codex instances system notifications से मेरी बारी बताते हैं, और जरूरत पड़ने पर मैं fzf की मदद से tmux sessions से attach हो जाता हूं
मैंने अभी MCP नहीं आजमाया है, लेकिन वह मेरी interest list में है
इस तरह का setup छोटे बिखरे हुए tasks संभालने में बहुत मददगार है, और अब मैं पहले से कहीं ज्यादा छोटे-छोटे PRs बना पा रहा हूं
"cattle not pets" रूपक यहां अब भी लागू होता है; छोटे कामों के लिए मैं बस जल्दी से prompt फेंक देता हूं ताकि distraction कम हो
बड़े कामों पर यह अभी उतना फिट नहीं बैठता, शायद इसलिए कि मैं भी पर्याप्त context flywheel नहीं बना पाया हूं
अधिकतर मामलों में मैं result code हमेशा खुद पढ़ता और सुधारता हूं, फिर उसे code review के लिए डालता हूं
change management भी लगभग पूरी तरह manual है; branch, commit, push सब मैं खुद करता हूं
कुछ automation tools भी आजमाए हैं, लेकिन पूरी तरह उन पर नहीं गया हूं
"output नहीं, input ठीक करो" वाली सोच से मैं 100% सहमत हूं
AI के बिना भी यह एक बेहद ताकतवर सिद्धांत है, और industry भी धीरे-धीरे इसे ज्यादा अपना रही है
LLM जैसे non-deterministic process में इसे लागू करना आसान नहीं है, और यह science से ज्यादा practice जैसा लगता है
अच्छे लेख के लिए धन्यवाद
मैंने "Vibe Specs" नाम के लेख में एक मिलते-जुलते लेकिन थोड़ा सरल workflow का परिचय दिया है
संबंधित ब्लॉग निबंध
मैं पूरे codebase में यह rule इस्तेमाल करता हूं, और AI को दो चीजें अलग तरीके से करने देता हूं
(1) सबसे पहले सवाल पूछो
(2) coding शुरू करने से पहले
spec.mddocument बनाओथीम मिलती-जुलती है, लेकिन मैं सिर्फ एक LLM तक सीमित रहता हूं
लगता है हममें से ज्यादातर लोग इसे मिलते-जुलते तरीके से आजमा रहे हैं
मैं एक solo developer हूं, इसलिए engineering-केंद्रित सोच के साथ तरह-तरह की production automation पर प्रयोग करता हूं
मेरे लिए अंतिम लक्ष्य यह है कि agent implementation से अलग, auto-generated e2e tests के जरिए code पर भरोसा दिलाए
मैं अभी तक इसमें पूरी तरह सफल नहीं हुआ हूं
अब Claude Code भी “plan mode” के जरिए इस तरह के flow को natively support करता है
.mdfiles manually बनाना सच में धीमा और झंझट वाला लगता हैमूल विचार यह है कि आप लगातार documentation कर सकते हैं कि system को क्या करना चाहिए (high level और detailed features दोनों), उसे कैसे prove करना है, और architecture तथा code style जैसी implementation approach क्या होनी चाहिए
कई models इस्तेमाल करने का कारण bias कम करना और खास tasks के लिए fine-tuning विकल्प बढ़ाना है
किसी दिन बड़े और जटिल systems को requirements sets के आधार पर दोबारा बनाया जा सकेगा, और तभी software वास्तव में requirements spec से मेल खाएगा
तब बचा हुआ ‘legacy code’ दरअसल सिर्फ legacy spec documents होंगे
नज़रिया यह है कि generated code नहीं, requirements spec को ठीक करो
संबंधित meme image
मैं सच में जानना चाहता हूं कि आखिर लोग बना क्या रहे हैं
जब भी AI workflows की बात होती है, समझना मुश्किल होता है कि लोग आधा सपना बेच रहे हैं या सच में productive तरीके से इसका इस्तेमाल कर रहे हैं
अगर LLM सारा code लिख दे, तो मेरी दिलचस्पी ही खत्म हो जाती है
करीब 50 projects में से सिर्फ 2 मैंने LLM से बनाए हैं, और उनमें भी मैंने खुद बदलाव किए
बाकी में बस यह लगा कि “कुछ होना अच्छा होगा”, लेकिन असल में नतीजे में मेरी खास रुचि नहीं थी
आखिरकार आप कई models और implementation details से जूझते रहते हैं, और जब मनचाहा behavior नहीं निकलता तो design docs, prompts, example data सब फेंककर computer से लड़ते रहते हैं
सिर्फ code completion या छोटे-छोटे input augmentation वाली शैली कहीं ज्यादा तेज और कम तनावपूर्ण है
पीछे मुड़कर देखूं तो लगता है कि समय और पैसा तो बहुत गया, और बदले में बस किसी तरह चलने वाला software मिला
अगर स्पष्ट requirements हों या मौजूदा codebase हो, और मैं सक्रिय रूप से guide करूं, तो agents काफी मदद करते हैं; लेकिन vibe coding जैसा flow छोटे scripts या niche apps के अलावा न तो मजेदार है, न मनचाही quality देता है
यह जरूरत से ज्यादा महंगा भी है और code अब भी messy रहता है
आखिर में ऐसा लगता है जैसे computer से अंतहीन बहस में समय बर्बाद कर रहा हूं
इससे तो बेहतर है कि मैं खुद ही कर लूं
जब कई agents अपने-अपने work tree में काम करते हैं, तो समस्या यह आती है कि हर agent हर detail में बिल्कुल अलग ideas लेकर आता है, इसलिए user experience में कोई consistency नहीं रहती
मसलन Documents dashboard और Design dashboard बनाने वाले agents उन्हें बिल्कुल अलग नजरिए से design करते हैं
design consistency, structure, DB schema, API design — किसी में एकरूपता नहीं होती
input एक ही हो, तब भी output अलग आता है
आखिर consistency बनाए रखने के लिए आप instruction files बढ़ाते जाते हैं, और बड़े projects में वे हजारों lines की हो जाती हैं, जिससे context window भी कम पड़ जाती है
नतीजतन मुझे लगता है कि ऐसे में वही बेहतर है कि एक छोटा LLM इस्तेमाल किया जाए जिसे कुछ खास rules और schemas पर train किया गया हो
prompts के जरिए ब्रह्मांड जितने विशाल ideas संभालने वाले बड़े LLMs की तुलना में छोटा LLM ज्यादा सही जवाब लगता है
हर agent का बिल्कुल अलग output, design में consistency नहीं
आखिर में एक senior की जरूरत पड़ती ही है
चाहे AI हो या इंसान, आपको खुद ही कम से कम इतना structure और flexibility देनी पड़ती है कि चीजें मनचाही दिशा में चलें
अगर structure नहीं है, तो सीधे खुद coding करना कहीं बेहतर है
मैंने पहला version खुद बनाया, फिर बाद के कामों में Claude Code से कहा, "इसी example की तरह बनाओ", तो consistency बनाए रखना आसान हो गया
ADHD-style coding, यानी बस यूं ही product generate करने की कोशिश करते रहना और fit होने तक दोहराते रहना?
क्या इससे बेहतर नहीं कि सीधे खुद future-extensible code लिखा जाए?
कम से कम सिर्फ carbon footprint बढ़ाने के लिए तो यह न किया जाए
अंतिम लक्ष्य तो developer को इस process से बाहर करना है
business owner नया CRUD app मांगे और वह सीधे production में deploy हो जाए
बेशक नतीजा bugs से भरा होगा, slow होगा, और unauthenticated DB में store करेगा, लेकिन वह मेरी समस्या नहीं — ऐसी सोच
अंत में वह गरम चाय एक ही घूंट में पी जाने वाली उग्र अभिव्यक्ति के साथ खत्म करता है
programming हमेशा के लिए बदल चुकी है, और इस बदलाव को जल्दी स्वीकार करना होगा
“बस code खुद लिखो” कहना ऐसा है जैसे कोई कहे कि हम सब अपनी-अपनी घोड़ागाड़ी खुद ही दुरुस्त करें
कारें भी खराब होती हैं, इसलिए पुराने तरीके पर लौट चलो — बात लगभग वैसी ही है
मुझे समझ नहीं आता कि हर बार ‘future-extensible code खुद लिखो’ वाली बात क्यों सामने आती है
आज के coding assistants भी zero-shot में extensible और maintainable code लिख सकते हैं; मैं पूछना चाहूंगा कि क्या लोगों ने सच में ऐसा कहकर उनसे लिखवाने की कोशिश की है?
इंसान भी आखिरकार trial and error के जरिए ही जवाब तक पहुंचता है
फर्क बस इतना है कि अनुभव बढ़ने पर दिमाग के भीतर simulation ज्यादा हो जाती है
अगर carbon footprint को मुद्दा बनाना है, तो क्या AI data centers renewable energy पर चलें तो वह स्वीकार्य होगा?
मुझे लगता है कि AI को workflow में और प्रभावी ढंग से integrate करने का तरीका खोजना होगा
जिन लोगों ने AI को सक्रिय रूप से अपनाया है, वे शायद इसी तरह की समस्याओं से गुजरे होंगे, लेकिन अभी तक कोई पक्का समाधान नहीं दिखता
इस चरण में मुझे लगता है कि AI को बहुत सीमित लेकिन साफ-साफ defined role देना सबसे अहम है
उदाहरण के लिए, stock research में इस्तेमाल होने वाले agent workflow के लिए ‘Bullish Guy’ और ‘Bearish Guy’ नाम के दो AI बनाए जाएं, जो एक ही stock पर फायदे और नुकसान पर बहस करें
जब आप उन्हें एक-दूसरे के उलट रुख से research करवाते हैं, तो analysis ज्यादा व्यापक और गहरा निकलता है
यह idea दरअसल social media पर होने वाली बहसों को देखकर आया
vibe-coding में output अक्सर self-referential बातों से आगे बढ़ता नहीं दिखता, और अंततः यह 3D printing की तरह एक महंगा hobby बन जाता है — अंतहीन खिलौने बनाते रहने जैसा
आजकल vibe coding का “benchy” शायद todo app ही है, क्या ऐसा नहीं?
जो लोग products design या engineering करते हैं, वे सब इसका इस्तेमाल करते हैं
आम consumers इसका उपयोग इसलिए नहीं करते क्योंकि उन्हें चाहिए लगभग हर plastic item वे Amazon से तुरंत मंगा सकते हैं
अगर online shopping न होती, तो यह औसत व्यक्ति के लिए कहीं ज्यादा उपयोगी होती
आने वाले समय में शायद यह सचमुच उन्हीं लोगों के लिए जरूरी तकनीक रह जाएगी जो custom files खुद design कर सकते हैं