- 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 करता है
3 टिप्पणियां
मैंने spec-driven development को multi-agent के साथ करके देखा। यह सच है कि यह काम काफ़ी कम कर देता है, लेकिन LLM की performance limits की वजह से ग्राहक को संतुष्ट करने वाला product नहीं बनाया जा सकता। 100% replacement संभव नहीं है और कुछ हद तक इंसानी काम की ज़रूरत रहती है।
काफ़ी उकसाने वाला है, लेकिन कुछ हद तक बात समझ में भी आती है.. पता नहीं, यह ऐसा लेख है जो अजीब-सा एहसास कराता है.
इस लेख को देखकर नीचे वाला लेख पढ़ें तो और ज़्यादा सहमति महसूस होती है.
हमारी कारीगर भावना के लिए शोक
Hacker News टिप्पणियाँ
मुझे Digital Twin Universe की अवधारणा समझ में आती है
मेरे codebase में भी बाहरी services के बहुत सारे integrations हैं, इसलिए testing के समय external calls को रोक दें तो लगभग कुछ भी verify नहीं हो पाता था
इसलिए मैंने Okta, Jira, Slack, Google Docs जैसी APIs के लिए fake implementations बनाकर test किया
लेकिन UI तक replicate नहीं किया, सिर्फ API behavior की नकल की
“अगर आप प्रति engineer प्रति दिन $1,000 के tokens नहीं जला रहे हैं, तो सुधार की गुंजाइश है” वाली बात बहुत अवास्तविक लगती है
यह सचमुच गंभीर दावा है या नहीं, इस पर शक होता है
हिसाब लगाएँ तो यह सालाना लगभग $250k बैठता है
अगर AI उतनी productivity दे सके तो यह तर्कसंगत हो सकता है
व्यावहारिक रूप से देखें तो यह शायद दो junior engineers जितनी efficiency होगी
आखिरकार इंसान सिर्फ lead role में planning और verification ही करेंगे, ऐसा लगता है
यह बढ़ा-चढ़ाकर किया गया optimism है, लेकिन पूरी तरह पागलपन भी नहीं
मैं तो सिर्फ $20/महीने वाले Claude और OpenAI subscriptions इस्तेमाल करता हूँ
tokens खत्म हो जाएँ तो टहलने निकल जाता हूँ या किताब पढ़ता हूँ
मैं accelerationist नहीं हूँ, फिर भी काम ठीक-ठाक हो जाता है
मैं StrongDM टीम का एक सदस्य हूँ
प्रति दिन $1,000 के tokens खर्च करना आसान है, लेकिन उन्हें उत्पादक ढंग से खर्च करना मुश्किल है — असली बात यही है
यह बस सीधा-सीधा दिखावा लगता है
जैसे कहना हो, “हम तुमसे ज़्यादा AI में आगे हैं”
यह पढ़ते हुए मुझे संकोच महसूस हुआ
लगा जैसे पुराने mocks और simulation tests को “innovation” की तरह पैक कर दिया गया हो
फिर भी इन्होंने अपनी cost structure ईमानदारी से बताई, इसके लिए श्रेय देना चाहिए
मैं उनकी site पर असली code या product ढूँढ रहा था
मुझे सिर्फ strongdm/attractor मिला
अब “Canadian girlfriend coding” ही business model बन गया है
इसके अलावा strongdm/cxdb भी मिला, लेकिन उसका commit history साफ़-सुथरा किया गया था
cxdb repository में असली code है
पता नहीं यह पागलपन है या भविष्य की एक झलक
Products page पर database और ID systems भी हैं
कई agents को साथ काम करना है तो shared context और permissions system अनिवार्य हैं
मैंने BoundaryML के BAML पर एक webinar सुना था
Spec-driven development ऐसा तरीका है जिसमें human-in-the-loop के साथ structured workflow बनाए जाते हैं
/research → /plan → /implementloop को साफ़-साफ़ define किया जाता है, और हर चरण पर human verification होती हैयह StrongDM के “इंसान code न लिखते हैं, न पढ़ते हैं” वाले दावे के ठीक उलट दर्शन है
यह भी एक और खोखली blog post जैसी लगती है
कोई ठोस नतीजा नहीं दिखता, और $1,000/दिन token वाली बात investor appeal के लिए लगती है
अगर verification problem हल नहीं हुई, तो यह सब बस दिखावा है
automated reviews या guardrails लगा लें, फिर भी specification और result के मेल को जाँचने वाला आखिर इंसान ही होगा
हम Speedscale में traffic capture और replay के ज़रिए verification automate कर रहे हैं
सच कहें तो इंसानी development भी परफेक्ट नहीं है
code review, tests, QA जैसी कई systematic verification processes पहले से मौजूद हैं
अहम सवाल यह नहीं कि AI परफेक्ट है या नहीं, बल्कि यह है कि पूरे system की quality converge करती है या नहीं
मेरे अनुभव में Opus 4.5 के हिसाब से थोड़ा-बहुत net positive effect है
मैं भी लगभग सहमत हूँ
असली मुद्दा generation नहीं, verification है
मैं ऐसा ढाँचा बना रहा हूँ जिसमें कई independent agents मतभेद सामने रखते हुए सहमति तक पहुँचें
सीधी बात यह है कि verification और security testing को end users पर थोप दिया जाता है
specification-based languages और formal verification का ज़्यादा सक्रिय इस्तेमाल होना चाहिए
आखिरकार programming को “specification को concrete बनाना” के रूप में फिर से परिभाषित किया जाएगा
अगर tokens पर $1,000/दिन लग रहा है, तो मतलब AI पर इंसानों से ज़्यादा पैसा खर्च हो रहा है
यह AI vision के ढहने का बिंदु लगता है
कहा गया कि Simon Willison ने पोस्ट update की है
सालाना $240k तो entry-level FANG engineer के बराबर है
ईमानदारी से कहूँ तो Claude से भी कमज़ोर junior बहुत हैं
अंत में चीज़ें शायद ऊपर कुछ इंसानों वाली pyramid structure में फिर से व्यवस्थित होंगी
अगर वही काम 5 दिन में पूरा हो जाए, तो speed के हिसाब से cost तर्कसंगत हो सकती है
अगर output अनुपात में बढ़ता है, तो cost efficiency ठीक बैठ सकती है
ऊपर से token pricing आगे चलकर गिर भी सकती है
कानूनी और insurance industry इस बदलाव में सबसे ज़्यादा जूझेंगी
इंसानी गलतियाँ model की जा सकती हैं, लेकिन autonomous loops की chain errors बिल्कुल अलग समस्या हैं
AI के फ़ैसलों की ज़िम्मेदारी आखिरकार इंसानों पर ही आएगी
शायद यही पूरे agentic shift पर ब्रेक का काम करेगा
$1,000/दिन tokens वाला metric पूरी तरह बेतुका है
अगर code quality खराब हो, तो token consumption बहुत तेज़ी से बढ़ती है
आखिरकार बेतरतीब codebase ही cost बढ़ाता है
जो टीम रोज़ एक हज़ार डॉलर जला रही है, वह शायद लगभग अक्षम ही होगी
(संदर्भ: यह meme)
यह short-term बनाम long-term optimization का सवाल है
अभी efficiency बढ़ानी है या पूरे system को सुधारना है, यही चुनाव है
शायद अब management को refactoring की अहमियत समझ आए
मैंने पहले जिस Dark Factory pattern का ज़िक्र किया था, यही वही टीम है
मैंने इस पर एक पोस्ट लिखी थी, और यह टीम सबसे महत्वाकांक्षी प्रयोगकर्ताओं में से है
लेकिन हकीकत में नतीजे लगभग नहीं हैं
कुछ college students को $10k दे दें तो शायद वे इससे बेहतर बना दें
$1,000/दिन tokens? मेरी टीम के budget में तो यह कल्पना से बाहर है
निजी तौर पर भी living expenses की वजह से यह असंभव है
कुल मिलाकर एहसास यही है: “करो तो भी गए, न करो तो भी गए”
verify किया जा सकने वाला output न हो, तो यह सिर्फ बातें हैं
और अब बातें करना भी LLM की वजह से बहुत सस्ता हो गया है
ethical disclosure की ज़रूरत है
site की terminology पुरानी अवधारणाओं की नई packaging भर है
“Digital Twin Universe” यानी mocks, “Gene Transfusion” यानी reference code पढ़ना, “Semport” यानी transpiling
असली data या benchmarks बिल्कुल नहीं हैं
यह AI marketing को engineering insight की तरह पैक करने का मामला है
दरअसल ज़्यादातर core code पहले से GitHub पर है
असली अंतर mechanism design और values में है
भविष्य formal methods और AI के मेल की तरफ़ जाएगा
“scenarios को holdout set की तरह रखकर test करना” वाला तरीका दिलचस्प है
यह QA team की आक्रामक testing की नकल जैसा विचार है
build team और bug-finding team को अलग रखकर आपसी प्रतिस्पर्धा वाली संरचना बनाना प्रभावशाली लगा
लेकिन $1,000/दिन tokens open source developers के लिए निराशाजनक हैं
local models इस्तेमाल करें तो cost घटाई जा सकती है
इस thread की तरह local agent automation भी पूरी तरह संभव है
शायद किसी दिन agents आपस में रिश्वत भी देने लगें
मैं अब भी human-in-the-loop तरीका ही पसंद करता हूँ
यूँ ही tokens जलाना बर्बादी है
मैंने “LLMs aren’t tools” पोस्ट में LLM के उपयोग के मानसिक ढाँचे पर विचार किया था
“software factory” आज की मौजूदा मंज़िल हो सकती है, लेकिन अगला चरण LLM को एक application की तरह देखने का है
यानी सिर्फ workflow automation नहीं, बल्कि custom harnesses बनाने का चरण