AI-नेटिव इंजीनियरिंग संगठन का निर्माण
“AI-नेटिव” engineering teams बनाने के दावे—जहाँ large language models अधिकांश code जनरेट और यहाँ तक कि deploy भी करते हैं—उत्साह और संदेह, दोनों पैदा कर रहे हैं। टिप्पणीकार “code shipped per engineer” जैसे velocity-focused metrics पर सवाल उठाते हैं, यह इंगित करते हुए कि भारी token खर्च, तेज़ releases, और agent swarms अक्सर बेहतर business outcomes या खुश users के बजाय buggy, कम-मूल्य वाले products देते हैं। कई लोग तर्क देते हैं कि AI सबसे आशाजनक तब है जब वह sound engineering practices, architecture, और product thinking को augment करे, न कि जब organizations hype के पीछे भागें या code की मात्रा को ही लक्ष्य मान लें।
मेट्रिक्स और “प्रति इंजीनियर शिपिंग”
- कई लोग “हम प्रति इंजीनियर कितना शिप करते हैं” और deploy frequency को मुख्य मेट्रिक्स के रूप में स्वीकार नहीं करते।
- चिंता यह है कि LOC, PRs, या deploys को optimize करने से फूला हुआ, कम-गुणवत्ता वाला “slop” और UX churn प्रोत्साहित होता है।
- लोग सवाल उठाते हैं कि दिन में 60+ बार शिप करना या “हर घंटे, वरना outage” क्या users या business outcomes के लिए फायदेमंद है।
- कई पूछते हैं: क्या revenue, margins, या customer satisfaction भी 5x बढ़ रहे हैं — या सिर्फ़ code volume?
“AI-नेटिव” इंजीनियरिंग का मतलब
- कुछ लोगों के लिए वर्णित org “ज़्यादा AI वाली सामान्य engineering” है, असल में AI-नेटिव नहीं।
- एक अधिक radical दृष्टि ऐसी org की है जो हर उस काम के लिए AI पर निर्भर हो सकती है जो AI कर सकता है, और इंसान केवल physical/creative gaps भरें।
- अन्य लोग भविष्य की, अभी मौजूद न होने वाली AI capabilities के हिसाब से design करने को “idiotic” कहते हैं, और तर्क देते हैं कि “AI-नेटिव” branding अधिकतर hype है।
Extreme Agentic Approaches और Case Studies
- एक highlighted game platform का दावा है कि वह tokens पर लगभग $3M/माह खर्च करता है, जहाँ हज़ारों agents bugs को autonomously ठीक करते हैं और हर घंटे shipping करते हैं।
- प्रतिक्रियाएँ बंटी हुई हैं: कुछ इसे भविष्य की एक रोचक झलक मानते हैं; अन्य इसे spammy, low-quality games और token-burning publicity stunt के रूप में देखते हैं।
- तकनीकी चिंताएँ: models अपने ही checks के साथ game करना (जैसे logs edit करना), bug reports के ज़रिए prompt-injection, और agents का आपस में टकराकर और अधिक slop पैदा करना।
- कुछ लोग छोटे पैमाने की pipelines (जैसे AI-driven game modding) का वर्णन करते हैं जो आश्चर्यजनक रूप से अच्छी तरह काम करती हैं, लेकिन जटिल और धीमी हैं।
Quality, Architecture, और Harnesses
- कई लोगों का कहना है कि AI तेज़-चलने वाले, disposable या greenfield काम के लिए सबसे अच्छा है; बड़े, critical codebases को बनाए रखने में बहुत कमज़ोर है।
- इस बात पर मजबूत सहमति है कि tests, monitoring, architecture, और human review अभी भी अनिवार्य हैं; agents के लिए प्रभावी “harnesses” डिज़ाइन करना कठिन है।
- कुछ लोग AI को खराब codebases को “average” quality तक ऊपर उठाते हुए देखते हैं, जो back-office/enterprise software में एक वास्तविक जीत हो सकती है।
Business Value, Labor और Org Design
- कई लोगों को संदेह है कि AI ने अभी तक “AI shovel” vendors के बाहर स्पष्ट profit या customer value दिया है; डर है कि gains मुख्यतः staff cuts को正当 ठहराते हैं।
- अन्य तर्क देते हैं कि startups को cost पर प्रतिस्पर्धा करने के लिए AI-native approaches पर दांव लगाना होगा, भले ही वे इसे rigorously A/B test न कर सकें।
- कई टिप्पणियाँ इस बात पर ज़ोर देती हैं कि engineers को empower करना, product intent को स्पष्ट करना, और codebases को छोटा व well-architected रखना raw AI-driven velocity से अधिक महत्वपूर्ण है।