- StrongDM AI टीम ने कोड देखे बिना भी high-quality software बनाने वाली Software Factory की अवधारणा पेश की
- specs/scenarios के आधार पर agent कोड लिखते हैं, test harness चलाते हैं, और मानव review के बिना converge करने वाली non-interactive development पद्धति अपनाते हैं
- कोड इंसानों द्वारा लिखा या review नहीं किया जाना चाहिए, और Software Factory को सही तरह से चलाने के लिए प्रति engineer प्रतिदिन कम से कम $1,000 से अधिक token cost खर्च होनी चाहिए
- Claude 3.5 के दूसरे revised edition (अक्टूबर 2024) से long-running agent coding workflows ने error accumulation के बजाय accuracy को compounding तरीके से जमा करना शुरू किया, जिससे non-interactive development की संभावना की पुष्टि हुई
- पारंपरिक test अवधारणा का विस्तार करते हुए scenario और satisfaction को शामिल किया गया, ताकि LLM उपयोगकर्ता संतुष्टि का probabilistic आकलन कर सके
- Digital Twin Universe(DTU) के जरिए Okta, Jira, Slack जैसे प्रमुख SaaS की प्रतिकृतियाँ बनाकर बड़े पैमाने पर verification किया जाता है, जिससे production limits से भी अधिक volume और speed पर scenario validation संभव होता है
- agent युग software economics को मूल रूप से बदल रहा है, और जो high-fidelity SaaS clone बनाना पहले आर्थिक रूप से असंभव था, वह अब रोज़मर्रा का काम बन रहा है
Software Factory की अवधारणा
- specs और scenarios agent को चलाते हैं, जो कोड लिखते और verify करते हैं; यह एक non-interactive development system है
- मानव द्वारा code writing और review पर रोक, और पूरा development process agents द्वारा संचालित
- efficiency का आकलन प्रति engineer प्रतिदिन $1,000+ token usage के आधार पर
- इस approach का लक्ष्य ऐसा autonomous software production environment बनाना है, जहाँ बिना मानव हस्तक्षेप के कोड अपने आप generate, verify और converge हो
StrongDM AI टीम की शुरुआत
- 14 जुलाई 2025 को StrongDM AI टीम बनाई गई और non-interactive development के प्रयोग शुरू हुए
- प्रतिभागी: Jay Taylor, Navan Chauhan, Justin McCarthy(co-founder और CTO)
- 2024 के अंत में Claude 3.5 (अक्टूबर revision) के बाद long-term coding accuracy में सुधार हुआ, जिससे बार-बार error accumulation के बजाय compounding correctness संभव हुई
- Cursor का YOLO mode model की long-form coding क्षमता को स्पष्ट रूप से दिखाता है
- पहले के models में coding tasks पर LLM को बार-बार लागू करने से misunderstanding, hallucination, syntax error, version DRY violation, library incompatibility जैसी हर तरह की गलतियाँ जमा होती जाती थीं और app "ढह" जाता था
- Anthropic के updated model और YOLO mode के संयोजन से non-interactive development या grown software की पहली संभावना दिखी
मुख्य सिद्धांत: हाथ हटाओ
- AI टीम के पहले दिन के पहले घंटे में एक charter बनाया गया, और सबसे महत्वपूर्ण सिद्धांत था: "कोड इंसान सीधे नहीं लिखेंगे"
- शुरुआत में यह केवल एक सीधा intuition और experiment था: बिना हाथ से code लिखे कितनी दूर तक जाया जा सकता है?
- पहले सीमाएँ सामने आईं, फिर tests जोड़ने के बाद प्रगति शुरू हुई
- agents तत्काल task पर अटक जाते हैं और shortcuts चुनते हैं: return true जैसी संकरी तरह से लिखी गई tests पास हो जाती हैं, लेकिन वह वास्तव में वांछित software तक generalize नहीं करतीं
- केवल simple tests काफी नहीं हैं; integration test, regression test, end-to-end test और behavior test तक विस्तार ज़रूरी है
test से scenario और satisfaction की ओर बदलाव
- agent युग का एक recurring theme है: नई भाषा की ज़रूरत, क्योंकि "test" शब्द पर्याप्त नहीं और अस्पष्ट है
- codebase में stored tests को code के मुताबिक आलस में फिर से लिखा जा सकता है, या code को ऐसे बदला जा सकता है कि वह tests को तुच्छ तरीके से पास कर दे
- scenario शब्द को फिर से परिभाषित किया गया: यह end-to-end user story को दर्शाता है, codebase के बाहर store किया जाता है (model training के "holdout" set की तरह), और LLM इसे सहज रूप से समझकर लचीले ढंग से verify कर सकता है
- क्योंकि जो software grow किया जा रहा है उसमें खुद agent components शामिल होते हैं, इसलिए सफलता को सिर्फ boolean value से नहीं बल्कि probabilistic और experiential satisfaction में बदला गया
- satisfaction: उन observed trajectories का अनुपात जो सभी scenarios पास करने के बाद उपयोगकर्ता को संतुष्ट करने की संभावना रखते हैं
Digital Twin Universe के जरिए scenario validation
- पहले की व्यवस्था में integration test, regression test और UI automation के आधार पर "क्या यह काम करता है?" तय किया जाता था
- पहले भरोसेमंद मानी जाने वाली techniques की दो सीमाएँ मिलीं:
- tests बहुत rigid हैं: क्योंकि coding agents के साथ की जाती है और LLM/agent loop को design primitive की तरह बनाया जाता है, इसलिए success evaluation में अक्सर LLM-as-judge की ज़रूरत पड़ती है
- tests reward hacking के प्रति संवेदनशील हैं: ऐसे validation की ज़रूरत है जो model की cheating के प्रति कम संवेदनशील हो
- Digital Twin Universe(DTU) इसका उत्तर है: software जिन third-party services पर निर्भर है, उनके behavioral clones
- Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets के twins बनाए गए, जिनमें API, edge cases और observable behavior की नकल की गई
- DTU के जरिए production limits से बहुत अधिक volume और speed पर verification संभव है
- live services पर जो failure modes जोखिमभरे या असंभव होते, उनकी testing भी संभव है
- rate limit hit किए बिना, abuse detection trigger किए बिना, और API cost जमा किए बिना प्रति घंटे हज़ारों scenarios चलाए जा सकते हैं
गैर-पारंपरिक economics
- DTU के जरिए मिली सफलता दिखाती है कि agentic moment software economics को मूल रूप से बदल रहा है
- प्रमुख SaaS applications के high-fidelity clones बनाना हमेशा संभव था, लेकिन आर्थिक रूप से व्यावहारिक नहीं था
- कई पीढ़ियों के engineers test के लिए CRM का पूरा in-memory replica चाहते थे, लेकिन manager को यह प्रस्ताव तक नहीं देते थे (क्योंकि इनकार तय था)
- Software Factory बनाने वालों को deliberate naivete का अभ्यास करना चाहिए: Software 1.0 की आदतों, conventions और constraints को पहचानकर हटाना
- DTU के जरिए जो 6 महीने पहले अकल्पनीय था, वह अब routine daily work बन चुका है
आगे पढ़ने लायक चीज़ें
- Principles : agents का उपयोग करके software development पर हमारे विश्वास
- seed → validation harness → feedback loop संरचना के ज़रिए software को grow किया जाता है, और tokens fuel की तरह काम करते हैं
- हर software को एक शुरुआती seed चाहिए: पहले के PRD या spec, और अब कुछ वाक्य, screenshots, या existing codebase भी पर्याप्त हो सकते हैं
- validation harness end-to-end होना चाहिए और वास्तविक environment(ग्राहक, integrations, economics) के जितना संभव हो उतना करीब होना चाहिए
- output samples को input के रूप में feedback करने वाला closed loop system को self-correction और compounding correctness संभव बनाता है
- validation और feedback का सिद्धांत समझना आसान है, लेकिन practical execution के लिए creative और cutting-edge engineering चाहिए: हर obstacle को ऐसे representation में बदलना जिसे model समझ सके
- Techniques : इन principles को लागू करने के लिए recurring patterns
- Digital Twin Universe (DTU)
- महत्वपूर्ण third-party dependencies के externally observable behavior की नकल
- production limits से बहुत अधिक volume और speed पर verification
- deterministic और reproducible test conditions उपलब्ध कराना
- Gene Transfusion
- agents को ठोस उदाहरणों पर anchor करके codebase के बीच working patterns का transfer
- अच्छे references के साथ जोड़े गए solutions को नए context में reproduce करना
- Filesystem
- model repository को तेज़ी से navigate करे और file read/write के ज़रिए अपना context खुद समायोजित करे
- directories, indexes और on-disk state practical memory substrate की तरह काम करें
- Shift Work
- interactive work और fully specified work को अलग करना
- जब intent complete हो(specs, tests, existing app), agent बिना back-and-forth के end-to-end execute कर सकता है
- Semport
- semantically aware automated porting, one-off या continuous दोनों रूप में
- intent को बनाए रखते हुए language या framework के बीच code को स्थानांतरित करना
- Pyramid Summaries
- कई zoom levels पर reversible summaries
- context को compress करना, बिना पूरे details में वापस expand करने की क्षमता खोए
- Products : वे tools जिन्हें हम हर दिन इस्तेमाल करते हैं और जिन्हें हम दूसरों के लिए भी उपयोगी मानते हैं
- CXDB AI agents के लिए self-hosted context store है, जो Turn DAG, blob deduplication, dynamic types और visual debugging देता है
- StrongDM ID इंसानों, workloads और AI agents के लिए identity system है, जो federated auth और path-scoped sharing को support करता है
- Attractor phase graph में संरचित non-interactive coding agent है, जो task पूरी तरह specified होने पर end-to-end execution करता है
अभी कोई टिप्पणी नहीं है.